Eberhard Wolff, adesso AG

Zehn Hinweise für Architekten

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

Why?

•  Educating architects internally at adesso

•  What should they know?

•  What is the bare minimum?

Software Architect Software architect is a general term with many accepted definitions which refers to a broad range of roles.

Not really well defined…

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.

Why We Care

Software Architecture

Structures Software elements Relations Properties

Performance

Availability

Productivity

Maintainability

Security

Operations

Defines non-functional requirements &

quality

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

YOU ARE NOT AN ARCHITECT!

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?

You Are Not An Architect!

•  No manager •  Need to convince not manage •  Therefore: Not that different from a developer •  More experienced •  More knowledge

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

Different Way to Think About Roles

1999 2001

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

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

YOUR OPINION MATTERS!

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

•  http://lemmings.mytrash.tv/

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!

PEOPLE WANT TO IMPROVE!

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

What You Can Do…

•  Education •  Review •  Pairing •  Talks •  …

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

ARCHITECTURE = TRADE OFF

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?

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

IMPROVE YOUR VOCABULARY

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

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

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

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)

•  …

EAT YOUR OWN DOG FOOD!

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

NO BROKEN WINDOWS

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

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

But…

•  There might still be broken windows •  There might be more and less skilled

developers

•  What do I do?

STRATEGIC DESIGN

Domain Driven Design •  “Tackling Complexity

in the Heart of Software”

•  E.g. Ubiquitous Language for Code, Developers and Customers

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

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

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

CARE ABOUT ARCHITECTURE AND CODE

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

MEASURE AND REDUCE

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

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

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

DEPENDENCIES MATTER!

Dependency Management

•  Essential for measuring architecture •  i.e. what is the structure in the code?

•  Why are Dependencies so important?

What is Architecture?

•  Architecture is the decomposition of systems in parts

•  No large or complex parts •  No cyclic dependencies

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

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

Bigger cyclic dependencies

Component A

Component C

Component B

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

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!

www.AAAjobs.de

jobs@adesso.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!