These are ten advices for Software Architechts.

1. Eberhard Wolff, adesso AG
Ten Advices for Architects

2. About me
• Eberhard Wolff
• Architecture & Technology Manager at adesso
• adesso is a leading IT consultancy in Germany
• Speaker
• Author (e.g. first German Spring book)
• Blog: http://ewolff.com
• Twitter: @ewolff
• http://slideshare.com/ewolff
• eberhard.wolff@adesso.de

3. Why?
• Educating architects internally at adesso
• What should they know?
• What is the bare minimum?

4. Software Architect
Software architect is a general term
with many accepted definitions
which refers to a broad range of roles.
Not really well defined…

5. Software Architecture
The software architecture of a system is the set of
structures
needed to reason about it, which comprise
software elements,
relations among them, and
properties of both.

6. Why We Care
Defines
Structures Performance
Software elements
non-functional
Relations
Properties
Availability
Productivity
requirements &
Software
Architecture
Maintainability
quality Security
Operations

7. Software Architect:
Responsibilities
• Manager
• Responsibility: non-functional
requirements / quality
• Tool: Define and enforce
architecture
• Functional requirements covered
by requirements process
• Functional requirements influence
the architecture

8. YOU ARE NOT AN
ARCHITECT!

9. Agile Development i.e. Scrum
Where is Scrum Master
Removes obstacles
Enforces rules
the
Architect Stories
?
Product
Owner
Creates stories
Team
Self-organizing
Implements stories

10. You Are Not An Architect!
• No manager
• Need to convince not manage
• Therefore: Not that different from a developer
• More experienced
• More knowledge

11. Is “Architect” a Good Metaphor?
• Buildings are physical entities
– Hard to change
• Construction industry is established
• …and has a long history
• Buildings can be fully specified
• Software can’t (see Agility)
• Clear separation: Architect vs.
construction worker
• Common for a Software Architect to
be a former developer
• …or even doing some coding

12. Different Way to Think About
1999
Roles
2001

13. Software Craftsmanship Manifesto
(2009)
• As aspiring Software Craftsmen we are raising the bar
of professional software development by practicing it
and helping others learn the craft. Through this work
we have come to value:
• Not only working software,
– but also well-crafted software
• Not only responding to change,
– but also steadily adding value
• Not only individuals and interactions,
– but also a community of professionals
• Not only customer collaboration,
– but also productive partnerships

14. Architect as a Master Craftsman
• More experienced
• Knows the tools very
well
• Guides and helps others
• Incorporates feedback
• Improves the craft
• Quality
• Will work on code
• But knows the bigger
picture of the project
• Education and work on
the project at hand

15. YOUR OPINION MATTERS!

16. Your Opinion Matters!
• You need to have your own opinion
• …about technologies
• …about architecture approaches
• Listen to opinions of others
• …but come up with your own
• Your responsibility

17. • http://lemmings.mytrash.tv/

18. Your Opinion Matters!
• This applies to this conference
• …and this talk
• If it does not make sense to you
– say so
• Your opinion – your responsibility
• Even if someone is a speaker – he might still
be wrong
• Never be intimidated!

19. PEOPLE WANT TO IMPROVE!

20. People Want to Improve!
• Technical people take pride in
their skills
• …often also quality
• They want to improve and create
great quality!
• Guide the way
• Define what quality is

21. What You Can Do…
• Education
• Review
• Pairing
• Talks
• …

22. What If They Don’t Want to
Improve?
• You are screwed
• No way to create high quality with
those people
• Ensure that they know what
quality is and what is expected

23. ARCHITECTURE = TRADE OFF

24. Architecture = Trade Off
• There are numerous ways to architect
each system
• There is no one single right
architecture
• Each architecture has strength and
weaknesses
• Think about architecture in terms of
Trade Offs
• Do they match your requirements?

25. Example for Trade Off:
Persistence
• Option: SQL
– More control
– Less infrastructure
• Option: O/R mapper
– Seemingly easier to use
– But a complex piece of technology
• Option: NoSQL
– A lot of options with individual strength and
weaknesses

26. IMPROVE YOUR
VOCABULARY

27. Vocabulary
• Approaches to architecting a
system
• Defines what kind of architectures
and systems you can express
• The more you know the better you
can do trade offs
• Will offer new perspectives on what
you doing
• Also it is interesting to learn what
others do

28. How to Improve Your Vocabulary
• Patterns
– Fowler: Patterns of Enterprise
Application Architecture
– Gamma et al: Design Patterns
– Buschmann et al: Patterns-
Oriented Software Architecture
– Hohpe: Pattern of Enterprise
Integration
• Evans: Domain Driven Design

29. How to Improve Your Vocabulary
• Technologies
– How many Persistence
approaches do you know?
– Should at least have a high level
overview
– There is life beyond standards
– Can save a lot of time and effort
• Conferences
• Web Sites
• Reviews

30. Again: Persistence
• “Patterns of Enterprise Application
Architecture” lists persistence approaches
• Ruby on Rails uses Active Record (i.e.
objects can store themselves)
• myBATIS for easy persistence using SQL
(Java / .NET)
• …

31. EAT YOUR OWN DOG FOOD!

32. Eat Your Own Dog Food!
• Defining an architecture is easy
• It is hard to create the right
architecture
• Need feedback
• Eat your own dog food: Develop
code yourself
• Do pair programming
• To become grounded

33. NO BROKEN WINDOWS

34. Broken Windows Theory
• Once windows are not
repaired…
• …vandals will break more
• …break into the building
• …
• Accepting compromises on
quality is risky
• …but if you strive for ultimate
quality everywhere, you will fail
• In particular with legacy
software

35. Broken Windows in Architecture
• Compromises on quality will
become out of hand
• Might speed up a project for
a limited time
• But: Will hurt productivity in
the long run
• …and ultimately slow it down
• Higher quality can mean less
cost and quicker delivery
• Metaphor: Technical debt
• Much like debt in real life

36. But…
• There might still be broken windows
• There might be more and less skilled
developers
• What do I do?

37. STRATEGIC DESIGN

38. Domain Driven Design
• “Tackling Complexity
in the Heart of
Software”
• E.g. Ubiquitous
Language
for Code, Developers
and Customers

39. Strategic Domain Driven Design
• Bounded Context:
Model used only in a specific
part of the system
• Context Map:
Translate models from
different parts of the system
• Anti-Corruption Layer:
Make sure the core domain
is not corrupted

40. Strategic Domain Driven Design
• Can be used to manage
quality
• What are the core business
domains?
• Focus on quality of those
• Isolate them from the rest of
the system
• Let the best developer work
on the most important parts

41. Strategic Domain Driven Design
• Acknowledges that not all developers are
equals
• …and not all parts of a system will have the
same quality
• Allows you to steer which parts will be better

42. CARE ABOUT ARCHITECTURE
AND CODE

43. Care About Architecture and Code
• You can draw diagrams until the end of time
• It’s the code and the architecture in the code
that matters
• Architectures is only used to influence code

44. MEASURE AND REDUCE

45. Measure and Reduce
• No way to know all code by heart
• Still: You and the team need to understand
the state of the project
• Need tools to measure and reduce
information

46. Sonar
• Server that integrates a lot of systems
• Static code analysis (Findbugs, PMD etc)
• Lines of Code, classes
• Test code coverage
• Complexity
• Historized i.e. easy to spot trends
• Easy to install
• Visit http://nemo.sonarsource.org/ for
examples

47. Draw Conclusions!
• Do not try to enforce a certain value for a
metric!
• Metrics are used to reduce information and
get warning signs
• Use them to improve quality
• If you enforce a value mindlessly problems
will be avoided – not solved
• …and measurements will become worthless

48. DEPENDENCIES MATTER!

49. Dependency Management
• Essential for measuring architecture
• i.e. what is the structure in the code?
• Why are Dependencies so important?

50. What is Architecture?
• Architecture is the decomposition of systems
in parts
• No large or complex parts
• No cyclic dependencies

51. Normal Dependencies
• A and B might be
packages or classes
Component A
• B depends on A, i.e. it
uses classes, methods
etc.
Component B
• Changes in A impact B
• Changes in B do not
impact A

52. Cyclic Dependency
• B depends on A and A on
B
Component A
• Changes in A impact B
• Changes in B impact A
• A and B can only be
changed as one unit Component B
• …even though they should
be two separate units

53. Bigger cyclic dependencies
Component A
Component B
Component C

54. Measure Dependencies!
• …otherwise they will get out of hand
• Cyclic dependencies mean:
– It should be separated according to the
architecture
– …but it is not
• JDepend – rather outdated
• Structure 101
• Sonargraph

55. Care about
You are Not an Architecture is
Code and Quality
Architect Trade Off
Architecture
Measure and Eat your own No Broken
Vocabulary
Reduce Dog Food Windows
Dependencies People Want Strategic
Matter To Improve Design
And Remember: Your Opinion Matters!

56. Wir suchen Sie als
Ø Software-Architekt (m/w)
Ø Projektleiter (m/w)
Ø Senior Software Engineer (m/w)
Ø Kommen Sie zum Stand und gewinnen Sie ein iPad 2!
jobs@adesso.de
www.AAAjobs.de