This document outlines a 10 step process for developing agile architecture. It begins by discussing how innovation drives business and the need for supporting IT architecture. The 10 steps include: identifying business domains; creating a business entity model; defining a ubiquitous language; defining an initial process architecture; modeling core business processes; defining vertical requirements; defining bounded contexts; creating a BD/QA relevancy matrix; defining solution strategies; and defining building blocks. The goal is to develop an architecture that reduces risks, supports business agility, and focuses on simplicity through transparency, abstractions and partitioning.

1. Agile Architecture
in 10 Steps v1.0
ADAM BOCZEK | 01.2015

2. Motivation
AGILE ARCHITECTURE

3. 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.

4. 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.

5. 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.

6. 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

7. Agile Architecture Focuses On Simplicity using
Transparency, 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

8. Transparency Helps to Define As-Is and
Desired State (as a Pillar of Empiricism)
1
3
2

9. Abstractions Help to Find Solutions to the
Real World Problems
COMMUTING DIAGRAM
TO EMPHASIZE MODELS
WHEN SOLVINGCOMPLEX
REALWORLD PROBLEM*
1
2 3
4

10. 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.

11. Design Process
AGILE ARCHITECTURE

12. Business Architecture
“4+1 View Model” by Chris Reynolds
Processes
EntitiesCommunication
Facades
GOALS

13. IT Architecture
“4+1 View Model” by Philippe Kruchten
Development
DeploymentQuality
Functionality
SCENARIOS

14. Interaction Between Business and IT
Architectures
“Impedance
Mismatch”
Processes
EntitiesCommunication
Facades
GOALS
Development
DeploymentQuality
Functionality
SCENARIOS

15. Functional Domain N
Functional Domain B
Functional Domain A
Functional Domains Represent
the Glue between Business and IT Architectures
Processes
Entities Quality
Functionality

16. Step 01
Identification of the Business Domains

17. 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.

18. Step 02
Creation of a Business Entity Model

19. Ubiquitous Language
Standardizes 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.

20. Step 03
Creation of the Ubiquitous Language
 Customer
 Address
 Order
 Offer
 Accommodation
 Flight
 Insurance
 Offer

21. Process Architecture
Defines 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.

22. Step 04
Definition of the Initial Process Architecture
Business
Processes
Taxonomy
Business
Process Models
Level 0
Value Chains
Level 1
MainTasks
Level 2
Process Map
Level 3
End-to-End Process Models
Level 4
Sub-process Models

23. Process Architecture
Modelling 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.

24. Step 05
Modelling of the Core Business Processes

25. Agile Architecture Uses Vertical Requirements
Processes
Presentation
Orchestration
Service
Persistence
VerticalRequirement1
VerticalRequirement2
VerticalRequirement…
VerticalRequirement…
Relevant
horizontal layers

26. Define order
Step 06
Definition of Vertical Requirements
Based on Process Models
Presentation
Orchestration
Service
Persistence
VerticalRequirement1
VerticalRequirement2
VerticalRequirement…
VerticalRequirement…
1
2
3

27. 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

28. 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
1st
2nd ...th

29. Construction Flavor
AGILE ARCHITECTURE

30. Agile Architecture is
Business Centric
Entities
Controllers
Ext. Interfaces
UseCases
CLEAN ARCHITECTURE
BY BOB MARTIN
Application
specific
business rules
Technical interface
adapters and
frameworks and
drivers
Dependency Rules
Enterprise wide
business rules

31. Agile Architecture is
Multi Paradigm
Entities
Controllers
Ext. Interfaces
UseCases
Entities
Controllers
Ext. Interfaces
UseCases
Entities
Controllers
Ext. Interfaces
UseCases
Active Record Domain Driven
Design
Lambda/CQRS

32. 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

33. Business Domain Consists of
Subdomains and Bounded Contexts
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 boundary
Sub-domain – functional boundary
Up-stream/Down-stream
relationship
Business Domain

34. Step 07
Definition of the Bounded Contexts
Commission
and Billing
Sub-domain
Publisher
Sub-domain
Advertiser
Sub-domain
Core Bounded Context
Ad-Tracking
Sub-domain
Tracing
Sub-domain
Streaming Bounded Context
Statistics
/DWH
Sub-domain
Near-
Real-time
Sub-domain
Reporting Bounded Context
Bounded Context – technical boundary
Sub-domain – functional boundary
Up-stream/Down-stream
relationship
Power Advertising Domain

35. 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

36. Architectural Risks
Shape 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

37. 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
AttributeA High High
Quality
Attribute B High High
Quality
AttributeC High High
Quality
Attribute D High
…
High impact thus
in focus of Agile
Architecture

38. Step 08
Definition 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
…
…
…

39. Solution Strategies
Are 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

40. Step 09
Definition of the Solution Strategies

41. Building Blocks
Make 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

42. Step 10
Definition of the Building Blocks

43. Conclusion
AGILE ARCHITECTURE

44. Agile Architecture Process Summary
Review, Refine & Extend, Repeat
Review, Refine and Extend, Repeat
Let the agile architecture grow
together with your system

45. Agile Architecture Process Summary
All Artifacts at One Place
Level 0
Value Chains
Level 1
Main Tasks
Level 2
Process Map
Level 3
End-to-End Process Models
Level 4
Sub-process Models
Presentation
Orchestration
Service
Persistence
VerticalRequirement1
VerticalRequirement2
VerticalRequirement…
VerticalRequirement…
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 boundary
Sub-domain – functional boundary
Up-stream/Down-stream
relationship
Business Domain
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
…

46. Agile Architecture
Takeaways
Motivation
Risk reduction
Agility support
DesignProcess
Declarative
knowledge
Transparency
Abstractions
Partitioning
ConstructionFlavor
Business-Centric
Multi-Paradigm
Risk-Driven

47. 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