INCOMPLETEBYDESIGN
thoughts on agile architectures




agile portugal 2010      hugo.sereno.ferreira
Reality Check
Our field has been in crisis for more than 30 years:
  Most projects are beyond schedule and over budget.
  R...
Reality Check
Our field has been in crisis for more than 30 years:
    Most projects are beyond schedule and over budget.
 ...
Our struggle... our job...
               Domain
    Reality




    Software
Soft. Eng. in the wild 101

        !"#"$$%#&'#()*'#$+#
         *,',-*./#-01#23#      >,44666#?*$=-=4)#"/5'#5'#8/-"#
    ...
Agile Manifesto

 Individuals and interactions over processes and tools,
 Working software over comprehensive documentatio...
Agile Manifesto

 Individuals and interactions over processes and tools,
 Working software over comprehensive documentatio...
Agile Manifesto

 Individuals and interactions over processes and tools,
 Working software over comprehensive documentatio...
... when change becomes a
       requirement ...
A simple system
                                                  Doctor
                                         Name
   ...
A simple system
                                                 Doctor
                                        Name
     ...
A simple system
                                                 Doctor
                                        Name
     ...
Is this the best we can do?
 Do we really need to ...
   ... specify every generalization?
   ... produce new code for eac...
Is this the best we can do?
 Do we really need to ...
   ... specify every generalization?
   ... produce new code for eac...
Is this the best we can do?
 Do we really need to ...
   ... specify every generalization?
   ... produce new code for eac...
“   What’s the problem? We just sell more horses! —
    an horse breeder before the invention of the car.
Business   vs   Engineering
Business          vs    Engineering

Are our software artifacts so good that all we
 need to address is the way we build t...
eXtreme Programming
          Short iterations, continuous
          integration, pair-programming,
          test-driven ...
Soft. Eng. in the wild 102




                         xkcd 2008
What does agile
software look
     like?
“   Law of Unavoidable Variance. If you think
    something is not going to change, it will.
“   Law of Unavoidable Variance. If you think
    something is not going to change, it will.



“   In nature, it’s not th...
Incomplete by Design

“   Traditional approaches to design extols the virtues of
    completeness. However, in environment...
Introspect! Abstract! Adapt!

“   An abstraction is the process or result of
    generalization: we reduce, or hide, the d...
Using Type-Object Pattern
       Surgery: Procedure     ‹‹is-instance-of››           Procedure            Procedure Type
 ...
But...
Which is simpler?
         Doctor                             Surgery: Procedure     ‹‹is-instance-of››           Procedur...
Accidental Complexity

“   Accidental complexity is that which arises in
    programs, or during their development process...
Domain models should become
first-class artifacts of our systems.
Adaptive Object-Model
If...
   ...we use a sufficient expressive model for the system’s
   components that ought to be freq...
Model-Driven Manifesto

“   We prefer to validate software-under-construction over
    validating software requirements.

...
Is this the silver bullet?
Development is expensive. Higher startup costs.
It can be hard to understand and maintain. Seve...
Questions?
hugo.sereno@fe.up.pt
Upcoming SlideShare
Loading in...5
×

Incomplete by Design — Thoughts on Agile Architectures

1,522

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 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,522
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
138
Comments
1
Likes
12
Embeds 0
No embeds

No notes for slide


































  • Incomplete by Design — Thoughts on Agile Architectures

    1. 1. INCOMPLETEBYDESIGN thoughts on agile architectures agile portugal 2010 hugo.sereno.ferreira
    2. 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. 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. 4. Our struggle... our job... Domain Reality Software
    5. 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. 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. 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. 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. 9. ... when change becomes a requirement ...
    10. 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. 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. 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. 13. Is this the best we can do? Do we really need to ... ... specify every generalization? ... produce new code for each of them?
    14. 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. 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. 16. “ What’s the problem? We just sell more horses! — an horse breeder before the invention of the car.
    17. 17. Business vs Engineering
    18. 18. Business vs Engineering Are our software artifacts so good that all we need to address is the way we build them?
    19. 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. 20. Soft. Eng. in the wild 102 xkcd 2008
    21. 21. What does agile software look like?
    22. 22. “ Law of Unavoidable Variance. If you think something is not going to change, it will.
    23. 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. 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. 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. 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. 27. But...
    28. 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. 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. 30. Domain models should become first-class artifacts of our systems.
    31. 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. 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. 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. 34. Questions? hugo.sereno@fe.up.pt
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×