1. Everything You Always Wanted to Know
About Software Architects* but Were
Afraid to Ask
© 2014, Prof. Dr. Michael Stal

2. Why do we need Architects?
„We use an agile process
where architecture is built
by community“
„Architecture is being
created in one small design
step“
„Our application is so
small; architecture design is
a waste of resources“
„We always use the same
reference architecture“
Get rid of the
architectural chains and
get rid of architects
Houdini

3. Because Architecture is the
Backbone of any System
Architecture design comprises
the whole lifecycle
Architects have many
responsibilities that are not
related to design
Almost all design-bycommunity efforts result in
bad products (see Frederick P.
Brooks‘ The Design of Design)
Architecting and
implementation need different
sets of skills
Architectural flaws cause
substantial costs and risks (i.e.,
accidental complexity as
opposed to inherent
complexity)

4. Becoming an Architect seems to be
incredibly easy
Just read the right books ...
and obtain some mathematical skills

5. Just shift your Shape
Some Miracle
Developer
Architect

6. Birth of Architects
In some organizations
architects are those
who have the label
„Architect“ (on
their business card)

7. Birth of Architects (cont‘d)
cont‘d)
Some other
organizations may
use sophisticated
questionaires

8. Birth of Architects (cont‘d)
cont‘d)
Advanced
organizations may
even have a job
profile ...
... that is insufficient
(e.g. RUP)

9. Design errors may cause expensive
and lethal failures
Architecture as the
backbone of all
systems:
Tacoma Narrows Bridge (1940)
collapsed due to neglecting
resonance forces
Radiation Therapy System
Therac-25: lack of quality and
software failure caused 3 deaths
Architectures with lack of
quality are doomed to fail
Architecture design should
happen in a planned and
systematic way, not ad-hoc
Skilled & experienced architects
needed across the whole
product lifecycle, not just in
one short project phase

10. Lousy Architects create lousy
Architectures ...
Tower of Pisa:
structural
engineering did not
work very well
Intempo Skyscaper, Spain:
Architects forgot elevators between
21st and 47th level – Maybe for
health reasons
Airport BER: No
compliance with
safety regulations led
to a
very large
delay

11. ... and Lousy Architectures cause
Disasters
„Even God himself
could not sink this ship“
Challenger Disaster caused
by bad rocket booster design
Ariane 5 explosion
due to overflow
exception

12. And all of this reduces Customer
Happiness

13. How can we find good Architects?
Only with the help of
wizards?
Or by chasing this rare
species in its habitats? Architects in quest
for good design
Or by assigning the role to
some unfortunate
developers?
Architecture as the
Holy Grail

14. Architects Habitat - Theory
What we want:

15. Architects Habitat - Practice
What we often get:

16. Failure has many Roots
We can‘t forbid failure, but we can
enforce learning from failure!
Cemetery for past/passed projects

17. Real Architects need Skills,
Knowledge & Experience
Requirements
Engineering
Software
Architect

18. Responsibilities and Involvements of
Architects
(c) Siemens AG

19. Architecture & Design Skills
Architects need deep knowledge and skills
such as:
Development Processes
Architecture Design and Implementation incl.
Scoping, Modelling, Prototyping
Architecture Evolution & Improvement
Product Line & Platform Engineering
Architecture Assessment + CQM
Assessment of Internal Architecture Quality
System and Application Integration
Relevant Technologies, Methods and Tools
Relevant Best Practices (e.g., Design Tactics,
Patterns & Architecture Styles)
Usability & Habitability
Project management skills are optional but
very useful (e.g. for effort planning)

20. Knowledge of Business and Strategy
To help achieve business goals and
make projects succeed it is
necessary for architects to know:
Business Strategy of own organization
Product Roadmap
Technology Roadmaps
Vendor Management
Target Markets & Customers
Legal Issues, Patents, Licensing
Standards and Regulations (i.e., TÜV,
DIN, FDA, …)
Product Line & Platform Engineering
Otherwise, they cannot make
appropriate design decisions

21. Requirements Engineering Skills
Architects must know the
domain(s) (i.e. problem
domain and solution
domain)
They need to understand
requirements, assess their
quality, feasibility &
sufficiency, and give feedback
Prioritization is typically
conducted by business AND
architects

22. Testing & Quality Skills
Architects need in-breadth
knowledge about
Test Plans
Test Methods
Flavors of testing (integration
tests, system tests, component
tests, acceptance tests, load
tests, …)
… and in-depth knowledge
about
Design for Testability
TDD
Test Strategies

23. Soft Skills
… are essential for architects, e.g.:
Stakeholder-specific communication
(Giving and receiving) feedback,
Mentoring
Listening
Conflict resolution
Understanding different personalities
Leading and convincing others without
line function
Typically, Architects are leaders
without power. Their only means
is to convince with arguments

24. Cooperation, not Confrontation
Architecture design
requires many
contributors: testers,
customers, developers,
product managers, ...
Architecture is the
result of joint work
Joint work requires
close and effective
cooperation
The day, when the architect died

25. Domain Knowledge
It is important for
architects to understand
the relevant domains:
Solution Domain: important
concepts, technologies,
methods, tools, trends, ...
Problem Domain: Domainspecific concepts, standards,
regulations, markets,
products, competitors,
trends, ...
They should know
essential aspects in-depth,
other aspects in-breadth

26. Experiences in Software Engineering
Architects of small systems
should have
at least 3 years experience as
software engineer
experience as a key developer
or subsystem architect
For mission-critical Systems
at least 6 years experience as
software/systems engineer
3 years experience as
architect in small to medium
projects

27. Uncertainty Principle
Architects are facing the Uncertainty Principle in their
daily work. They must be able to deal with uncertainty.

28. Architecture Process
Not-iterative, nonincremental development
process models don‘t work
for strategic and tactical
design
We require a risk-driven
and test-driven feedback
loop to address uncertainty
Architecture must be built
using piecemeal growth even within more
„traditional“ processes

29. Activities of an Architect
Architecting does not only
involve creation of
architectures but also:
Monitoring the
development process by
CQM (Code quality
Management) tools
Reviewing architectures
Improving and extending
architectures
Conducting Architecture
Archeology
You need to foster
architectures as if they were
your children

30. Unchartered Territories
No technology is a panacea – you
can even loose all of the benefits
by bad design
We cannot predict how new and
innovative, sometimes disruptive
technologies will influence the
architecture (e.g. quality
attributes)
This is even worse for the
combination of technologies, and
is usually not addressed very well
Architects should leverage
feasibility prototypes, at least for
the most crucial qualities
Methods for Architecture
Assessment are applicable as well
Some Prototypes

31. Tip of the Iceberg
There are many forces
architects have to balance
E.g., architects are actually
facing additional nontechnical and nonarchitectural
responsibilities and
involvements
All the rest
Design

32. Decision Making
Architecting is about
decision making and risk
mitigation
Sometimes, architects are
anxious to make a wrong
decision or don‘t have the
courage to enforce a
decision
Experience tells us to be
courageous. In most cases
is almost always better to
go the wrong way than
being stuck
Power stealing in India

33. Essence of Good Collaboration
Software Development is a collaborative game [Alistair
Cockburn]
Thus, communication skills are probably the most
important skills in software/system engineering
Hence:
NO!
YES!

34. Network of Communication
Leadership, Communication and Interaction with other roles in software
development, are probably the most time-intensive and most important
Other
responsibilities
Roles
?
Product line
Manager
Head of
R&D
Requirements Engineer
Software Project Manager –
in a meeting with the CEO
Software
Developer
Test Manager
Software
Architect

35. Be aware of Conway‘s Law
One important
consideration is
Conway‘s law:
“organizations which design
systems ... are constrained to
produce designs which are
copies of the communication
structures of these
organizations”
Corperate Spam
Complex
decision processes
Meeting Overkill
Unclear or overlapping
Responsibilities

36. Systems Engineering
In systems engineering the
architect needs to closely
cooperate with the systems
architect
Software Architects must
understand
the contribution of different
disciplines (Electronics, Mechatronics,
Software, ...) and their
„orchestration“,
the additional development phases
such as commissioning,
the pitfalls and traps (developing
software when the rest is only
partially available, relation of unit
costs and software architecture, ...).
Electrial Engineering
Project Manager
Systems engineer
Software Architect

37. Stay Up-To-Date
Up-ToTechnologies & methods appear and evolve very
frequently
Consequently, architects need to stay in sync with
relevant technologies and methods
„Architect always implements“
Active Networking
Mutual Architecture Assessments
Attending events such as Conferences
Collecting & digesting news in (practioner) magazines, web sites
Clouds
Sustainability
Mobile Devices,
...

38. The other Side of the Coin Working as an Architect
... can be extremely
exhausting,
even dangerous.

39. Ten Reasons not to be an Architect*
1.
The gene pool that is your social life will not have a lot of diversity
2.
The pay and benefits are not as good as they could be
3.
The hours you work are long and under-valued
4.
Your ideals don’t really matter
5.
If your ideals are important to you, you will lose work
6.
Not all architects have fun jobs
7.
The systems you use will depress you
8.
You will live with terrible decisions
9.
Architecture requires a lot of work and dedication
10.
You probably won’t be a designer
Interestingly this is what building architects think
* source: http://www.lifeofanarchitect.com/top-ten-reasons-not-to-be-an-architect/

40. Avoid Design Hell
How to create a bad architect
Ingredients:
Spaghetti Design
Design Erosion
Architecture Drift
Design Flaw
UML
Failure,
New Requirements
....

41. If you are still not terrified ...
How can you systematically achieve or
increase architecture skills?

42. Let us take the long & dangerous
Route to Architect‘s Paradise

43. Step 1: Profiling
Develop a set of skills,
knowledge and experience you
need as an architect (in your
organization)
Compare your current profile
with this target profile
Don‘t do this alone but ask
other colleagues and roles to
give you feedback about your
current profile and their
expectations

44. Step 2: Reflection
Elaborate and prioritize your
gaps
Or as they say in the London
Underground: Mind the gap!
Make a detailed and
prioritized plan how to
systematically fill these gaps,
e.g. by
certifications
seminars
books, web casts
coaches, mentors
opportunities to practice
...

45. Step 3: Doing
Perform the
aforementioned steps
In our fast moving
industry this process
should be repeated
regularly
In addition, active
networking with other
architects is highly
recommended

46. Piecemeal Growth
The gaps might be
terrifying, but don‘t
panic!
Be patient and improve
step by step, the same
way your architectures
should be created
Your education as an
architect will never end,
since methods and
technologies evolve
quickly

47. Mission Accomplished
Be relaxed: You‘ll eventually become a cool
architect, ... if you start early enough

48. Architects Certification
Development of company-internal
education program
Benefits:
customized for specific needs
continuous improvement
not limited to architecture (may also teach in
testing, business, …)
Liabilities:
requires large cost
Certification by 3rd party organisations
such as iSAQB, IASA, CMU Software
Engineering Institute
Benefits:
usually less expensive
Liabilities:
more „generic“ to suit all kinds of participants
Architecture & Design only
different trainings lead to education patchwork
Hybrid approach (Best-of-Breed)
use option 1, but fill gaps with option 2
(Best-of-Breed)

49. Example:
Example: Siemens Education
Programs for (Senior) Architects
Introduced in 2007
Main Constituents of Senior Architects
Program
Proposal of Candidates by Sector CEOs
Interviews with each Candidate =>
Acceptance
4 Workshops with 2-3 month breaks
Certification Gates after each workshop
Candidates work on topics (optional) and
homework (mandatory) within their actual
project (no toy projects!)
Education areas: Architecture, Business &
Strategy, Requirements/Product Line
Engineering, Testing & Quality, Soft Skills
Network of Siemens Architects who
meet regularly and work jointly on
important topics
So far, excellent feedback and high
acceptance in Top Management
Content not carved in
stone. Feedback of
participants helps improve
and evolve the material
continuously

50. Learning from Failure

51. Senior Architect Certification @
Siemens
Goal: share good practices, be aware of pitfalls and
eliminate the potential for failure in software
development at Siemens!
© SIEMENS AG

52. Workshop 1: Establish Architecture
Vision
© SIEMENS AG

53. Workshop 2: Realize Architecture
© SIEMENS AG

54. Workshop 3: Sustain Architecture
© SIEMENS AG

55. Don‘t ignore Work Life Balance
If you want to be
successful, balance work &
life
This aspect is commonly
underestimated
In my experience
architects with work
overload cause more
harm than good.
Exhausted, unfocused
architects are a common
root of design flaws

56. Summary
Becoming and being a good architect is
a continuous and sometimes hard
process, not a one-way street
Architects need expertise, skills and
knowledge - not only in Engineering
but also in Communication, Testing,
Requirements Engineering, Business &
Strategy, ...
Architecting is also about decision
making and learning from failure
If not reviewed regularly, design flaws
will erode the architecture. Thus,
Test/Risk-Driven-Design, Architecture
Assessments, Refactoring should
considered mandatory
Reflect continuously about the
capabilities you need and where you
should increase or improve your
knowledge
Stairway to Heaven (for
Software Architects)

57. The End
Source: starush, flickr.com

58. Just kidding
This is the real Happy End