10 hinweise für architekten
DESCRIPTION
Diese Präsentation enthält 10 pragmatische Hinweise für Software Architekten.TRANSCRIPT
![Page 1: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/1.jpg)
Eberhard Wolff, adesso AG
Zehn Hinweise für Architekten
![Page 2: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/2.jpg)
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 • [email protected]
![Page 3: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/3.jpg)
Why?
• Educating architects internally at adesso
• What should they know?
• What is the bare minimum?
![Page 4: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/4.jpg)
Software Architect Software architect is a general term with many accepted definitions which refers to a broad range of roles.
Not really well defined…
![Page 5: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/5.jpg)
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.
![Page 6: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/6.jpg)
Why We Care
Software Architecture
Structures Software elements Relations Properties
Performance
Availability
Productivity
Maintainability
Security
Operations
Defines non-functional requirements &
quality
![Page 7: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/7.jpg)
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
![Page 8: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/8.jpg)
YOU ARE NOT AN ARCHITECT!
![Page 9: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/9.jpg)
Agile Development i.e. Scrum
Product Owner
Creates stories
Stories
Scrum Master Removes obstacles
Enforces rules
Team Self-organizing
Implements stories
Where is the
Architect?
![Page 10: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/10.jpg)
You Are Not An Architect!
• No manager • Need to convince not manage • Therefore: Not that different from a developer • More experienced • More knowledge
![Page 11: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/11.jpg)
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
![Page 12: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/12.jpg)
Different Way to Think About Roles
1999 2001
![Page 13: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/13.jpg)
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
![Page 14: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/14.jpg)
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
![Page 15: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/15.jpg)
YOUR OPINION MATTERS!
![Page 16: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/16.jpg)
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
![Page 17: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/17.jpg)
• http://lemmings.mytrash.tv/
![Page 18: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/18.jpg)
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!
![Page 19: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/19.jpg)
PEOPLE WANT TO IMPROVE!
![Page 20: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/20.jpg)
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
![Page 21: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/21.jpg)
What You Can Do…
• Education • Review • Pairing • Talks • …
![Page 22: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/22.jpg)
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
![Page 23: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/23.jpg)
ARCHITECTURE = TRADE OFF
![Page 24: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/24.jpg)
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?
![Page 25: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/25.jpg)
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
![Page 26: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/26.jpg)
IMPROVE YOUR VOCABULARY
![Page 27: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/27.jpg)
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
![Page 28: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/28.jpg)
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
![Page 29: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/29.jpg)
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 • Coaching
![Page 30: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/30.jpg)
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)
• …
![Page 31: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/31.jpg)
EAT YOUR OWN DOG FOOD!
![Page 32: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/32.jpg)
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
![Page 33: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/33.jpg)
NO BROKEN WINDOWS
![Page 34: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/34.jpg)
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
![Page 35: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/35.jpg)
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
![Page 36: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/36.jpg)
But…
• There might still be broken windows • There might be more and less skilled
developers
• What do I do?
![Page 37: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/37.jpg)
STRATEGIC DESIGN
![Page 38: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/38.jpg)
Domain Driven Design • “Tackling Complexity
in the Heart of Software”
• E.g. Ubiquitous Language for Code, Developers and Customers
![Page 39: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/39.jpg)
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
![Page 40: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/40.jpg)
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
![Page 41: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/41.jpg)
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
![Page 42: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/42.jpg)
CARE ABOUT ARCHITECTURE AND CODE
![Page 43: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/43.jpg)
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
![Page 44: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/44.jpg)
MEASURE AND REDUCE
![Page 45: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/45.jpg)
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
![Page 46: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/46.jpg)
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
![Page 47: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/47.jpg)
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
![Page 48: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/48.jpg)
DEPENDENCIES MATTER!
![Page 49: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/49.jpg)
Dependency Management
• Essential for measuring architecture • i.e. what is the structure in the code?
• Why are Dependencies so important?
![Page 50: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/50.jpg)
What is Architecture?
• Architecture is the decomposition of systems in parts
• No large or complex parts • No cyclic dependencies
![Page 51: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/51.jpg)
Normal Dependencies • A and B might be
packages or classes
• B depends on A, i.e. it uses classes, methods etc.
• Changes in A impact B • Changes in B do not
impact A
Component A
Component B
![Page 52: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/52.jpg)
Cyclic Dependency • B depends on A and A on
B • Changes in A impact B • Changes in B impact A • A and B can only be
changed as one unit • …even though they should
be two separate units
Component A
Component B
![Page 53: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/53.jpg)
Bigger cyclic dependencies
Component A
Component C
Component B
![Page 54: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/54.jpg)
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
![Page 55: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/55.jpg)
Care about Code and
Architecture
Measure and Reduce
Dependencies Matter
You are Not an Architect
Eat your own Dog Food
People Want To Improve
Architecture is Trade Off
Vocabulary
Quality
No Broken Windows
Strategic Design
And Remember: Your Opinion Matters!
![Page 56: 10 Hinweise für Architekten](https://reader034.vdocuments.site/reader034/viewer/2022051513/5479adb25806b576048b4749/html5/thumbnails/56.jpg)
www.AAAjobs.de
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!