Adam boczek 2015 agile architecture in 10 steps v1.0
- 1. Agile Architecture in 10 Steps v1.0 ADAM BOCZEK | 01.2015
- 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.
- 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
- 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
- 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