The document discusses aligning architecture practices with agile principles and delivery. It proposes that architecture can be viewed as a product in itself when it comes to enterprise and solution architecture. When architecture is the product, it can be delivered using agile practices to provide value early despite uncertainty. The document also discusses how agile principles apply to architecture values around decision quality, strategic alignment and performance. It suggests the relationship between agile and architecture depends on whether architecture is the product or enables information system changes.

1. solutioniser
school
Strange Bedfellows?
Agile and Architecture
Perth Solutioniser School, 14th April 2021 Meetup

2. 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
AND
We accept that ‘agile’ is a mindset focused on
empowering people to deliver value as early as
possible despite change and uncertainty
THEN
We’re aligned, let’s do ‘agile architecture’ and go home
Architecture
Agile
Delivering
Value
Managing
Change

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

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

5. solutioniser
school
Adjusting ‘agile’ to an architecture context …
Source: Epic Agile 2018
• 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.

6. solutioniser
school
Philosophy Break!
Source: Epic Agile 2018
• 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?
Architecture Products
Options
Decisions
Models & Roadmaps
Strategies
Standards & Policies
Information Systems Products
Information Systems
Information Systems Change

7. 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
• 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.
Information Systems Change-as-a-Product
• 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.

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

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

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

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

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

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

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

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

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

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

18. 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).

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

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

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

22. solutioniser
school
The O-AA Standard: Part 1 Comments
• 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?
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

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

24. solutioniser
school
</presentation>

25. solutioniser
school
Some additional notes …

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

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

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

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

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