Agile Architecturein 10 Steps v1.0

A DA M B O CZ E K | 0 1 .20 15

MotivationAG IL E A R CHIT E CTUR E

Innovation Drives Business…

Evolutionary Innovation keeps your business running only and is not in focus of the business nowadays (e.g. VW Beetle).

Revolutionary Innovation guarantees nowadays the business success (e.g. electric car).

Disruptive Innovation changes existing or creates new markets causing old business to die (e.g. digital camera).

…and requires supporting IT.

Revolutionary or Disruptive Driven Business…

Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment and the principles guiding its design and evolution(IEEE1471 2007).

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. (Booch 2006)

Architecture is non-functional. Architecture is about Quality. (Graves 2010)

…needs Architecture, Agile Architecture.

Architecture Empowers…

Declarative knowledge is the type of knowledge that is, by its very nature, expressed in declarative sentences or indicative propositions.

Declarative knowledge focuses on the answer to the question “why am I able to do it”.

Procedural knowledge in opposition focuses on the answer to the question “how to do it”.

…Declarative Knowledge.

The Promise of the Agile Architecture

Reduction of risks throughout transparency, abstractions and partitioning

Precise definition and understanding of your business

Active collaboration of the domain and IT experts on the software design

Clean definition of the boundaries around abstractions

Better organization of your enterprise architecture

Agile, iterative, continuous and aim-oriented modeling

In-sync with the agile development process

Agile Architecture Focuses On Simplicity usingTransparency, Abstractions and Partitioning

Transparency investigates the “as-is” architectural state

Abstractions focus using models on the essential architectural challenges

Partitioning creates taxonomy for grouping architectural elements

…Complexity is the Disease, Simplicity is the Cure

Transparency Helps to Define As-Is and Desired State (as a Pillar of Empiricism)

1

3

2

Abstractions Help to Find Solutions to the Real World Problems

COMMUTING DIAGRAM TO EMPHASIZE MODELSWHEN SOLVING COMPLEX REAL WORLD PROBLEM*

1

2 3

4

Partitioning Helps to Structure the Functionality of a Software System

Reduces complexity of any system*

Closely related to a mathematical concept known as equivalence relations.

The most important equivalence relation, from the perspective of enterprise architecture, is synergy.

Two functions are synergistic when each requires the other to be effective.

Synergy is closely related to an inverse equivalence relation known as autonomy.

Design ProcessAG IL E A R CHIT E CTUR E

Business Architecture“4+1 View Model” by Chris Reynolds

Processes

EntitiesCommunication

Facades

GOALS

IT Architecture“4+1 View Model” by Philippe Kruchten

Development

DeploymentQuality

Functionality

SCENARIOS

Interaction Between Business and IT Architectures

“Impedance Mismatch”

Processes

EntitiesCommunication

Facades

GOALS

Development

DeploymentQuality

Functionality

SCENARIOS

Functional Domain N

Functional Domain B

Functional Domain A

Functional Domains Represent the Glue between Business and IT Architectures

Processes

Entities Quality

Functionality

Step 01Identification of the Business Domains

Business Entity Model (BEM)Shows Existing Objects and Their Relations

Used to get better understanding of the business, objects involved and their relationships.

These relationships define cardinalities to emphasis places with high complexity (as many-to-many is much more complex as one-to-one).

Notation used is based on the class diagrams of UML, however this model must not be understood as a class or data entity diagram.

Step 02Creation of a Business Entity Model

Ubiquitous LanguageStandardizes Communication of Stakeholders

Important to avoid misunderstandings in definition of the requirements and communication.

Initially based on the Business Entity Model.

Defines entities as well as actions based on the defined cardinalities.

Uses common syntax <verb object> e.g. create customer.

Step 03Creation of the Ubiquitous Language

Customer

Address

Order

Offer

Accommodation

Flight

Insurance

Offer

Process ArchitectureDefines the Scope of the Software System

Business processes consist of actions that are run in a specific order and as a result create, update or destroy business entities.

Due to their complexity it is important to use a process architecture as a taxonomy system for them.

Process architecture uses horizontal levels which represent various details of the modelled processes, from value chains down to sub-processes.

Step 04Definition of the Initial Process Architecture

Business Processes Taxonomy

Business Process Models

Level 0Value Chains

Level 1 Main Tasks

Level 2Process Map

Level 3End-to-End Process Models

Level 4Sub-process Models

Process ArchitectureModelling of the Core Business Processes

Models emphasis a certain aspects of the modelled object, thus create an abstraction of it. As a result it simplifies its analysis.

In case of business processes modelling focuses on the activities, their order and rules defining the flow and events.

Models at level 3 represent end-to-end processes.

Models at level 4 represent sub-processes.

Step 05Modelling of the Core Business Processes

Agile Architecture Uses Vertical Requirements

Processes

Presentation

Orchestration

Service

Persistence

Ver

tical

Req

uire

men

t1

Ver

tical

Req

uire

men

t2

Ver

tical

Req

uire

men

t…

Ver

tical

Req

uire

men

t…

Relevant horizontal layers

Define order

Step 06Definition of Vertical Requirements Based on Process Models

Presentation

Orchestration

Service

Persistence

Ver

tical

Req

uire

men

t1

Ver

tical

Req

uire

men

t2

Ver

tical

Req

uire

men

t…

Ver

tical

Req

uire

men

t…

1

2

3

How Much Architecture Remains Agile?

20-30% of

Planned Design

70-80% of

Emergent Design

EMERGENT DESIGN

You Ain’t Gonna Need It (YAGNI)

PLANNED DESIGN

Big Design Up-Front (BDUF)

Architectural effort scale

Agile Architecture

Agile Architecture is Based on the Lean Process Principles

Defer commitment and decide as late as possible

Deliver as fast as possible

See and optimize the whole

Work iterative and incremental

ITERATION

ARCHITECTURAL INCREMENT

1st2nd ...th

Construction FlavorAG IL E A R CHIT E CTUR E

Agile Architecture is Business Centric

Entities

Controllers

Ext. Interfaces

Use Cases

CLEAN ARCHITECTUREBY BOB MARTIN

Application specific

business rules

Technical interface adapters and

frameworks and drivers

Dependency Rules

Enterprise wide business rules

Agile Architecture is Multi Paradigm

Entities

Controllers

Ext. Interfaces

Use Cases

Entities

Controllers

Ext. Interfaces

Use Cases

Entities

Controllers

Ext. Interfaces

Use Cases

Active Record Domain Driven Design

Lambda/CQRS

Agile Architecture Uses Core Concepts of Domain Driven Design*

At the heart of DDD (Domain Driven Design) lies the concept of the domain model.

Domain models are typically composed of elements such as entities, value objects, aggregates, and described using terms from a ubiquitous language.

A bounded context is the context for one particular domain model and defines implementation boundaries.

* by Eric Evans

Business Domain Consists of Subdomains and Bounded Contexts

Sub-domain A

Sub-domainB

Sub-domainC

Bounded Context A

Sub-domainD

Bounded Context B

Sub-domainE

Bounded Context C

Bounded Context – technical boundarySub-domain – functional boundary

Up-stream/Down-streamrelationship

Business Domain

Step 07Definition of the Bounded Contexts

Commission and Billing

Sub-domain

Publisher Sub-domain

Advertiser Sub-domain

Core Bounded Context

Ad-TrackingSub-domain

TracingSub-domain

Streaming Bounded Context

Statistics/DWH

Sub-domain

Near-Real-time

Sub-domain

Reporting Bounded Context

Bounded Context – technical boundarySub-domain – functional boundary

Up-stream/Down-streamrelationship

Power Advertising Domain

Core 4 Quality (non-Functional) Attributes*that Drive Agile Architecture

Performance and Scalability - ability of a system to predictably execute within its mandated performance profile and to handle increased processing volumes in the future.

Availability and Resilience - ability of a system to be fully or partly operational as and when required and to effectively handle failures that could affect system availability.

Evolution - ability of a system to be flexible in the face of the inevitable change that all systems experience after deployment, balanced against the costs of providing such flexibility.

Security - ability of the system to reliably control, monitor, and audit who can perform what actions on which resources and the ability to detect and recover from security breaches.

* from Software Systems Architecture, Rozanski&Woods 2011

Architectural RisksShape Agile Architecture

Agile architecture focuses on risks by enforcing design to reduce them

Architectural decisions and their benefits are aligned with their costs

Architectural design is used in situations where it is likely to have the most pay-off*

* from Just Enough Software Architecture, Fairbainks, 2013

Business Domain/Quality Attribute Relevancy Matrix

BD/QA Relevancy Matrix helps to identify business domains where the QA in case of risks has the highest impact, thus pay-off if reduced

Domain A Domain B Domain C Domain D

Quality Attribute A High High

Quality Attribute B High High

Quality Attribute C High High

Quality Attribute D High

…

High impact thus in focus of Agile

Architecture

Step 08Definition of the BD/QA Relevancy Matrix

Sales Order Product Customer …

Performance and Scalability High High High

Availability and Resilience High High

Evolution High High

Security High

…

…

…

Solution StrategiesAre Backbone of the Agile Architecture

Solution strategies are core concept of the agile architecture due their focus on business value delivered by the solution

Solution strategies allow proper reasoning about architecture describing internal structure of the elements and collaboration between them

Best created using composite UML diagram type

Step 09Definition of the Solution Strategies

Building BlocksMake Business Architecture Part of IT

Building Blocks are counterparts to the Solution Strategies

They focus on the technical design used where it should have most pay-off

Similar to the solution strategies, building blocks describe elements and their relations

Best created using components UML diagram type

Step 10Definition of the Building Blocks

ConclusionAG IL E A R CHIT E CTUR E

Agile Architecture Process SummaryReview, Refine & Extend, Repeat

Review, Refine and Extend, RepeatLet the agile architecture grow

together with your system

Agile Architecture Process SummaryAll Artifacts at One Place

Level 0Value Chains

Level 1 Main Tasks

Level 2Process Map

Level 3End-to-End Process Models

Level 4Sub-process Models

Presentation

Orchestration

Service

Persistence

Ver

tical

Req

uire

men

t1

Ver

tical

Req

uire

men

t2

Ver

tical

Req

uire

men

t…

Ver

tical

Req

uire

men

t…

Sub-domain

A

Sub-domain

B

Sub-domain

C

Bounded Context A

Sub-domain

D

Bounded Context B

Sub-domain

E

Bounded Context C

Bounded Context – technical boundarySub-domain – functional boundary

Up-stream/Down-streamrelationship

Business Domain

Domain A

DomainB

Domain C

Domain D

Quality Attribute A High High

Quality Attribute B High High

Quality Attribute C High High

Quality Attribute D High

…

Agile ArchitectureTakeaways

Mo

tiva

tio

n

Risk reduction

Agility support

Des

ign

Pro

cess

Declarative knowledge

Transparency

Abstractions

Partitioning

Co

nst

ruct

ion

Fla

vor

Business-Centric

Multi-Paradigm

Risk-Driven

About Adam Boczek

Management Consultant @ codecentric AG

Architect since 1997, Agile protagonist since 2007, Coach, Manager

IT-Houses: Cirquent/NTT Data, LogicaCMG/CGI Group, CS Consulting AG/Capgemini, ACS/GFT Solutions

Customers: Provinzial Insurance, Deka Bank, Shell AG, Deutsche Bank, 1&1, SAP, NTT Data and more…

Adam’s main expertise areas:

• Enterprise Architectures, Agile Software Engineering & Project Management,

• Innovative Software Development Methods, Nearshore and Offshore Project Coordination

Agile Architecture coach, BPMN coach, AngularJS coach

Conference speaker: Berlin Expert Days 2014, Agile Dev Practices 2013, Manage Agile 2012 and more…

Adam’s connections: @nativeagile, http://nativeagile.com, http://boczek.com