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.

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