1. Kirk Knoernschild
Analyst, SDLC and Containers,
Agile Architecture - Patterns & Technology
Languages, & Frameworks
Burton Group
www.burtongroup.com
kknoernschild@burtongroup.com
Blog: http://apsblog.burtongroup.com
Blog: http://techdistrict.kirkk.com
Twitter: pragkirk

2. Agile Architecture 2
The Law of Two Feet
If at any time during our time together you
find yourself in any situation where you are
neither learning nor contributing, use your
two feet. Go to some other place where you
may learn and contribute.
Image Source: http://www.flickr.com/photos/jamesfarnham/32302798/

3. Agile Architecture 3
Defining Architecture
Modularity
The Patterns
Patterns Applied

4. Agile Architecture 3
Defining Architecture
Modularity
The Patterns
Patterns Applied

5. Agile Architecture 4
Defining Architecture
What What What
is arc is is
hitect
ure? archit the goal of archit ag ile
ecture ecture
? ?

6. Defining Architecture 5
Preliminary Thoughts
• Architects architect architecture
• “Architecture is design, but not all design is architecture”.1
• We are often asked to design solutions to problems that require
knowledge we currently do not possess.
• Gall’s Law
• A complex system that works is invariably found to have evolved from a
simple system that worked. A complex system designed from scratch never
works and cannot be patched up to make it work. You have to start over,
beginning with a working simple system. 2
• This session describes my approach to agile architecture. It is
not all-inclusive, nor necessarily complete.
Your feedback is valued and encouraged!
1. Booch made this statement.
2. John Gall. “How Systems Really Work and How They Fail.” P. 71

7. Defining Architecture 6
What is Architecture?
• An architecture is the set of significant decisions about the
organization of a software system, the selection of the structural
elements and their interfaces by which the system is composed,
together with their behavior as specified in the collaborations
among those elements, the composition of these structural
elements and behavioral elements into progressively larger
subsystems, and the architecture style that guides this
organization -- these elements and their interfaces, their
collaborations, and their composition.
Source: Kruchten: The Rational Unified Process. Also cited in Booch, Rumbaugh, and
Jacobson: The Unified Modeling Language User Guide, Addison-Wesley, 1999

8. Defining Architecture 7
What is Architecture?
• In most successful software projects, the expert developers
working on that project have a shared understanding of the
system design. This shared understanding is called
‘architecture.’ This understanding includes how the system is
divided into components and how the components interact
through interfaces. These components are usually composed of
smaller components, but the architecture only includes the
components and interfaces that are understood by all the
developers...Architecture is about the important stuff. Whatever
that is.
Source: Fowler, Martin. IEEE Software, 2003. “Who Needs an Architecture.” A quote
from Ralph Johnson on the XP mailing list.

9. Defining Architecture 8
What is Architecture?
• The fundamental organization of a system, embodied in its
components, their relationships to each other and the
environment, and the principles governing its design and
evolution.
Source: ANSI/IEEE Std 1471-2000

10. Defining Architecture 9
What is Architecture?
• A formal description of a system, or a detailed plan of the
system at component level to guide its implementation
• The structure of components, their inter-relationships, and the
principles and guidelines governing their design and evolution
over time.
Source: TOGAF - http://www.opengroup.org/architecture/togaf8-doc/arch/chap01.html

11. Defining Architecture 10
What is Architecture?
• Architecture embodies the critical design decisions that typify a
system.
• Relates to cost of change, organizational structure, structure of code,
capabilities of a system, etc.
• The significance of decisions needs to be understood and
assessed
• A heavy-weight approach is likely to reduce understanding and our ability to
assess
Source: QCON London Presentation by James Coplien & Kevlin Henney title Agile
Architecture Is not Fragile Architecture - http://www.infoq.com/presentations/Agile-
Architecture-Is-Not-Fragile-Architecture-James-Coplien-Kevlin-Henney

12. Defining Architecture 11
The Goal of Architecture

13. Defining Architecture 11
The Goal of Architecture
What if we were
able to reduce the
impact and
cost of change?

14. Defining Architecture 11
The Goal of Architecture
What if we were
able to reduce the
impact and
cost of change?
We n
ee d t
elimin o
ate
archit
ectur
e!

15. Defining Architecture 12
Architecture Paradox
Increa
sing e
decre vo
ases s lvability
ur viva
bility
... making everything easy to change makes the entire
system very complex... - Ralph Johnson in “Who Needs an Architect”

16. Defining Architecture 12
Architecture Paradox
We m Increa
ust re sing e
decre vo
which cogniz
e ases s lvability
areas ur viva
system of the bility
deman
increa d the
se d co
that w mplex
ill bri ity
greate ng
r flex
ibility!
... making everything easy to change makes the entire
system very complex... - Ralph Johnson in “Who Needs an Architect”

17. Defining Architecture 13
I contend...
• Architecture requires modularity
• otherwise, how do we understand the impact of change
• how do we identify areas of the system that demand flexibility
• Agile architecture requires decision temporality
• we cannot create solutions today for that which we will not know until
tomorrow
• otherwise we’ll create unnecessarily complex designs that do not address the
impact of change

18. Agile Architecture 14
Modularity
What Why i What
is mo d s mo d ch
ular neces ula us to d allenges fa
ity? sar y c rity a ay in c
of ag i o mp o n mo dul design e
le arc ent ar sof in
hitect tware g
ure? ?

19. Modularity 15
Defining Module
Hey, it’s a JAR file!
- unit
of reu
- unit se
of co m
- unit po
of dep sition
- unit loyme
of ma nt
nagem
ent

20. Modularity 15
Defining Module
Hey, it’s a JAR file!
- unit
of reu
- unit se
of co m
- unit po
of dep sition
- unit loyme
of ma nt
nagem
ent
A module system provides a runtime environment for modules

21. Modularity 16
Advantages of Modularity
- reus
e
- re du
ce co m
- ease ple
mainte xity
- incr nance
ease
exten
sibility

22. Modularity 17

23. Modularity 17
as change occurs

24. Modularity 17
as change occurs
modules and their
dependencies

25. Modularity 17
as change occurs
isolate change
modules and their
dependencies

26. Modularity 17
as change occurs
isolate change
modules and their
dependencies

27. Modularity 18
Architectural Joints
Which
ar
system ea of the
deman
flexib ds mo
ility? re

28. Modularity 18
Architectural Joints
Which
ar
system ea of the
deman
flexib ds mo
ility? re

29. Modularity 19
Module Design
Few teams are designing software systems this way today!
POLL:
Question: Response:
-----------------------------------------------------
- How many design class relationships? _____
- How many design package relationships? _____
- How many design module (JAR, Assembly) relationships? _____

30. Modularity 20
Platform Modularity
Why a
re
design n’t we
ing mo
mo dul re
ar sof
tware
?

31. Modularity 20
Platform Modularity
Why a
re
design n’t we
Platforms discourage modularity! ing mo
mo dul re
ar sof
tware
?

32. Modularity 21
Platform Modularity
But w
hat if
platfo the
rm
enco u
rage d
mo dul
arity?

33. Modularity 21
Platform Modularity
But w
This is the next generation application platform! hat if
platfo the
rm
enco u
rage d
mo dul
arity?

34. Modularity 22
Runtime Model
- Dyn
am
- Mult ic deployme
ipl nt
- Enfo e versions
rce
depen
dencie
s

35. Modularity 23
Development Model
Progra Design
m ming Para d
- The Mo del - The igm
frame techn
an d te works use d t iques
ch
that a nolog ies create
o i den
tify a
llow u the ri nd
create s to of mo ght se
mo dul dules t
softw ar
are

36. Modularity 23
Development Model
Progra Design
m ming Para d
- The Mo del - The igm
frame techn
an d te works use d t iques
ch
that a nolog ies create
o i den
tify a
llow u the ri nd
create s to of mo ght se
mo dul dules t
softw ar
are
The Design Paradigm
- What’s the right granularity for a module?
- What the right weight for a module?

37. Modularity 24
Modular Tension
Maximizing reuse complicates use

38. Modularity 24
Modular Tension
Maximizing reuse complicates use
- SOL
ID
- Desi
gn Pat
- Mo d terns
ularity
Patter
ns

39. Agile Architecture 25
The Patterns
What
ar
mo dul e the
arity
patter
ns?

40. The Patterns 26
Base Patterns
• ManageRelationships – Design Module Relationships.
• ModuleReuse – Emphasize reusability at the module level
• CohesiveModules – Create cohesive modules.
• ClassReuse - Classes not reused together belong in separate
components.

41. The Patterns 27
Dependency Patterns
• AcyclicRelationships - Module relationships must be acyclic.
• LevelizeModules – Module relationships should be levelized
• PhysicalLayers - Module relationships should not violate the
conceptual layers.
• ContainerIndependence - Consider your modules container
dependencies.
• IndependentDeployment - Modules should be independently
deployable units.
• CollocateExceptions - Exceptions should be close to the
classes that throw them.

42. The Patterns 28
Usability Patterns
• PublishedInterface - Make a modules published interface well
known.
• ExternalConfiguration – Modules should be externally
configurable.
• ModuleFacade – Create a facade serving as a coarse-grained
entry point to the modules underlying implementation.

43. The Patterns 29
Extensibility Patterns
• StableModules - Modules heavily depended upon should be
stable.
• AbstractModules - Depend upon the abstract elements of a
module.
• ImplementationFactory - Use factories to create a modules
implementation classes.
• SeparateAbstractions - Separate abstractions from the classes
that realize them.

44. The Patterns 30
Utility Patterns
• LevelizedBuild – Execute the build in accordance with module
levelization.
• TestComponent – For each module, create a test component
that validates it’s behavior and illustrates usage.

45. Agile Architecture 31
Patterns Applied
How c How d
an I u o they
mo dul se the acco m h
arity mo dat elp
patter archit e
ns? ectura
l shift
s?

46. Patterns Applied 32
The System
Design a system to handle payment and
auditing of various types of bills. The
system must integrate with 3rd party
auditing software, and a legacy
financials system that must be fed
payment information for reconciliation.

47. Patterns Applied 33
Initial System Class Diagram
Note t
he bi-
direct
io n
associ al
ations
!

48. Patterns Applied 34
Initial System Modules
If I la
yer
conce
ptu
physic ally but no
all t
I real y, then am
izing t
a dvan he
tages
layeri of
ng? W
layer ? hy do
I

49. Patterns Applied 35
Physical Layers
• Module relationships should not violate the conceptual layers.

50. Patterns Applied 36
Abstract Modules
• Depend upon the abstract elements of a module.
- “Inje
ct
implem ” the
entati
Client. on int
o
- “Lo o
ku
implem p” the
entati
w ithin on
Client.

51. Patterns Applied 37
Abstract Modules
What
if Bill
be ab m
le to u ust
differ se
ent au
system diting
s?

52. Patterns Applied 38
Abstract Modules
Au ditF
ac
inject a de1 is
e d int
as an oB
Au ditF ill
type. aca de

53. Patterns Applied 39
Abstract Modules

54. Patterns Applied 40
Acyclic Relationships
• Module relationships must be acyclic.

55. Patterns Applied 41
Recall - Abstract Modules Class Diagram
Au ditF
ac
inject a de1 is
e d int
as an oB
Au ditF ill
type. aca de

56. Patterns Applied 42
Recall - Abstract Modules

57. Patterns Applied 43
Uni-Directional Associations

58. Patterns Applied 44
Acyclic Relationships

59. Patterns Applied 45
Separate Abstractions
• Separate abstractions from the classes that realize them.
How d
o I
integr
ate w
ith
anoth
er au
diting
syste
m? W
here
does
Audit
Facad
live? e2

60. Patterns Applied 46
Separate Abstractions
Shoul
d I p
ut
Audit
Facad
e2 in
audit.
jar?

61. Patterns Applied 47
Separate Abstractions

62. Patterns Applied 48
CollocateExceptions
• Exceptions should be close to the classes that throw them.
Audit
Facad
e
throw
s
the
Audit
Excep
tion.

63. Patterns Applied 49
Independent Deployment
• Modules should be independently deployable units.
How d
o I re
bill.ja use
r with
financ out
ial.ja
in a b r? Lik
atch e
applic
ation?

64. Patterns Applied 50
Independent Deployment

65. Patterns Applied 51
Independent Deployment
1.) PayAction invokes Bill.pay()
and passes BillPayAdapter
as a BillPayer.
2.) Bill.pay() invokes
BillPayer.generateDraft()
3.)BillPayAdapeter.generateDraft()
invokes Payment.generateDraft()
passing itself as a Payable.
4.) Payment.generateDraft()
invokes Payable.getAmount()

66. Patterns Applied 52
Independent Deployment

67. Patterns Applied 53
Implementation Factory
• Use factories to create a modules implementation classes.

68. Patterns Applied 54
Final Module Structure

69. Patterns Applied 55
Opportunities for Extension

70. Agile Architecture 56
Additional Resources
• OSGi - http://www.osgi.org
• JarAnalyzer - http://www.kirkk.com/main/Main/JarAnalyzer
• Illustrates dependencies between JAR files
• Google Code - http://code.google.com/p/jaranalyzer/

71. Agile Architecture 57
irk Knoernschild
Presented By: K m
kknoernschild @burtongroup.co
m
p ragkirk@kirkk.co m
http://te chdistrict.kirkk.co