What Does It Really Mean to Be an Architect?

13.09.11

What Does It Really Mean to Be an Architect? Eberhard Wolff

Architecture and Technology Manager

adesso AG

About Me

►  Eberhard Wolff

►  Architecture & Technology Manager at adesso

►  adesso is a leading IT consultancy in the German speaking region

►  Speaker

►  Author

►  Blog: http://ewolff.com

►  Twitter: @ewolff

►  http://www.slideshare.net/ewolff

►  [email protected]

Eberhard Wolff: What Does It Really Mean to Be an Architect?

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.

(Won’t be talking about Enterprise Architecture) Eberhard Wolff: What Does It Really Mean to Be an Architect?

Software Architecture: Why We Care

13.09.11 5

Software Architecture

Structures Software elements Relations Properties

Performance

Availability

Productivity

Maintainability

Security

Operations

Defines non-functional requirements &

quality Eberhard Wolff: What Does It Really Mean to Be an Architect?

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

13.09.11 6 Eberhard Wolff: What Does It Really Mean to Be an Architect?

Traditional View on Architect’s Role

►  Define the architecture

►  Enforce the architecture

►  i.e. create frameworks

►  Not necessarily any coding

►  Code reviews (maybe)

►  Assumptions >  Separation of labor >  Developers must be “controlled”

►  Does that still work in today’s world?


Issues in the Real World

►  Ivory tower architecture

►  Architecture does not fit the domain

►  Architecture is not in the code

►  The documented architecture is different from the real architecture

►  Developers don’t feel their feedback is listened to

►  Either architecture is ignored

►  …or project results in a failure


Agile Development i.e. Scrum

13.09.11 9

Product Owner

Creates stories

Stories

Scrum Master Removes obstacles

Enforces rules

Team Self-organizing

Implements stories

Where is the

Architect?


Team

►  Is self organizing

►  An architect might / will emerge

►  …but is not planned for

►  Benefit: >  Responsibility is shared >  i.e. not just the architect cares

►  If the architecture / architect is not helpful, it / he will be ignored

►  Less damage in the end

►  Architect will see his ideas directly in action

►  Better feedback

►  Needs trust and collaboration


New Challenges for Architects

Role

►  Needs to collaborate with other team members

►  …and make himself useful

►  Supports and trusts other team members

►  Leads by experience

►  …not by title

Creating an Architecture

►  Stories defined during the project

►  Not all requirements known at the start

►  No Big Design Upfront possible

►  Architecture needs to emerge

►  Architecture must be constantly redefined

►  More focus on code

►  Code is the reliable source for the current architecture and state of the project


New Skills For Architects

►  Even more communication

►  Convince, not enforce

►  Must listen to other team members

►  …and use their experience and knowledge

►  Must have excellent technical skills

►  Must not think about architecture as stable

►  i.e. must be able to change plans and adapt


Traditional Architect as a Metaphor

13.09.11 13

An architect is a person trained in the planning, design and oversight of the construction of buildings.


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

►  Specification

►  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


A New Way to Think About Creating Software

13.09.11 15

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


Software Craftsmanship

►  Quality, even perfection

►  Work with code

►  Apprenticeship / collaboration

►  Smaller barriers between team members


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


Architect’s Experience

►  Bigger “Vocabulary” >  Architecture patterns >  Basic approaches >  Frameworks, languages etc.

►  Thinks in trade offs >  Knows the alternatives >  There is no black and white

►  Knows what is going on in the project >  Code quality >  Current issues

►  Knows how to get software into production


Code vs. Architecture

►  Ultimately, code is the deliverable

►  Architecture must be expressed in the code

►  If the architecture is not in the code, the architect failed

►  It makes sense to focus on code

►  …and see whether the architecture is really implemented

►  Of course architecture and its documentation are important to reach the project goal!


What Is Wrong About Craftsmanship?

►  The software is at the center

►  It fails to mention what the software is created for

►  Most software has a clear business goal

►  At the end customers have to be happy

►  Quality and how it is created must serve this goal

►  Software is not a goal in itself

►  http://dannorth.net/ 2011/01/11/programming-is-not-a-craft/


Responsibilities Again

►  Non-functional requirements / quality >  Performance >  Availability >  Productivity >  Maintainability >  Security >  Operation readiness

►  The architecture will create a compromise between these goals

►  E.g. seemingly half finished software might be enough

►  Even though it is not well-crafted

►  See agility


Quality

►  Not all parts of a system will have the same quality

►  Not all team members are equally skilled

►  The compromise on the quality can happen “by chance”

►  …or you can steer it

►  Identify core domains >  The ones that add the most value >  i.e. have a good business reason

►  Might want to isolate those

►  …and focus on them


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


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


More Responsibilities for Architects

►  Define the Core Domain

►  Ensure that the Core Domain will be implemented properly

►  …and won’t be compromised

►  I.e. manage the overall quality

►  Needs detailed domain knowledge

►  Need to understand business case


So: What Does It Really Mean to Be an Architect?

13.09.11 28

Architect

►  Cares about non-functional requirements

►  Used to be clearly separated from developers

►  Cannot lead “by title” >  In particular in self-organizing teams >  Will be ignored >  …or create a failure

►  Communication, giving and accepting feedback

►  Craftsmanship might be a better metaphor >  Apprenticeship and learning >  More focus on code

►  Vocabulary (pattern, typical architectural approaches) important

►  Strategic design – quality where it matters
