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
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
• 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

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

Phases
May 4, 2020 126
Overall Solution
Architecture
Design
Solution
Components
Design And
Implementation
Detailed estimate from Solution Design Framework And Scope Definition provides the basis for the whole solution
design and delivery and throughout the remainder of solution design and delivery this estimate needs to be frequently
monitored and revised
Estimation is performed for each time unit to assess whether the design and delivery plan is achievable and to evaluate
the impact on the solution design and delivery if any revisions to the estimate are required
Before the start of each time unit an estimate for the expected work is carried out to ensure that it remains achievable
in the light of solution design and delivery experience to date
If there is any significant deviation from the estimates, the original estimates should be carefully reviewed
Until the implementation plan is prepared during Overall Solution Architecture Design and its iterations there are only
very high-level estimates available for Solution Components Design And Implementation and its iterations
Before implementation phase begins, the estimates must be reviewed to ensure they are still reasonable

Estimation Techniques And Approaches
• Top Down - estimating by comparison where the proposed solution is compared
to similar completed solutions – reference class forecasts
− Based on the business requirements (rather than system components)
− Give a figure for solution design and delivery as a whole which may be broken down
into phases
− Fast to prepare
− Can be derived from very high-level requirements
− Give a high-level view of solution design and delivery which can be used in evaluating
the feasibility of the solution
• Bottom Up - counting components and other implementation-related information
shown in a design and estimating the effort for each of those
− Based on tangible system components
− Give detailed figures for low level components of solution design and delivery which
can be aggregated to give higher level views
− Take time to prepare
− Need sufficiently detailed information to allow identification of system components
− Provide a good basis for solution design and delivery planning, scheduling and
management
• Combination of approaches allows estimates to be cross-checked to avoid
bias-related inaccuracies
May 4, 2020 127

Solution Design And Delivery Estimation Concerns
• Estimation can be a painful and difficult process
• There is always be a tendency not to include all items and solution components that
consume resources
• This does not make the costs go away
• Accurate cost analysis and estimation are very important as they affect decision-making
• You need to avoid problems with inaccurate estimation such as:
− Strategic Misrepresentation – Deliberate misrepresentation in estimates caused by distorted incentives
− Planning Fallacy – Systematic tendency to underestimate how long it will take to complete a task even
when there is past experience of similar tasks over-running
− Optimism Bias – Systematic tendency to be overly optimistic about the outcome of actions
• Some of the key sets of factors in any decision include:
− Overall solution operation and use lifetime estimates
− Risks associated with solution option
− Resources and time to implement
− Compliance with organisation’s business strategy, IT strategy and enterprise architecture and the
associated design and delivery overheads
− Implementation of solution pre-requisites and enabling technologies
− Complexity of the solution based on numbers of components, integration points, numbers of consumers
− Whether it is an externally facing solution
− Security requirements and the sensitivity of the data being processed
− Adoption of new technologies, platforms and delivery approaches
− Number of suppliers
May 4, 2020 128

Strategic Misrepresentation
• Deliberate misrepresentation in planning and budgeting caused by
distorted incentives
• Tends to be a response to and consequence of how organisations
structure rewards, give rise to motivations or tolerate dissent
− “Fit in or fuck off”
− “My way or the highway”
− “You're either with us or against us”
• Systematic (and predictable) misrepresentation
− Deliberately underestimate costs to gain acceptance with understanding that
costs will increase
− Ignore necessary solution components
− Not willing to face reality of high costs
− Overstatement or understatement of requirements
− Competition for scarce funds or contending for position and prestige
− Inclusion of ideology and organisational politics into planning and estimation
• Underlying system and processes need to be redesigned to eliminate
May 4, 2020 129

Estimation Model
• Create a structured estimation model that can be reviewed and
updated during the solution design and delivery
• The structure and detail of the estimation model is as
important as the values themselves
• A good estimation model reflects the source and structure of
the estimation
• It allows the estimation to be known and understood
• The amounts of each element within the estimation model can
be changed as more accurate information becomes known
• Completely accurate information may not be available at this
stage but the model can be created and partially populated
• Identify the gaps and repeat the analysis when more certain
information is available
May 4, 2020 130

Solution Configuration Management
• Dynamic nature of agile solution
design and delivery means good
configuration management is
important
• Many activities are happening at
once and products are being
delivered at potentially a very
fast rate
• Configuration management
approach must be decided and
documented before leaving the
Solution Design Framework
And Scope Definition phase
needs to track the details on the
dimensions of the solution and
its design and delivery
May 4, 2020 131
Design And
Delivery
Cycles
Within
Component
Components
Within
Component
Types
Component
Types

Management Of The Solution Design And Delivery
Process
• The objective of solution design and delivery management is to
manage the design and delivery of the right solution on time
and on budget using the available resources wisely
• Management of traditional solution delivery is about control
− Preventing drift from the signed off specification, controlling resources,
etc.
• Managing agile solution design and delivery is about enabling
constant change while continuously correcting the course of
the solution design and delivery activities in order to maintain
its aim at the target - a fixed delivery date for a usable solution
• To be successful with agile solution design and delivery, the
organisation may have to change organisational, social,
cultural, political and technical elements at the same time
• All of the changes impact on the management of solution
design and delivery
May 4, 2020 132

Process
• For tradition solution design and delivery projects, the project manager has
a detailed plan against which to monitor and control activities
• For agile solution design and delivery, there are typically more activities
going on in parallel
− The delivery manager has a number of distinctive responsibilities to ensure that the
solution design and delivery is under control in each phase
• Speed of progress and multiple parallel activities can pose some difficulties
for managers from a traditional background in information technology
project management
− If problems arise during a timebox then it is often tempting for the traditional
manager to renegotiate the end date as that is what they would normally do
− In agile solution design and delivery, the time unit duration and deadline are fixed
usually because it is set by the business need
− Consequently, the approved approach is to renegotiate the content of the time
unit rather than its duration
• Agile solution design and delivery requires a greater ability and willingness
to engage with detail
May 4, 2020 133

Process
• In agile solution design and delivery, there is far greater interaction
between solution consumers, stakeholders and implementers in task
completion
• It is important that communication is clear and concise if rapid
design and delivery is to be achieved
− Look at implementing centralised knowledge management and sharing
• Agile solution design and delivery should have an informal but
planned communication process
• As each time unit is completed, it is the responsibility of the solution
delivery manager to ensure that there is a clear understanding about
what is to be delivered in the following time units and to ensure that
the relevant requirements are established in detail
− Likely that the users will change their minds about priorities and requirements
− Solution design and delivery manager must be open to making such changes
while ensuring that any consequences and impacts are fully understood by the
solution consumers and stakeholders
May 4, 2020 134

Process During Phases
May 4, 2020 135
Pre-Solution
Design And
Delivery
Solution
Feasibility
Analysis And
Study
Solution Design
Framework And
Scope Definition
• Initial solution design and delivery schedule and resource and time estimates
• Verify suitability of solution for agile approach
• Agree solution design and delivery review and termination evaluation and decision factors
• Confirm key solution consumer and stakeholder involvement
• Give training in agile approach for all people new to the approach
• Agree and schedule workshop facilitators
• Establish the Solution Feasibility Analysis And Study team
• Schedule and ensure attendance at workshops, if relevant
• Review/accept and get signoff for the Solution Feasibility Analysis And Study outputs
• Ensure that all key stakeholders and key solution consumers have contributed to and reviewed the prioritised
requirements list and the proposed timescales for phased and iterated delivery of the solution
• Create a high-level Business Case for the solution
• Refine the previously created initial solution design and delivery schedule and resource and time estimates
• Schedule the Solution Design Framework And Scope Definition phase and resources
• Manage production of the Solution Design Framework And Scope Definition deliverables
• Schedule and ensure attendance at workshops, if relevant
• Review and update solution design and delivery risks
• Update the solution design and delivery jointly with all relevant people
• Refine the Business Case and get it agreed by the relevant people
• Obtain agreement to proceed into solution design and delivery
• Ensure that all solution design and delivery team leaders are aware of the contents of the Business Case so that they
can use it as the basis for negotiation about what is important within their units of work

Process During Phases
May 4, 2020 136
Overall Solution
Architecture
Design
Solution
Components
Design And
Implementation
• Agree individual time unit plans with the team leaders
• Participate in time unit initiation and close-out meetings
• Accept all time unit deliverables to the solution design and delivery at each time unit closeout meeting
• Monitor the team(s)
• Create the design and delivery plan jointly with all relevant people
• Refine the previously created initial solution design and delivery schedule and resource and time estimates and get it
agreed by the relevant people before the end of the last pass through the Overall Solution Architecture Design
• Accept design refinement feedback from the Solution Components Design And Implementation activity
• Participate in time unit initiation and close-out meetings
• Accept all time unit deliverables to the solution design and delivery at each time unit closeout meeting
• Monitor the team(s) performance
• Manage the design refinement feedback to the Overall Solution Architecture Design activity
• Manage the migration of the solution components to their operational status
• Ensure all necessary documentation and knowledge transfer takes place in a timely way
• Ensure all necessary training takes place in a timely way
• Run the solution component completion workshop and produce the solution component review
• Obtain sign-off of the solution component completion from all relevant parties
• Plan the next solution component completion if there is one
• For the final solution component completion, set the date for the Post-Implementation Review
Post-Solution
Design And
Delivery
• Collate lessons learned from solution design and delivery participants
• Ensure all lessons learnt are made available to other subsequent solution design and delivery activities
• Schedule the Post-Solution Design And Delivery review
• Participate in and finalise the Post-Solution Design And Delivery review

Planning For Solution Design And Delivery
• The purpose of solution design and delivery planning is to ensure the success of
the activity and of the designed and delivered solution
• For agile solution design and delivery planning, planning is not just an activity that
takes place at the start - it continues throughout all the phases
• Planning an agile solution design and delivery planning can be especially difficult
for a delivery manager who is used to more traditional methods
• Agile solution design and delivery plans evolve with additional detail as the activity
progresses, as requirements are progressively refined, as options are explored and
selected and as lessons are learnt
• Plan should address all products generated by, and activities undertaken in, the
solution design and delivery
− Includes the deliverable products (prototypes, models, documentation, etc.)
• Solution design and delivery initiation
• Change control
• Solution breakdown structure
• Overall solution description and descriptions of individual solution components
• Risk management
• Work instructions for specific time units
May 4, 2020 137

Planning For Solution Design And Delivery
• Traditional project planning
− Focus on agreeing a detailed contract with solution stakeholders and
consumers about the entirety of the solution to be delivered along with the
costs and timescales
− Concerned with understanding the requirements in complete detail so that the
correct level of resources can be secured and an estimate of the completion
time can be made
− Plan is created in a great detail and is ideally executed with minimal change
• Agile solution design and delivery planning
− Focus on setting up a collaborative relationship with the solution stakeholders
and consumers, bringing them fully into the composition of the team
− Concerned with agreeing with the solution stakeholders and consumers the
process by which the business requirements will be met
− Initial plans are created in sufficient detail to establish the main boundaries of
the solution design and delivery and with the firm expectation that the
solution stakeholders and consumers will change the plan during solution
design and delivery as they gain a deeper understanding of their needs
− More intensive planning and management effort
May 4, 2020 138

Refinement Of Design And Delivery Plans During
Phases
May 4, 2020 139
Solution Feasibility
Analysis And Study
Solution Design
Framework And Scope
Definition
Overall Solution
Architecture Design
Solution Components
Design And
Implementation
Delivery
• Identification of very high-level plan and approach to assess the suitability of the solution for
agile solution design and delivery
• Creation of an outline solution design and delivery plan identifying major solution components
and the activities and resources required to implement
• Identification and agreement of scope of the solution
• Definition of major solution components and their interactions
• Elaboration and refinement of the outline solution design and delivery plan with detail on
solution components and their implementation
• Maintain and update the solution design and delivery plan in the context of the overall solution
design and the iterations to expand the design of its constituent components
• Maintain and update the delivery plans for each of the solution components and provide
feedback to the Overall Solution Architecture Design phase to allow the overall solution design
and delivery plan to be maintained

Refinement And Evolution Of Design And Delivery
Plans
• The solution design and
delivery plan evolves
and is expanded on as
the work proceeds
May 4, 2020 140
Solution Feasibility
Analysis And Study
Solution Design
Framework And Scope
Definition
Overall Solution
Architecture Design
Solution Components
Design And
Implementation
Delivery
Indicative
High-Level
Plan
Outline
Plan
Detailed Solution
Component Plan
Updates to Plan
Based on
Implementation
Results
Plan
Updates

Planning Issues
• Objectives and requirements that are either too vague or
too detailed
• Failure to architect the approach before starting the
solution design and delivery process
• Frequent changes to the schedule for solution consumer
and stakeholder involvement
• Incomplete and conflicting information
• Introducing too much change at one time
May 4, 2020 141

Solution Design And Delivery Planning Success
Factors
• The planned scope and contents of time units are very important
• Plan for deliverables and not activities
− Consider the key questions who, when what, where and how when planning
• Define quality evaluation factors for each deliverable
• Plan for frequent delivery of products
− Distinguish from delivery to the project from delivery to the solution consumers and stakeholders
• Focus of planning and control in agile solution design and delivery is on sustaining a high rate of progress,
agreeing priorities, keeping relationships healthy, learning as the design and delivery progresses, and allowing
plans to evolve based on experience gained
• Make design and delivery planning work by focusing on principles, products, and people rather than methods
and techniques
• Manage expectations by planning appropriate briefings and training on agile approach, addressing roles and
responsibilities, and defining and agreeing products and acceptance criteria
• Plan for the use of experienced mentors where there is insufficient experience in the team
• Plan to do the work during normal working hours
• Plan contingency only for prerequisites (software, hardware, setup, etc.) but not for time or resource on
solution design and delivery itself
− Contingency in agile is managed through prioritisation of requirements
• Plan for regular daily team meetings
• Plan formal reviews at the end of each timebox and establish dates in diaries early
• Plan early for testing interfaces, theoretical performance analysis, and performance prototyping
May 4, 2020 142

Supporting Tools And Technologies
• Tools will assist the agile solution design and delivery
process and its management and tracking (separate from
design and delivery tools)
− Solution configuration management and reporting to assist with
tracking solutions across their design and delivery dimensions
− Solution delivery planning
− Knowledge sharing and collaboration
− Issue tracking
• The tools are means to an end and not ends in themselves
• Focus on the use of and deriving value from the tools
May 4, 2020 143

Risk Management
• Managing risk needs to take place throughout solution
design and delivery
• Actively control all the risks facing solution design and
delivery
− Identification of any and all risks that may threaten solution
design and delivery for business, systems or technical reason
− Assessment of the impact of those risks on the success of solution
design and delivery should they arise and deciding on the
likelihood of the risk occurring and if it does on the severity of its
impact on solution design and delivery
− Management of those risks through defining specific
countermeasures that are aimed at either avoiding the identified
risks or accepting them and minimising their negative impact on
the solution design and delivery
− Applying the appropriate countermeasures when a risk becomes
actual
May 4, 2020 144

Deliverables From Phases
• One of the characteristics of some agile approaches is that
there few interim deliverables explaining how the result
was obtained, especially documentation and retained
knowledge
• The agile solution design and delivery process described
here creates these necessary interim deliverables to allow
for knowledge retention and reuse
May 4, 2020 145

Risk Management
• Risks must be identified and their impact assessed as early as
possible
• Risks should be continuously reviewed throughout the life of
solution design and delivery, particularly at critical go/no go decision
points within solution design and delivery such as the end of the
Solution Design Framework And Scope Definition phase
• All risks should be assessed in terms of their potential impact
• Risks must be actively managed through countermeasures and
mitigations to minimise their possible impact
• The emphasis of risk management activities should be on the risks
with the highest levels
• Solution design and delivery with risks determined as unacceptable
should not be started
• Solution design and delivery whose risks rise to an unacceptable
level should be stopped
May 4, 2020 146

May 4, 2020 147
Risk Logging
• Opened at the start of solution design and delivery to assist management in
deciding the future of the solution
− Class of risk (business, systems or technical)
− Description of the risk - should be in sufficient detail to be understood by all interested
parties but short enough to enable a checklist approach to risk monitoring throughout
solution design and delivery
− Likelihood of the risk occurring (high, medium or low)
− Severity of impact on solution design and delivery should the risk occur (high, medium
or low)
− One or more proposed countermeasures, which will mitigate the risk either by
preventing it occurring or by containing when it arises
• Countermeasures should include the dates beyond which they are no longer applicable
− The status of the risk (open or closed), open risks are still possible, closed risks have
either happened and have been dealt with or the time at which they were likely to
happen has passed
− Owner of the risk (who is responsible for monitoring the risk and/or implementing any
countermeasures)
• Checklist
− Are all the factors potentially affecting the success of solution design and delivery
discussed?
− Are risks sufficiently quantified for a decision to be made?
− Does each risk have at least one countermeasure identified?

Quality Management And Validation
• Quality of an information technology solution often defined in
terms of the way in which that system provides the capability
and support required by the solution consumers of all types
− Agile approach designed to ensure the quality of solution design and
delivery
− Facilitated workshops ensure that the system's requirements are
properly considered at the outset
− Continuous and focused solution consumer involvement helps to ensure
that all parties understand each others - needs and viewpoints
− Reviews (whether of prototypes or of supporting documentation) serve
to ensure (and record) that the system continues to meet the needs of
the business - the quality criteria against which products should be
reviewed are identified the solution component descriptions
− Thorough testing validates the delivered system against its
requirements
− Configuration management and change control serve to ensure that
quality, once built in to the system, is preserved
May 4, 2020 148

Quality Planning
• Quality planning should be an integral part of solution design and
delivery planning
− Identification of which solution components are to be produced and which of
those warrant specific quality-related activities
− How the quality of each type of solution component is to be checked - for
example by review and/or by testing
− When quality checks are to be performed and whether they are they optional
or mandatory, whether or not all examples of a particular type of product must
be checked or only a sample, and whether items are checked during
development or only on completion
− Who is responsible for reviewing and testing each solution components who
has authority to accept the product and what is to happen if such a review or
test is unsuccessful
− Which criteria are to be used to assess each product's quality - typically by
reference to the quality criteria defined in each of the solution component
descriptions
− Which procedures are to be used to define quality-related processes
− Which records are to be kept to document decisions and actions taken
− Which standards are to be applied to solution components
May 4, 2020 149

Quality Checks
• Perform audits on solution design and delivery from time to time in order
to determine their compliance with the organisation's procedures,
practices and standards
• Important in agile solution design and delivery that such audits are not
allowed to result in unnecessary rework or in ineffective effort expenditure
− They are lesson-learning and lesson-embedding exercises
− Must be more than exercises where lessons are written down and ignored
• Greatest benefit obtained from audits will be to update organisation
procedures, practices and standards based on real and practical experience
• Agile-specific audit questions
− Are solution consumers being involved?
− Are the solution consumers empowered?
− Is the overall agile solution design and delivery life-cycle being followed?
− Are comments from prototype reviews being incorporated?
− Is backtracking allowed when necessary?
− Are priorities being adhered to?
− Are time limits and time units being respected?
May 4, 2020 150

May 4, 2020 151
Solution Validation
• Solution validation takes place throughout the solution
− Validation - check that the solution is fit for the intended
purposes of the solution consumers
− Benefit-directed testing - testing the parts of the solution that
deliver the most important business benefits is the highest
priority
− Error-centric testing - objective of designing and running a test is
to find an error or a problem
− Testing throughout the design and delivery process - performed
on all products at all stages of solution design and delivery
− Independent testing – the solution or its components should be
tested by someone other than its creator
− Repeatable testing - tests must be repeatable

May 4, 2020 152
Solution Validation
• Solution validation and testing activities must be prioritised based on
the business goals
− Overall business process performance (i.e. business processing cycle times)
− Large processing volumes (i.e. very frequently occurring events)
− Labour-intensive or complex business tasks
− Human computer interface, particularly if the solution will be visible to solution
consumers outside the organisation
• Efficient use of time available can be made through risk-based
testing
− Identify the risk areas
− Assess the impact of errors
− Plan for risk-based testing
− Reduce the risk of errors

Solution Component Validation
• The approach to validation is different for each solution
design and delivery component
− Functional and operational testing
− Formal walkthrough
− Simulation
May 4, 2020 153

May 4, 2020 154
Workshops
• Workshop is a structured approach to ensure that a group of people can reach a predetermined
objective in a compressed timeframe supported by an impartial facilitator
• Benefits
− Rapid, quality decision-making
• Because all stakeholders are present at the same time, there is great confidence in the result
• Group is focused on the objectives to be achieved in the session so that the information-gathering and review cycle is
performed at a greater speed
• Misunderstandings and disagreements can be worked out at the time
• Concerns should therefore have been raised and resolved or noted by the end of the workshop
− Greater user buy-in
• Workshops, run effectively, lead to participants feeling more involved in solution design and delivery and decisions being made
• Build and maintain enthusiasm
− Building team spirit
• Controlled way of building rapport as well as delivering
• Promotes understanding and co-operation between departments - important when a solution involves many groups
− Process redesign by the user community
• If practices are reviewed as a result of a workshop, participants can gain a greater understanding of the inputs and implications
of their work
• Leads to improved efficiencies that are led by the participants themselves, giving greater buy-in and commitment
• Greater chance of successful implementation
− Clarification of requirements when they are unclear
• Business users can be led through their objectives and processes to define what they may require
• Participants can explore and model ideas
• Successful through a combination of structured discussion and the presence of knowledgeable participants

Solution Design And Delivery Workshops
• Active Solution Consumer Involvement Is Essential For Success
− Workshops provide an ideal format for the business to be directly involved in planning, designing and
implementing a solution
• A Collaborative And Co-operative Approach Between All Stakeholders Is Essential
− Create a climate of co-operation within the workshop and enforcing any ground rules for the group to
behave effectively
− Only possible with the co-operation and commitment of all stakeholders
− Effective way of achieving either compromise or consensus
• Agile Solution Design And Delivery Team Must Be Allowed Make Decisions
− Workshop participants need to be empowered and have the right level of knowledge and authority within
the scope of the workshop, so that decisions can be made without delay
• Focus Is On Frequent Delivery of Products
− Structure a workshop so that there are intermediate deliverables
− Helps to order participants' thinking as they progress in logical steps
− Enables them to work towards an ultimate goal and gives them a growing sense of achievement as the
workshop progresses
• Fitness For Business Purpose And Value Is The Essential Measure for Acceptance of
Deliverables
− Fitness for purpose is achieved by keeping participants focused on delivery against an agreed set of
objectives
− Ensure solution consumers and stakeholders are involved in decision-making
May 4, 2020 155

Solution Design And Delivery Workshops
• Iterative And Incremental Development Is Necessary To Converge On An Accurate Business
Solution
− Strength of workshops is the unit of purpose and collaboration achieved by the group
− Ideas do not have to be born fully developed but can grow during discussion
− Ideal setting to try out ideas with all stakeholders and it is up to the facilitator to provide a safe
environment in which this can happen
• All Changes During Solution Design And Delivery Are Reversible
− Information and decisions should be recorded as necessary by either one or both of the facilitator and
scribe so that ideas can be backtracked where necessary
− Often what happens in practice is that an idea or decision is redeveloped
• Requirements Are Baselined At A High Level
− Objectives must be set during the preparation for a workshop
− As the workshops progress, information is gathered, analysed and interpreted so that discussion can be
effective and a decision reached as a result of an increased understanding of the issues involved
• Solution Validation Is Integrated And Performed Throughout the Lifecycle
− Because all stakeholders are present, workshop provides the quality control approach of testing ideas and
deliverables as they are discussed
− Participants can challenge or agree
• Understand And Confirm The Scope Of The Solution In Its Entirety
− Individual solution component design needs to take place within the context of the overall end-to-end
solution
− An end-to-end solution view provides team members with a view of what the work is aiming to achieve
May 4, 2020 156

Prototyping
• Prototypes provide the mechanism through which solution consumers can
ensure that the detail of what is being delivered is correct
• Demonstration of a prototype broadens the solution consumers'
awareness of the possibilities for the new solution and assists them in
giving feedback to the solution design and delivery team
• Accelerates the solution delivery process and increases confidence that the
right solution is being implemented
• Types of prototype
− Business - demonstrating the business processes being automated
− Usability - investigating aspects of the user interface that do not affect
functionality
− Performance and Capacity - ensuring that the system will be able to handle full
workloads successfully
− Capability/Technique – testing a particular design approach or proving a concept
− Simulation – use simulation or modelling techniques and tools to breathe life into a
component design
May 4, 2020 157

2 Pre-Solution Design And Delivery
Structure Contents
May 4, 2020 158

Objectives And Scope Of Pre-Solution Design And
Delivery
• The objective of this phase is to ensure that only the right
solutions are selected and that their design and delivery are
established to maximise success
• Initial definition of the business problem or opportunity to be
addressed
• Verify suitability of the solution design and delivery for an agile
approach
• Decision to proceed or not to proceed with solution design and
delivery
• Initial solution architect and solution delivery manager
assigned
• Verify solution consumer and stakeholder availability and
participation
• Initial solution delivery governance is put in place
May 4, 2020 159

Pre-Solution Design And Delivery Activities
• Review the business case for the solution
• Document the solution topology and constraints
• Validate that the design and delivery of the solution is initially
suitable for an agile approach by applying the solution design
and delivery checklist
• Validate that the organisation structure enables and supports
agile approach
− Identify gaps and actions to resolve
• Check that the agile solution design and delivery principles can
be successfully applied
− Identify bottlenecks and actions to resolve
• Identify resources required for the Solution Feasibility Analysis
And Study phase
May 4, 2020 160

Pre-Solution Design And Delivery Activities
• Prepare estimate for the Solution Feasibility Analysis And Study
phase
− Consider allocating a (reasonable) fixed interval and doing only as much work
that can be accomplished within that fixed time
• Create initial high-level plan for overall solution design and delivery
• Agree initial solution design and delivery review and termination
evaluation and decision factors
• Confirm solution consumer and stakeholder involvement
• Identify gaps in the knowledge and experience of agile solution
design and delivery approach of participants in the for the Solution
Feasibility Analysis And Study phase
− Give training in approach for all people new to the method
• Agree initial approach to Solution Feasibility Analysis And Study
− This can always be changed during the phase
• Schedule workshop facilitators
May 4, 2020 161

3 Solution Feasibility Analysis And Study
May 4, 2020 162
Structure Contents

Solution Feasibility Analysis And Study
• Feasibility study phases should be short and should last no
more than a few weeks
− This is not a detailed exercise creating a detailed report – it is a
structured solution sanity check to validate if the solution is worth
progressing further
− Any information collected here will be revisited during later phases
• Consider using workshop(s) to perform some of feasibility
analysis
• Feasibility study generates the following outputs
− Feasibility report – some form of document that defines the work done,
the options identified and the recommendation
• Table of contents of report forms a work plan for this phase
− Outline plan for implementation
− Feasibility prototype/simulation/model, if necessary and justified
− High-level set of solution consumption journeys
− Initial solution risk log
May 4, 2020 163

Solution Feasibility Report Scope, Structure And
Contents
• Enables the solution decision-making forum to decide not only which option to choose for
the way forward and whether or not solution design and delivery should proceed beyond
the Solution Feasibility Analysis And Study phase
• Indicative structure and contents of the solution design and delivery feasibility report
1. Outline the problem or opportunity to be addressed by the new system
2. Define the scope of the solution design and delivery
3. Give a preliminary indication of any areas within the scope which may be desirable but not
essential
4. State, at least in outline, the Business Case for the solution - including where possible expected
costs, benefits, assumptions and risks (whether quantifiable or not)
5. Indicate what alternative solutions have been or could be considered
6. Define the major products to be delivered by the solution design and delivery
7. Report on the suitability of an agile approach for use on the solution design and delivery
8. Document the objectives of the solution design and delivery including operational characteristics
9. Document high-level technical and business constraints, e.g. timescale, hardware and software
platforms
10. Identify whether the system may be safety-related, processes personal data or if there may be
any product liability issues
11. Describe at a high level the business processes and data integrations/transfers that are expected
to be automated
12. Identify at a high level the interfaces necessary to existing data and applications
13. Identify which business processes and/or systems (whether automated or not) might be impacted
by the new system and which might need to change in order to accommodate it
14. Completed solution feasibility checklist
15. Description of feasibility prototype/simulation/model and results generated
16. Define the expected life of the solution and therefore the requirements for maintainability
May 4, 2020 164

Contents – 1/2
Section Indicative Contents
1. Outline the problem or opportunity to
be addressed by the new system
State the problem, its consequences an the benefits that will arise from its resolution or state the
opportunity, its size, its importance to the organisation and how it can be addressed
2. Define the scope of the solution design
and delivery
Define the end-to-end scope of the solution, identifying at a high-level all the likely components.
Identify key delivery responsibilities
3. Give a preliminary indication of any
areas within the scope which may be
desirable but not essential
List the optional elements of the solution that are not being included and the reasons for their
exclusion. List the potential benefits for the inclusion
4. State, at least in outline, the Business
Case for the solution - including where
possible expected costs, benefits,
assumptions and risks (whether
quantifiable or not)
Summarise the key elements of the business case as it exists so far including a high-level solution design
and delivery costs breakdown and payment schedule, the quantified expected benefits including when
they will start to materialise, assumptions included in the business case, risks associated with the
solution and any other relevant information such as organisation change required
5. Indicate what alternative solutions
have been or could be considered
List the alternatives evaluated, including the do nothing option, their advantages, disadvantages,
estimated costs and benefits and explain why they were not selected
6. Define the major products to be
delivered by the solution design and
delivery
Identify the major solution components in terms of applications or organisation changes that are
expected to be created by the delivery of the solution
7. Report on the suitability of an agile
approach for use on the solution design
and delivery
List the results of applying the agile suitability checklist to the proposed solution
8. Document the objectives of the
solution design and delivery including
operational characteristics
List the major planned or desired operational and quality characteristics of the proposed solution
May 4, 2020 165

Contents – 2/2
Section Indicative Contents
9. Document high-level technical and
business constraints, e.g. timescale,
hardware and software platforms
Document any limitations, constraints and dependencies that are currently known. This includes
planned new technologies, platforms or approaches not currently in use.
10. Identify whether the system may be
safety-related or if there may be any
product liability issues
State if the proposed solution is related to areas such as safety operations, if it is planned to process
personal data or it is relates to the delivery of a consumer product about which there may be product
liability issues, should faults arise
11. Describe at a high level the business
processes and data integrations/transfers
that are expected to be automated
List any existing or new business processes or data exchanges/integrations/transfers that the solution
will operate automatically
12. Identify at a high level the interfaces
necessary to existing data and
applications
List any data or application interfaces to existing systems and data sources
13. Identify which business processes
and/or systems (whether automated or
not) might be impacted by the new
system and which might need to change
in order to accommodate it
List existing business processes and associated operations that may be impacted by the solution and
that may need to change
14. Completed solution feasibility
checklist
Complete the solution design and delivery feasibility checklist
15. Description of feasibility
prototype/simulation/model and results
generated
If prototypes/models/simulations were developed in this phase their operation and use should be
described
16. Define the expected life of the
solution and hence the requirements for
maintainability
Describe the expected life of the solution and the associated service management impacts
May 4, 2020 166

Feasibility Prototype/Model/Simulation
• Feasibility prototype/model/simulation may be produced
for one or more of the solution components as a proof of
concept for the proposed solution
− To prove one or more of the possible technical solutions
contained within the Feasibility Report
− To demonstrate to the business the possible content of the
solution component consumer interfaces and their appearance
and usability
• Prototype should only be produced if it will really assist the
decisions made in the Feasibility Report
May 4, 2020 167

Solution Feasibility Analysis And Study Report
Questions and Checklist
1. Is the problem or opportunity definition in line with the needs of solution
stakeholders and solution consumers?
2. Is the scope of the solution sufficiently clear for it to be refined within the
Solution Framework And Scope Definition phase?
3. Are the business objectives to be met by the solution clearly defined?
4. Is the solution to the problem or opportunity, as laid out in the major solution
components to be delivered and in the objectives of the solution, feasible in
both technical and business terms?
5. Is the case for the solution design and delivery approach sound and are the
risks acceptable?
6. Do the solution stakeholders and solution consumers accept what has been
included and excluded from the scope?
7. Are all associated solutions and their interfaces identified, at least at a high-
level?
8. Is the impact on those solutions acceptable?
9. Is the business case for the solution design and delivery to proceed valid?
May 4, 2020 168

Outline Plan for Solution Design And Delivery
• First formal planning product within the overall solution
design and delivery
• Indicative set of deadlines and milestones for various
major phases of work and key deliverables
• Use the information contained in the feasibility study to
ensure consistency across all outputs from this phase
• Deadlines become the major control points around which
the later, lower level plans will be developed
• Provides the detailed plan for how the Solution
Framework And Scope Definition phase will be run
May 4, 2020 169

Outline Plan for Solution Design And Delivery
• Purpose and objectives
− Provide solution stakeholders with very high-level estimates of the financial
and resource implications (both solution design and delivery teams and
solution consumers) of the proposed solution
− Provide a basis for agreement of indicative schedule for the proposed solution
design and delivery activities
− Define the high-level acceptance criteria for the proposed solution
components such as that the solution will deliver all the agreed requirements
− Define and agree the approach to the Solution Framework And Scope
Definition phase
− Identify any particular facilities that the solution design and delivery teams will
require
− Define the expected path through the agile framework for the solution design
and delivery
− Identify any currently known issues surrounding the implementation of the
solution and in particular aspects such as data load/migration, organistion
change and solution consumer handover and transition to operational use
May 4, 2020 170

Outline Plan for Solution Design And Delivery –
Questions and Checklist
1. Are the estimates for effort realistic in the light of the contents within the Solution
Feasibility Analysis And Study Report ?
2. Are the estimated timescales consistent with the business needs of the solution?
3. Will the business be addressed in terms of what is delivered and when will they be
provided for?
4. Are the solution stakeholders able to commit to the level of solution consumer
resources required for the Solution Framework And Scope Definition phase and to
ongoing user involvement for the proposed duration of solution design and delivery?
5. Is solution components delivery management able to commit to the level of
development resources required for the Solution Framework And Scope Definition
phase and to ongoing involvement for the proposed duration of the solution design and
delivery?
6. Will all necessary tools and facilities be available as required?
7. Is it clear what the acceptance factors are and are they rigorous enough to define the
quality of deliverables while allowing the requirements to change and be reprioritised
during solution design and delivery?
8. Are all the currently identified standards and guidelines available and for those that are
not yet available, are there sufficient resources to enable their implementation or
acquirement?
May 4, 2020 171

4 Solution Design Framework And Scope Definition
May 4, 2020 172
Structure Contents

Solution Design Framework And Scope Definition
• This is a the first major deliverable from the solution
design and delivery processes
• It is effectively a high-level broad but not very deep
solution design
• It will be the starting point for the more detailed and more
delivery-oriented Overall Solution Architecture Design and
Solution Components Design And Implementation phases
• This phase should not be long – depending on the solution
complexity, it should last between 2 and 10 weeks, at most
• The priorities are breadth first and then depth
May 4, 2020 173

Two Sets of Activities In The Solution Design
Framework And Scope Definition Phase
Principal Solution Design Activities
− Step 1 - Inventory Of Solution Processes
− Step 2 - Inventory Of Solution Functions
− Step 3 - Inventory Of Solution Actors
− Step 4 - Inventory Of Solution Systems And
Applications
− Step 5 - Inventory Of Solution System
Integrations, Transfers And Interfaces
− Step 6 - Inventory Of Solution Actor-System
Interactions
− Step 7 - Inventory Of Solution Actor-Actor
Interactions
− Step 8 - Solution Logical Data Model View
− Step 9 - Inventory Of Solution Data Exchanges
− Step 10 - Inventory Of Solution Usage Journeys
Solution Design Estimation, Planning
And Management Activities
− Step 11 – Solution Design And Delivery Views
− Step 12 - Additional Solution Components
Design
− Step 13 - Map Solution Delivery Component
Dependencies
− Step 14 - Update Business Case
− Step 15 - Update Solution Design And Delivery
Estimates
− Step 16 - Update Solution Design And Delivery
Plan
− Step 17 - Make Go/No Go/Review
Recommendation
May 4, 2020 174
• Steps 1 to 10 can be repeated
• Steps 11 to 17 should only need to be done once but can be repeated
• The order of the activities can be varied
• Steps can be combined
• Having a formal set of activities and steps means you know what you have to do, how long it will take, what
information you need and what outputs you will generate

Solution Design Framework And Scope Definition Design
Principal Activity Steps Can Be Repeated During This Phase
May 4, 2020 175
Step 1 - Inventory Of Solution
Business Processes
Functions
Usage Journeys
Data Exchanges
Step 8 - Solution Logical Data
Model View
System Integrations, Transfers
And Interfaces
Actor-Actor Interactions
Actor-System Interactions
Actors
Systems And Applications

Principal Solution Design Activities
• Start with identifying core solution design elements – those
elements directly involved in the operation and use of the solution
• Expand initial solution design with extended elements – element
interactions and interfaces and information storage and exchange
• This initial design activity is concerned with the what of the solution
rather than the how – the implementation services required – these
can be defined later
May 4, 2020 176
Core Definition Elements Extended Definition Elements
Processes
Functions
Actors
Systems/Applications
System Interfaces
Solution Usage Journeys
Logical Data Model View
Data Exchange

Approach To Solution Design Framework And Scope
Definition
• This phase quickly identifies the components that are likely to comprise the
required solution
• It allows options to be identified and evidence-based decisions to be made
• Key elements of initial solution scope and design:
− Core
• Processes – business processes required to operate the solution
• Functions – functions that must be delivered by the overall solution
• Actors – business functions and roles that will interact with the overall solution and its components
• Systems/Applications – new and existing systems that must be developed/changed to deliver functions
− Extended
• System Interfaces – links between systems
• Actor-System Interactions – interactions between Actors and Systems/Applications
• Actor-Actor Interactions – interactions between Actors
• Journey – standard journey through processes/functions and exceptions/deviations from “happy path”
• Logical Data Model View – data elements required
• Data Exchanges – movement of data between Systems/Applications
• These design elements combine to provide a comprehensive view of the potential
solution design at this phase
May 4, 2020 177

Solution Components Types And Solution Design
Framework And Scope Definition
May 4, 2020 178
Solution Component Type Solution Design Framework And
Scope Definition Core Areas
Solution Design Framework And
Scope Definition Extended Areas
• Functions
• Systems/Applications
• Functions
• Functions
System Integrations/Data Transfers/Exchanges
• Data Exchanges
• System Interfaces
Reportingand Analysis Facilities • Functions
Sets of Installation and ImplementationServices
Information StorageFacilities • Systems/Applications
Existing Data Conversions/Migrations • Logical Data Model View
New Data Loads • Logical Data Model View
Infrastructure
Cutover/ Transferto Production And Support • Processes
Operational Functionsand Processes • Processes
Parallel Runs
Enhanced Support/Hypercare
Sets of Maintenance,Service Management and
Support Services
Changes to Existing Business Processes • Processes
New Business Processes • Processes
Organisational Changes,Knowledge Management • Actors
• Actor-SystemInteractions
• Actor-ActorInteractions
= Not Explicitly Covered in Solution Design Framework And Scope Definition Phase Principal Design Activities

Approach To Solution Design Framework And Scope
Definition
• The work in this phase can be repeated several times in
greater levels of detail as information is gathered, clarified
and analysed and options are identified and discussed
May 4, 2020 179

Solution Processes
• Define the business processes, either manual or automated, partially or
fully, new or existing, that will be used in the operation of the solution
• Solutions exist to allow business processes to operate
− The business organisation develops, implements and operates business processes
− Solutions enable those business processes
• Processes impact the design of the solution in number of ways
− New business processes may need to be defined that describe how solution
consumers should or will use the solution
− Existing business processes may need to be changed
− Both the new and existing processes should be optimised in a way that the number
of activities and the number of roles involved (and their associated handoffs) are
kept to a minimum
− Decisions may be made about the scope of solution, the components to be
implemented and the functionality provided by those components that necessitate
work being done outside the core solution, such as manual workarounds for which
processes will need to be defined
• Create an initial inventory of business processes enabled and impacted by
the solution
− The inventory can be refined as processes are added, moved or consolidated
May 4, 2020 180

Step 1 – Inventory Of Solution Business Processes
• Create an inventory of
business processes that
the solution should
allow to operate
• This will require
engaging with the
business solution
consumers to
understand the business
context of the solution
and its purposes and
objectives
• Document the existing
business processes, if
any, to understand the
changes required to
operate the solution
May 4, 2020 181

Step 2 – Inventory Of Solution Functions
May 4, 2020 182
• Create an inventory of
the functions, abilities
and facilities that should
be available in the
solution to enable and
operate the processes
− Functions can be linked
to the business processes
that use them, but this is
not needed
• Identify the significant
functions only
• These functions can be
provided by existing
systems or may be new
functions not currently
available that the
solution must deliver

Step 3 – Inventory Of Solution Actors
May 4, 2020 183
• Identify the actors –
individuals, groups or
business functions –
who will consume the
solution
− Focus on direct solution
consumers – those who
will use the solution –
rather than indirect –
those who will use the
outputs of the solution
• Identify if these are new
or existing actors
• For internal solution
consumers, identify
where they fit into the
organisation structure
• External solution
consumers will need
internal representatives

Step 4 – Inventory Of Solution Systems And
Applications
May 4, 2020 184
• Identify the major solution
system components, both
new and existing systems
that either to continue to
operate unchanged or that
will require changes
− Functions and processes can
be linked to system
components, but this is not
needed
• Initially this can be a logical
view of what is required
that may be different from
the final set of system
components implemented
• It is important to identify
the conceptual systems
required needed as part of
the overall solution
• These conceptual systems
can be translated later into
actual solution components

Step 5 – Inventory Of Solution System Integrations,
Transfers And Interfaces
May 4, 2020 185
• Identify the
integrations, data
transfers and
interfaces between
the system
components
• Describe their
operation and use
• Describe the source
and target systems,
the integration
approach, any
transformations that
occur and other
integration
characteristics

Step 6 – Inventory Of Solution Actor-System
Interactions
May 4, 2020 186
• Identify the interactions
that actors have with
systems and applications
that will occur as part of
the operation of the
solution
• Identify the method of
interface and interaction
• Define likely frequency
• Classify interactions by
complexity
• These interactions will
assist when defining
solution consumer
journeys later

Step 7 – Inventory Of Solution Actor-Actor
Interactions
May 4, 2020 187
• Identify the
interactions that
actors have with
other actors that
will occur as part
of the operation
of the solution

Solution On A Page
May 4, 2020 188
• The output from
the previous
steps can be
viewed as a high-
level solution-on-
a-page
• This identifies
some of the key
solution design
elements and
deliverables

Step 8 – Solution Logical Data Model View
May 4, 2020 189
• Lists the possible
data impacts -
sets or groups of
data – to existing
and new systems,
both existing and
new data
• Data impacts can
be new data
required or
existing data that
must be
expanded

Step 9 – Inventory Of Solution Data Exchanges
May 4, 2020 190
• Identify the data
exchanges and
movements
between systems
in the context of
the previously
identified data
sets

Step 10 – Inventory Of Solution Usage Journeys
May 4, 2020 191
• Create an inventory of proposed/expected solution consumer usage journeys for each
solution consumer type previously identified
• Journey is the set of steps performed and interactions experienced by the solution
consumer from initiation to completion of specific solution tasks
− What the consumer sees, does and experiences
• External representation of the tasks and actions performed by the solution components
and solution actors
• Journeys will have standard paths and exception/problem/deviation handling
• Journey can span multiple business processes
• Journey can span more than one solution component

Solution Consumer Journey Mapping
• Business
processes tends
to be internally
focussed and
represent the
work of business
functions
• Solution
consumer
journeys
represent the
end-to-end
experience of a
consumer for a
given scenario
May 4, 2020 192
Business
Processes
Solution Usage And Solution
Consumer Journeys

Proposed/Expected Solution Journeys
• The solution consumer journey begins when the consumer
starts to interact with the solution for a defined purpose, stops
when the interaction end and includes all that happens
between these two points
• Working through the proposed solution consumer journeys will
enable you to understand if the solution is fit for purpose
• Document the desired/proposed journey steps
• List each step or solution touchpoint in the journey
• Map the solution components and business processes involved
in each step
• List the step inputs, outputs and outcomes
• List the standard path and the exceptions that can occur
May 4, 2020 193

Proposed/Expected Solution Journeys
• Identify the following information for each solution
consumer journey step
− Ease of interaction
− Effort required
− Speed
• Use the consumer journey information to design the
solution to optimise the solution
• This will validate if the solution is fit for purpose
May 4, 2020 194

Core Solution Design Elements – Descriptive
Information
May 4, 2020 195
Core Design Element Descriptive Information
Processes
• Description, purpose, scope
• New or existing, changed or unchanged
• Users and usage
• Inputs and triggers
• Processing steps
• Processing rules
Functions
• Functionality provided
• Interface
• Business processes that use functions
• Processing performed
• Outputs and results created
Actors
• Actor type - individuals, groups or business functions, internal or external
• Size, number, roles, structure
• Workloads performed
• Required skills and experience
• Location
Systems/Applications
• Business process(es)
• Function(s)

Extended Solution Design Elements – Descriptive
Information – 1/2
May 4, 2020 196
System Interfaces And
Integrations
• Interface type
• Source and target system
• Inputs, triggers and outputs
• Frequency and volume
• Protocol
• Security and encryption used
• Actor and system and direction
• Interface type
• Business process and function context
• Source and target actor
Logical Data Model View
• Description, purpose, scope of data element
• Contents
• System
• Processing
• Volume and usage
• Indicative storage platform

Extended Solution Design Elements – Descriptive
Information – 2/2
May 4, 2020 197
Data Exchange
• Source and target system
• Inputs, triggers and outputs
Solution Usage Journeys
• Actors, solution components and business processes
• Inputs, triggers, outputs and outcomes
• Path deviations, exceptions and exception handling
• Steps and processing performed
• Ease of interaction
• Effort required
• Speed

Design Outputs From Solution Design Framework
And Scope Definition Design Activities
May 4, 2020 198
Solution Business Processes, Functions,
Actors and Systems and Interfaces Views
Data Impact and Exchanges Views
Solution Usage Journeys View

Output From Solution Design Framework And Scope
Definition
• Three sets of solution design outputs from steps 1 to 10:
1. Solution Business Processes, Functions, Actors and Systems and Interfaces
2. Data Impact and Exchanges
3. Solution Usage Journeys
• Together, these will contain a substantial amount of solution design
information that will form the foundation of the next more detailed
and more delivery-oriented Overall Solution Architecture Design
and Solution Components Design And Implementation phases
• Through iterations in steps 1-10, the solution will be understood and
agreed by design and delivery team, solution consumers and
solution stakeholders
• The scope of the solution is now well-defined at a high-level
− The key solution components have been identified
− We know what the solution will more likely consist of
May 4, 2020 199

Additional Solution Design Estimation, Planning And
Management Activities
• Step 11 - Create solution design views building on information
collected
• Step 12 - Additional design activities – filling the solution
component gaps left by the core solution design activities
• Step 13 - Map the solution component delivery dependencies
• Step 14 - Update business case with additional details
• Step 15 - Update solution design and delivery estimates based
on greater detail now available
• Step 16 - Update solution design and delivery plan based on
improved estimates and solution component dependencies
• Step 17 - Make go/no go/review recommendation
May 4, 2020 200

Step 11 – Create Solution Design And Delivery Views
• Solution design and
delivery views are
structured sets of
solution characteristics,
features, conditions,
specifications,
provisions, concerns and
fundamentals for each
dimension of the overall
solution
• Design views define
what the solution must
do and the results
expected
• Delivery views define
how the solution should
be implemented,
managed and operated
• Views can be used as
checklists to consolidate
and extend existing
solution design
information collected in
steps 1 to 10
May 4, 2020 201
Solution Design
And Delivery
Views
Solution Design
Business View
Context
Purpose
Characteristics
Functional View
Context
Stakeholders
Characteristics
Data View
Context
Entities
Roles
Interfaces
Characteristics
Solution Delivery
Technical View
Context
Structure
Operation
Development
Characteristics
Implementation
View
Context
Artefacts/
Products
Execution
Characteristics
Management
and Operations
View
Context
Operational
Processes
Support
Operation
Characteristics

Solution Design Business View
May 4, 2020 202
Business View
Business Context
Business
Environment
Resources,Skills
and Experience
Products,Services
and Value
Propositions
Value Chain
Stakeholders
Business Processes
Purpose Characteristics
Availability,
Continuityand
Resilience
Cost and
Affordability
Flexibility and
Ability to Evolve
Ease of
Implementation
Suitability and
Efficiency
Performance
Reliability
Manageabilityand
Ease of Operation
Linkages to Other
Systems
Stability
Security Usability

Solution Design Functional View
May 4, 2020 203
Functional View
Functional Context
Related Systems
Operational Processes
Products,Services and
Value Propositions
Value Chain
Stakeholders
Business Processes
Purpose Characteristics
Availability, Continuity
and Resilience
Cost and Affordability
Flexibility and Ability to
Evolve
Ease of Implementation
Suitability and Efficiency Performance
Reliability
Manageabilityand Ease
of Operation
Linkage to Other
Systems
Scalability
Security Usability

Solution Design Technical View
May 4, 2020 204
Technical View
Technical Context
Implementation
Environment and
Tools
Development
Approach
Language
Framework/
Systems
Technical
Configuration
System Structure
Hardware
Infrastructure
Software
Infrastructure
Data Infrastructure
Integration
Infrastructure
Operation
System Operation
System
Management and
Administration
Innovationand
Growth
System Lifecycle
System Change and
Growth
Characteristics
Availability,
Continuityand
Resilience
Cost and
Affordability
Flexibility and
Ability to Evolve
Ease of
Implementation
Suitability and
Efficiency
Performance
Reliability
Manageabilityand
Ease of Operation
Linkage to Other
Systems
Scalability
Security Usability

Solution Design Implementation View
May 4, 2020 205
Implementation View
Implementation
Context
Implementation
Environment
Development
Approach
Language
Framework/Systems
Implementation
Artefacts/Products
Solution Elements
Delivered
Components
Collateral
SupportingMaterial
Execution
Governance
Implementation
Organisation
Implementation
Process
Delivery Plan
Configuration
Financial
Management
Solution Validation
Characteristics
Availability,
Continuityand
Resilience
Cost and Affordability
Flexibility and Ability
to Evolve
Ease of
Implementation
Suitability and
Efficiency
Performance
Reliability
Manageabilityand
Ease of Operation
Linkage to Other
Systems
Scalability
Security Usability

Solution Design Data View
May 4, 2020 206
Data View
Data Context
Data Model
Reference and
Master Data
Conversion/
Migration
Data Volumes
Data Velocity
Data Variety
Entitles
Data Entities
Relationships
Access Rights and
Permissions
Interfaces
Sources and
Targets
Transformations
Data Types
Data Types
Analysis and
Reporting
Reporting
Analysis
Characteristics
Availability,
Continuityand
Resilience
Cost and
Affordability
Flexibility and
Ability to Evolve
Ease of
Implementation
Suitability and
Efficiency
Performance
Reliability
Manageability
and Ease of
Operation
Storage and
Capacity
Scalability
Security Usability

Solution Design Management And Operation View
May 4, 2020 207
Management and
Operation View
Management and
Operation Context
Service Management
Framework
Operational
Framework
Transition
Business Readiness
Organisational
Change
Steady State
Operational
Processes
Capacity
Availability,
Continuityand
Resilience
Change
Service Level
Configuration
Release and
Deployment
Incident
Problem
Support
Support Model
Support Processes
Service Desk
Operation
Deployment/
Maintenance
Structure
Deployment/
Maintenance
Process
Service Management
Processes
Alerting and
Monitoring
Backup and
Recovery
Service Level
Management
Characteristics
Availability,
Continuityand
Resilience
Cost and
Affordability
Flexibility and Ability
to Evolve
Ease of
Implementation
Suitability and
Efficiency
Performance
Reliability
Manageabilityand
Ease of Operation
Linkage to Other
Systems
Scalability
Security Usability

Step 12 - Additional Solution Component Design
• Expand the design with the components types not
explicitly covered in previous design activities:
− 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
• These are largely solution implementation components
and activities
• For each component of each of these component types
identify their requirements implied by the other solution
components
May 4, 2020 208

Additional Solution Component Design
• This activity consists of creating initial designs for these
implementation-related solution components
• These components impact multiple other solution
components and the overall solution
May 4, 2020 209

Likely Scope Of The Solution Is Now Known
Solution
Components
Changes to Existing Systems Component 1 Component 2 Component 3 Component 4
New Custom Developed Applications Component 1 Component 2 Component 3 Component 4
Information Storage Facilities Component 1 Component 2
Acquired, Configured and Customised Software
Products
Component 1 Component 2 Component 3
System Integrations/ Data Transfers/ Exchanges Component 1 Component 2 Component 3 Component 4
Changes to Existing Business Processes Component 1 Component 2 Component 3 Component 4
New Business Processes Component 1 Component 2 Component 3
Organisational Changes Component 1 Component 2 Component 3 Component 4
Reporting and Analysis Facilities Component 1 Component 2 Component 3
Existing Data Conversions/Migrations Component 1 Component 2 Component 3 Component 4
New Data Loads Component 1 Component 2 Component 3 Component 4
Training and Documentation Component 1 Component 2 Component 3
Central, Distributed and Communications Infrastructure Component 1 Component 2 Component 3
Sets of Installation and Implementation Services Component 1 Component 2
Cutover/Transfer to Production And Support Component 1 Component 2 Component 3
Operational Functions and Processes Component 1 Component 2 Component 3 Component 4
Parallel Runs Component 1 Component 2 Component 3 Component 4
Enhanced Support/ Hypercare Component 1 Component 2
Sets of Maintenance, Service Management and Support
Services
Component 1 Component 2
Application Hosting and Management Services Component 1 Component 2 Component 3
May 4, 2020 210

Likely Scope Of The Solution Is Now Known
• At this stage, the likely scope of the solution should be well
known in terms of the number and type of solution
components and what is included
• The breadth of the solution should be known
• The extent to which the depth of the solution component
detail is not currently defined should be known
• This is a strong foundation for estimation, planning and
performing subsequent detailed design and delivery work
• We should know what we do not know with a high degree
of confidence and there should be few, if any, unknowns
May 4, 2020 211

Step 13 - Map Solution Delivery Component
Dependencies
• Map the dependencies between the solution components
• This will assist in expand the previously created design and
delivery plan
May 4, 2020 212

Step 14 - Update Business Case
• There is now sufficient information to update the business
case with accurate design and delivery costs, resources
and timescales
• This can be balanced against stated benefits to understand
the actual solutions costs and returns to assist effective
decision-making
May 4, 2020 213

Step 15 - Update Solution Design And Delivery
Estimates
• The scope of the entire solution should now be well
defined and agreed, at least at a high-level
• The previous estimate can be updated with reasonably
accurate, realistic and detailed estimates for costs,
resources, timescale and schedule
May 4, 2020 214

Step 16 - Update Solution Design And Delivery Plan
• The knowledge of the components that comprise the
solution and their dependencies will allow an accurate
plan and schedule to be prepared the subsequent work:
− Expanding the high-level design work into detailed designs
− Implementing the detailed solution component designs
• This is all subject to change based on reprioritisation of
requirements but it is a baseline
May 4, 2020 215

Step 17 - Make Go/No Go/Review Recommendation
• You now know what solution are going to get
• You have a good idea of how it will operate
• You know the extent to which the business and solution
consumer needs will be met
• You know what it is likely to cost
• You have a good estimate of how long it will take
• You know the expected benefits
• You have enough detail to make an informed decision
−Go – proceed to detailed design an delivery, with possible conditions
−No Go – stop work – this is always an option
−Review – consider options to reduce cost/time or add/remove
solution functionality/technology/components
May 4, 2020 216

5 Overall Solution Architecture Design
May 4, 2020 217
Structure Contents

• This phase maintains ownership of the overall solution design
− It provides solution design subject matter expertise
• The detailed estimate from the Solution Design Framework And
Scope Definition phase provides the basis for the whole solution
design and delivery and throughout the remainder of the work
− This estimate needs to be frequently monitored and revised
• This phase tracks progress, allocates detailed design work, validates
design work done, makes design decisions, passes designs to the
delivery teams and manages the integrity of the overall solution
design
− Solution configuration management will assist here
• It receives design feedback from Solution Components Design And
Implementation iterations and updates the design as necessary
• It monitors both the progress and status of both design and delivery
activities
May 4, 2020 218

Solution Component Design Work Allocation And
Management
• Planning and management activities in this phase:
− Participate in time unit initiation and close-out meetings
− Accept all time unit deliverables to the solution design and
delivery at each time unit closeout meeting
− Monitor the operation of the various design and delivery team(s)
− Manage and update the design and delivery plan jointly with all
relevant people
− Refine the previously created initial solution design and delivery
schedule and resource and time estimates and get it agreed by
the relevant people before the end of the last pass through the
Overall Solution Architecture Design phase
− Accept design refinement feedback from the Solution
Components Design And Implementation activity
May 4, 2020 219

Estimation
• The detailed estimate from the Solution Design Framework
And Scope Definition phase provides the basis for the whole
solution design and delivery and throughout the remainder of
the work
− This estimate needs to be frequently monitored and revised
• Estimation is performed for each time unit to assess whether
the design and delivery plan is achievable and to evaluate the
impact on the solution design and delivery if any revisions to
the estimate are required
• Before the start of each time unit an estimate for the expected
work is carried out to ensure that it remains achievable in the
light of solution design and delivery experience to date
• If there is any significant deviation from the estimates, the
original estimates should be carefully reviewed
May 4, 2020 220

Solution Design And Delivery Progress And Status
Monitoring
May 4, 2020 221
• We need to track both the progress and status of both
solution design and solution delivery activities for each
solution component
− Design and delivery activities are occurring in parallel and so need
to be tracked together
• This provides an integrated single view of the status of the
solution across all activities
Design Delivery
Status Status
Progress Progress
=
Design
Status
Delivery
Status
Delivery
Progress Bars
Design
Progress Bars

Solution Design And Delivery Progress And Status
Monitoring
• Complete
solution design
and solution
delivery progress
and status view
May 4, 2020 222
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

Overall Solution Design And Delivery Status
May 4, 2020 223
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
• The overall design
and delivery
framework can be
used to monitor and
display design and
delivery status and
progress

6 Solution Architecture Design Iterations
May 4, 2020 224
Structure Contents

Solution Architecture Design Iterations
• These are solution component specific design iterations where
previous higher level designs are expanded and refined until
completion
• The Overall Solution Architecture Design phase allocates
design activities based on outstanding work or design updates
received from the Solution Components Design And
Implementation phase
• Incomplete component designs are refined
• Their impact on the overall solution is assessed
• The design and delivery status is updated
• Estimates are revisited and refined if necessary
• The design and delivery plan is reviewed and updated
• Any changes to the plan and estimates are communicated
May 4, 2020 225

7 Solution Components Design And Implementation
May 4, 2020 226
Structure Contents

Solution Components Design And Implementation
• Co-ordinates and manages the delivery activities of
solution components
• Allocates work to individual delivery teams and receives
and validates outputs
• Works with the Overall Solution Architecture Design
phase to record, track and maintain the overall solution
design and delivery status
• Receives updates from individual component delivery
iterations
• Passes design issues and requests back to Overall Solution
Architecture Design
May 4, 2020 227

Solution Component Delivery Teams
• Solution component delivery will involve different teams
with different skills
− Development
− Product Customisation
− Data
− Infrastructure
− Business Analysis and Process Design
− Service Management
− Organisation Change
• This phase needs to manage and co-ordinate work across
all these teams
May 4, 2020 228

Solution Delivery Hierarchy
Overall Solution
Solution
Delivery Stages
Solution
Components
Solution
Delivery
Iterations
May 4, 2020 229
Delivered In A
Number Of
Stages
Each Stages
Consists Of A Set
Of Delivered
Components
Each Solution
Component Delivered
In A Number Of
Iterations

Solution Go Live Events
• The phases manages the multiple go live activities that will
occur as stages of the solution that comprise completed
solution components are made operational
• The size of the operational solution expands through these
multiple go live events over the delivery stages
• The solution is built-up over these delivery stages
May 4, 2020 230

Multiple Go Live Events Over Delivery Stages
May 4, 2020 231

Deferred Work
• The solution scope may change during this phase
• Work may be deferred to subsequent solution delivery
chapters
• Any decisions on work to be deferred needs to be
communicated and agreed by solution stakeholders and
solution consumers
May 4, 2020 232

8 Individual Solution Component Delivery Iterations
May 4, 2020 233
Structure Contents

Individual Solution Component Delivery Iterations
• These are solution component specific delivery iterations where
previous higher level deliveries are expanded and refined until
completion
• The Solution Components Design And Implementation phase
allocates delivery activities based on outstanding work or design
updates received from the Overall Solution Architecture Design
phase
• Incompletely delivered components are worked on until complete
• Solution component delivery work may impact its design
• The impact of the delivery work on the overall solution is assessed
• The design and delivery status is updated
• Estimates are revisited and refined if necessary
• The design and delivery plan is reviewed and updated
• Any changes to the plan and estimates are communicated
May 4, 2020 234

Solution Component Delivery Teams
• Each solution component will be delivered in a different way
• Different skills will be needed
• The work will be done by different teams in different ways
• The work of these teams will overlap
• This approach does not dictate how the individual solution component delivery
iterations are performed – that is left to the specific team
• We just want them to follow the Scope, Approach, Implement, Validate approach
• We treat the delivery teams as service providers – the internal operation of the
service provision are secondary to the results and outcomes
May 4, 2020 235
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

9 Overall Solution Design and Individual Solution
Component Design Interactions
May 4, 2020 236
Structure Contents

Overall Solution Design and Individual Solution
Component Design Interactions
• This reflects the co-ordination activities between the
Overall Solution Architecture Design phase and the
Solution Components Design And Implementation phase
• Solution component design updates are passed to delivery
• Solution component design updates based on delivery
activities and outcomes are passed to design to be
updated
May 4, 2020 237

10 Post-Solution Design And Delivery
May 4, 2020 238
Structure Contents

Post-Solution Design And Delivery
• Occurs once the solution has been delivered and is initially
operational
• Includes the management of the delivery and review of the
operation of the overall hypercare and steady-state support
and maintenance solution activities
• There should be a post-implementation review to assess the
system in use
− To keep the solution operational
− To assess whether or not the proposed benefits of the solution as
stated initially in the business case and refined later have been achieved
− To enable the agile design and delivery processes to improve
− To review the solution in use
− To manage the knowledge and collateral acquired during design and
delivery
May 4, 2020 239

Outstanding/Deferred Work
• The Solution Components Design And Implementation
phase may decide to defer solution components to
subsequent delivery chapters
• The Post-Solution Design And Delivery phase should
review the deferred work and decide if, when and how it
should be delivered
May 4, 2020 240

Post-Implementation Review
• Captures lessons learnt about the solution in its actual operation and
use and an assessment of the benefits achieved
− Determine whether or not the solution has caused any problems in use
− Decide if there are any enhancement opportunities that have been revealed by
use of the product
− Demonstrate how well the expected benefits from the solution were actually
achieved
• Questions and checklist
− Does the report include comments from representatives (stakeholders and
solution consumers) of all those affected by the solution?
− Does the report make recommendations in cases where a problem has been
identified?
− Have all proposed benefits from the business case been considered?
− Where benefits have not been realised is there a clear approach to addressing
the issue?
May 4, 2020 241

Operable And Usable Solution
• Solution ready to be migrated into steady-state use
− Ensure that the solution performs all agreed functionality and
meets all the agreed operational requirements
− Ensure that the working and usable solution which can be placed
safely in the solution consumers’ environment(s)
− Ensure that the support and maintenance functions have
sufficient information to perform enhancements, support the
solution consumers, perform solution administration, monitoring,
management tasks, etc.
May 4, 2020 242

May 4, 2020 243
Operable Solution Deliverables
• User documentation
• Handover documents
• Support guide
• Operating procedures
• Backup and recovery procedures
• Disaster recovery procedures
• Build procedures
• Install procedures
• Help desk scripts
• Design documentation (taken from system architecture and design)
• Business procedures
• Service and operational level agreements
• Training documentation

May 4, 2020 244
Operable Solution Questions And Checklist
• Does the solution satisfy all the user-defined acceptance criteria?
• Is the solution delivery team satisfied that the solution is sufficiently robust to be
put into full operation?
• Has the solution been tested at an appropriate level, considering its intended use?
• Is there evidence that all the essential requirements (functional and non-
functional) have been tested and, where necessary, demonstrated to the users?
• Have any and all safety-related and product liability aspects of the system been
properly validated?
• Has all functionality that is provided to support implementation been adequately
tested (in particular, has account been taken of any need for data
conversion/uploading tools)?
• Are all components of the solution traceable to the design?
• Is the solution documentation consistent with the solution?

May 4, 2020 245
Solution Maintenance
• Maintenance is a fact of life since the business needs change, so although
maintenance is necessarily in the Post-Solution Design and Delivery phase, it has
to be considered from the very beginning of solution delivery
• Poor maintainability is a real risk to the business
− A new solution could rapidly become a problematic, unmaintainable legacy solution so
triggering user requests to replace it
• The agile solution design and delivery process places fitness for business purpose
as the essential factor for acceptance of deliverables
• Components with poor maintainability can slow the delivery of future changes and
deferred work
• Maintainability and the ability to deliver quickly therefore go hand in hand
• Poor maintainability means solutions
− Take more resources in maintenance
− Take longer to change
− Affect solution availability and performance
− Are more likely to introduce further errors with change and be unreliable
− Will cost more to maintain
− Will lead to solution consumer dissatisfaction
− Will affect benefits realised

More Information
Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney
https://www.amazon.com/dp/1797567616
4 May 2020 246

Agile Solution Architecture and Design

More Related Content

What's hot

Similar to Agile Solution Architecture and Design

More from Alan McSweeney

Recently uploaded

Agile Solution Architecture and Design