In my latest ten years, working as an IT consultant in the area of enterprise architecture, I got more and more questions about combination of the agile software engineering (not just only development) and the enterprise architecture which comprises business and software architecture. Especially for the big organizations it is a challenging topic due to their internal culture and structure that doesn't really suit to the values and principles of "being agile" as defined by the Agile Manifesto. The main idea of the agile software engineering, besides the responsive, incremental and iterative development process, is to work in a *vertical* and not *horizontal* way. Only *vertical work*, defined e.g. in a form of a user story, can deliver business value as expected by the stakeholders. However this 90 degree turn in the way you work is the biggest problem especially in case of a big organization. It requires involvement of much more departments that work together *in parallel* comparing to the classical *horizontal work* with defined layers and responsibilities. This *vertical work* simply drill down your whole system thus affect many areas, especially architecture, which in this context has also *to be agile*, means that you have to think about agile architecture as a process of building a software system as well as a structure of it. You can find plenty books about architecture. Most of them describe *what* architecture is and *why* you should architect it (yes, it sounds a little bit strange but you actually *architect architecture*). However there are just few books that say *how* to do it. That is exactly what this presentation and my upcoming book is about. This “HOW to architect agile architecture”, based on my experience and examples from my current project where I work as a lead architect in one of the biggest insurance companies in Germany.

1. Agile Architecturein 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…
Architectureis 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).
Architecturerepresents the significant designdecisions that shapea system, where significant is measured by cost of change. (Booch 2006)
Architectureis non-functional. Architectureis about Quality. (Graves 2010)
…needs Architecture, Agile Architecture.

5. Architecture Empowers…
Declarative knowledgeis the type of knowledge that is, by its very nature, expressed in declarative sentences or indicative propositions.
Declarative knowledgefocuses 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 Promiseof 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 organizationof your enterprise architecture
Agile, iterative, continuous and aim-oriented modeling
In-sync with the agile development process

7. Agile Architecture Focuses On SimplicityusingTransparency, Abstractions and Partitioning
Transparencyinvestigates the “as-is” architectural state
Abstractionsfocus using models on the essential architectural challenges
Partitioningcreates taxonomy for grouping architectural elements
…Complexity is the Disease,
Simplicity is the Cure

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

9. AbstractionsHelp to Find Solutions to the Real World Problems
COMMUTING DIAGRAM
TO EMPHASIZE MODELS
WHEN SOLVING COMPLEX
REAL WORLD PROBLEM*
1
2
3
4

10. PartitioningHelps 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 aresynergistic 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
Entities
Communication
Facades
GOALS

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

14. InteractionBetween Business and IT Architectures
“Impedance Mismatch”
Processes
Entities
Communication
Facades
GOALS
Development
Deployment
Quality
Functionality
SCENARIOS

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

16. Step 01Identification 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 02Creation of aBusiness Entity Model

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

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

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

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

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

24. Step 05Modelling of the Core Business Processes

25. Agile Architecture Uses Vertical Requirements
Processes
Presentation
Orchestration
Service
Persistence
Vertical Requirement1
Vertical Requirement2
Vertical Requirement…
Vertical Requirement…
Relevant horizontal layers

26. Define order
Step 06Definition of Vertical Requirements Based on Process Models
Presentation
Orchestration
Service
Persistence
Vertical Requirement1
Vertical Requirement2
Vertical Requirement…
Vertical Requirement…
1
2
3

27. How Much Architecture Remains Agile?
20-30% ofPlannedDesign
70-80%ofEmergent 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
Use Cases
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
Use Cases
Entities
Controllers
Ext. Interfaces
Use Cases
Entities
Controllers
Ext. Interfaces
Use Cases
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 07Definition 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 asystem 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.
* fromSoftware Systems Architecture, Rozanski&Woods2011

36. 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*
* fromJust EnoughSoftware 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
DomainB
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

38. 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
…
…
…

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

40. Step 09Definition of the Solution Strategies

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

42. Step 10Definition of the Building Blocks

43. Conclusion
AGILE ARCHITECTURE

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

45. Agile Architecture Process SummaryAll 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
Vertical Requirement1
Vertical Requirement2
Vertical Requirement…
Vertical Requirement…
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
DomainB
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 ArchitectureTakeaways
Motivation
Risk reduction
Agility support
Design Process
Declarative knowledge
Transparency
Abstractions
Partitioning
Construction Flavor
Business-Centric
Multi-Paradigm
Risk-Driven

47. About Adam Boczek
Management Consultant @ codecentricAG
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: ProvinzialInsurance, DekaBank, 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, Nearshoreand Offshore Project Coordination
Agile Architecture coach, BPMN coach, AngularJScoach
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