Agile and Architecture: Strange Bedfellows in Perth

solutioniser school Strange Bedfellows? Agile and Architecture Perth Solutioniser School, 14thApril 2021 Meetup

solutioniser school Here is the answer, let s go home IF We accept that architecture is a practice that contributes value to the enterprise and/or to users by making reasoned decisions about change Architecture AND Delivering Value Managing Change We accept that agile is a mindset focused on empowering people to deliver value as early as possible despite change and uncertainty Agile THEN We re aligned, let s do agile architecture and go home

solutioniser school But hold on, it s a bit complicated Are we talking about agile architecture practice or doing architecture in the context of agile delivery? Does this apply equally to enterprise, solution and software architecture? Does this apply equally in the context of hierarchical enterprises, decentralised enterprises, ISVs etc.? [ we re agile | BDUF sucks | architecture is emergent | architecture is a tax | ] so we don t actually need architecture. A mindset doesn t tell me how.

solutioniser school How not to flog a dead horse Source: https://www.slideshare.net/AgileNZ/ahmed-sidky-keynote-agilenz

solutioniser school Adjusting agile to an architecture context Software Product Extending the software-focus of agile first principles to a broader set of work products is hopefully uncontentious. Development Delivery Customer Stakeholder When architecture is the product (more on this momentarily). Developer Architect The producer of the product. Source: Epic Agile 2018

solutioniser school Philosophy Break! Architecture Products Is architecture a product in itself? That is, under what circumstances might architecture be the product of delivery? If so, can this architecture-as-a- product be aligned with the agile mindset? That is, can we empower architects to deliver value as early as possible despite change and uncertainty? Options Decisions Models & Roadmaps Strategies Standards & Policies Information Systems Products Information Systems Information Systems Change Source: Epic Agile 2018

solutioniser school Towards a hypothesis for agile architecture Architecture-as-a-Product vs. Information Systems Change-as-a-Product is a key determinant how the agile mindset applies to the practice of architecture. Architecture-as-a-Product Information Systems Change-as-a-Product Premise: Architecture has inherent value to stakeholders worth more than alternative activities (or just don t do it). Premise: Analysis and planning can deliver to an organisation s strategic objectives more effectively than unstructured, uncoordinated change. Potential product value is a function of factors including organisational size, complexity and product suite. Real product value is an economy of effort and risk/benefit that might be adjusted using an agile mindset and techniques (e.g. lean). Typically applies to Enterprise Architecture and Enterprise Solution Architecture. Premise: Architecture does not add direct user value to the product and so must be minimised or eliminated. Premise: Architecture can nevertheless (in certain circumstances) deliver more value earlier than purely emergent architecture. Potential product value is a function of factors including platform maturity, interdependencies (consider enterprise vs. ISV), solution/product complexity and risk of major re-work. Real product value is an economy of effort and risk/benefit that might be adjusted using an agile mindset and techniques (e.g. lean). Typically applies to Solution Architecture and Software Architecture.

solutioniser school Architecture Value Drivers If agile is value-focussed, then what value do we deliver with architecture? Architecture Value Decision/Option Quality Doing the things right Delivery and Operational Performance Minimising investment and waste Strategic Alignment Doing the right things

solutioniser school Value Proposition for Architecture-as-a-Product Strategy, roadmaps and standards can streamline options definition, evaluation and selection (and specifically re-definition, re-evaluation and re-selection). Strategic and organisational context can be applied to planning and design in a way that product/project technologists are not enabled to consider (e.g. portfolio awareness). We can optimise for the enterprise as well as the specific solution. Enable quicker, better decision-making by agile delivery teams.

solutioniser school So, with our understanding of architecture as product vs. enabler, let s inspect the Agile Values and Principles for relevance in the domains of Enterprise, Solutions and Software architecture.

solutioniser school Agile Values Working Software Product over comprehensive documentation Individuals and Interactions over processes and tools Responding to Change over following a plan Customer Collaboration over contract negotiation That is, while there is value in the items below, we value the items above more. Adapted from http://agilemanifesto.org/

solutioniser school Agile Principles Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software product. Business people and developers architects must work together daily throughout the project. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Adapted from http://agilemanifesto.org/

solutioniser school Agile Principles The most efficient and effective method of conveying information to and within a development delivery team is face-to-face conversation. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Agile processes promote sustainable development delivery. The sponsors, developers architects, and users should be able to maintain a constant pace indefinitely. Working software product is the primary measure of progress. Adapted from http://agilemanifesto.org/

solutioniser school Agile Principles Simplicity the art of maximizing the amount of work not done is essential. Continuous attention to technical excellence and good design enhances agility. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. The best architectures, requirements, and designs emerge from self-organizing teams. Adapted from http://agilemanifesto.org/

solutioniser school Hasn t this nut been cracked? Wikipedia Agile architecture means how enterprise / system / software architects apply architectural practice in agile software development. Nup. Scaled Agile Frameworks Useful for placing architecture in the enterprise context for agile delivery but not for developing specific practice. e.g. SAFe (https://www.scaledagileframework.com/agile-architecture/) How does this definition deviate from architecture in general? Where does this definition tell me how? not just what. Mostly advice and truisms (Gregor Hohpe, https://www.agilearchitect.org/agile/principles.htm) Industry Standards/BoKs The Open Group s Open Agile Architecture Standard. More on this in a moment.

solutioniser school What do our scholars say? Gregor Hohpe ( https://architectelevator.com/ ) Are we talking about architecture as: The system? The doing? The people? Systems thinking says don t do change in isolation and expect system wide benefit. A rationale for the agile/architecture nexus: IF options become more valuable with uncertainty and architecture sells options, architecture becomes more valuable with increasing uncertainty. AND Agile methods are most valuable when we re dealing with high levels of uncertainty. THEN agile and architecture are addressing the same problem from different angles: architecture gives you the options to sustain velocity when the unexpected happens and agile gives you the attitude to always be learning and to quickly adapt to changing circumstances. Agile is the steering wheel, not the accelerator. Organizations can increase decision and execution discipline in several ways. So, next time someone touts the Agile panacea, remind them to bring some discipline first. Speed, agility, and sloppiness don t mix.

solutioniser school What do our scholars say? https://architectelevator.com/transformation/agile_architecture/

solutioniser school The Open Agile Architecture (O-AA) Standard Has The Open Group got our backs with the Open Agile Architecture Standard published late 2020? Disclaimer: The Open Group do good work and I genuinely appreciate the contribution of everyone who contributes (mostly volunteers) but I m going to be critical. Before I opine, I should read some sections in more detail and read the document twice (but haven t yet).

solutioniser school The O-AA Standard: Structure Introduction Definitions Part 1: The O-AA Core (Concepts & Rationale) Chapter 3: A Dual Transformation Chapter 4: Architecture Development Chapter 5: Intentional Architecture Chapter 6: Continuous Architectural Refactoring Chapter 7: Architecting the Agile Transformation Chapter 8: Agile Governance Chapter 9: Axioms for the Practice of Agile Architecture Part 2: The O-AA Building Blocks (Approaches & Techniques) Chapter 10: Building Blocks Overview Chapter 11: Agile Strategy Tenets Chapter 12: Agile Organization Chapter 13: Experience Design Chapter 14: Product Architecture Chapter 15: Journey Mapping Chapter 16: Lean Value Stream Mapping Chapter 17: Operations Architecture Chapter 18: Data Information and Artificial Intelligence (AI) Chapter 19: Event Storming Chapter 20: Domain-Driven Design: Strategic Patterns Chapter 21: Software Architecture Chapter 22: Software Engineering for Hardware

solutioniser school The O-AA Standard: General Comments A standard ? O RLY? It is not prescriptive. It offers advice and techniques for adaptation to specific situations. It could not be reasonably audited. I recall early drafts as framework . Perhaps it should have remained so. Despite noting that enterprise, solutions and software architecture have their respective, specific concerns, it does not clearly or consistently describe how the approaches and techniques offered are more or less relevant to the architecture sub-disciplines. [There is plenty of work for the architecture community to do here.] Given the Enterprise Architecture focus of The Open Group Architecture Forum, it is perhaps not surprising that commentary tends to fall back to this discipline even as many of the approaches and techniques presented may be seen as more suited to the implementation and product-focussed disciplines of Solution and Software Architecture. Some observations on governance are good and incorporate approaches we have already seen applied. Generally wordy and unfocussed. Perhaps a major revision might improve that the standard by: Clarifying Part 1 as conceptual/contextual framework for understanding the enterprise (rather than the necessary target of architecture work). Structuring Part 2 by architecture sub-discipline so that approaches and techniques can be presented per their relevance to each sub-discipline.

solutioniser school The O-AA Standard: Part 1 Comments Chapter 1: Introduction A single objective! This document is The Open Group Open Agile Architecture standard. The objective of this document is to cover both the Digital Transformation of the enterprise, together with the Agile Transformation of the enterprise. Is this SMART? No normative references! Chapter 2: Definitions 20 pages but no definition of Agile . Buzzword Bingo level 9000 unlocked. Chapter 3: A Dual Transformation Advocates for simultaneous Agile Transformation and Business Transformation. Chapter 4: Architecture Development Advocates for a combination of emergent and intentional architecture. Chapter 5: Intentional Architecture Type 1 vs Type 2 decisions. Chapter 8: Agile Governance Observations generally good.

solutioniser school The O-AA Standard: Part 1 Comments The scope of this document covers the enterprise as a whole, not just the alignment of business and IT It includes designing the enterprise business, organization, and operating models, which is the responsibility of senior executives who can be assisted by management consultants or Enterprise Architect profiles Enterprise Architecture in this context will become more like an internal management consultancy, which implies that Enterprise Architects must develop their management consulting skills to include relationship building, problem solving, coaching, and negotiation and well as specialty skills, such as product management, design thinking, and Lean management. The range of skills that should be considered part of the Enterprise Architect role includes the disciplines needed for management consultants who design business and operating models. Open Agile Architecture pp. 39 Is the borderline cosmological extension of architecture scope to matters of organisational culture, organizational design and the like an example of divergent/convergent thinking or overreach? The scope of this document might, indeed, seem appropriate for Enterprise Architecture and I would concur that well-executed Enterprise Architecture quickly evolves as an internal consulting service but is it relevant to the agile practice of architecture?

solutioniser school The O-AA Standard: Axioms 1. Customer Experience Focus 2. Outside-in Thinking 3. Rapid Feedback Loops 4. Touchpoint Orchestration 5. Value Stream Alignment 6. Autonomous Cross-Functional Teams 7. Authority, Responsibility and Accountability Distribution 8. Loosely-Coupled Systems 9. Modular Data Platform 10. Simple Common Operating Principles 11. Partitioning Over Layering 12. Organisation Mirroring Architecture 13. Organisational Levelling 14. Bias for Change 15. Project to Product Shift 16. Secure By Design

solutioniser school </presentation>

solutioniser school Some additional notes

solutioniser school The Open Agile Architecture Standard Chapter 4: Architecture Development Architecture development styles. Advocates a combination of emergent and intentional architecture. Emergence Modularity, standardization and architecting for responsiveness to change. Agile architecting steers the evolution of the enterprise by modifying its organization and changing the allocation of authority, responsibility and accountability. Intentional BUFD continuous architecture Quoting Colien: Some upfront, intentional architecture prevents waste and accelerates decision making Driving architecture from requirements is a mistake Intentional architecture should focus on the essence not the functionality of the system Partitioning/segmentation enables autonomous evaluation of parts Other points System evolution makes investment in detailed models wasteful Is guided by guardrails imposed by governance Concentrating on important stuff will make the model easier to understand Concurrent, Continuous and Refactored Adopts Set-Based Concurrent Engineering from Lean Product Development Simultaneous explore multiple solutions for every subsystem Aggressively explore them with rapid, low-cost analysis/tests and eliminate weak solutions Converge on a solution only after it is proven Tailoring Architecture Development Document modules enable formulation of architecture development approaches to solve specific enterprise problems

solutioniser school The Open Agile Architecture Standard Chapter 5: Intentional Architecture Elaborates on Architecturally Significant Decisions Type 1 vs. Type 2 for each decision scope Would we consider COTS implementation and bespoke development scenarios Type 1 or Type 2? Architecture Decision Records! Shifts between enterprise/organisation and product context a lot without describing how/why.

solutioniser school The Open Agile Architecture Standard Chapter 6: Continuous Architectural Refactoring Focus is on software architecture Conditions Constraints Fitness functions Test for a specific system characteristic Guardrails Implemented via governance group. If you stick to the guardrails the group approives your chooices It may not be possible to comply. This is a trigger for consideration. They are not absolute; they require collaboration. Technical Environment Continuous Delivery Feature Toggles are a great technique but do they belong in this standard and without reference to any other similar software development techniques? Componentisation

solutioniser school The Open Agile Architecture Standard Chatper 7: Architecting the Agile Transformation Recommend concurrent digital and agile transformation (i.e. adoption of new ways of working). Inevitable Spotify model example.

solutioniser school The Open Agile Architecture Standard Chapter 8: Agile Governance Description and review of classical IT governance. Agile Governance not compatible with command and control thinking. Four levels: Shared purpose Shared consciousness of the operating environment Guardrails Feedback loops to adjust the behaviour of autonomous teams The Design Authority can be adapted to this scope, promoting products, platforms and services rather than gatekeeping individual systems or system changes.