Architecture has an important role to play when deploying Agile at scale. In this session, we will take a look at Agile Architecture, its key building blocks, the mental model change that Agile Architecture requires and how it plays a critical role in supporting an organisation’s Digital-Agile Transformation success.
Emergent Methods: Multi-lingual narrative tracking in the news - real-time ex...
Agile Architecture – Enabling the Organisation’s Successful Digital-Agile Transformation
1. Agile Architecture – Enabling the
Organisation’s Successful Digital-
Agile Transformation
Tan Eng Tsze
Principal Lecturer & Consultant
Digital Strategy and Leadership
[Total Slides: 46]
#ISSLearningFest
2. 2
#ISSLearningFest
isstet@nus.edu.sg
Enterprise Architect with many years of experience in Digital and IT.
• Experience in Enterprise Architecture, Agile Architecture, Business Architecture, Data
Architecture, Application Architecture & Security Architecture
• Consulted and developed Enterprise Architecture for public and private sector and the most
recent for a Healthcare company, Gaming and Energy operators in Singapore; and also
advised on architecture implementation strategies to modernise their architectures to
transition towards a Digital Enterprise
• Master and Bachelor degrees in Computer & Information Science, NUS
• Professional certifications in TOGAF, Agile Architecture, SABSA, DPBoK, COBIT and ITIL
Tan Eng Tsze
3. Learning Outcome
Upon completion of this session, you will be able to understand:
The Digital-Agile Transformation
• The Need to Evolve Architecture
• Mental Model Shift that Agile Architecture Requires
• Open Agile Architecture
3
#ISSLearningFest
4. Digital and Agile Transformation go Hand-in-Hand
4
#ISSLearningFest
Figure source: Open Agile Architecture: A Standard of the Open Group
5. 5
#ISSLearningFest
Architecting The Dual Transformation
Two major drivers of Digital and Agile Transformation:
• Customer Experience which drives Digital Transformation
• The Project-to-Product (-to-Platform) shift which epitomizes Agile Transformation
Source: The Open Group Agile Architecture Standard
6. Most Digital Transformations are like this…what is
missing here?
6
Digital
Transformation
Strategy
Digital Design,
Development
& Deployment
Digital
Transformation
Strategy
Architecture
Digital Design,
Development
& Deployment
Linking Strategy
to Execution
#ISSLearningFest
7. 7
77 million
customer details
stolen
Service down for
X days
Costed USD $250
million
Operational Backbone and Digital Platform are
Linked
Source: Designed for Digital, Jeanne W. Ross etc, MIT Press, 2019,
#ISSLearningFest
8. 8
77 million
customer details
stolen
Service down for
X days
Costed USD $250
million
Contrasting Requirement for Operational
Backbone and Digital Platform
Source: Designed for Digital, Jeanne W. Ross etc, MIT Press, 2019,
Operational Backbone (Digitised) Digital Platform (Digital)
Targeted Outcomes Process efficiencies, predictability and reliability
leading to increased profitability
Rapid innovation of new digital offerings
leading to revenue growth
Technology Requirements Stable, scalable, secure operational systems;
automation of repetitive processes
Repositories of API-enabled business,
data and infrastructure components
Data Requirements Accurate and accessible transaction and master
data
Flexible repositories of big data (from
sources like sensors, social media etc)
for analytics
Process Requirements Deliberate, methodical design and implementation
of transaction-processing applications
Iterative design, development,
configuration and commercialization of
digital offerings
People Requirements Process owners and data architects; project leaders
for large projects
Platform architects; component owners
who can hypothesize, test and manage
functionality of components
#ISSLearningFest
9. Learning Outcome
Upon completion of this session, you will be able
to understand:
• the Digital-Agile Transformation
The Need to Evolve Architecture
• Mental Model Shift that Agile Architecture
Requires
• Open Agile Architecture
9
#ISSLearningFest
11. 11
77 million
customer details
stolen
Service down for
X days
Costed USD $250
million
#ISSLearningFest
Change in an Application is Inevitable
We need to support:
• New business requirements
• New non-functional requirements
• Updates to existing technologies
• New technologies
12. In the Digital-Agile@Scale Transformational
Enterprise, Architects are Challenged!
12
#ISSLearningFest
“If we’re going to have to
do a heavy-weight
architecture which plans
for two to five years into
the future, how can we
be agile? “
“Ideally, that pool of seniors in
your team act as a kind of
proxy architecture committee
and we don’t need to go to
someone who supposedly got
the title sitting in an ivory
tower for approval”
Though the architecture discipline is still needed, the architect’s role has
to evolve otherwise they are at risk of being marginalised
14. Intentional Architecture
14
• Definition: A purposeful set of statements, models and decisions that represent
some future architectural state
• Although Big Design Up-Front (BDUF) is incompatible with Agile ways of
working, Intentional Architecture is needed and valuable
• Some up-front intentional architecture prevents waste and accelerates decision-
making
• Intentional architecture should be simple, focused and compact because:
• It is likely to evolve so investing in a detailed model would be wasteful
• It is guided by guardrails imposed by governance
#ISSLearningFest
15. Emergent Architecture
15
• The best architectures, requirements, and designs emerge from self-
organizing teams ~ Agile Manifesto Principle 11
• Emergence refers to what appears, materializes, or surfaces when a
complex system operates; desired or undesirable functions or outcomes
emerge
• Process of producing deliverables without defining the design or
architecture upfront and allow the architecture to materialize over time in
order to be able to respond to change quicker
#ISSLearningFest
16. 16
#ISSLearningFest
Big Design Up Front vs No Big Design Up Front?
Provide some example projects in which you should do the
following:
1. Big Design Up Front
2. No Big Design Up Front
17. 17
#ISSLearningFest
Big Design Up Front
Here are some examples of projects for which you should do more design up front:
• Those with extremely stable requirements, with no changes expected on the
order of years
• Ones for highly isolated environments (for example, space travel, underwater
exploration), for safety reasons
• A project for which you've written the exact same piece of software before, with
the same group of people, with no scope changes (You'll get a deadly accurate
estimate for this one)
• Projects for highly constrained environments, such as embedded systems, to
make sure that you consider the constraints for that environment
18. 18
#ISSLearningFest
No Big Design Up Front
Types of projects for which you should not do too much up-front
design include:
• Projects with highly variable, changing requirements (on the
order of months or weeks), like most business applications
• Those that need to respond to external factors, such as market
conditions
• Projects for which you're not yet sure about many of the
business or technical details
19. Agile Architecture (1)
19
• Agile Architecture is leaner and combines intentionality and
emergence
• Agile Architecting aims at benefiting from emergence while minimizing
unnecessary complexity and undesirable outcomes
• And it avoids the overhead and delays associated with the start-stop-start
nature and large-scale redesign inherent with phase-gate processes and
Big Design Up-Front (BDUF)
#ISSLearningFest
20. Agile Architecture (2)
20
Agile Architecture is a set of values, practices and collaboration
that support the active, evolutionary design and architecture of a
system. This approach embraces the DevOps mindset, allowing
the architecture of a system to evolve continuously over time while
simultaneously supporting the needs of current users
~ Source: Agile Architecture in SAFe
#ISSLearningFest
21. 21
#ISSLearningFest
Agile Architecture (and Continuous Product
Development) (3)
MVA
Least possible set
of architecture done to
support the MVP to be released
MVP
Agile Architecture facilitates incremental changes to the
product or platform architectures
22. Agile Architecture (4)
22
Agile Architecting recommends using the levers below to mitigate
undesirable complexity growth:
• Modularity to facilitate team autonomy and increase resilience
• Standardization to facilitate product or operating model reconfiguration
• Architecting for a built-in responsiveness to change => Evolvability
• Relaxing control favors emergent over-designed or micromanaged
solutions which are often inferior
#ISSLearningFest
23. 23
#ISSLearningFest
Ability for Architecture to be Changed
• In a Digital and Agile world, the ability for
architecture to be changed or evolved
over time – is becoming a top-quality
attribute:
• The increasingly fast pace of the industry
• Adoption of Agile approaches at scale
• The Cloud-first nature of much new development
• The failure of expensive, high profile long-
running projects, etc
• The objective should be to architect a
system in such a way that will allow change
without damaging any non-functional
qualities
24. 24
#ISSLearningFest
Prefer Evolvable over Predictable
• Unknown unknowns are the nemesis of software
systems – things no one knew were going to crop up
yet have appeared unexpectedly
• This is why all Big Design Up Front (BDUF)
software efforts suffer – architects cannot design
for unknown unknowns
• Prefer to build evolvability into software – if
projects can easily incorporate changes, architects
do not need a crystal ball
• Architecture is not a solely upfront activity –
projects constantly change throughout their life
25. Agile Architecture (5)
25
Architecture designed in an agile context:
• Provides the Vision (Intentional Architecture) where
the team fits in with their development work
• Gives clear boundaries and guardrails for the agile
teams to make their own decisions ( Emerging
Architecture)
• Evolves with the cadence of iterative and incremental
development along the agile journey (Evolutionary
Architecture) and ensures a proper alignment
between intentional architecture (top-down) and the
architecture emerging from the agile teams (bottom-
up)
• Must be fit for purpose; do as much architecture work
as needed to build it just in time
• Breaks up the solution in pieces of work (iteration
size chunks) that can be taken further by different
teams
#ISSLearningFest
26. Learning Outcome
Upon completion of this session, you will be able to understand:
• The Digital-Agile Transformation
• The Need to Evolve Architecture
Mental Model Shift that Agile Architecture Requires
• Open Agile Architecture
26
#ISSLearningFest
27. 27
#ISSLearningFest
Mental Model Shift that Agile Architecture Requires
FROM TO
Aligning Business and IT Architecting the Whole Enterprise
Layered View of the Enterprise Segmenting the Enterprise
Inside-Out Outside-In
Requirements-Driven Value-Driven
Product Features Prioritization Business Results and Outcome
Prioritization
Sequential Concurrent
Big Design Up Front Continuous Architecture
28. 28
#ISSLearningFest
Architecturally Significant Decisions
Architecturally significant decisions fall into the
categories below. They define or modify:
• The way the enterprise is segmented
• The allocation of functions or activities to
segment
• The structural interfaces that link segments
• The standards or guardrails that facilitate
interoperability and composability
They are classified according to:
• Their degree of reversibility
• The breadth of their scope
29. 29
#ISSLearningFest
Make Decisions Reversible (1)
When architecture decisions arise, ask yourself:
•Do I need to make this decision now?
•Can I safely defer this decision?
•What can I do to make the decision reversible?
The biggest risk to irreversible decisions is deciding
before you need to. The biggest risk to reversible ones is
waiting until the last minute. Make reversible decisions
as soon as possible and make irreversible decisions
as late as possible (the last responsible moment) and
until you have more information.
30. 30
#ISSLearningFest
Make Decisions Reversible (2)
“Some decisions are Consequential and Irreversible or nearly irreversible – One-way Doors
– and these decisions must be made methodically, carefully, slowly, with great deliberation and
consultation. If you walk through and don’t like what you see on the other side, you can’t get
back to where you were before. We can call these Type 1 decisions.
But most decisions aren’t like that – they are Changeable, Reversible – they’re Two-way
Doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the
consequences for that long. You can reopen the door and go back through. Type 2 decisions
can and should be made quickly by high judgment individuals or small groups."
-- Jeff Bezos
Feature Toggles or in DevOps, Blue/Green Deployments or Service
Routing in Microservice are examples of techniques to make decisions
reversible
31. 31
#ISSLearningFest
Governance in the Face of Agile (1) – And The
Need to Rethink the Traditional IT Governance
Traditional IT Governance models:
• Appoint a decision-making body, for which names and composition vary; for example, an
IT executive committee or a large project committee, which may include the CEOs of
operational entities
• Set rules to determine which projects or programs will be reviewed, and what happens
when approval is denied
• Organize architecture reviews to inform Architecture Governance committee decisions
• Set up architecture offices to conduct reviews, define standards, and drive compliance
• Consolidate IT budgets and manage an enterprise-wide IT investment portfolio
• Track the utilization of IT resources to verify that once projects are approved, they follow
plans and comply with budget guidelines
Classical IT governance does not prevent large projects or programs from failing. Large
enterprises have experienced project or program failures resulting in several hundred
million dollar write-offs.
32. 32
#ISSLearningFest
Governance in the Face of Agile (2)
• Smaller number of projects that get reviewed by the IT Governance
Committees
• Fewer initiatives reach the minimum size to meet the threshold of IT
Governance
• Large projects are split into smaller pieces. These smaller pieces are
no longer projects but products delivered by Agile teams
• Teams of teams operate in rapid learning and decision-making cycles
• Most Agile teams are cross-functional and stream-aligned
• There are fewer standards and processes – standards now provide
context and define purpose. Candidate software products are
assessed against guardrails by agile teams in a bottom-up manner
33. 33
#ISSLearningFest
Agile Governance
Integrated Business/IT Governance
1. Quarterly Business Reviews verify that tribes fulfil their
commitments
2. Tribes are monitored by their sponsors, who
progressively release resources to match market
growth needs
3. Tribes evolve autonomously, paced by Agile
ceremonies
4. Post mortems are conducted during business reviews;
resource reallocation decisions take team performance
and business situations into account
• The integrated governance model does not isolate IT
investment decisions anymore. IT investments are a
subset of the investments made by the business to
develop new products or journeys. Investment
decisions are evaluated against business outcome
metrics.
• The Agile governance features need to be adapted to fit
the context, culture and maturity level of each
enterprise.
Source: The Open Group Agile Architecture Standard
34. 34
#ISSLearningFest
DevOps Principles
• Create with the End in Mind
• Continuous Delivery of Value
• Continuous Improvement
• Collaboration
• Design and Simplicity
• Feedback and Testing
• Automation
• Repeatability
• Culture and People
35. Learning Outcome
Upon completion of this session, you will be able to understand:
• The Digital-Agile Transformation
• Evolving Architecture
• Mental Model Shift that Agile Architecture Requires
Open Agile Architecture
35
#ISSLearningFest
37. Open Agile Architecture – Scope
37
#ISSLearningFest
Figure source: Open Agile Architecture: A Standard of the Open Group
38. Open Agile Architecture – Building Blocks
38
#ISSLearningFest
Figure source: Open Agile Architecture: A Standard of the Open Group
39. 39
#ISSLearningFest
What the Enterprise “Is”
• Analyzing what the enterprise
“is” starts by defining the
boundaries that connect:
• The enterprise to its environment
• The enterprise parts to each other
and to the environment
• Defining boundaries covers:
• Product Architecture
• Operations Architecture
• Organisation
• Domain-Driven Design Segmentation
41. 41
#ISSLearningFest
What the Enterprise “Does”
• Experience Design combines
customer research and product
discovery during a set of design
thinking iterations
• Journey Maps bridge outside-in
thinking with inside-out thinking by
defining which activities deliver the
experience customers expect
• Value Streams complement the
outside-in view by representing all
the activities
• Event Storming helps Agile teams to
explore the domain
43. Axioms for Agile Architecture
43
• Guidelines or restrictions that Agile
architects are recommended to
follow
• Adherence to these axioms will help
to guide the Digital and Agile
Transformation of the enterprise
#ISSLearningFest
44. Summary
The Digital-Agile Transformation
The Need to Evolve Architecture
Agile Architecture – Combines Intentional and Emergent
Architecture
Mental Model Shifts that Agile Architecture Requires
Open Agile Architecture
44
#ISSLearningFest
45. Give Us Your Feedback
#ISSLearningFest
Day 1 Programme