Love your architecture - Alexander von Zitzewitz

15:44 © 2005-2015 hello2morrow 1

Love your Architecture

Alexander v. [email protected]

blog.hello2morrow.com

The single best thing you can do for the long term health, quality and maintainability of a non-trivial

software system is to carefully manage and control the dependencies between its different elements and

components by defining and enforcing an architectural blueprint over its lifetime.

02.05.23 © 2005-2015, hello2morrow 2

Loving Architecture equals Dependency Management

Because, if you don’t…

02.05.23 © 2005-2015, hello2morrow 3

Architecture of Apache-Cassandra (or what is left of it)

So, why is it not happening in every project?

“Software-Architects” rarely do architecture, i.e. dependency managementIf they do it, it is often informal (PowerPoint, Wiki etc.)That means it is hard to check conformity of code to architectural rulesRules that are not enforced will be brokenOften nobody in the team is really responsible for technical quality, and that includes architecture and structureAgile projects consider architecture as a side effect of a user storyWho has time for this??

02.05.23 © 2005-2015, hello2morrow 4

Understanding Technical Debt as a Metaphor

Ward Cunningham first defined the term in 1992:

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

02.05.23 © 2005-2015, hello2morrow 5

Categories of Technical Debt

Category Repair Cost Visible Impact

Maintainability Impact

Programming Low Medium Mostly low

Testing Potentially High High Medium

Local/Global Metrics Low / High Low Low / High

Architecture Very High Low Very High

02.05.23 © 2005-2015, hello2morrow 6

Agile Development and Architecture

The agile approach does not automatically create maintainable and well architected systems. Often the opposite is true. Ongoing management of Technical Debt is considered to be a critical success factor for high quality and maintainable software systems even by promoters of the agile approachArchitectural debt is a very toxic form of technical debtThat challenges the idea that software development should almost exclusively be driven by business valueProject size has obviously an important influence

02.05.23 © 2005-2015, hello2morrow 7

15:44 © 2005-2015, hello2morrow 8

Architectural Debt – Symptoms (Robert C. Martin)

Rigidity – The system is hard to change because every change forces many other changes.Fragility – Changes cause the system to break in conceptually unrelated places.Immobility – It's hard to disentangle the system into reusable components.Viscosity – Doing things right is harder than doing things wrong.Opacity – It is hard to read and understand. It does not express its intent well.

Overall: “The software starts to rot like a bad piece of meat”

Do you manage Technical/Architectural Debt?

Do you have binding rules for code quality? Do you measure quality rule violations on a daily base? Is your architecture defined in a formal way? Do you measure architecture violations on a daily base?Does quality management happen at the end of development? Does your current QM lead to sustainable results?Are there incentives for writing great code?

02.05.23 © 2005-2015, hello2morrow 9

How to give love to your Architecture

Define your architecture in a formal and enforceable way (we’ll get to the details)Use tools to check for violations of architecture rules, ideally with every commit or directly in the IDEBroken architecture rules have to be fixed while it is still easy to fix themAvoid cyclic dependencies between packages or higher level artifactsInvest about 20% of all development and maintenance effort into code hygiene and architecture

02.05.23 © 2005-2015, hello2morrow 10

Example : Cyclic Dependency

AlarmClock

AlarmHandler

Presentation Model

Main

AlarmToConsole

AlarmToFile

Breaking the Cycle

AlarmClock

<<abstract>>AlarmHandler

Main

<<interface>>IAlarmHandler

AlarmToConsole

AlarmToFile

Presentation<<bottom>>

Model

Introducing a DSL to describe Architecture

02.05.23 © 2005-2015, hello2morrow 13

Advantages of a DSL

Easy to read and understandWorks well with version control systems and can be diffedCan be changed without access to a toolMore powerful than just drawing boxesDifferent aspects can be described in independent filesArchitecture diagrams can be generatedArchitecture files can be generated from diagrams

02.05.23 © 2005-2015, hello2morrow 14

Components

A component is the atomic element of architectureUsually a single source file, in C/C++ a combination of header and source filesIs addressed via the relevant parts of its physical location

02.05.23 © 2005-2015, hello2morrow 15

Patterns address groups of components

Artifacts

Artifacts can contain components or other artifactsArtifacts have interfaces and connectorsAn interface is an incoming port granting access to a subset of components in artifactA connector is an outgoing port that can be connected to an interface of another artifactsConnections are only possible between connectors and interfacesEach artifact has a default connector and a default interface, both containing all components in the artifactsUser can restrict the default connector and the default interface

02.05.23 © 2005-2008, hello2morrow 16

Artifacts Example

02.05.23 © 2005-2015, hello2morrow 17

Encapsulation

© 2015, hello2morrow GmbH 18

Artifact 1

Artifact 2Connector

Artifact 1.1

Interface Unlimited nesting depth of artifactsEncapsulation: Controlling access via Interface (outside-in) and Connector (inside-out)

Now lets build an Architecture step by step

02.05.23 © 2005-2015, hello2morrow 19

Q & A

[email protected]