1. successful projects
doen‘t happen
You have to make them

2. success rate and
project duration
80%
60%
40%
GULP poll
20%
successful
0% changed
1-3 3-6 6-12 >12 months stopped

3. why do they fail
• deficit of soft-skills
• dogmatism
• no universal IT-architecture
• no clearly defined interfaces
• lack of clearness & precision
• lack of manageability

4. working in projects
New Development
Support 30 %
40 %
Maintenance
30 %

5. working in projects
under- normal
estimated work
New Development
Support 30 %
40 %
Maintenance
30 %

6. these:
increasing project
runtime

7. these:
increasing project
runtime
more complex eroding
architecture architecture

8. eroding architecture
• is normal
• quality of architecture is not easy to
measure
• typical signs:
• many dependancies
• cyclic dependancies

9. reasons
• distributed system knowledge
• size generates complexity
• outgrowing dependancies and complexity
• time pressure and money is a good reason
to loose structure
• no one pays attention

10. what next?
• cycle check with JDepend / SonarJ
• code reviews
• CheckStyle and FindBugs
• using metrics
• generate abstraction with own frameworks

11. what to do?
• definition of architecture
• use of relevant metrics
• pattern and rules to keep the system simple
• early violation recognition
• regular reviews
• agile development

12. abstract architecture
User Interface
Business Logic
Data Access
1. layer

13. abstract architecture
User Interface
Customer
Contracts
Common
User
Business Logic
Data Access
1. layer
2. functional slice

14. abstract architecture
User Interface
Customer
Contracts
Common
User
Business Logic
Data Access
1. layer
2. functional slice
3. allowed interactions

15. abstract architecture
User Interface
Customer
Contracts
Common
subsystem
User
Business Logic
Data Access
1. layer
2. functional slice
3. allowed interactions

16. layer, slices and subsystems
• a subsystem belongs to one layer
• a subsystem may belong to a functional slice (not
required)
• classification by naming conventions
• not all layer need functional slices
• subsystems can be private

17. assignment of elements
• physical
• type
• build unit
• package
• logical
• subsystem is a set of packages with naming conventions
for packages and interfaces
• layer is a set of subsystems
• functional slices with naming conventions

18. reduce dependancies
• Dependency Inversion Principle (Robert C. Martin)
• use interfaces / traits

19. reduce dependancies
• Dependency Inversion Principle (Robert C. Martin)
• use interfaces / traits
Main
Mid 1 Mid 2
Detail Detail Detail Detail

20. reduce dependancies
• Dependency Inversion Principle (Robert C. Martin)
• use interfaces / traits
High Level
Main Policy
Mid 1 Mid 2 Interface Interface Interface
Detailed Detailed Detailed
Detail Detail Detail Detail Implement. Implement. Implement.

21. metrics

22. Average Component
Dependency (ACD metric)

23. Average Component
Dependency (ACD metric)
6
3 3
1 1 1
ACD=15/6=2.5

24. Average Component
Dependency (ACD metric)
6 3
3 3 1 1
1 1 1 2 3 2
ACD=15/6=2.5 ACD=12/6=2
Dependancy Inversion

25. Average Component
Dependency (ACD metric)
6 3 6
cycles
3 3 1 1 6 6
1 1 1 2 3 2 1 6 1
ACD=15/6=2.5 ACD=12/6=2 ACD=26/6=4.33
Dependancy Inversion

26. stability vs. instability
(Robert C. Martin)
This metric has the range [0,1].
I=0 indicates a maximally stable category
Ca I=1 indicates a maximally instable category
Instability I =
(Ce+Ca)
Ce = Efferent Couplings (incoming)
Ca = Afferent Couplings (outgoing)

27. stability vs. instability
(Robert C. Martin)
This metric has the range [0,1].
I=0 indicates a maximally stable category
Ca I=1 indicates a maximally instable category
Instability I =
(Ce+Ca)
Ce = Efferent Couplings (incoming)
Ca = Afferent Couplings (outgoing)
Y is instable
Y 3 / (0+3) = 1

28. stability vs. instability
(Robert C. Martin)
This metric has the range [0,1].
I=0 indicates a maximally stable category
Ca I=1 indicates a maximally instable category
Instability I =
(Ce+Ca)
Ce = Efferent Couplings (incoming)
Ca = Afferent Couplings (outgoing)
Y is instable X is stable
Y 3 / (0+3) = 1
0 / (3+0) = 0 X

29. stability vs. instability
(Robert C. Martin)
This metric has the range [0,1].
I=0 indicates a maximally stable category
Ca I=1 indicates a maximally instable category
Instability I =
(Ce+Ca)
Ce = Efferent Couplings (incoming)
Ca = Afferent Couplings (outgoing)
Y is instable X is stable
Y 3 / (0+3) = 1
0 / (3+0) = 0 X
lower elements need to be more stable

30. abstractness
(Robert C. Martin)
na
abstractness A =
nc
na = number of abstract classes in category
nc = total number of classes in category
This metric has the range [0,1].
0 means concrete and 1 means completely abstract

31. abstractness vs. instability
(Robert C. Martin)
1
Th
e
Abstraction
M
ain
Se
qu
en
c e
0 Instability 1

32. abstractness vs. instability
(Robert C. Martin)
1
Th o ss
Zo l es
U
e f
se
ne sne
Th
e
Abstraction
M
ain
Se
qu
en
c e
Th
e Pain
Zo
ne
of
0 Instability 1

33. distance
(Robert C. Martin)
1
Th o ss
Zo les
U
e f
se
ne sne
D = A + I – 1
Th
e
Abstraction
M
ain
D
range [-1 .. +1]
Se
qu
en
ce
Th
e Pain
Zo
ne
of
0 Instability
1
„Any category that has a D value that is not
near zero can be reexamined and restructured“

34. design rules
• create a logical architecture based on layer, functional
slices and subsystems as an incremental process
• no cycles beginning at package level
• use metrics (e.g. as part of the build process)
• rACD less less than 15% (for smaller systems and less
than 4% for bigger systems)
• compile units should have less than 1000 LOC
• limit for CCN
• implement frequent architecture reviews