Your SlideShare is downloading. ×
0
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Incomplete by Design — Thoughts on Agile Architectures
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Incomplete by Design — Thoughts on Agile Architectures

1,479

Published on

Traditionally, once the analysis phase is finished and the implementation progresses, a strong resistance against further changes emerge, due to the mismatch between specification and implementation …

Traditionally, once the analysis phase is finished and the implementation progresses, a strong resistance against further changes emerge, due to the mismatch between specification and implementation artifacts. Nonetheless, some domains do rely on constant adaptation of their processes to an evolving reality, since knowledge being continuously acquired lead to new insights of their own business and what support they expect from software.

Confronted with the above issues, Agile methodologies have intensified their focus on a highly iterative and incremental approach, accepting that change is, in fact, an invariant of software development. This blurs the line between designing and developing, specifying and implementing, and should we wish to harness continual change, that distinction no longer suits our purposes: design should become both the medium and outcome of action. Consequently, we are thus looking forward not just for a process to be effective and agile, but to what form should agile software take.

Published in: Technology, Business
1 Comment
12 Likes
Statistics
Notes
  • cok guzel hareketler bunlar http://www.siirtim.com herkesi davet ediyoruz.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
1,479
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
136
Comments
1
Likes
12
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide


































  • Transcript

    • 1. INCOMPLETEBYDESIGN thoughts on agile architectures agile portugal 2010 hugo.sereno.ferreira
    • 2. Reality Check Our field has been in crisis for more than 30 years: Most projects are beyond schedule and over budget. Requirements are hard to formalize... ... change faster than implementation. ... are outdated on day one.
    • 3. Reality Check Our field has been in crisis for more than 30 years: Most projects are beyond schedule and over budget. Requirements are hard to formalize... ... change faster than implementation. ... are outdated on day one. “ We really don’t know what we need — an honest customer.
    • 4. Our struggle... our job... Domain Reality Software
    • 5. Soft. Eng. in the wild 101 !"#"$$%#&'#()*'#$+# *,',-*./#-01#23# >,44666#?*$=-=4)#"/5'#5'#8/-"# 450,'#$+#.$1,6# 8,9:,#!"#$%#+$*@#=&"#8/-"#8,# 7&"#8,9:,#;-0-<,1 *,-44)#&$!'(#8-'#;$*,#45%,#-# "$#=&541#"/5' :544-<,#85"/#';-44#/$&','6#A-0# 7D3 ')'",;#)$&9:,# )$&#./-0<,#5"#50666#B#1-)'C -'%,16 hugo.sereno.ferreira 2007
    • 6. Agile Manifesto Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan.
    • 7. Agile Manifesto Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan. What about the Architecture and Design?
    • 8. Agile Manifesto Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan. Isn’t change the real issue? Up to the point it’s inherent to some business domains?
    • 9. ... when change becomes a requirement ...
    • 10. A simple system Doctor Name Specialization Procedure * Description Group: enum Cost Observations * ‹‹enumeration›› Patient Profession Name Profession Birthdate Appointment Engineer 0..* / Age Date Architect Sex: enum Symptom ... Observations Observations / Total Cost Contact Insurance Pathology Description Number Severity: enum Observations Expiration Date Observations 1. How many “open generalizations” do you count?
    • 11. A simple system Doctor Name Specialization Procedure * Description Group: enum Cost Observations * ‹‹enumeration›› Patient Profession Name Profession Birthdate Appointment Engineer 0..* / Age Date Architect Sex: enum Symptom ... Observations Observations / Total Cost Contact Insurance Pathology Description Number Severity: enum Observations Expiration Date Observations 2. How many “open enumerations” do you count?
    • 12. A simple system Doctor Name Specialization Procedure * Description Group: enum Cost Observations * ‹‹enumeration›› Patient Profession Name Profession Birthdate Appointment Engineer 0..* / Age Date Architect Sex: enum Symptom ... Observations Observations / Total Cost Contact Insurance Pathology Description Number Severity: enum Observations Expiration Date Observations 3. How many “observations fields” do you count?
    • 13. Is this the best we can do? Do we really need to ... ... specify every generalization? ... produce new code for each of them?
    • 14. Is this the best we can do? Do we really need to ... ... specify every generalization? ... produce new code for each of them? How many of you have already realized that ... ... vital information will be dumped as text in observations? ... eventually, you’ll be parsing that unstructured text?
    • 15. Is this the best we can do? Do we really need to ... ... specify every generalization? ... produce new code for each of them? How many of you have already realized that ... ... vital information will be dumped as text in observations? ... eventually, you’ll be parsing that unstructured text? Why can’t the end-user simply extend basic functionality? Will the product ever be finished?
    • 16. “ What’s the problem? We just sell more horses! — an horse breeder before the invention of the car.
    • 17. Business vs Engineering
    • 18. Business vs Engineering Are our software artifacts so good that all we need to address is the way we build them?
    • 19. eXtreme Programming Short iterations, continuous integration, pair-programming, test-driven development... We’re ready to embrace change through our processes. But how do we embrace change through our designs?
    • 20. Soft. Eng. in the wild 102 xkcd 2008
    • 21. What does agile software look like?
    • 22. “ Law of Unavoidable Variance. If you think something is not going to change, it will.
    • 23. “ Law of Unavoidable Variance. If you think something is not going to change, it will. “ In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change. Charles Darwin.
    • 24. Incomplete by Design “ Traditional approaches to design extols the virtues of completeness. However, in environments characterized by continual change, an approach to design in which incompleteness is harnessed, suggests a change in the meaning of the word design itself — from one that separates the process from its outcome, to one that considers design as both the medium and outcome of action.
    • 25. Introspect! Abstract! Adapt! “ An abstraction is the process or result of generalization: we reduce, or hide, the detailed content of a concept, only retaining the relevant information for a particular purpose. “ Metadata is just saying that if something is going to vary in a predictable way, store the description of the variation (somewhere) so that it is easy to change. In other words, if something is going to change a lot, make it easy to change. Ralph Johnson.
    • 26. Using Type-Object Pattern Surgery: Procedure ‹‹is-instance-of›› Procedure Procedure Type Name = "Surgery" Name: string Description Group: enum Cost Observations Doctor Appointment Architect: Profession * Date Name = "Architect" Symptom Observations ‹‹is-instance-of›› * / Total Cost Patient Profession Name 0..* Birthdate Name / Age Sex: enum Observations Fever: Pathology Pathology Pathology Type ‹‹is-instance-of›› * Severity: enum Name = "Fever" Name: string Observations
    • 27. But...
    • 28. Which is simpler? Doctor Surgery: Procedure ‹‹is-instance-of›› Procedure Procedure Type Name Name = "Surgery" Name: string Description Specialization Group: enum Procedure Cost * Description Observations Group: enum Cost Observations Doctor * Appointment Architect: Profession * Date Patient Name = "Architect" Symptom Name Appointment Observations Birthdate * / Total Cost Date ‹‹is-instance-of›› / Age Sex: enum Symptom Patient Observations Observations Name / Total Cost Profession 0..* Birthdate Name / Age Sex: enum Observations 0..* Pathology Profession Severity: enum Observations Engineer Pathology Type Fever: Pathology ‹‹is-instance-of›› Pathology * Architect Severity: enum ... Name = "Fever" Name: string Observations exhibit A exhibit B domain model implementation model
    • 29. Accidental Complexity “ Accidental complexity is that which arises in programs, or during their development process, which is non-essential to the problem to be solved. “ While essential complexity is inherent and unavoidable, accidental complexity is caused by the chosen approach to solve the problem. In this case, we kept repeating the same pattern.
    • 30. Domain models should become first-class artifacts of our systems.
    • 31. Adaptive Object-Model If... ...we use a sufficient expressive model for the system’s components that ought to be frequently changed. ...and, we ensure no outside dependencies (no code generation, no glue code, etc.) Then... ...design becomes the outcome of action. ...we are able to enpower end-users to adapt!
    • 32. Model-Driven Manifesto “ We prefer to validate software-under-construction over validating software requirements. “ We work with domain-specific assets. “ We strive to automate software construction from domain models. “ We support the emergence of supply chains for software development, which implies domain-specific specialization and enables mass customization.
    • 33. Is this the silver bullet? Development is expensive. Higher startup costs. It can be hard to understand and maintain. Several levels of abstraction. It requires skilled developers. If programming is not your passion, this is out of your league. It requires domain experts.
    • 34. Questions? hugo.sereno@fe.up.pt

    ×