Agile Solution Architecture and Design

Agile Solution Architecture
and Design
Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney
https://www.amazon.com/dp/1797567616

The Enemy Of A Good Solution Is The Dream Of A
Perfect Solution
It is even better to act quickly and err than to hesitate until the time
of action is past.
Carl von Clausewitz
A good plan violently executed now is better than a perfect plan
executed next week.
George S. Patton
May 4, 2020 2

Introduction
• This describes systematic, repeatable and co-ordinated
approach to agile solution architecture and design
• It is intended to describe a set of practical steps and activities
embedded within a framework to allow an agile method to be
adopted used
• This approach ensures consistency in the assessment of
solution design options and in subsequent solution delivery
• It leads to the design and delivery of realistic and achievable
solutions that meet real solution consumer needs
• It provides for effective solution decision-making
• It generates results and options quickly
• It creates a knowledgebase of previous solution design and
delivery exercises that leads to an accumulated body of
knowledge within the organisation
May 4, 2020 3

Contents
The Solution
Solution Context
Solution Component Types
Solution Topography
The Agile Solution
Agile Context
Solution Monolith
Solution Stakeholders And Solution
Consumers
Organisation Solution Design And
Delivery Waste
Integrated Solution Design And Delivery
Agile Approach To Solution Architecture
And Design
Introduction
Agile Enablers, Techniques, Controls and
Principles
Principles
Success Factors
Time Limits
Solution Design And Delivery
Management
Solution Requirements
Solution Design and Delivery Estimates
Solution Configuration Management
Management And Planning Of The
Solution Design And Delivery Process
Supporting Tools And Technologies
Risk Management
Quality Management And Validation
Workshops
Prototyping
Pre-Solution Design and Delivery
Solution Feasibility Analysis And Study
Solution Framework and Scope Definition
Overall Solution Architecture Design
Solution Architecture Design Iterations
Solution Components Design And
Implementation
Individual Solution Component Delivery
Iterations
Overall Solution Design and Individual
Solution Component Design Interactions
Post-Solution Design and Delivery
May 4, 2020 4

Solution Is The Sum Of Its Components
• The solution is a window to its constituent components
• Solution consumers experience the totality of the solutions
May 4, 2020 6

The Solution …
• … Is what gets implemented and made operational by the
design and delivery process
• A deep understanding and knowledge of the solution – its
purposes, scope, constraints - is critical to the success of
the process
• Without this understanding the solution design and
delivery process will fail, fully or partially
• Once of the complete scope of the solution is accepted ad
understood the actual solution complexity and its impact
on solution deliverability can be comprehended
• You cannot separate the solution and its design from its
delivery and implementation
May 4, 2020 7

Staged And Iterated Solution Design
May 4, 2020 8
Changes to Existing Systems
New Custom Developed Applications
Information Storage Facilities
Acquired and Customised Software Products
System Integrations/Data Transfers/Exchanges
New Business Processes
Organisational Changes, Knowledge Management
Reporting and Analysis Facilities
Existing Data Conversions/Migrations
Changes to Existing Business Processes
New Data Loads
Training and Documentation
Central, Distributed and Communications Infrastructure
Application Hosting and Management Services
Cutover/Transfer to Production
Parallel Runs
Enhanced Support/Hypercare
Sets of Maintenance, Service Management and Support Services
Operational Functions and Processes
Sets of Installation and Implementation Services
Solution Delivery From Design To Operations
Components Must
Converge To Create
Solution
Stage 1
Stage 2
Stage 3
The design and delivery of
the solution components
can be accomplished in
stages

Extent Of The Complete Solution Design
• Complete solution design is the sum of all components of
each component type
• Ignoring some of these components will not make them
disappear or be unnecessary to the design, delivery and
successful operation and use of the solution
May 4, 2020 9
Number of
Component
Types
ΣComplete
Solution = Component
Type
i = 1
Σ Component
Individual
Component
of Type i
j = 1
i j

Solution Design To Operations
• Design-to-Operations view of solution means all aspects of the solution design are
considered
• The solution is only complete when all its constituent components are operational
• The implementation of the individual components must converge at some point
during the solution delivery phases
May 4, 2020 10
Operation
And Use
Idea
Solution Delivery Journey and Solution Design Scope

Component Types And Their Classification
1. Core Technical Delivery – acquisition and configuration
or development technical component types
2. Extended Technical Delivery – technical component
types involved in making the solution usable and putting
it into production
3. Extended Organisation Change – solution component
types relating to organisational changes
May 4, 2020 11

Core And Extended Solution Type Classifications
May 4, 2020 12
Changes to Existing
Systems
New Custom
Developed
Applications
Acquired and
Reporting and
Analysis Facilities
System Integrations/
Data Transfers/
Exchanges
Acquired and
Customised Software
Products
Changes to Existing
Business Processes
New Business
Processes
Organisational
Changes, Knowledge
Management
Training and
Documentation
New Data Loads
Central, Distributed
and Communications
Infrastructure
Operational
Functions and
Processes
Existing Data
Conversions/
Migrations
Cutover/ Transfer to
Production And
Support
Parallel Runs
Information Storage
Facilities
Sets of Installation
and Implementation
Services
Enhanced Support/
Hypercare
Sets of Maintenance,
Service Management
and Support Services
Application Hosting
and Management
Services
Extended Organisation Change
Extended Technical Delivery
Core Technical Delivery

Solution Component Types
• This just one solution component classification approach – others are possible
• Having a structured classification and decomposition approach allows the likely
components of a solution to be characterised quickly and to be worked on
individually in the context of the overall solution
• The solution component framework can be used throughput subsequent design
and delivery activities
• In this solution component type classification, components such as:
− Sets of Installation and Implementation Services
− Parallel Runs
− Enhanced Support/ Hypercare
− Sets of Maintenance, Service Management and Support Services
− Application Hosting and Management Services
− Training and Documentation
• Are not discrete or independent – one solution component can apply to or be
connected with multiple other solution components
• These specific components can be regarded as the glue that brings and holds the
functional and operational solution components together as live solutions
May 4, 2020 13

Scope Of Solution Component Types – 1/3
May 4, 2020 14
Solution Component
Type
Description
Modifications and enhancements to existing IT systems, either custom developed or acquired
products, that will form part of the overall solution, including the definition of the scope of
the work
New Custom Developed
Applications
New custom developed IT applications that will form part of the overall solution, including
the definition of the scope of the work
Acquired and Customised
Software Products
Packaged IT applications that are configured and customised that will form part of the overall
solution, including any product acquisition and supplier and product evaluation and selection
System Integrations/ Data
Transfers/ Exchanges
Scheduled and ad hoc data transfers and exchanges of different types such, as batch or real
time, between solution components including data transformations or application level
integrations such as application interfaces, remote calls, messaging interfaces or services
with associated results and data being communicated. This also includes the infrastructures
required to enable and support this and its management
Reporting and Analysis
Facilities
Reporting and analysis facilities including the implementation and configuration and
customisation of any underlying toolsets, associated reporting tools and data structures,
specific report and analyses and related functionality
Sets of Installation and
Implementation Services
Services acquired from third party suppliers to install, implement, configure and get
operational hardware and software components of the solution, including the specification
of these services
Internally installed data storage infrastructure, either existing or new, or externally provided
data storage facilities including their installation, customisation and provision of data access.
This includes any data storage software such as database management systems and other
elements

May 4, 2020 15
Solution
Component Type
Description
Existing Data
Conversions/
Migrations
Migration of data held in old systems to the new solution, including data transfer and
aggregation/transformation and the design and specification of associated target data structures
New Data Loads
Modifications and enhancements to existing IT systems, either custom developed or acquired
products, that will form part of the overall solution, including the definition of the scope of the work
Central, Distributed
and Communications
Infrastructure
Information technology infrastructure, either installed on-premises or in co-located or outsourced
facilities or provided by an XaaS arrangement, of any type, dedicated or shared, that is required to
allow components of the solution to operate
Cutover/ Transfer to
Production And Support
Sets of services required to put the solution and its constituent components into production
including organisational readiness, go live preparation and operations acceptance testing
Operational Functions
and Processes
Service management processes required to enable the solution to operate including incident,
problem, change, service request, asset and other processes and the resourcing of the support and
operational functions. This includes the implementation of new operational processes and the
integration of the solution into existing processes
Parallel Runs
If the solution replaces or extends an existing solution, the old and new solutions may need to
operate in parallel for an defined interval or until defined exit criteria have been met. This includes
the definition of the parallel run processes, the exit criteria and the additional resources needed to
perform the parallel runs
Enhanced Support/
Hypercare
Immediately after the solution goes live, an enhanced level of support may be required for a defined
interval or until defined exit criteria have been met. This includes the definition of the hypercare
required and how long it should last

May 4, 2020 16
Solution
Component Type
Description
Sets of Maintenance,
Service Management and
Support Services
Different solution components will require different types of maintenance and support
arrangements. These services may be provided internally or acquired from external suppliers. This
includes the design and specification of the support and maintenance arrangement and their
acquisition from third parties and the implementation of the arrangements
Application Hosting and
Management Services
Some of the solution components may be hosted outside the organisation either through cloud
service providers or outsourcing arrangements. This includes the design and specification of the
hosting services and their acquisition
Changes to Existing
Business Processes
Solutions exist to enable business processes to be operated. Existing business processes may need
to be redesigned to take advantage of or to efficiently use the facilities of the solution and its
components. This includes the redesign of the processes, the implementation of those changes
and any process or standards documentation and training required
New business processes may need to be defined, either entirely new ones or ones to replace
existing processes, to operate the solution. This includes the redesign of the processes, the
implementation of those changes and any process or standards documentation and training
required
Organisational Changes,
Knowledge Management
Organisation changes may be required to operate the solution. This can include additional
resources or redeployment of existing resources, new role types, new organisation structures and
new locations. This includes the design of these organisation changes. New knowledge
management facilities may be required to support the business operation and use of the solution
Training and
Documentation
Training and supporting documentation may ne required across some or all of the solution
components at different levels and aimed at different solution consumer types, both business and
operational

Solution Components And Design And Delivery
Team Roles And Skills
• Each of the solution component types will require different
skills to design and implement
• The solution design and delivery team will needs access to
those skills
• Knowing the true scope of the solution will allow the
required skills to be identified and obtained
May 4, 2020 17

Team Roles And Skills – 1/2
May 4, 2020 18
Solution Component Type Team Skills
• Knowledge of existing systems
• Software analysis, design, development and testing
• Software development and testing
• Software analysis, design, development and testing
• Solution evaluation
• Procurement and supplier negotiation
• Specific product implementation and customisation skills
System Integrations/ Data Transfers/ Exchanges
• Data architecture and integration
• Data integration and transformation platform skills
• Data visualisation and reporting
• Data analytics
• Data warehouse design
• Data extraction, transformation and load
Sets of Installation and Implementation Services • Specific production implementation and installation skills
• Database design, management and administration
• Data architecture and integration
• Data infrastructure and storage platforms
Existing Data Conversions/ Migrations
• Data profiling and analysis
New Data Loads
• Data profiling and analysis
Central, Distributed and Communications
Infrastructure
• Communications infrastructure
• Technology infrastructure

Team Roles And Skills – 2/2
May 4, 2020 19
Solution Component Type Team Skills
Cutover/ Transfer to Production And Support
• IT service management
• Service analysis and design
• Operations acceptance testing
Parallel Runs
Enhanced Support/ Hypercare
Sets of Maintenance, Service Management and Support
Services
• Procurement and supplier negotiation
• Infrastructure
• Business analysis
• Process design
• Organisation change management
• Process design
• Knowledge management
• Documentation
• Training

Solution Component Specific Design And Delivery
Issues
• Each of the solution components of each type will have
individual design and delivery issues and concerns
• These should be considered for each solution component
to assess their impact of the design and deliverability of
the component
• The outcome of the assessment may lead to changes in
the solution design options
May 4, 2020 20

Issues – 1/5
May 4, 2020 21
Solution Component Type Some Questions, Issues and Concerns
• Ease of changing
• Ability to change
• Availability of skills and ability to make changes
• Existing change backlog
• What are the impacts and dependencies on other activities?
• Can the changes be avoided or minimised both in number and size
Applications
• Are customised applications required?
• What development and deployment platform should be used?
• What is the long-term support and maintenance plan?
• How will then be interfaced with and used?
Acquired and Customised Software
Products
• What is the process for procuring products from suppliers?
• How good a fit is the proposed product?
• How easily and quickly can the products be implemented and customised and what
skills are needed?
• How are the customisations supported and maintained?
• What are the application and data integration issues?
• Are the products hosted internally or externally?
• What infrastructure is needed to run the product?
• How many integration, data transfers and exchanges are needed?
• What transfer approach(es) are proposed?
• Does the integration infrastructure already exist?
• What integration tools are being proposed?
• What is the proposed frequency of integrations?
• What is the number of integration transactions and the volumes of data?

Issues – 2/5
May 4, 2020 22
• Can existing reporting, visualisation and analytics facilities be used or are new ones
required?
• How will reporting and analytics be deployed
• Can existing data reporting structures (data warehouses, data marts) be used or are
new ones required?
• What data extraction, transformation and load facilities are required to enable and
support reporting and analytics?
• How many data sources will be used for reporting
• How much reporting and analysis is required?
• What solution components require installation and implementation?
• From whom will the services be procured?
• What handover will be required?
• What long-term support arrangements will be required?
• How long with the installation and implementation take?
• How many data storage facilities – hardware and software - will be required?
• Where will they be located?
• Are they existing or new facilities?
• If they are new, what are the provisioning issues, requirements and costs?
• What are the expected data volumes and throughputs?
• What is the approach to data backup, recovery, retention and archival?
Existing Data Conversions/
Migrations
• How much data needs to be migrated?
• How well-defined is the source data?
• What are the data quality and transformation requirements and issues?
• What data conversion/migration facilities are available?

Issues – 3/5
May 4, 2020 23
New Data Loads
• How much new data is required to make the solution usable?
• Where will the data come from and how much processing is required to make it
usable?
• What is the approach to data governance and management?
• What is the approach to master and reference data management?
Central, Distributed and
Communications Infrastructure
• What technology infrastructure is required?
• Where will the infrastructure be located?
• How much existing infrastructure can be reused?
• What infrastructure installation and configuration services are required?
Cutover/ Transfer to Production And
Support
• What is the approach to transferring the solution to production?
• What is the approach to organisation change management?
• What service management processes need to be updated to accommodate the
operation of the solution?
• Who will made the service management process changes?
• What changes – training, staffing, new structures - need to be made the operational
functions to accommodate the solution?
• Who will made the operational function changes?
Parallel Runs
• How many parallel runs are required after the solution goes live?
• What additional resources will be needed to support the parallel runs?
• What are the exit deciding factors to stop the parallel runs?

Issues – 4/5
May 4, 2020 24
• What level of enhanced support will be required after the solution goes live?
• What will be the approach to providing enhanced support?
• How long will enhanced support be required for?
• What are the exit deciding factors to stop the enhanced support?
• Who will provide enhanced support?
Sets of Maintenance, Service
Management and Support Services
• What solution components will require maintenance services?
• Who will provide the maintenance services?
• What is the scope and extent of the maintenance services?
• What maintenance service transition is required?
• How will the maintenance services be managed and reported on?
• What solution components will require support services?
• Who will provide the support services?
• What is the scope and extent of the support services?
• What support service transition is required?
• How will the support services be managed and reported on?
Application Hosting and Management
Services
• What solution components will be hosted externally?
• Who will provide the hosting services?
• What connectivity will be required to the hosting service provider(s)?
• How will security be managed?
• What hosting model(s) will be adopted?
• How will the hosting services be managed and reported on?

Issues – 5/5
May 4, 2020 25
Changes to Existing Business
Processes
• What existing business processes will need to be changed to support the use the
solution?
• Who will design, validate and implement the changed business processes?
• What training will be required in the changed business processes?
• What additional material will be required to support the changed business
processes?
• What new business processes will need to be implemented to support the use the
solution?
• Which existing business processes will be replaced by the new processes, if any?
• Who will design, validate and implement the new business processes?
• What training will be required in the new business processes?
• What additional material will be required to support the new business processes?
Organisational Changes, Knowledge
Management
• What organisational changes – new or changed functions, new locations, new or
changed roles – will be required to enable the effective use of the solution?
• What effort will be required to implement the changes?
• What approach to organisation change management will be adopted?
• What approach to knowledge management will be adopted?
• What knowledge management facilities will be required?
• How will knowledge management be initially loaded with information?
• How much training of what types and formats will be required?
• What approach to training will be adopted?
• What documentation of what types will be required?

Solution Component Dependency Map
• Solution components will depend on one another
− Complex solutions with many components will have many
dependencies
• These dependencies affect
− When detail about the component is known
− When the component can be scheduled to be implemented
− When it can be tested
− When it can be put into operation
• Knowing solution component dependencies allows for
− Effective and efficient scheduling of activities
− Avoidance of wasted efforts
• Solution component dependencies need to be mapped using
solution configuration management approach
May 4, 2020 26

Depth And Breadth Of Solution With Component
Dependencies
May 4, 2020 27
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Applications
Products
Migrations
New Data Loads
Cutover/ Transfer to Production
And Support
Operational Functions and
Processes
Parallel Runs
Management Services
Processes
Management

Outline Solution Component Implementation In
Overall Solution Design And Delivery
• Different solution components will be implemented at
different stages of solution design and delivery
• This will affect when resources are required to work on the
solution components
• It will also impact when dependent solution components
can be implemented
• Knowing when solution components are required will
allow intelligent and effective of scheduling of solution
design and delivery activities
May 4, 2020 28

Outline Solution Component Implementation
Phasing In Overall Solution Design And Delivery
May 4, 2020 29
Solution Component Type Solution Delivery Phase
Start Early Middle Late Go Live
System Integrations/ Data Transfers/ Exchanges
Sets of Installation and Implementation Services
Existing Data Conversions/ Migrations
New Data Loads
Central, Distributed and Communications
Infrastructure
Parallel Runs
Sets of Maintenance, Service Management and
Support Services

Outline Solution Component Implementation
Phasing In Overall Solution Design And Delivery
• Different solution component types will be needed and
can only be delivered at different phases
• This scheduling of the design and delivery of solution
components will impact on:
− Identifying and mapping dependencies between solution
components that affect when they design and delivery work can
start
− The scheduling of the design and delivery work
May 4, 2020 30

Solution Topography
• The to-be-designed and delivered solution will need to operate
in and co-exist with an existing multi-layered solution
topography
1. Extended Solution Landscape With Integration With Other Solutions
2. Business Process and Organisation Structure
3. Common Data Architecture
4. Common Security and Regulatory Compliance Architecture
5. Common Enterprise Architecture Standards
6. Common Financial Management Processes and Standards
7. Common Service Management Processes and Standards
• The solution design and delivery process needs to be aware of
and take account of this wider solution topography
• This is true even for XaaS solutions
May 4, 2020 31

Solution Topography
May 4, 2020 32
Extended Solution Landscape With
Integration With Other Solutions
Individual Solution Landscape
Business Process and Organisation Structure
Common Data Architecture
Common Security and Regulatory Compliance Architecture
Common Enterprise Architecture Standards
Common Financial Management Processes and Standards
Common
Service
Management
Processes
and
Standards

Solution Topography
• Irrespective of whether the solution is hosted inside or outside the organisation, it
will still need to operate in a solution topography consisting of a number of logical
layers
• This topography is important as its implicitly or explicitly delineates borders to
what is feasible
May 4, 2020 33
Common Service Management
Processes and Standards – solution
support, service level management
Common Financial
Management Processes and
Standards – solution cost and
asset management
Common Enterprise Architecture
Standards – compliance with
organisation technology standards
and principles
Common Security and
Regulatory Compliance
Architecture – integration of
solution into overall security
standards and operations
Common Data Architecture –
integration of solution data into the
organisation data model and access
to solution data, compliance with
data regulations and standards
Business Process and
Organisation Structure –
business processes and
organisation functions that use
the solution
Extended Solution Landscape With
Integration With Other Solutions –
solution support, service level
management, integration, data
exchange
Individual Solution
Landscape – set of
components that comprise
the overall solution

Solution Topography And Solution Boundaries
May 4, 2020 34
Solution Topography Defines The Solution
Technical And Operational Boundaries And
Constraints
Solution
Solution
Architecture
And Design
Defines The
Solution Scope
And Delivery
Boundaries
And
Constraints

The Agile Solution
May 4, 2020 35

Agile Is About Finding The Right Path To The Right Solution Through
Analysis, Design, Experimentation And Review Cycles
• Iterations become fewer and longer as optimum solution design emerges and is
converged upon
• Level of uncertainty diminishes over time as confidence in the solution increases
• Agile involves focussed and directional experimentation to confirm design ideas
May 4, 2020 36
Direction Of Solution Design And Delivery
Decreasing
Degree Of
Solution
Uncertainty
Over Time
Number
And
Duration
Of Design
And
Delivery
Iterations

The Agile Funnel
• The agile process can be
viewed as a funnel,
proceeding from a high
degree of uncertainty and
many choices along an even
restricted path to a definite
resolution
• The solution trajectory can be
set at an early stage without
the impact being fully
understood
• As you progress down the
solution design path and the
delivery funnel, the options
narrow and become more
limited
• Initial decisions and direction
can have major consequences
for later work
May 4, 2020 37
Optimal Solution

Number Of Iterations Needs To Be Limited
• Solution design and delivery iterations are expensive
• They need to be kept to a minimum
• If there are too many iterations the value of an agile approach is
diminished
May 4, 2020 38

Agile Is and Is Not …
• Agile is not some magic way of doing more work than is realistically
possible
− It is about working in a smarter manner to achieve more with fewer resources and
removing waste from the solution design and delivery process
• The traditional solution design and delivery journey is direct but uphill
− Long detailed design phase means the nature of the problem being fixed or the
opportunity being addressed may have changed before delivery starts
− Designed solution may be too complex
• The agile journey is indirect, repeated, iterative and involves rework and
repetition
− No large upfront effort with fixed and invariable design subject to change request
processes
− Continuous co-ordinated design effort and involvement throughout design and
delivery
− Continuous course and design changes based on frequent assessments
• However the sum of agile savings is greater than sum of loss due to rework
and repetition
May 4, 2020 39

Using An Agile Approach Effectively
• Agile is all too frequently seen as a panacea to solution
design and delivery problems
− It is not
− Agile is hard
• Agile has become fashionable without an understanding of
the effort involved and pre-requisites involved
• Agile requires commitment, involvement and can be
intense and demanding
• If you have current solution design and delivery problems,
agile is probably not the solution
− You need to fix the underlying organisational issues first
May 4, 2020 40

Structured Agile Process
• Agile is not an unstructured or random process
• Used well, agile achieves an intelligent balance between:
− Speed and quality
− Cost and affordability
− Scope changes and delivery timescale
− Risk and reality
− What is possible and what is realistically achievable
May 4, 2020 41

Agile Is A Team Activity
• The agile team needs to maintain situational awareness
and avoid becoming inwardly focussed and disconnected
from the solution reality
− Share information
− Use data from multiple sources to cross-validate and resolve
information and perception conflicts
− Question assumptions
− Continuously affirm the solution design and delivery direction
with solution stakeholders and consumers as the process
progresses
May 4, 2020 42

Agile Is A Team Activity
Solution Stakeholders and
Consumers/Consumer Representatives
Solution Design and Delivery
May 4, 2020 43
This is what I believe I want That I what I understand you
want
This is what is possible within
constraints
This is what I am designing and
delivering
This is what I now understand
what I am getting
These are the changes that are
happening during design and
delivery
• Constant
communication and
reaffirmation of the
solution is required
to keep the solution
design and delivery
process on track

May 4, 2020 44
Solutions And Projects When to Use Agile
• Solution that is interactive, where the functionality is clearly
demonstrable at the solution consumer interface
− Agile is based on incremental prototyping with close solution consumer
involvement
− Solution consumers must be able to assess the functionality easily through
viewing and operating working prototypes
• Solution that has a clearly defined solution consumer group
− If the solution consumer group is not clearly defined, there may be a danger of
driving the solution from a wrong viewpoint or ignoring some important aspect
of the solution entirely
• Solution that is computationally complex, the complexity can be
decomposed or isolated
− If the internal operation and use of the solution are hard to understand from
the user interface then there is a risk
− Level of computational complexity is often quite difficult to determine in
advance
− Interactions between different solution components that can be difficult to
identify up front

May 4, 2020 45
Solutions And Projects When to Use Agile
• Solution that is large, possesses the capability of being split into smaller functional
components
− If the proposed solution is large it should be possible to break it down into small,
manageable chunks, each delivering some clear functionality
− These can then be delivered sequentially or in parallel
− Each sub-solution must be constantly aware of the overall solution design and
architecture
• Solution that is time-constrained
− There should be a fixed end date by which the solution must be completed
− If there is no real case for the end date to be fixed, it will be relatively easy to allow
schedules to slip and the fundamental benefits of agile approach will be lost
• Solution where requirements can be prioritised
− Requirements should be able to be prioritised using the MoSCoW rules
• Solution where requirements are unclear or subject to frequent change
− In periods of rapid change it may be difficult to specify the requirements in detail at the
outset of the solution making traditional approaches unsuitable
− Agile approach is designed specifically to deal with requirements that change and
evolve during the solution
− Applications that are difficult to specify in advance because the users do not know
exactly what is needed at the outset

Replacing The Solution Monolith
• Traditional solution delivery journey can
feel like pushing a monolithic solution
design up a hill
− Inflexible and resource-intensive
• An agile approach replaces this monolithic
straight-line journey with than faster but
more winding journey
May 4, 2020 46
• Solution monolith is the large up-front
solution design with too much
unnecessary functionality handed to
solution delivery and pushed through
to implementation

Monolithic Solution Design And Delivery And
Solution Shrinkage
• An almost unvarying characteristic of monolithic
solution design and delivery is that the monolith
is chipped away and gets smaller as functionality
is removed to meet time, cost and risk
constraints, as both schedule and budget overrun
• Frequent cause of monolithic solution delivery
problems
May 4, 2020 47

The Agile Trade-Off
• Agile works (for the right solutions) because the cost of solution design and
delivery iterations and repeated work that creates the right solution at the
right time is less that the cost of the solution monolith
• More benefits are achieved more quickly
May 4, 2020 48

Suitability Checklist Of Solutions For Agile Approach
• Do the sponsor and management understand and accept the agile philosophy as their buy-in is essential?
• Will the team members be empowered to make decisions?
• Is there senior user commitment to provide end user involvement?
• Can the organisation accommodate the frequent delivery of increments?
• Will it be possible for the solution design and delivery team to have access to the users throughout solution
design and delivery?
• Will the solution design and delivery team remain the same throughout solution delivery as stability of the
team including the user representatives is important?
• Will the solution design and delivery team have the appropriate skills including technical skills, knowledge of
the business area?
• Will the individual solution design and delivery teams consist of six people or less?
• Will the solution use technology suitable for prototyping?
• Is there a highly demonstrable user interface?
• Is there clear ownership?
• Will the solution development be computationally non-complex as the more complex the development the
greater the risks involved?
• Can the solution be implemented in increments if required?
• Has the development a fixed timescale?
• Can the requirements be prioritised with a mix of Must Haves, Should Haves, Could Haves and Want to Have
but Won't Have This Time?
• Are the requirements not too detailed and fixed so users can define requirements interactively?
May 4, 2020 49

Agile Solution Architecture And Design Enablers
• Agile solution architecture and design is enabled by:
− Solution architecture and design involvement throughout the
solution delivery process
− A solution design and delivery process that is constructed for and
actively supports rapid solution delivery
• The organisation cannot be Agile In Name Only and expect
agile design and delivery to work
• An agile approach requires:
− Positive support for the process
− Active elimination of barriers that give rise to waste
• These are significant organisation cultural and political
changes that should not be underestimated
May 4, 2020 50

Solution Stakeholders And Solution Consumers
• Solution design and delivery needs to take account of both solution
consumers and solution stakeholders
• Solution consumers are those sets of people who will use aspects of
the solution
• There can be (many) different sets of solution consumers, each of
whom will have different solution usage experiences and outcomes
• Solution consumers experience the functional and operational
aspects of the solution
• Solution stakeholders have an investment (money, time, resources,
organisation impact/change, affected by the solution outcomes) in
the solution
• While not necessarily being direct solution consumers, the needs of
stakeholders need to be considered in solution design
• Agile process must limit stakeholders to only the most relevant
May 4, 2020 51

Solution Stakeholders
• Traditional
Power/Interest
grid view of
solution
stakeholder
map
May 4, 2020 52
High Degree Of
Influence And Power
But Limited Interest
And Engagement –
These Are The Most
Difficult Stakeholders –
Maintain Limited
Focussed Engagement
But Monitor Closely
Most Important
Stakeholders With The
Greatest Interest And
Influence – Maintain
Constant Close
Engagement and
Involvement
Limited Influence And
Involvement – Maintain
Passive
Communications
Limited Influence And
Power But High Degree
Of Interest – Keep
Informed But Limit
Direct Involvement
LEVEL OF INTEREST IN SOLUTION
LEVELOFINFLUENCEOVERSOLUTIONDIRECTION,DESIGN,FUNCING

Solution Stakeholders – Potential Attitude Within
Each Group
May 4, 2020 53
LEVEL OF INTEREST IN SOLUTION
LEVELOFINFLUENCEOVERSOLUTIONDIRECTION,DESIGN,FUNCING
Seagull
Efficient
Delegator
Micro
Manager
Narcissist
Macro
Manager
Genuinely
ConcernedDisinterested
Not
Relevant
• Extended
stakeholder
map showing
Power/Interest/
Attitude
• An agile
approach is
concerned with
keeping
solution
stakeholders to
a necessary and
committed
minimum

Solution Consumers And Consumer Representatives
• Solutions can have many
different consumers,
each of whom will have
different usage
requirements and
experiences
• External consumers may
have to have internal
representatives
appointed to reflect
their usage of and
interaction with the
solution
• The correct
identification of all
solution consumers is
important in its design,
especially in the Solution
Design Framework And
Scope Definition phase
May 4, 2020 54
Solution
Consumers
Internal
Business
Executive
Management
Supervisory
Operational
Employee
Service
Management
Operator
Support
Administration
External
Consumer
Business
Customer
Partner
Supplier
…

Organisation Solution Design And
Delivery Waste
May 4, 2020 55

Supporting Agile Solution Architecture And Design
To Eliminate Waste
• Agile requires the elimination of waste in the solution
design and delivery process and in the wider organisation
solution delivery governance, management and support
processes
• Waste contributes to large solution design and delivery
resource requirements and long elapsed times
− Resources are expended wastefully and allocated to performing
work that does not add value to the required solution
• Original concept of waste comes from Lean Manufacturing
May 4, 2020 56

Organisation Inflation And Solution Design And
Delivery Waste
May 4, 2020 57
Delivery
Process
Inflation - Too
Many Non-
Value Adding
Delays,
Processes And
Steps
Organisation
Inflation - Too
Many Roles And
Functions
Unnecessarily
Involved In
Solution Design
Consultation,
Decision-Making
And Approval
Solution Pre-
requisite Inflation
– Solution Design
Has To Take
Onboard Enabling
Facilities That Are
Not In Place
Actual
Core
Solution
Solution
Inflation -
Too Many
Features
And Too
Much
Complexity

Delivery Waste
• Solution Inflation - Too Many
Features And Too Much
Complexity
− Too much unnecessary
functionality added
− Solution not optimised or
automated
• Solution Pre-requisite Inflation
– Solution Design Has To Take
Onboard Enabling Facilities
That Are Not In Place
− Solution requires enabling/
supporting/ plumbing-type
technologies not currently
available
− Absence of supporting facilities
reduces the ability to deliver
solutions quickly
• Delivery Process Inflation - Too
Many Non-Value Adding
Delays, Processes And Steps
− Organisation has overly complex
design and delivery review and
approval processes that case
delays without adding value
• Organisation Inflation - Too
Many Roles And Functions
Unnecessarily Involved In
Solution Design Consultation,
Decision-Making And Approval
− Too many stakeholders and
decision-makers are allowed to
have a say in the solution design
and delivery process
May 4, 2020 58

Delivery Waste
• An agile solution design and delivery approach will only
succeed if it can avoid the processes, structures and
activities that lead to wasted effort and resources
May 4, 2020 59

Conway’s Law And Organisation And Solution Design
And Delivery Waste
• Short article written by Dr Melvin Conway in April 1968 - How
Do Committees Invent? - Design Organization Criteria
− http://www.melconway.com/Home/pdf/committees.pdf
• “Parkinson's Law plays an important role in the
overassignment of design effort. As long as the manager's
prestige and power are tied to the size of his budget, he will
be motivated to expand his organization. This is an
inappropriate motive in the management of a system design
activity. Once the organization exists, of course, it will be
used. Probably the greatest single common factor behind
many poorly designed systems now in existence has been the
availability of a design organization in need of work.”
May 4, 2020 60

Conway’s Law And Large System Design And
Development Disintegration
May 4, 2020 61
“Third, the [structure-preserving relationship
between the organisation and its designs]
insures that the structure of the system will
reflect the disintegration which has occurred in
the design organization.”
“The structures of large systems
tend to disintegrate during
development, qualitatively more so
than with small systems.”
“First, the realization by the initial
designers that the system will be large,
together with certain pressures in their
organization, make irresistible the
temptation to assign too many people
to a design effort..”“Second, application of the
conventional wisdom of management
to a large design organization causes
its communication structure to
disintegrate.”

Solving The Design Structure Reproduction Bias And
The Waste It Causes
• “Ways must be found to reward design managers for
keeping their organizations lean and flexible. There is
need for a philosophy of system design management
which is not based on the assumption that adding
manpower simply adds to productivity. The development
of such a philosophy promises to unearth basic questions
about value of resources and techniques of
communication which will need to be answered before
our system-building technology can proceed with
confidence.”
May 4, 2020 62

Organisation Bloat
• The tendency and desire for organisation functions to
become large to reflect the status of their managers add
unnecessary and wasteful effort to the solution design and
delivery process
− This growth adds strata of review and approval designed to justify
the existence of the enlarged functions
• In agile, smaller design and delivery teams yield
significantly better results
• The organisation must allow agile teams to be small and
focussed
May 4, 2020 63

Generic Causes Of Waste
• Overproduction - manufacturing an item before it is actually required
• Waiting - whenever goods are not moving or being processed
• Transport - moving products between processes is a cost which adds no value to the product
• Inventory – excess work in progress (WIP) cases by overproduction and waiting
• Unnecessary / Excess Motion - people or equipment moving more than is required to perform
the processing
• Over/Inappropriate Processing - using expensive resources where simpler ones would be
sufficient
• Defects - resulting in rework or scrap or the need for excessive quality control
• Wrong Product - manufacturing goods or services that do not meet customer demand or
specifications
• People Unmatched to Role - waste of unused human talent/underutilising capabilities and skills
and allocating tasks to people with insufficient training to do the work
• Inadequate Performance Measurement - working to the wrong performance metrics or to no
metrics
• Uninvolved Personnel - not using staff fully by not allowing them to contribute ideas and
suggestions and be part of participative management
• Inadequate Technology - improper use of information technology - inadequate or poorly
performing systems requiring manual workarounds, systems that deliver poor response times,
systems or the underlying data that are unreliable or inadequate training in the use of systems
May 4, 2020 64

Waste Results In A Large Input Creating A Small
Output
May 4, 2020 65
Overproduction
Waiting Transport
Inventory Unnecessary /
Excess Motion
Input
Resources
Defects
Wrong Product
Inadequate
Technology
Uninvolved
Personnel
People
Unmatched
to Role
Inadequate
Performance
Measurement
Over/
Inappropriate
Processing
Output Results

Agile Solution Architecture, Design And Delivery
Requires …
• The team to be empowered to eliminate waste in work practices
• The core principles of the elimination of unnecessary work are:
− Compression – reduce unnecessary/non-value-adding steps and combine
activities
− Collapse – eliminate unnecessary handoffs, duplicate or unnecessary decision-
making and involvement by unnecessary roles
May 4, 2020 66
Compress
Collapse

Agile Requires Flexibility in Solution Design And
Delivery
• There is no merit in attempting to pursue an agile
approach to solution design and delivery if the
organisation is inflexible in its delivery processes and
structures
• The ability to eliminate bloated and wasteful structures
and practices is an essential precondition to an agile
solution design and approach
• The elimination of wasteful structures, processes and
decision-making arrangements impacts the organisation
culturally and politically
− It seeks to change existing organisation power structures
May 4, 2020 67

Causes Of Waste In Solution Design And Delivery
May 4, 2020 68
Cause Of Waste Solution Architecture And Design And Solution Delivery Waste Causes
Overproduction • Adding unnecessary solution design functionalityand features
• Making the solution design more complex than necessary
• Performingwork too early that requires change
Waiting • Long decision cycles resulting in solution deliverydelays
• Overhead in co-ordinatingand scheduling work across multipledelivery teams
• Delays caused by scheduling of dependent solution components
Transport • Moving work between multiple separate delivery teams
• Deliveryteams not optimallylocated
• Overhead in approval of signoffs before work can move to the next processing stage
Inventory • Large number of change requests because originaldesign does not meet changed needs
Unnecessary / Excess Motion • No devolved responsibility
• Multiple signoffs needed before work can progress
• Large delivery teams with movement and co-ordinationof work between teams and team members
• No single person responsible for individualdeliverables
Over/InappropriateProcessing • Too many unnecessary/unused features in the solution
• Overengineeredand overly complex solution
• Non-value adding activities
• Unnecessary or inappropriatechecks and controls
Defects • Error-pronemanual processes
• Overly complex solution leading to increased likelihood of defects
• Work scheduled before pre-requisitesare in place
• No automation of quality checks and identification of errors as early in the process as possible
• Do not allow work to start until necessary pre-requisitesare available
• Lack of focus on data quality from the start
Wrong Product • The solution being delivered partiallyor completely fails to meet the intended needs
• The solution is too complex
People Unmatched to Role • Wrong people involved in the solution design and delivery
• Team members do not have the rights skills, experience or training to perform the required roles
• Team members do not accept the agile design and deliveryapproach
• Undeveloped potential of delivery teams due to poor motivation, loss of creativity and ideas
InadequatePerformance
Measurement
• Not measuring the right set of achievements and results giving a false measure of progress
• Decisions are being taken based on incorrect metrics
Uninvolved Personnel • Deliveryteam does not include all the personnel who need to be involved in ensuring solution delivery success
• Roles and involvementare compartmentalisedalong the solution delivery process
• Decisions are being made without the involvement of solution delivery team
• People not involved directly in the deliveryof the solution are involved in decision making
InadequateTechnology • The solution does not incorporatethe correct technologies
• The solution delivery team does not know or understand the technologies being used
• The solution delivery team does not have access to the right support technologies

Actions To Avoid Waste In Solution Design And Delivery
May 4, 2020 69
Cause Of Waste Waste Avoidance Actions in Solution Architecture And Design And Solution Delivery
Overproduction • Short limited design and delivery activitieswith constant feedback to focus scope on what is actually required
• Scheduling work to its optimum location in the design and delivery plan
• Eliminatingunnecessary complexity from the solution design
Waiting • Eliminatingunnecessary decision makers, delegating decision-makingand empowering local decision-making
• Smaller, co-located delivery teams eliminatingwork scheduling across multiple deliveryteams
Transport • Smaller teams located together with end-to-end design and deliveryresponsibility
• Devolved, localisedand simplified decision making
Inventory • Small deliverables eliminatinglarge amounts of work in progress
• Avoid changes in priorities leading to incomplete paused work
Unnecessary / Excess Motion • Localised responsibilityfor decision making and signoff
• Reduced number of approvals required
• Small deliveryteams
• Schedule component deliverieswhen they are ready to be accepted
Over/InappropriateProcessing • Simplified solution designs with refinement introduced based on demonstrable need and proof of utility and use
• Eliminationof non-value adding activities and overheads
• Automated and risk-based testing
Defects • Focus on data quality from the start
• Reduce solution complexity and eliminate unnecessary on unproven features
• Automation of solution delivery support and management processes as much as possible
• Frequent small checks and risk-based testing
• Devolved and integrated responsibilityfor quality
Wrong Product • Frequent validationof solution design with its ultimate users
• Frequent small developments with frequent delivery
• Deliver a usable and used product quickly as possible to learn lessons from use
• Eliminate complexity from solution design
• Involve ultimate users early and frequently
People Unmatched to Role • Keep the design and delivery teams small and focussed
• Share knowledge and implementknowledge sharing, transfer and retention
InadequatePerformance
Measurement
• Define and implement limitedand achievable set of performanceand delivery metrics
• Measure and public metrics
Uninvolved Personnel • Involve people and devolve responsibility
• Give everyone an end-to-end solution view
• Implementappropriate and limited design and delivery management processes
InadequateTechnology • Limit the range of technologies involved in the solution to reduce complexity
• Allow the introduction of new technologies where appropriate

Integrated Solution Design And
Delivery
May 4, 2020 70

Integrated Solution Design And Delivery To
Operations
• Design-to-Operations view of solution means all aspects of the solution design are
considered
• The solution is only complete when all its constituent components are operational
• The implementation of the individual components must converge at some point
during the solution delivery phases
May 4, 2020 71
Operation
And Use
Idea or
Need
Solution Delivery Journey And Solution Design Scope

Staged And Iterated Solution Design And Delivery
• The solution design and delivery process does not have to
be monolithic
• The process can be staged and iterated to achieve rapid
results
• Taking a integrated Solution Design and Delivery to
Operations approach means you can make informed
knowledge-based decisions on what to do when to balance
delivery factors
• Initial high-level design is refined during repeated design
and delivery work
May 4, 2020 72

Integrated Solution Design And Delivery to
Operations Is About …
• … Understanding the value of solution design
• Maximising the impact and value of solution design
• Creating a common solution design language along the
length of the solution delivery journey
• Avoiding solution delivery estimation errors due to factors
such as strategic misrepresentation
• Reducing solution design effort and time while maximising
the value delivered
• Increasing solution design and delivery collaboration
• To solve a problem, you need sufficient information to
understand the problem
May 4, 2020 73

Core Elements Of Integrated Solution Design And
Delivery To Operations
May 4, 2020 74
People, Skills,
Experience,
Mentoring,
Training
Development
Engagement,
Delivery and
Quality
Processes
Management,
Leadership,
Governance
Standards,
Methodologies,
Tools, Knowledge
Management

Why Take A Integrated Solution Design And Delivery
To Operations Approach?
• Solution architecture and design teams are becoming larger so more
co-ordination, standardisation and management is required
• Focus on digital transformation increases the need for improved
design as business applications are exposed outside the organisation
• User expectations of solutions are growing
• Solution complexity is increasing
• Data volumes and data processing requirements and capabilities are
growing
• There is a need to protect the organisation from the Just Do It
approach of development
• Establish common solution design principles that are universally
applied
• Improve solution outcomes
May 4, 2020 75

Solution Operations Is Concerned With Solution
Characteristics And Quality Properties
• Solution design should incorporate the
definition, agreement, importance and
prioritisation of the required operational
characteristics of the solution
− Usable
− Suitable
− Affordable
− Deliverable
− Operable
− Supportable
− Maintainable
− Flexible
− Adaptable
− Capable
− Scalable
− Reliable
− Securable
− Available
− Auditable
− Recoverable
− Stable
− Testable
− Accessible
• These are enduring solution characteristics
that will impact solution operations long
after design and delivery has ended
May 4, 2020 76

Agile Solution Design And Delivery
May 4, 2020 77

Topics
• Introduction
• Agile Enablers, Techniques, Controls and Principles
• Pre-Solution Design and Delivery
• Solution Feasibility Analysis And Study
• Solution Framework and Scope Definition
• Overall Solution Architecture Design
• Solution Architecture Design Iterations
• Solution Components Design And Implementation
• Individual Solution Component Delivery Iterations
• Overall Solution Design and Individual Solution Component
Design Interactions
• Post-Solution Design and Delivery
May 4, 2020 78

Not All Solution Concepts Are Implemented
• A process is needed to identify feasible, worthwhile, justified
solution concepts to proceed to solution design and delivery and to
eliminate those that are not cost-effective or justified
• Agile solution architecture and design has an important role in
identifying solutions worth implementing and in quantifying the
effort
• Need to involve solution architecture and design at an early stage to
understand the full scope of the solution and its implementation
• Enable decisions to be made on whether to proceed and what will
be included in the scope
• Create initial high-level solution architecture that can be expanded
on if the solution is being proceeded with
• Minimise the work done while maximising the information gathered
and processed and results obtained
May 4, 2020 79

May 4, 2020 80
Post-
Solution
Design And
Delivery
Implementation
Pre-
Solution
Design And
Delivery
Solution
Feasibility
Analysis
And Study
Solution Design
Framework And
Scope
Definition
Approach
Validate Scope
Implement
Approach
Validate Scope
Implement
Approach
Validate Scope
Implement
Approach
Validate Scope
Implement
Approach
Validate Scope
Implement
2 3 4 5
6
7
10
9
Solution
Architecture
Design Iterations
8
Individual Solution
Component
Delivery Iterations
1
Agile
Enablers,
Techniques,
Controls and
Principles

Agile Solution Architecture And Design Framework
Overview
Agile Enablers, Techniques,
Controls and Principles
Defines the framework, enablers and pre-requisites, techniques, controls and principles needed to
allow agile solution architecture, design and delivery to operate successfully
Pre-Solution Design And
Delivery
Creates an initial definition of the problem or opportunity to be resolved by the proposed solution and
validates that the solution is suitable for an agile approach and that the structures are in place and
operational to maximise success
Solution Feasibility Analysis
And Study
Conducts a more detailed assessment of the feasibility through workshops with the intended business
solution consumers and creates an initial view of implementation activities
Solution Design Framework
And Scope Definition
Creates an initial solution framework covering affected business processes (existing and new), internal
and external solution actors (individuals and business function), key functionality required and
indicative view of solution components (new, existing and modified)
Overall Solution Architecture
Design
Consists of iterated design activities where the initial high-level solution design is refined, enhanced
and expanded
Solution Architecture Design
Iterations
Individual Scope/Approach/Implement/Validate solution design iterations
Solution Components Design
And Implementation
Consists of iterated solution component delivery/implementation activities
Individual Solution
Component Delivery
Iterations
Individual Scope/Approach/Implement/Validate solution component design/delivery/implementation
iterations
Interactions Between Overall
Solution Design and
Individual Solution
Component Design
Interactions between the Overall Solution Architecture Design activity and the individual Solution
Components Design And Implementation activities where design feedback from implementation is
incorporated into design and overall design refinements are passed to delivery iterations
Post-Solution Design And
Delivery
Conducts a post-solution-implementation review, assesses the delivered against the planned benefits,
reviews the use and usability of the solution and evaluates the operation of the delivery process
May 4, 2020 81
1
2
3
4
5
6
7
8
9
10

Agile Solution
Architecture
And Design
Agile Enablers,
Techniques,
Controls and
Principles
Principles And
Success Factors
Time Limits
Solution Design
And Delivery
Management
Risk
Management
Quality
Management
And Validation
Workshops
Prototyping
Pre-Solution
Design And
Delivery
Solution
Feasibility
Analysis And
Study
Solution
Requirements
And Feasibility
Analysis and
Study
Feasibility
Analysis And
Study Questions
and Checklist
Feasibility
Prototype
First Pass Design
And Delivery
Schedule
First Pass Design
And Delivery
Schedule
Questions and
Checklist
Solution Design
FrameworkAnd
Scope Definition
Core Design
View
Business
Processes
Solution
Consumers
Solution
Functionality
Solution
Components
Extended Design
View
Interfaces
Solution Usage
Journeys
Data View and
Data Model
Data Exchanges
Second Pass
Design and
Delivery
Schedule
Overall Solution
Architecture
Design
Solution
Architecture
Design Iterations
Solution
Components
Design And
Implementation
Individual
Solution
Component
Delivery
Iterations
Solution Design
and Component
Design
Interactions
Updated Design
and Delivery
Schedule
Post-Solution
Design And
Delivery
Agile Solution Architecture and Design Content And
Structure
• This lists the
main content
areas of the
agile solution
and design
framework
May 4, 2020 82
1 2 3
4
5
6
7
8
9 10

Solution Design And Delivery Process Decision Points
And Entry And Exit Factors
• There are points in the solution design and delivery process
where key decisions are made
− 2 - Ensure that the solution is suitable for an agile approach
− 3 - Create feasibility report with recommendation to progress or not
− 4 - Go/No Go/Review recommendation
− 5 - Decisions on solution scope
− 9 - Decision on deferring work to subsequent delivery chapters
− 10 - Review of deferred work
May 4, 2020 83
Post-
Solution
Design And
Delivery
Implementation
Pre-
Solution
Design And
Delivery
Solution
Feasibility
Analysis
And Study
Solution Design
Framework And
Scope
Definition
2 3 4 5
7
10

Benefits Of A Structured Approach
• A structured approach ensures consistency in the
assessment of solution design options and in subsequent
solution delivery
• Leads to the design and delivery of realistic and achievable
solutions that meet real solution consumer needs
• Provides for effective decision-making
• Generates results and options quickly
• Creates a knowledgebase of previous solution design and
delivery exercises that leads to an accumulated body of
knowledge within the organisation
May 4, 2020 84

Mapping The Solution Design And Delivery Process
To The Agile Funnel
• The agile solution design and
delivery process maps to the agile
funnel
May 4, 2020 85
Post-
Solution
Design And
Delivery
Implementation
Pre-
Solution
Design And
Delivery
Solution
Feasibility
Analysis
And Study
Solution Design
Framework And
Scope
Definition
• The solution evolves and
becomes more refined, detailed
and focussed through the design
and delivery process

Sequential And Repeated Phases
• Agile solution design and delivery consists of both
sequential and iterated phases
May 4, 2020 86
Post-
Solution
Design And
Delivery
Pre-
Solution
Design And
Delivery
Solution
Feasibility
Analysis
And Study
Solution Design
Framework
And Scope
Definition
Assessment, Scoping,
Refinement And Decision
To Proceed Phases
Iterated Design And Delivery
Phases And Activities
Completion
Implementation

Changing The Degree Of Agility
• The degree of agility in the solution design and delivery
approach depends on the degree to which the Overall Solution
Architecture Design phase and the Solution Components
Design And Implementation phase are offset
• The greater the degree to which the phases are offset the less
agile and the more monolithic the overall process will be
− A more detailed and less flexible design will be passed to
implementation
May 4, 2020 87
Implementation
Phase
Offset
Degree

Compression Of Phases
• Some or all of the phases
− Pre-Solution Design And Delivery
− Solution Feasibility Analysis And Study
− Solution Design Framework And Scope Definition
• Can be compressed into a single study and design phase
May 4, 2020 88
Post-
Solution
Design And
Delivery
Implementation
Pre-
Solution
Design And
Delivery
Solution
Feasibility
Analysis
And Study
Solution Design
Framework And
Scope
Definition
2 3 4 5
7
10

Basic Iterated Unit Of Design And Delivery Work
• The basic iterated unit of work consists of a cycle of four
activities within an agreed time unit
− Scope – Accept and agree what is to be produced during this work cycle
and reprioritise, if necessary, during the work
− Approach - Agree who, how and when to do the work by refining the
design and agreeing a timescale
− Implement - Create the product or deliverable
− Validate - Check that the agreed deliverable has been produced
correctly (by reviewing documentation or other material,
demonstrating a prototype or testing part of the overall solution) and
that it matches what was agreed in the scope (or changes to the scope)
and collate information to refine and extend the overall solution design
May 4, 2020 89
Scope
Validate Approach
Implement
Time
Unit

Basic Iterated Unit Of Design And Delivery Work
• The unit of work receives as an input:
1. The design of the solution component that is being worked on in this work unit
2. The work to be done or the deliverables to be produced
• The outputs from the unit of work are:
1. The actual work done – either new work or updates to existing work - or the deliverables
produced based on reprioritisation during the unit
2. Areas of the solution design to be refined
3. Inputs to the overall solution design and delivery plan based on work done and
information and understanding acquired
May 4, 2020 90
Scope
Validate Approach
Implement
Time
Unit
Work to be Done
and Deliverables
to be Produced
Actual Work,
or Products
Produced –
New or
Updated
Refinements to
Overall Solution
Design
Changes to
Design and
Delivery Plan
Solution
Component
Design
1 2 31 2

Solution Components Are Created Repeating Basic
Units of Work
• The basic unit of work is repeated a number of times as
each solution component is refined and enhanced
May 4, 2020 91
Scope
Validate Approach
Implement
Scope
Validate Approach
Implement
Scope
Validate Approach
Implement
Time
Unit
Time
Unit
Time
Unit

Solution Components Design And Delivery Over Work Cycles
• Each of the solution components
will be refined and created during a
number of work cycles
May 4, 2020 92
Component Component Component Component ComponentChanges to Existing Systems
Applications
Products
Migrations
New Data Loads
Cutover/ Transfer to Production And
Support
Parallel Runs
Management Services
Processes
Management

Solution Components Design And Delivery In Parallel
• Work on the iterations for the delivery of solution
components occurs in parallel
• This requires management of the configuration of the
overall solution and management of delivery activities
May 4, 2020 93
Component Component Component Component Component

Dimensions Of The Solution In The Context Of Agile
• There are now three
dimensions of
solution design and
delivery
− Delivery adds a third
dimension of
component iterations
to the previous two
dimensions
• Solution design and
delivery configuration
management assists
in tracking solution
work in an agile
context
May 4, 2020 94
Design And
Delivery
Cycles
Within
Component
Components
Within
Component
Types
Component
Types

1 Agile Techniques, Controls And Principles
Structure Contents
May 4, 2020 95

Agile Techniques, Controls And Principles Topics
• Principles
• Success Factors
• Time Limits
• Solution Design And Delivery Management
− Solution Requirements
− Solution Design and Delivery Estimates
− Solution Configuration Management
− Management And Planning Of The Solution Design And Delivery Process
− Supporting Tools And Technologies
• Risk Management
• Quality Management And Validation
• Workshops
• Prototyping
May 4, 2020 96

Key Principles of Iterative Agile Solution Design And
Delivery Approach
May 4, 2020 97
Active Solution Consumer Involvement Is
Essential For Success
Agile Solution Design And Delivery Team
Must Be Allowed Make Decisions
Fitness For Business Purpose And Value Is
The Essential Measure for Acceptance of
Deliverables
All Changes During Solution Design And
Delivery Are Reversible
Requirements Are Baselined At A High
Level
Collaborative And Co-operative Approach
Between All Stakeholders And Solution
Consumers Is Essential
Focus Is On Frequent Delivery of Solution
Products
Iterative and Incremental Development Is
Necessary To Converge On An Accurate
Business Solution
Solution Validation Is Integrated And
Performed Throughout the Lifecycle
Understand And Confirm The Scope Of
The Solution In Its Entirety
21
43
65
87
109

May 4, 2020 98
Principle 1 – Active Solution Consumer Involvement
Is Essential For Success
• Agile is solution consumer-centered
− Solutions have multiple consumer types:
• Functional consumers at different levels
• Operations consumers - support, maintenance
− Understand the solution consumer landscape and involve them
• Solution consumers may feel that the final solution is imposed
by the solution design and delivery team and/or their own
management
• Solution consumers are not outside the solution design and
delivery team acting as passive suppliers of information and
reviewers of results but are active participants in the solution
design and delivery process
• Solution consumer and thus business commitment is
fundamental to success

May 4, 2020 99
Principle 2 – Collaborative And Co-operative Approach Between All
Stakeholders And Solution Consumers Is Essential
• The nature of agile solution design and delivery means that low-level detailed
requirements are not necessarily fixed when the solution design and delivery team
is assembled to perform the work
• Solution stakeholders and solution consumers must be allowed and encouraged to
contribute
• Create a predictable rhythm of working between solution stakeholders with
regular solution design planning sessions
• Implement knowledge management and sharing
• The short-term direction that solution design and delivery takes must be quickly
decided without the use of restrictive change control procedures
• The stakeholders include not only the business and development staff within
solution design and delivery , but also other staff such as service delivery and
management and resource managers
• When the solution design and delivery is procured from an external supplier, both
the vendor and the purchaser organisations should aim for as efficient a process
as possible while allowing for flexibility during both the pre-contract phase and
when the contracted work is carried out
− Can be difficult and needs substantial mutual trust

May 4, 2020 100
Principle 3 – Agile Solution Design And Delivery
Team Must Be Allowed Make Decisions
• Solution design and delivery teams must be mixed and consist
of both IT personnel (across a wide range of technical and
business skills) and solution consumers of all types
• Solution design and delivery teams must be able to make
decisions as requirements are refined and possibly changed
• Solution design and delivery teams must be able to agree that
defined levels of functionality, usability, etc. are acceptable
without frequent need to refer to higher-level management
• Agile approach requires quick, localised and devolved decision-
making by those closest to knowledge and experience
• Constraints and delays to decisions and actions need to be
minimised

May 4, 2020 101
Principle 4 – Focus Is On Frequent Delivery of
Solution Products
• A product-based approach is more flexible than an activity-based one
− Products include interim solution components products, not just complete
delivered solutions
• Work of a solution design and delivery team is concentrated on products
that can be delivered in an agreed period of time
• Enables the team to select the best approach to achieving the products
required in the time available
• Reduce work in progress and size of design and delivery activities to deliver
value quickly, learn lessons or identify dead-ends
• By keeping each solution design and delivery interval short, the team can
easily decide which activities are necessary and sufficient to achieve the
right products
• Maintain a central view of all design and delivery activities showing
schedule and dependencies
• Use configuration management to understand the entire solution and its
components and iterations

May 4, 2020 102
Principle 5 – Fitness For Business Purpose And Value Is The
Essential Measure for Acceptance of Deliverables
• Focus of agile is on delivering the necessary functionality at the
required time
− Balance of the best functionality at the best value to the best quality in
the shortest time
• Traditional solution design and delivery focus has been on
satisfying the contents of a requirements document and
conforming to previous deliverables, even though the
requirements are often inaccurate, the previous deliverables
may be flawed and the business needs may have changed since
the start of solution design and delivery
• Solution can be more rigorously engineered subsequently if
such an approach is acceptable and needed
• Use cost and value as a guide to action
• Seek to take a cross-functional view of solution operation
rather than vertical view on organisation silos

May 4, 2020 103
Principle 6 – Iterative And Incremental Development Is Necessary To
Converge On An Accurate Business Solution
• Agile iterative approach allows solutions to grow incrementally
• Therefore the solution design and delivery team can make full use of
feedback from the solution consumers of all types
• Iterations allow for solution concept validation, the narrowing of solution
design and change of direction if necessary
• Partial solutions can be delivered to satisfy immediate business needs
• Agile approach uses iteration to continuously improve the solution being
implemented
• When rework is not explicitly recognised in a solution design and delivery
lifecycle, the return to previously completed work is surrounded by
controlling procedures that slow development down
• Rework is built into the agile iterative approach process so the solution can
proceed more quickly during iteration

May 4, 2020 104
Principle 7 – All Changes During Solution Design And
Delivery Are Reversible
• To control the evolution of all solution components
everything needs to be in a known state at all times
− Solution configuration management must be implemented and
maintained
• Backtracking is a feature of agile iterative approach
− Sometimes it may be easier to reconstruct than to backtrack
depending on the nature of the change and the environment in
which it was made
• Agile solution design and delivery accepts the variability
and lack of certainty
• Preserve solution design options as long as possible

May 4, 2020 105
Principle 8 – Requirements Are Baselined At A High
Level
• Baselining high-level requirements involves freezing and
agreeing the purpose and scope of the solution at a level
that allows for detailed investigation of what the
requirements imply
• Further, more detailed baselines can be established later
in solution design and delivery
− The scope should not change significantly
• Changing the scope defined in the baselined high-level
requirements generally requires escalation

May 4, 2020 106
Principle 9 – Solution Validation Is Integrated And
Performed Throughout the Lifecycle
• Solution validation is not treated as a separate activity during
design and delivery
• Validation includes verifying the solution is fit for its intended
purpose and delivers economic and business benefits
• As the solution is developed incrementally, it is also tested and
reviewed by both the solution design and delivery team and
solution consumers incrementally
− Ensures that the solution is moving forward not only in the right
business direction but is also technically sound
• Early in solution design and delivery lifecycle, the testing focus
is on validation against the business needs and priorities
• Towards the end of solution design, the focus is on verifying
that the whole solution operates effectively – system and
integration testing

Principle 10 – Understand And Confirm The Scope
Of The Solution In Its Entirety
• Understand and confirm the desired operational context
of the solution
• Understand what is necessary to get the complete solution
operational and delivering business value and benefits
• Understand the objectives of the solution and what the
organisation wants to achieve through it
• Understand the complexity of the solution and the
interdependencies and interactions of its components
• Solution optimisation involves optimising all its
components
May 4, 2020 107

Agile Solution Design And Delivery Critical Success
Factors
• Acceptance of the agile approach before starting work
• Delegation of decision-making to the business people and developers in
the development team
• Commitment of senior business management to provide significant end-
user involvement
• Incremental delivery
• Easy access by developers to end-users
• Stability of the team
• Solution design and delivery team should be skilled people in terms of both
the business area as well as the technical environment
• Size of the solution design and delivery team should be small in order to
minimise the overheads of management and communication
• Solution technology and supporting tools that allows configuration
management, iterative development, demonstrable work products and
control of versions
May 4, 2020 108

Application Of Time Limits And Time Units
• Limiting time spent is important aspect of agile iterative process and solution
design and delivery
• Process to reach defined objectives at a pre-determined and fixed date through
continuous prioritisation and flexing of solution requirements using a MoSCoW
type approach
• Unit of time should be fixed - typically between two and six weeks in length but
the shorter the better
• Without the control of time limits, solution design and teams can lose their focus
and run out of control
• Used at various stages of solution design and delivery
− Solution design and delivery end-date is fixed and the overall business objectives to be
achieved by that date are defined
− End date for each increment within the solution design and delivery is fixed and the
prioritised set of business and technical requirements to be satisfied by that date are defined
− End date for phase level activities is fixed, e.g. for the Feasibility Study, and the objectives for
this solution defined
− End date for part of the prototyping activity is fixed and the prototype is created, reviewed
and tested according to the objectives defined in the timebox schedule contained in the
Development Plan
− End time for a workshop, meeting or review is fixed and the participants work to the
predefined and prioritised objectives
May 4, 2020 109

May 4, 2020 110
Time Limits And Time Units
• The time unit must have an agreed scope and clear objectives based on a subset
of the prioritised requirements list
• With time limits and time units, control is not activity-based
• Objective of a time unit is to make a product - produce something tangible in
order that progress and quality can be assessed and quantified
• How that solution is put together will be decided by the people doing the work, as
long as the solution design and delivery standards and procedures are followed
• Team working in the time unit must agree the objectives and must themselves
estimate the time required
• At the deadline, the solution consumers must be able to approve the delivery of
the products covered by the time unit
• If it appears that deadlines could be missed, the deliverable should be de-scoped
dropping the lower priority items
• Detailed planning of a subsequent time unit containing dependent work cannot be
started before the current time unit is complete

May 4, 2020 111
Plan For Time Limits And Time Units
• Plan for an individual timebox within the Overall Solution
Architecture Design and Solution Components Design And
Implementation phases
• Define their purpose and objectives
• Define the products of an individual time unit
• Define key milestones, such as technical or solution
consumer review dates, within a time unit
• Agree the priority and importance of deliverables,
products and activities within a time unit

May 4, 2020 112
Time Limits, Time Units And Daily Meetings
• During each time unit, the solution design and delivery team working
on the time unit should meet daily to review their progress and to
raise issues
− Provides the solution design and delivery team with evidence regarding their
progress and the problems they face
− Highlight risks as they occur
− Each daily meeting should be limited at 30 minutes and ideally lasts no longer
than 15 minutes
− All solution design and delivery team members attend
• Topics to cover
− What work has been completed for this time unit since the last daily meeting?
− What (if anything) got in the way of completing the planned work?
− What work will be done between now and the next daily meeting?

May 4, 2020 113
Time Limits And Time Units Plan Questions And
Checklist
• Are the estimates of effort reasonable? Were they produced by the
members of the solution design and delivery time that will be doing
the work?
• Have acceptance criteria been agreed for the products of the time
unit? If they have not, is it clear when these will be available?
• Is there a high degree of certainty that the Must Have requirements
will be created, developed and tested to the required standard?
• Are the review dates agreed with all key personnel?
• Have lessons learnt in previous time units been applied?
• Can the team commit to delivering at least the Must Have
requirements by the agreed end date?

Solution Design And Delivery Management
• This topic covers:
− Solution requirements
− Solution design and delivery estimates
− Solution configuration management
− Management and planning of the solution design and delivery
process
− Supporting tools and technologies
May 4, 2020 114

• It is unreasonable to expect that business stakeholders in and
consumers of a potential solution can articulate a set of complete,
fully-developed consistent requirements through part-time
involvement in a few requirements gathering exercises
• Requirements never capture the detail of the complete solution
• Requirements are just one set of constraints imposed on the
solution design
• You will just end-up with apparent delivery changes as the need for
ignored components become actual
• Requirements are not delivered – it is the solution and its
components that are delivered
• The Solution Design Framework And Scope Definition phase creates
a structure that can be used to identify solution requirements that
are refined during later design and delivery iterations
May 4, 2020 115

• The reality is that what is gathered during requirements
workshops, meetings, interviews, questionnaires and other
activities are not solution requirements but business
stakeholder requirements
• Stakeholder requirements must be translated into solution
requirements which is turn must be translated into a solution
design
• Requirements gathering is a means to an end and not an end in
itself
• Requirements gathering should never be part of the delivery
activity but be the subject of an analysis and architecture
design exercise prior to any solution design and delivery
activity
• You cannot know what the scope of the delivery activity is until
the solution that needs to be delivered is known
May 4, 2020 116

Gathered Solution Requirements Tend To Be …
− … Sparse and disconnected
− Isolated and disintegrated statements
− At different levels of detail
− Inconsistent
− Incomplete
− Disjointed
− Conflicting
− Uncosted
− Unprioritised
• Representations of specific points of
functionality that do not aggregate
into a complete well-defined solution
• A source of additional unstated and
implied requirements
• The solution design and delivery
process needs to weave these into a
complete solution
May 4, 2020 117
= Explicitly Identified Gathered Requirement
= Solution Factor Not Explicitly Listed As Requirement

Myth Of Changing Solution Requirements
• It is not solution requirements that change
• It is that latent solution requirements were not identified or
were ignored that become apparent or unavoidable during
implementation
• Undiscovered and unarticulated solution requirements then
impact other solution components leading to additional
downstream changes which affects solution design and delivery
• The agile solution design and delivery approach accepts the
initial uncertainty of requirements
• These initial solution requirements will be refined, elaborated
and expanded on, changed, reprioritised and possibly removed
during design and delivery iterations
May 4, 2020 118

May 4, 2020 119
MoSCoW Prioritisation Of Solution Requirements
And Characteristics
• MoSCoW
− Must Have
• Requirements that are fundamental to the solution and its operation, utility
and usability
• Without them the solution will be unworkable and useless
• Must Haves define the minimum usable subset
• Agile solution design and delivery guarantees to satisfy all the minimum
usable subset
− Should Have
• Important requirements for which there is a workaround in the short-term
and which would normally be classed as mandatory in less time-constrained
development, but the solution will be useful and usable without them
− Could Have
• Requirements that can more easily be left out of the increment under
development
− Want to Have But May Not Have This Time
• Requirements that can wait till later development takes place - the Waiting
List

And Characteristics
• Any solution design
and delivery activity
is a trade-off
between four
different factors
1. Solution Features
And Functionality
2. Resources And
Finance
3. Solution Quality
And Delivery And
Operational Risks
4. Time
• As factors become
constrained core
Must Have
requirements get the
highest design and
delivery priority
May 4, 2020 120
Solution Features
And Functionality
Solution Quality
And Delivery And
Operational Risks
Resources
And FinanceTime
Must
Have
Should
HaveCould
Have
Want To Have
But May Not
Have This Time

May 4, 2020 121
And Characteristics
• Delivering on a guaranteed date means that what was originally envisaged for an
individual delivery may have to be left out
• Important that essential work is done and that only less critical work is omitted
• Means of ensuring that this is true is clear prioritisation of the requirements
• Provides a basis on which decisions are made about what the solution design and
delivery team will do over the whole solution design and delivery, within a
solution component and during a time unit within a component
• As new requirements arise or as existing requirements are defined in more detail,
the decision must be made as to how critical they are to the success of the current
work using the MoSCoW approach
− All priorities should be reviewed throughout solution design and delivery to ensure that
they are still valid
• Essential that not everything to be achieved within a solution or a time unit is a
Must Have
− Having lower level requirements that enable teams to deliver on time by dropping them
out when problems arise

May 4, 2020 122
Solution Design And Delivery Estimation
• Estimation provides the information that is required for two
main purposes:
1. Assess solution design and deliverability feasibility by evaluating costs
and benefits
2. Use in design and delivery activity planning, scheduling, control and
management
• Estimation in agile solution design and delivery means
− Estimates should be tight from the outset with frequent deliverables
• Not unacceptable for activity overrun and for long timescales for agreeing the
quality of deliverables
− Estimates that are based on outline business functions provide the
closest match with the agile solution design and delivery approach
• Starting point for estimating should be the expected functionality of the end
deliverables rather than the activities used to deliver them

May 4, 2020 123
Solution Design And Delivery Estimation
• Estimation is a conditional forecast based on the information available at a time
− An extrapolation from past and current knowledge to the future
− Cannot be done with complete certainty because the future is not certain and therefore
the actual effort or cost to deliver will almost always be different from the estimate
− The better the quality of the information available for estimating and the better and
more realistic the estimation approach(es), the closer the estimate is likely to be to the
actual figures
• Estimation must be based on a defined process so that it is rigorous and
repeatable
− Whatever process is used, the primary information required to estimate is:
• Scope of what is to be delivered
• Delivery capability – resources, time
• Complexity and uncertainty of deliverable and its impact on estimates
• Contingency must be included in any estimate in order for it to be realistic
− Estimates are conditional forecasts that will be affected by future events both internal
and external to solution design and delivery
− Events cannot be known with certainty and the estimate must make reasonable
allowance for them
− Solution design and delivery is not exact
− The size of the contingency in an estimate must reflect the degree of uncertainty

Estimation During Solution Design And Delivery
• Estimation and associated solution design and delivery
planning occurs at five key stages:
1. Pre-Solution Design And Delivery
2. Solution Feasibility Analysis And Study
3. Solution Design Framework And Scope Definition
4. Overall Solution Architecture Design
5. Solution Components Design And Implementation
May 4, 2020 124

Estimation During Solution Design And Delivery
Phases
May 4, 2020 125
Pre-Solution
Design And
Delivery
Solution
Feasibility
Analysis And
Study
Solution Design
Framework And
Scope Definition
Before solution design and delivery starts properly an estimate must be prepared for the work to be done
during Solution Feasibility Analysis And Study and the required effort
Estimate could be a define amount of time and effort - a fixed team for a fixed period - or could be based on a
schedule of workshops and other activities and the associated effort to complete the products
First estimate for the whole solution design and delivery is prepared towards the end of Solution Feasibility
Analysis And Study
Rough estimate, based on high level solution needs – designed to assist management to assess the value and
practicality of continuing with the solution design and delivery activity
Second estimate is produced at the end of the Solution Design Framework And Scope Definition
- scope of the solution is reasonably well-defined and agreed, the necessary business and solution consumer
functionality to be delivered is defined and prioritised, and the solution architecture and design is outlined
This should be a detailed estimate as it based on the likely major components of the delivered solution
identified from the prioritised requirements
Estimate must reflect a level of risk and confidence that is acceptable to the relevant solution stakeholders
Purpose of this estimate is to plan and schedule solution design and delivery and used to re-evaluate the
business case to assess whether the solution is still viable

Agile Solution Architecture and Design

Agile Solution Architecture and Design

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Agile Solution Architecture and Design

Ähnlich wie Agile Solution Architecture and Design (20)

Mehr von Alan McSweeney

Mehr von Alan McSweeney (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Agile Solution Architecture and Design