SlideShare a Scribd company logo
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
The Solution
May 4, 2020 5
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
Changes to Existing Systems
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
Information Storage Facilities
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
Scope Of Solution Component Types – 2/3
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
Scope Of Solution Component Types – 3/3
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
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
Solution Components And Design And Delivery
Team Roles And Skills – 1/2
May 4, 2020 18
Solution Component Type Team Skills
Changes to Existing Systems
• Knowledge of existing systems
• Software analysis, design, development and testing
New Custom Developed Applications
• Software development and testing
• Software analysis, design, development and testing
Acquired and Customised Software Products
• 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
Reporting and Analysis Facilities
• 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
Information Storage Facilities
• Database design, management and administration
• Data architecture and integration
• Data infrastructure and storage platforms
Existing Data Conversions/ Migrations
• Data profiling and analysis
• Data extraction, transformation and load
New Data Loads
• Data profiling and analysis
• Data extraction, transformation and load
Central, Distributed and Communications
Infrastructure
• Communications infrastructure
• Technology infrastructure
Solution Components And Design And Delivery
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
Operational Functions and Processes
• IT service management
• Service analysis and design
Parallel Runs
• IT service management
• Service analysis and design
Enhanced Support/ Hypercare
• IT service management
• Service analysis and design
Sets of Maintenance, Service Management and Support
Services
• IT service management
• Procurement and supplier negotiation
Application Hosting and Management Services
• IT service management
• Infrastructure
Changes to Existing Business Processes
• Business analysis
• Process design
• Organisation change management
New Business Processes
• Business analysis
• Process design
• Organisation change management
Organisational Changes, Knowledge Management
• Business analysis
• Organisation change management
• Knowledge management
Training and Documentation
• Business analysis
• 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
Solution Component Specific Design And Delivery
Issues – 1/5
May 4, 2020 21
Solution Component Type Some Questions, Issues and Concerns
Changes to Existing Systems
• 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
New Custom Developed
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?
System Integrations/ Data
Transfers/ Exchanges
• 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?
Solution Component Specific Design And Delivery
Issues – 2/5
May 4, 2020 22
Solution Component Type Some Questions, Issues and Concerns
Reporting and Analysis Facilities
• 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?
Sets of Installation and
Implementation Services
• 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?
Information Storage Facilities
• 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?
Solution Component Specific Design And Delivery
Issues – 3/5
May 4, 2020 23
Solution Component Type Some Questions, Issues and Concerns
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?
Operational Functions and Processes
• 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?
Solution Component Specific Design And Delivery
Issues – 4/5
May 4, 2020 24
Solution Component Type Some Questions, Issues and Concerns
Enhanced Support/ Hypercare
• 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?
Solution Component Specific Design And Delivery
Issues – 5/5
May 4, 2020 25
Solution Component Type Some Questions, Issues and Concerns
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?
New 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?
Training and Documentation
• 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
Changes to Existing Systems
New Custom Developed
Applications
Acquired and Customised Software
Products
System Integrations/ Data
Transfers/ Exchanges
Reporting and Analysis Facilities
Sets of Installation and
Implementation Services
Information Storage Facilities
Existing Data Conversions/
Migrations
New Data Loads
Central, Distributed and
Communications Infrastructure
Cutover/ Transfer to Production
And Support
Operational Functions and
Processes
Parallel Runs
Enhanced Support/ Hypercare
Sets of Maintenance, Service
Management and Support Services
Application Hosting and
Management Services
Changes to Existing Business
Processes
New Business Processes
Organisational Changes, Knowledge
Management
Training and Documentation
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
Changes to Existing Systems
New Custom Developed Applications
Acquired and Customised Software Products
System Integrations/ Data Transfers/ Exchanges
Reporting and Analysis Facilities
Sets of Installation and Implementation Services
Information Storage Facilities
Existing Data Conversions/ Migrations
New Data Loads
Central, Distributed and Communications
Infrastructure
Cutover/ Transfer to Production And Support
Operational Functions and Processes
Parallel Runs
Enhanced Support/ Hypercare
Sets of Maintenance, Service Management and
Support Services
Application Hosting and Management Services
Changes to Existing Business Processes
New Business Processes
Organisational Changes, Knowledge Management
Cutover/ Transfer to Production And Support
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
Organisation Inflation And Solution Design And
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
Organisation Inflation And Solution Design And
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
Overall Solution Architecture Design
Solution Components Design And
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
Overall Solution Architecture Design
Solution Components Design And
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
Overall Solution Architecture Design
Solution Components Design And
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
Overall Solution Architecture Design
Solution Components Design And
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
Overall Solution Architecture Design
Solution Components Design And
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
Overall Solution Architecture Design
Solution Components Design And
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
New Custom Developed
Applications
Acquired and Customised Software
Products
System Integrations/ Data
Transfers/ Exchanges
Reporting and Analysis Facilities
Sets of Installation and
Implementation Services
Information Storage Facilities
Existing Data Conversions/
Migrations
New Data Loads
Central, Distributed and
Communications Infrastructure
Cutover/ Transfer to Production And
Support
Operational Functions and Processes
Parallel Runs
Enhanced Support/ Hypercare
Sets of Maintenance, Service
Management and Support Services
Application Hosting and
Management Services
Changes to Existing Business
Processes
New Business Processes
Organisational Changes, Knowledge
Management
Training and Documentation
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
Component Component Component Component Component
Component Component Component Component Component
Dimensions Of The Solution In The Context Of Agile
• There are now three
dimensions of
solution design and
delivery
− Delivery adds a third
dimension of
component iterations
to the previous two
dimensions
• Solution design and
delivery configuration
management assists
in tracking solution
work in an agile
context
May 4, 2020 94
Design And
Delivery
Cycles
Within
Component
Components
Within
Component
Types
Component
Types
1 Agile Techniques, Controls And Principles
Structure Contents
May 4, 2020 95
Agile Techniques, Controls And Principles Topics
• Principles
• Success Factors
• Time Limits
• Solution Design And Delivery Management
− Solution Requirements
− Solution Design and Delivery Estimates
− Solution Configuration Management
− Management And Planning Of The Solution Design And Delivery Process
− Supporting Tools And Technologies
• Risk Management
• Quality Management And Validation
• Workshops
• Prototyping
May 4, 2020 96
Key Principles of Iterative Agile Solution Design And
Delivery Approach
May 4, 2020 97
Active Solution Consumer Involvement Is
Essential For Success
Agile Solution Design And Delivery Team
Must Be Allowed Make Decisions
Fitness For Business Purpose And Value Is
The Essential Measure for Acceptance of
Deliverables
All Changes During Solution Design And
Delivery Are Reversible
Requirements Are Baselined At A High
Level
Collaborative And Co-operative Approach
Between All Stakeholders And Solution
Consumers Is Essential
Focus Is On Frequent Delivery of Solution
Products
Iterative and Incremental Development Is
Necessary To Converge On An Accurate
Business Solution
Solution Validation Is Integrated And
Performed Throughout the Lifecycle
Understand And Confirm The Scope Of
The Solution In Its Entirety
21
43
65
87
109
May 4, 2020 98
Principle 1 – Active Solution Consumer Involvement
Is Essential For Success
• Agile is solution consumer-centered
− Solutions have multiple consumer types:
• Functional consumers at different levels
• Operations consumers - support, maintenance
− Understand the solution consumer landscape and involve them
• Solution consumers may feel that the final solution is imposed
by the solution design and delivery team and/or their own
management
• Solution consumers are not outside the solution design and
delivery team acting as passive suppliers of information and
reviewers of results but are active participants in the solution
design and delivery process
• Solution consumer and thus business commitment is
fundamental to success
May 4, 2020 99
Principle 2 – Collaborative And Co-operative Approach Between All
Stakeholders And Solution Consumers Is Essential
• The nature of agile solution design and delivery means that low-level detailed
requirements are not necessarily fixed when the solution design and delivery team
is assembled to perform the work
• Solution stakeholders and solution consumers must be allowed and encouraged to
contribute
• Create a predictable rhythm of working between solution stakeholders with
regular solution design planning sessions
• Implement knowledge management and sharing
• The short-term direction that solution design and delivery takes must be quickly
decided without the use of restrictive change control procedures
• The stakeholders include not only the business and development staff within
solution design and delivery , but also other staff such as service delivery and
management and resource managers
• When the solution design and delivery is procured from an external supplier, both
the vendor and the purchaser organisations should aim for as efficient a process
as possible while allowing for flexibility during both the pre-contract phase and
when the contracted work is carried out
− Can be difficult and needs substantial mutual trust
May 4, 2020 100
Principle 3 – Agile Solution Design And Delivery
Team Must Be Allowed Make Decisions
• Solution design and delivery teams must be mixed and consist
of both IT personnel (across a wide range of technical and
business skills) and solution consumers of all types
• Solution design and delivery teams must be able to make
decisions as requirements are refined and possibly changed
• Solution design and delivery teams must be able to agree that
defined levels of functionality, usability, etc. are acceptable
without frequent need to refer to higher-level management
• Agile approach requires quick, localised and devolved decision-
making by those closest to knowledge and experience
• Constraints and delays to decisions and actions need to be
minimised
May 4, 2020 101
Principle 4 – Focus Is On Frequent Delivery of
Solution Products
• A product-based approach is more flexible than an activity-based one
− Products include interim solution components products, not just complete
delivered solutions
• Work of a solution design and delivery team is concentrated on products
that can be delivered in an agreed period of time
• Enables the team to select the best approach to achieving the products
required in the time available
• Reduce work in progress and size of design and delivery activities to deliver
value quickly, learn lessons or identify dead-ends
• By keeping each solution design and delivery interval short, the team can
easily decide which activities are necessary and sufficient to achieve the
right products
• Maintain a central view of all design and delivery activities showing
schedule and dependencies
• Use configuration management to understand the entire solution and its
components and iterations
May 4, 2020 102
Principle 5 – Fitness For Business Purpose And Value Is The
Essential Measure for Acceptance of Deliverables
• Focus of agile is on delivering the necessary functionality at the
required time
− Balance of the best functionality at the best value to the best quality in
the shortest time
• Traditional solution design and delivery focus has been on
satisfying the contents of a requirements document and
conforming to previous deliverables, even though the
requirements are often inaccurate, the previous deliverables
may be flawed and the business needs may have changed since
the start of solution design and delivery
• Solution can be more rigorously engineered subsequently if
such an approach is acceptable and needed
• Use cost and value as a guide to action
• Seek to take a cross-functional view of solution operation
rather than vertical view on organisation silos
May 4, 2020 103
Principle 6 – Iterative And Incremental Development Is Necessary To
Converge On An Accurate Business Solution
• Agile iterative approach allows solutions to grow incrementally
• Therefore the solution design and delivery team can make full use of
feedback from the solution consumers of all types
• Iterations allow for solution concept validation, the narrowing of solution
design and change of direction if necessary
• Partial solutions can be delivered to satisfy immediate business needs
• Agile approach uses iteration to continuously improve the solution being
implemented
• When rework is not explicitly recognised in a solution design and delivery
lifecycle, the return to previously completed work is surrounded by
controlling procedures that slow development down
• Rework is built into the agile iterative approach process so the solution can
proceed more quickly during iteration
May 4, 2020 104
Principle 7 – All Changes During Solution Design And
Delivery Are Reversible
• To control the evolution of all solution components
everything needs to be in a known state at all times
− Solution configuration management must be implemented and
maintained
• Backtracking is a feature of agile iterative approach
− Sometimes it may be easier to reconstruct than to backtrack
depending on the nature of the change and the environment in
which it was made
• Agile solution design and delivery accepts the variability
and lack of certainty
• Preserve solution design options as long as possible
May 4, 2020 105
Principle 8 – Requirements Are Baselined At A High
Level
• Baselining high-level requirements involves freezing and
agreeing the purpose and scope of the solution at a level
that allows for detailed investigation of what the
requirements imply
• Further, more detailed baselines can be established later
in solution design and delivery
− The scope should not change significantly
• Changing the scope defined in the baselined high-level
requirements generally requires escalation
May 4, 2020 106
Principle 9 – Solution Validation Is Integrated And
Performed Throughout the Lifecycle
• Solution validation is not treated as a separate activity during
design and delivery
• Validation includes verifying the solution is fit for its intended
purpose and delivers economic and business benefits
• As the solution is developed incrementally, it is also tested and
reviewed by both the solution design and delivery team and
solution consumers incrementally
− Ensures that the solution is moving forward not only in the right
business direction but is also technically sound
• Early in solution design and delivery lifecycle, the testing focus
is on validation against the business needs and priorities
• Towards the end of solution design, the focus is on verifying
that the whole solution operates effectively – system and
integration testing
Principle 10 – Understand And Confirm The Scope
Of The Solution In Its Entirety
• Understand and confirm the desired operational context
of the solution
• Understand what is necessary to get the complete solution
operational and delivering business value and benefits
• Understand the objectives of the solution and what the
organisation wants to achieve through it
• Understand the complexity of the solution and the
interdependencies and interactions of its components
• Solution optimisation involves optimising all its
components
May 4, 2020 107
Agile Solution Design And Delivery Critical Success
Factors
• Acceptance of the agile approach before starting work
• Delegation of decision-making to the business people and developers in
the development team
• Commitment of senior business management to provide significant end-
user involvement
• Incremental delivery
• Easy access by developers to end-users
• Stability of the team
• Solution design and delivery team should be skilled people in terms of both
the business area as well as the technical environment
• Size of the solution design and delivery team should be small in order to
minimise the overheads of management and communication
• Solution technology and supporting tools that allows configuration
management, iterative development, demonstrable work products and
control of versions
May 4, 2020 108
Application Of Time Limits And Time Units
• Limiting time spent is important aspect of agile iterative process and solution
design and delivery
• Process to reach defined objectives at a pre-determined and fixed date through
continuous prioritisation and flexing of solution requirements using a MoSCoW
type approach
• Unit of time should be fixed - typically between two and six weeks in length but
the shorter the better
• Without the control of time limits, solution design and teams can lose their focus
and run out of control
• Used at various stages of solution design and delivery
− Solution design and delivery end-date is fixed and the overall business objectives to be
achieved by that date are defined
− End date for each increment within the solution design and delivery is fixed and the
prioritised set of business and technical requirements to be satisfied by that date are defined
− End date for phase level activities is fixed, e.g. for the Feasibility Study, and the objectives for
this solution defined
− End date for part of the prototyping activity is fixed and the prototype is created, reviewed
and tested according to the objectives defined in the timebox schedule contained in the
Development Plan
− End time for a workshop, meeting or review is fixed and the participants work to the
predefined and prioritised objectives
May 4, 2020 109
May 4, 2020 110
Time Limits And Time Units
• The time unit must have an agreed scope and clear objectives based on a subset
of the prioritised requirements list
• With time limits and time units, control is not activity-based
• Objective of a time unit is to make a product - produce something tangible in
order that progress and quality can be assessed and quantified
• How that solution is put together will be decided by the people doing the work, as
long as the solution design and delivery standards and procedures are followed
• Team working in the time unit must agree the objectives and must themselves
estimate the time required
• At the deadline, the solution consumers must be able to approve the delivery of
the products covered by the time unit
• If it appears that deadlines could be missed, the deliverable should be de-scoped
dropping the lower priority items
• Detailed planning of a subsequent time unit containing dependent work cannot be
started before the current time unit is complete
May 4, 2020 111
Plan For Time Limits And Time Units
• Plan for an individual timebox within the Overall Solution
Architecture Design and Solution Components Design And
Implementation phases
• Define their purpose and objectives
• Define the products of an individual time unit
• Define key milestones, such as technical or solution
consumer review dates, within a time unit
• Agree the priority and importance of deliverables,
products and activities within a time unit
May 4, 2020 112
Time Limits, Time Units And Daily Meetings
• During each time unit, the solution design and delivery team working
on the time unit should meet daily to review their progress and to
raise issues
− Provides the solution design and delivery team with evidence regarding their
progress and the problems they face
− Highlight risks as they occur
− Each daily meeting should be limited at 30 minutes and ideally lasts no longer
than 15 minutes
− All solution design and delivery team members attend
• Topics to cover
− What work has been completed for this time unit since the last daily meeting?
− What (if anything) got in the way of completing the planned work?
− What work will be done between now and the next daily meeting?
May 4, 2020 113
Time Limits And Time Units Plan Questions And
Checklist
• Are the estimates of effort reasonable? Were they produced by the
members of the solution design and delivery time that will be doing
the work?
• Have acceptance criteria been agreed for the products of the time
unit? If they have not, is it clear when these will be available?
• Is there a high degree of certainty that the Must Have requirements
will be created, developed and tested to the required standard?
• Are the review dates agreed with all key personnel?
• Have lessons learnt in previous time units been applied?
• Can the team commit to delivering at least the Must Have
requirements by the agreed end date?
Solution Design And Delivery Management
• This topic covers:
− Solution requirements
− Solution design and delivery estimates
− Solution configuration management
− Management and planning of the solution design and delivery
process
− Supporting tools and technologies
May 4, 2020 114
Solution Requirements
• 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
Solution Requirements
• 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
MoSCoW Prioritisation Of Solution Requirements
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
MoSCoW Prioritisation Of Solution Requirements
And Characteristics
• Delivering on a guaranteed date means that what was originally envisaged for an
individual delivery may have to be left out
• Important that essential work is done and that only less critical work is omitted
• Means of ensuring that this is true is clear prioritisation of the requirements
• Provides a basis on which decisions are made about what the solution design and
delivery team will do over the whole solution design and delivery, within a
solution component and during a time unit within a component
• As new requirements arise or as existing requirements are defined in more detail,
the decision must be made as to how critical they are to the success of the current
work using the MoSCoW approach
− All priorities should be reviewed throughout solution design and delivery to ensure that
they are still valid
• Essential that not everything to be achieved within a solution or a time unit is a
Must Have
− Having lower level requirements that enable teams to deliver on time by dropping them
out when problems arise
May 4, 2020 122
Solution Design And Delivery Estimation
• Estimation provides the information that is required for two
main purposes:
1. Assess solution design and deliverability feasibility by evaluating costs
and benefits
2. Use in design and delivery activity planning, scheduling, control and
management
• Estimation in agile solution design and delivery means
− Estimates should be tight from the outset with frequent deliverables
• Not unacceptable for activity overrun and for long timescales for agreeing the
quality of deliverables
− Estimates that are based on outline business functions provide the
closest match with the agile solution design and delivery approach
• Starting point for estimating should be the expected functionality of the end
deliverables rather than the activities used to deliver them
May 4, 2020 123
Solution Design And Delivery Estimation
• Estimation is a conditional forecast based on the information available at a time
− An extrapolation from past and current knowledge to the future
− Cannot be done with complete certainty because the future is not certain and therefore
the actual effort or cost to deliver will almost always be different from the estimate
− The better the quality of the information available for estimating and the better and
more realistic the estimation approach(es), the closer the estimate is likely to be to the
actual figures
• Estimation must be based on a defined process so that it is rigorous and
repeatable
− Whatever process is used, the primary information required to estimate is:
• Scope of what is to be delivered
• Delivery capability – resources, time
• Complexity and uncertainty of deliverable and its impact on estimates
• Contingency must be included in any estimate in order for it to be realistic
− Estimates are conditional forecasts that will be affected by future events both internal
and external to solution design and delivery
− Events cannot be known with certainty and the estimate must make reasonable
allowance for them
− Solution design and delivery is not exact
− The size of the contingency in an estimate must reflect the degree of uncertainty
Estimation During Solution Design And Delivery
• Estimation and associated solution design and delivery
planning occurs at five key stages:
1. Pre-Solution Design And Delivery
2. Solution Feasibility Analysis And Study
3. Solution Design Framework And Scope Definition
4. Overall Solution Architecture Design
5. Solution Components Design And Implementation
May 4, 2020 124
Estimation During Solution Design And Delivery
Phases
May 4, 2020 125
Pre-Solution
Design And
Delivery
Solution
Feasibility
Analysis And
Study
Solution Design
Framework And
Scope Definition
Before solution design and delivery starts properly an estimate must be prepared for the work to be done
during Solution Feasibility Analysis And Study and the required effort
Estimate could be a define amount of time and effort - a fixed team for a fixed period - or could be based on a
schedule of workshops and other activities and the associated effort to complete the products
First estimate for the whole solution design and delivery is prepared towards the end of Solution Feasibility
Analysis And Study
Rough estimate, based on high level solution needs – designed to assist management to assess the value and
practicality of continuing with the solution design and delivery activity
Second estimate is produced at the end of the Solution Design Framework And Scope Definition
- scope of the solution is reasonably well-defined and agreed, the necessary business and solution consumer
functionality to be delivered is defined and prioritised, and the solution architecture and design is outlined
This should be a detailed estimate as it based on the likely major components of the delivered solution
identified from the prioritised requirements
Estimate must reflect a level of risk and confidence that is acceptable to the relevant solution stakeholders
Purpose of this estimate is to plan and schedule solution design and delivery and used to re-evaluate the
business case to assess whether the solution is still viable
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design
Agile Solution Architecture and Design

More Related Content

What's hot

Digital Transformation And Solution Architecture
Digital Transformation And Solution ArchitectureDigital Transformation And Solution Architecture
Digital Transformation And Solution Architecture
Alan McSweeney
 
Solution Security Architecture
Solution Security ArchitectureSolution Security Architecture
Solution Security Architecture
Alan McSweeney
 
Introduction to Enterprise architecture and the steps to perform an Enterpris...
Introduction to Enterprise architecture and the steps to perform an Enterpris...Introduction to Enterprise architecture and the steps to perform an Enterpris...
Introduction to Enterprise architecture and the steps to perform an Enterpris...
Prashanth Panduranga
 
Approach To It Strategy And Architecture
Approach To It Strategy And ArchitectureApproach To It Strategy And Architecture
Approach To It Strategy And Architecture
Alan McSweeney
 
Enterprise Architecture, Project Management & Digital Transformation
Enterprise Architecture, Project Management & Digital TransformationEnterprise Architecture, Project Management & Digital Transformation
Enterprise Architecture, Project Management & Digital Transformation
Riaz A. Khan, OpenCA, TOGAF
 
What is the Value of Mature Enterprise Architecture TOGAF
What is the Value of Mature Enterprise Architecture TOGAFWhat is the Value of Mature Enterprise Architecture TOGAF
What is the Value of Mature Enterprise Architecture TOGAF
xavblai
 
Agile, TOGAF and Enterprise Architecture: Will They Blend?
Agile, TOGAF and Enterprise Architecture:  Will They Blend?Agile, TOGAF and Enterprise Architecture:  Will They Blend?
Agile, TOGAF and Enterprise Architecture: Will They Blend?
Danny Greefhorst
 
Solution Architecture Framework
Solution Architecture FrameworkSolution Architecture Framework
Solution Architecture Framework
FirmansyahIrma1
 
EA Intensive Course "Building Enterprise Architecture" by mr.danairat
EA Intensive Course "Building Enterprise Architecture" by mr.danairatEA Intensive Course "Building Enterprise Architecture" by mr.danairat
EA Intensive Course "Building Enterprise Architecture" by mr.danairat
Software Park Thailand
 
Solution Architecture – Approach to Rapidly Scoping The Initial Solution Options
Solution Architecture – Approach to Rapidly Scoping The Initial Solution OptionsSolution Architecture – Approach to Rapidly Scoping The Initial Solution Options
Solution Architecture – Approach to Rapidly Scoping The Initial Solution Options
Alan McSweeney
 
Solution Architecture Concept Workshop
Solution Architecture Concept WorkshopSolution Architecture Concept Workshop
Solution Architecture Concept Workshop
Alan McSweeney
 
Enterprise Architecture & Project Portfolio Management 1/2
Enterprise Architecture & Project Portfolio Management 1/2Enterprise Architecture & Project Portfolio Management 1/2
Enterprise Architecture & Project Portfolio Management 1/2
Jean Gehring
 
A Brief Introduction to Enterprise Architecture
A Brief Introduction to  Enterprise Architecture A Brief Introduction to  Enterprise Architecture
A Brief Introduction to Enterprise Architecture
Daljit Banger
 
IT4IT and DevOps Tools Landscape (2020).
IT4IT and DevOps Tools Landscape (2020).IT4IT and DevOps Tools Landscape (2020).
IT4IT and DevOps Tools Landscape (2020).
Rob Akershoek
 
Design Science and Solution Architecture
Design Science and Solution ArchitectureDesign Science and Solution Architecture
Design Science and Solution Architecture
Alan McSweeney
 
ValueFlowIT: A new IT Operating Model Emerges
ValueFlowIT: A new IT Operating Model EmergesValueFlowIT: A new IT Operating Model Emerges
ValueFlowIT: A new IT Operating Model Emerges
David Favelle
 
Practical Enterprise Architecture in Medium-size Corporation using TOGAF
Practical Enterprise Architecture in Medium-size Corporation using TOGAFPractical Enterprise Architecture in Medium-size Corporation using TOGAF
Practical Enterprise Architecture in Medium-size Corporation using TOGAF
Michael Sukachev
 
IT4IT / DevOps Tooling Landscape 2022
IT4IT / DevOps Tooling Landscape 2022 IT4IT / DevOps Tooling Landscape 2022
IT4IT / DevOps Tooling Landscape 2022
Rob Akershoek
 
Implementing Effective Enterprise Architecture
Implementing Effective Enterprise ArchitectureImplementing Effective Enterprise Architecture
Implementing Effective Enterprise Architecture
Leo Shuster
 
Solution Architecture And Solution Security
Solution Architecture And Solution SecuritySolution Architecture And Solution Security
Solution Architecture And Solution Security
Alan McSweeney
 

What's hot (20)

Digital Transformation And Solution Architecture
Digital Transformation And Solution ArchitectureDigital Transformation And Solution Architecture
Digital Transformation And Solution Architecture
 
Solution Security Architecture
Solution Security ArchitectureSolution Security Architecture
Solution Security Architecture
 
Introduction to Enterprise architecture and the steps to perform an Enterpris...
Introduction to Enterprise architecture and the steps to perform an Enterpris...Introduction to Enterprise architecture and the steps to perform an Enterpris...
Introduction to Enterprise architecture and the steps to perform an Enterpris...
 
Approach To It Strategy And Architecture
Approach To It Strategy And ArchitectureApproach To It Strategy And Architecture
Approach To It Strategy And Architecture
 
Enterprise Architecture, Project Management & Digital Transformation
Enterprise Architecture, Project Management & Digital TransformationEnterprise Architecture, Project Management & Digital Transformation
Enterprise Architecture, Project Management & Digital Transformation
 
What is the Value of Mature Enterprise Architecture TOGAF
What is the Value of Mature Enterprise Architecture TOGAFWhat is the Value of Mature Enterprise Architecture TOGAF
What is the Value of Mature Enterprise Architecture TOGAF
 
Agile, TOGAF and Enterprise Architecture: Will They Blend?
Agile, TOGAF and Enterprise Architecture:  Will They Blend?Agile, TOGAF and Enterprise Architecture:  Will They Blend?
Agile, TOGAF and Enterprise Architecture: Will They Blend?
 
Solution Architecture Framework
Solution Architecture FrameworkSolution Architecture Framework
Solution Architecture Framework
 
EA Intensive Course "Building Enterprise Architecture" by mr.danairat
EA Intensive Course "Building Enterprise Architecture" by mr.danairatEA Intensive Course "Building Enterprise Architecture" by mr.danairat
EA Intensive Course "Building Enterprise Architecture" by mr.danairat
 
Solution Architecture – Approach to Rapidly Scoping The Initial Solution Options
Solution Architecture – Approach to Rapidly Scoping The Initial Solution OptionsSolution Architecture – Approach to Rapidly Scoping The Initial Solution Options
Solution Architecture – Approach to Rapidly Scoping The Initial Solution Options
 
Solution Architecture Concept Workshop
Solution Architecture Concept WorkshopSolution Architecture Concept Workshop
Solution Architecture Concept Workshop
 
Enterprise Architecture & Project Portfolio Management 1/2
Enterprise Architecture & Project Portfolio Management 1/2Enterprise Architecture & Project Portfolio Management 1/2
Enterprise Architecture & Project Portfolio Management 1/2
 
A Brief Introduction to Enterprise Architecture
A Brief Introduction to  Enterprise Architecture A Brief Introduction to  Enterprise Architecture
A Brief Introduction to Enterprise Architecture
 
IT4IT and DevOps Tools Landscape (2020).
IT4IT and DevOps Tools Landscape (2020).IT4IT and DevOps Tools Landscape (2020).
IT4IT and DevOps Tools Landscape (2020).
 
Design Science and Solution Architecture
Design Science and Solution ArchitectureDesign Science and Solution Architecture
Design Science and Solution Architecture
 
ValueFlowIT: A new IT Operating Model Emerges
ValueFlowIT: A new IT Operating Model EmergesValueFlowIT: A new IT Operating Model Emerges
ValueFlowIT: A new IT Operating Model Emerges
 
Practical Enterprise Architecture in Medium-size Corporation using TOGAF
Practical Enterprise Architecture in Medium-size Corporation using TOGAFPractical Enterprise Architecture in Medium-size Corporation using TOGAF
Practical Enterprise Architecture in Medium-size Corporation using TOGAF
 
IT4IT / DevOps Tooling Landscape 2022
IT4IT / DevOps Tooling Landscape 2022 IT4IT / DevOps Tooling Landscape 2022
IT4IT / DevOps Tooling Landscape 2022
 
Implementing Effective Enterprise Architecture
Implementing Effective Enterprise ArchitectureImplementing Effective Enterprise Architecture
Implementing Effective Enterprise Architecture
 
Solution Architecture And Solution Security
Solution Architecture And Solution SecuritySolution Architecture And Solution Security
Solution Architecture And Solution Security
 

Similar to Agile Solution Architecture and Design

Solution Design Services An Overview
Solution Design Services  An OverviewSolution Design Services  An Overview
Solution Design Services An Overview
Boston Technology Corporation
 
Rapid Results PLM Implementation Methodology
Rapid Results PLM Implementation MethodologyRapid Results PLM Implementation Methodology
Rapid Results PLM Implementation Methodology
ilievadaniela
 
· Choose an information system for an individual project.  During .docx
· Choose an information system for an individual project.  During .docx· Choose an information system for an individual project.  During .docx
· Choose an information system for an individual project.  During .docx
LynellBull52
 
Introduction To Software Concepts Unit 1 & 2
Introduction To Software Concepts Unit 1 & 2Introduction To Software Concepts Unit 1 & 2
Introduction To Software Concepts Unit 1 & 2
Raj vardhan
 
Hsc project management 2017
Hsc project management 2017Hsc project management 2017
Hsc project management 2017
greg robertson
 
Agile Application Modernization Project
Agile Application Modernization ProjectAgile Application Modernization Project
Agile Application Modernization Project
Lawrence Wilkes
 
Solution Architecture and Solution Estimation.pdf
Solution Architecture and Solution Estimation.pdfSolution Architecture and Solution Estimation.pdf
Solution Architecture and Solution Estimation.pdf
Alan McSweeney
 
System Development Life_IntroductionCycle.pdf
System Development Life_IntroductionCycle.pdfSystem Development Life_IntroductionCycle.pdf
System Development Life_IntroductionCycle.pdf
pncitechnologies
 
Online auction system srs riport
Online auction system srs  riportOnline auction system srs  riport
Online auction system srs riport
Dilip Prajapati
 
Project Formulation and Management - Project Scope Management
Project Formulation and Management - Project Scope ManagementProject Formulation and Management - Project Scope Management
Project Formulation and Management - Project Scope Management
Hrishikesh Satpute
 
Online auction system srs riport
Online auction system srs  riportOnline auction system srs  riport
Online auction system srs riport
Dilip Prajapati
 
system development life cycle
system development life cyclesystem development life cycle
system development life cycle
FLYMAN TECHNOLOGY LIMITED
 
Presentation - Scope and Schedule Management of Business Analytics Project
Presentation - Scope and Schedule Management of Business Analytics ProjectPresentation - Scope and Schedule Management of Business Analytics Project
Presentation - Scope and Schedule Management of Business Analytics Project
Sharad Srivastava
 
MSF Process model
MSF Process modelMSF Process model
MSF Process model
unruliness
 
Agile Network India | My experience as a Lead Technical Architect on Digital ...
Agile Network India | My experience as a Lead Technical Architect on Digital ...Agile Network India | My experience as a Lead Technical Architect on Digital ...
Agile Network India | My experience as a Lead Technical Architect on Digital ...
AgileNetwork
 
Crm saturday madrid 2017 razwan - d365 solution release management
Crm saturday madrid 2017   razwan - d365 solution release managementCrm saturday madrid 2017   razwan - d365 solution release management
Crm saturday madrid 2017 razwan - d365 solution release management
Demian Raschkovan
 
SharePoint Business Solution Deployment
SharePoint Business Solution DeploymentSharePoint Business Solution Deployment
SharePoint Business Solution Deployment
Chris Peters
 
Sabrion_Consulting_Overview CPG Retail Apparel.pdf
Sabrion_Consulting_Overview CPG Retail Apparel.pdfSabrion_Consulting_Overview CPG Retail Apparel.pdf
Sabrion_Consulting_Overview CPG Retail Apparel.pdf
Brion Carroll (II)
 
Chapter 7 Development Strategies
Chapter 7 Development StrategiesChapter 7 Development Strategies
Chapter 7 Development Strategies
Meryl C
 
Lecture 1_System Integration & Architecture
Lecture 1_System Integration & ArchitectureLecture 1_System Integration & Architecture
Lecture 1_System Integration & Architecture
CAPINPINSerelyn
 

Similar to Agile Solution Architecture and Design (20)

Solution Design Services An Overview
Solution Design Services  An OverviewSolution Design Services  An Overview
Solution Design Services An Overview
 
Rapid Results PLM Implementation Methodology
Rapid Results PLM Implementation MethodologyRapid Results PLM Implementation Methodology
Rapid Results PLM Implementation Methodology
 
· Choose an information system for an individual project.  During .docx
· Choose an information system for an individual project.  During .docx· Choose an information system for an individual project.  During .docx
· Choose an information system for an individual project.  During .docx
 
Introduction To Software Concepts Unit 1 & 2
Introduction To Software Concepts Unit 1 & 2Introduction To Software Concepts Unit 1 & 2
Introduction To Software Concepts Unit 1 & 2
 
Hsc project management 2017
Hsc project management 2017Hsc project management 2017
Hsc project management 2017
 
Agile Application Modernization Project
Agile Application Modernization ProjectAgile Application Modernization Project
Agile Application Modernization Project
 
Solution Architecture and Solution Estimation.pdf
Solution Architecture and Solution Estimation.pdfSolution Architecture and Solution Estimation.pdf
Solution Architecture and Solution Estimation.pdf
 
System Development Life_IntroductionCycle.pdf
System Development Life_IntroductionCycle.pdfSystem Development Life_IntroductionCycle.pdf
System Development Life_IntroductionCycle.pdf
 
Online auction system srs riport
Online auction system srs  riportOnline auction system srs  riport
Online auction system srs riport
 
Project Formulation and Management - Project Scope Management
Project Formulation and Management - Project Scope ManagementProject Formulation and Management - Project Scope Management
Project Formulation and Management - Project Scope Management
 
Online auction system srs riport
Online auction system srs  riportOnline auction system srs  riport
Online auction system srs riport
 
system development life cycle
system development life cyclesystem development life cycle
system development life cycle
 
Presentation - Scope and Schedule Management of Business Analytics Project
Presentation - Scope and Schedule Management of Business Analytics ProjectPresentation - Scope and Schedule Management of Business Analytics Project
Presentation - Scope and Schedule Management of Business Analytics Project
 
MSF Process model
MSF Process modelMSF Process model
MSF Process model
 
Agile Network India | My experience as a Lead Technical Architect on Digital ...
Agile Network India | My experience as a Lead Technical Architect on Digital ...Agile Network India | My experience as a Lead Technical Architect on Digital ...
Agile Network India | My experience as a Lead Technical Architect on Digital ...
 
Crm saturday madrid 2017 razwan - d365 solution release management
Crm saturday madrid 2017   razwan - d365 solution release managementCrm saturday madrid 2017   razwan - d365 solution release management
Crm saturday madrid 2017 razwan - d365 solution release management
 
SharePoint Business Solution Deployment
SharePoint Business Solution DeploymentSharePoint Business Solution Deployment
SharePoint Business Solution Deployment
 
Sabrion_Consulting_Overview CPG Retail Apparel.pdf
Sabrion_Consulting_Overview CPG Retail Apparel.pdfSabrion_Consulting_Overview CPG Retail Apparel.pdf
Sabrion_Consulting_Overview CPG Retail Apparel.pdf
 
Chapter 7 Development Strategies
Chapter 7 Development StrategiesChapter 7 Development Strategies
Chapter 7 Development Strategies
 
Lecture 1_System Integration & Architecture
Lecture 1_System Integration & ArchitectureLecture 1_System Integration & Architecture
Lecture 1_System Integration & Architecture
 

More from Alan McSweeney

Data Architecture for Solutions.pdf
Data Architecture for Solutions.pdfData Architecture for Solutions.pdf
Data Architecture for Solutions.pdf
Alan McSweeney
 
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
Alan McSweeney
 
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
Alan McSweeney
 
IT Architecture’s Role In Solving Technical Debt.pdf
IT Architecture’s Role In Solving Technical Debt.pdfIT Architecture’s Role In Solving Technical Debt.pdf
IT Architecture’s Role In Solving Technical Debt.pdf
Alan McSweeney
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Alan McSweeney
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Alan McSweeney
 
Solution Architecture And (Robotic) Process Automation Solutions
Solution Architecture And (Robotic) Process Automation SolutionsSolution Architecture And (Robotic) Process Automation Solutions
Solution Architecture And (Robotic) Process Automation Solutions
Alan McSweeney
 
Data Profiling, Data Catalogs and Metadata Harmonisation
Data Profiling, Data Catalogs and Metadata HarmonisationData Profiling, Data Catalogs and Metadata Harmonisation
Data Profiling, Data Catalogs and Metadata Harmonisation
Alan McSweeney
 
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Alan McSweeney
 
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
Alan McSweeney
 
Operational Risk Management Data Validation Architecture
Operational Risk Management Data Validation ArchitectureOperational Risk Management Data Validation Architecture
Operational Risk Management Data Validation Architecture
Alan McSweeney
 
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Alan McSweeney
 
Ireland 2019 and 2020 Compared - Individual Charts
Ireland   2019 and 2020 Compared - Individual ChartsIreland   2019 and 2020 Compared - Individual Charts
Ireland 2019 and 2020 Compared - Individual Charts
Alan McSweeney
 
Analysis of Irish Mortality Using Public Data Sources 2014-2020
Analysis of Irish Mortality Using Public Data Sources 2014-2020Analysis of Irish Mortality Using Public Data Sources 2014-2020
Analysis of Irish Mortality Using Public Data Sources 2014-2020
Alan McSweeney
 
Ireland – 2019 And 2020 Compared In Data
Ireland – 2019 And 2020 Compared In DataIreland – 2019 And 2020 Compared In Data
Ireland – 2019 And 2020 Compared In Data
Alan McSweeney
 
Critical Review of Open Group IT4IT Reference Architecture
Critical Review of Open Group IT4IT Reference ArchitectureCritical Review of Open Group IT4IT Reference Architecture
Critical Review of Open Group IT4IT Reference Architecture
Alan McSweeney
 
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Alan McSweeney
 
Creating A Business Focussed Information Technology Strategy
Creating A Business Focussed Information Technology StrategyCreating A Business Focussed Information Technology Strategy
Creating A Business Focussed Information Technology Strategy
Alan McSweeney
 
Describing the Organisation Data Landscape
Describing the Organisation Data LandscapeDescribing the Organisation Data Landscape
Describing the Organisation Data Landscape
Alan McSweeney
 
Shadow IT And The Failure Of IT Architecture
Shadow IT And The Failure Of IT ArchitectureShadow IT And The Failure Of IT Architecture
Shadow IT And The Failure Of IT Architecture
Alan McSweeney
 

More from Alan McSweeney (20)

Data Architecture for Solutions.pdf
Data Architecture for Solutions.pdfData Architecture for Solutions.pdf
Data Architecture for Solutions.pdf
 
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
 
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
 
IT Architecture’s Role In Solving Technical Debt.pdf
IT Architecture’s Role In Solving Technical Debt.pdfIT Architecture’s Role In Solving Technical Debt.pdf
IT Architecture’s Role In Solving Technical Debt.pdf
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
 
Solution Architecture And (Robotic) Process Automation Solutions
Solution Architecture And (Robotic) Process Automation SolutionsSolution Architecture And (Robotic) Process Automation Solutions
Solution Architecture And (Robotic) Process Automation Solutions
 
Data Profiling, Data Catalogs and Metadata Harmonisation
Data Profiling, Data Catalogs and Metadata HarmonisationData Profiling, Data Catalogs and Metadata Harmonisation
Data Profiling, Data Catalogs and Metadata Harmonisation
 
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
 
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
 
Operational Risk Management Data Validation Architecture
Operational Risk Management Data Validation ArchitectureOperational Risk Management Data Validation Architecture
Operational Risk Management Data Validation Architecture
 
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
 
Ireland 2019 and 2020 Compared - Individual Charts
Ireland   2019 and 2020 Compared - Individual ChartsIreland   2019 and 2020 Compared - Individual Charts
Ireland 2019 and 2020 Compared - Individual Charts
 
Analysis of Irish Mortality Using Public Data Sources 2014-2020
Analysis of Irish Mortality Using Public Data Sources 2014-2020Analysis of Irish Mortality Using Public Data Sources 2014-2020
Analysis of Irish Mortality Using Public Data Sources 2014-2020
 
Ireland – 2019 And 2020 Compared In Data
Ireland – 2019 And 2020 Compared In DataIreland – 2019 And 2020 Compared In Data
Ireland – 2019 And 2020 Compared In Data
 
Critical Review of Open Group IT4IT Reference Architecture
Critical Review of Open Group IT4IT Reference ArchitectureCritical Review of Open Group IT4IT Reference Architecture
Critical Review of Open Group IT4IT Reference Architecture
 
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
 
Creating A Business Focussed Information Technology Strategy
Creating A Business Focussed Information Technology StrategyCreating A Business Focussed Information Technology Strategy
Creating A Business Focussed Information Technology Strategy
 
Describing the Organisation Data Landscape
Describing the Organisation Data LandscapeDescribing the Organisation Data Landscape
Describing the Organisation Data Landscape
 
Shadow IT And The Failure Of IT Architecture
Shadow IT And The Failure Of IT ArchitectureShadow IT And The Failure Of IT Architecture
Shadow IT And The Failure Of IT Architecture
 

Recently uploaded

A Comprehensive Guide to DeFi Development Services in 2024
A Comprehensive Guide to DeFi Development Services in 2024A Comprehensive Guide to DeFi Development Services in 2024
A Comprehensive Guide to DeFi Development Services in 2024
Intelisync
 
Driving Business Innovation: Latest Generative AI Advancements & Success Story
Driving Business Innovation: Latest Generative AI Advancements & Success StoryDriving Business Innovation: Latest Generative AI Advancements & Success Story
Driving Business Innovation: Latest Generative AI Advancements & Success Story
Safe Software
 
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...
Jeffrey Haguewood
 
HCL Notes and Domino License Cost Reduction in the World of DLAU
HCL Notes and Domino License Cost Reduction in the World of DLAUHCL Notes and Domino License Cost Reduction in the World of DLAU
HCL Notes and Domino License Cost Reduction in the World of DLAU
panagenda
 
Energy Efficient Video Encoding for Cloud and Edge Computing Instances
Energy Efficient Video Encoding for Cloud and Edge Computing InstancesEnergy Efficient Video Encoding for Cloud and Edge Computing Instances
Energy Efficient Video Encoding for Cloud and Edge Computing Instances
Alpen-Adria-Universität
 
Dandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity serverDandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity server
Antonios Katsarakis
 
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAUHCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
panagenda
 
Presentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of GermanyPresentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of Germany
innovationoecd
 
JavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green MasterplanJavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green Masterplan
Miro Wengner
 
Public CyberSecurity Awareness Presentation 2024.pptx
Public CyberSecurity Awareness Presentation 2024.pptxPublic CyberSecurity Awareness Presentation 2024.pptx
Public CyberSecurity Awareness Presentation 2024.pptx
marufrahmanstratejm
 
Programming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup SlidesProgramming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup Slides
Zilliz
 
GNSS spoofing via SDR (Criptored Talks 2024)
GNSS spoofing via SDR (Criptored Talks 2024)GNSS spoofing via SDR (Criptored Talks 2024)
GNSS spoofing via SDR (Criptored Talks 2024)
Javier Junquera
 
WeTestAthens: Postman's AI & Automation Techniques
WeTestAthens: Postman's AI & Automation TechniquesWeTestAthens: Postman's AI & Automation Techniques
WeTestAthens: Postman's AI & Automation Techniques
Postman
 
June Patch Tuesday
June Patch TuesdayJune Patch Tuesday
June Patch Tuesday
Ivanti
 
Digital Marketing Trends in 2024 | Guide for Staying Ahead
Digital Marketing Trends in 2024 | Guide for Staying AheadDigital Marketing Trends in 2024 | Guide for Staying Ahead
Digital Marketing Trends in 2024 | Guide for Staying Ahead
Wask
 
System Design Case Study: Building a Scalable E-Commerce Platform - Hiike
System Design Case Study: Building a Scalable E-Commerce Platform - HiikeSystem Design Case Study: Building a Scalable E-Commerce Platform - Hiike
System Design Case Study: Building a Scalable E-Commerce Platform - Hiike
Hiike
 
Trusted Execution Environment for Decentralized Process Mining
Trusted Execution Environment for Decentralized Process MiningTrusted Execution Environment for Decentralized Process Mining
Trusted Execution Environment for Decentralized Process Mining
LucaBarbaro3
 
Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024
Jason Packer
 
Nordic Marketo Engage User Group_June 13_ 2024.pptx
Nordic Marketo Engage User Group_June 13_ 2024.pptxNordic Marketo Engage User Group_June 13_ 2024.pptx
Nordic Marketo Engage User Group_June 13_ 2024.pptx
MichaelKnudsen27
 
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
saastr
 

Recently uploaded (20)

A Comprehensive Guide to DeFi Development Services in 2024
A Comprehensive Guide to DeFi Development Services in 2024A Comprehensive Guide to DeFi Development Services in 2024
A Comprehensive Guide to DeFi Development Services in 2024
 
Driving Business Innovation: Latest Generative AI Advancements & Success Story
Driving Business Innovation: Latest Generative AI Advancements & Success StoryDriving Business Innovation: Latest Generative AI Advancements & Success Story
Driving Business Innovation: Latest Generative AI Advancements & Success Story
 
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...
 
HCL Notes and Domino License Cost Reduction in the World of DLAU
HCL Notes and Domino License Cost Reduction in the World of DLAUHCL Notes and Domino License Cost Reduction in the World of DLAU
HCL Notes and Domino License Cost Reduction in the World of DLAU
 
Energy Efficient Video Encoding for Cloud and Edge Computing Instances
Energy Efficient Video Encoding for Cloud and Edge Computing InstancesEnergy Efficient Video Encoding for Cloud and Edge Computing Instances
Energy Efficient Video Encoding for Cloud and Edge Computing Instances
 
Dandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity serverDandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity server
 
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAUHCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
 
Presentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of GermanyPresentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of Germany
 
JavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green MasterplanJavaLand 2024: Application Development Green Masterplan
JavaLand 2024: Application Development Green Masterplan
 
Public CyberSecurity Awareness Presentation 2024.pptx
Public CyberSecurity Awareness Presentation 2024.pptxPublic CyberSecurity Awareness Presentation 2024.pptx
Public CyberSecurity Awareness Presentation 2024.pptx
 
Programming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup SlidesProgramming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup Slides
 
GNSS spoofing via SDR (Criptored Talks 2024)
GNSS spoofing via SDR (Criptored Talks 2024)GNSS spoofing via SDR (Criptored Talks 2024)
GNSS spoofing via SDR (Criptored Talks 2024)
 
WeTestAthens: Postman's AI & Automation Techniques
WeTestAthens: Postman's AI & Automation TechniquesWeTestAthens: Postman's AI & Automation Techniques
WeTestAthens: Postman's AI & Automation Techniques
 
June Patch Tuesday
June Patch TuesdayJune Patch Tuesday
June Patch Tuesday
 
Digital Marketing Trends in 2024 | Guide for Staying Ahead
Digital Marketing Trends in 2024 | Guide for Staying AheadDigital Marketing Trends in 2024 | Guide for Staying Ahead
Digital Marketing Trends in 2024 | Guide for Staying Ahead
 
System Design Case Study: Building a Scalable E-Commerce Platform - Hiike
System Design Case Study: Building a Scalable E-Commerce Platform - HiikeSystem Design Case Study: Building a Scalable E-Commerce Platform - Hiike
System Design Case Study: Building a Scalable E-Commerce Platform - Hiike
 
Trusted Execution Environment for Decentralized Process Mining
Trusted Execution Environment for Decentralized Process MiningTrusted Execution Environment for Decentralized Process Mining
Trusted Execution Environment for Decentralized Process Mining
 
Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024
 
Nordic Marketo Engage User Group_June 13_ 2024.pptx
Nordic Marketo Engage User Group_June 13_ 2024.pptxNordic Marketo Engage User Group_June 13_ 2024.pptx
Nordic Marketo Engage User Group_June 13_ 2024.pptx
 
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
Overcoming the PLG Trap: Lessons from Canva's Head of Sales & Head of EMEA Da...
 

Agile Solution Architecture and Design

  • 1. Agile Solution Architecture and Design Alan McSweeney http://ie.linkedin.com/in/alanmcsweeney https://www.amazon.com/dp/1797567616
  • 2. 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
  • 3. 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
  • 4. 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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. Scope Of Solution Component Types – 1/3 May 4, 2020 14 Solution Component Type Description Changes to Existing Systems 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 Information Storage Facilities 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
  • 15. Scope Of Solution Component Types – 2/3 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
  • 16. Scope Of Solution Component Types – 3/3 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 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
  • 17. 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
  • 18. Solution Components And Design And Delivery Team Roles And Skills – 1/2 May 4, 2020 18 Solution Component Type Team Skills Changes to Existing Systems • Knowledge of existing systems • Software analysis, design, development and testing New Custom Developed Applications • Software development and testing • Software analysis, design, development and testing Acquired and Customised Software Products • 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 Reporting and Analysis Facilities • 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 Information Storage Facilities • Database design, management and administration • Data architecture and integration • Data infrastructure and storage platforms Existing Data Conversions/ Migrations • Data profiling and analysis • Data extraction, transformation and load New Data Loads • Data profiling and analysis • Data extraction, transformation and load Central, Distributed and Communications Infrastructure • Communications infrastructure • Technology infrastructure
  • 19. Solution Components And Design And Delivery 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 Operational Functions and Processes • IT service management • Service analysis and design Parallel Runs • IT service management • Service analysis and design Enhanced Support/ Hypercare • IT service management • Service analysis and design Sets of Maintenance, Service Management and Support Services • IT service management • Procurement and supplier negotiation Application Hosting and Management Services • IT service management • Infrastructure Changes to Existing Business Processes • Business analysis • Process design • Organisation change management New Business Processes • Business analysis • Process design • Organisation change management Organisational Changes, Knowledge Management • Business analysis • Organisation change management • Knowledge management Training and Documentation • Business analysis • Documentation • Training
  • 20. 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
  • 21. Solution Component Specific Design And Delivery Issues – 1/5 May 4, 2020 21 Solution Component Type Some Questions, Issues and Concerns Changes to Existing Systems • 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 New Custom Developed 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? System Integrations/ Data Transfers/ Exchanges • 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?
  • 22. Solution Component Specific Design And Delivery Issues – 2/5 May 4, 2020 22 Solution Component Type Some Questions, Issues and Concerns Reporting and Analysis Facilities • 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? Sets of Installation and Implementation Services • 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? Information Storage Facilities • 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?
  • 23. Solution Component Specific Design And Delivery Issues – 3/5 May 4, 2020 23 Solution Component Type Some Questions, Issues and Concerns 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? Operational Functions and Processes • 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?
  • 24. Solution Component Specific Design And Delivery Issues – 4/5 May 4, 2020 24 Solution Component Type Some Questions, Issues and Concerns Enhanced Support/ Hypercare • 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?
  • 25. Solution Component Specific Design And Delivery Issues – 5/5 May 4, 2020 25 Solution Component Type Some Questions, Issues and Concerns 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? New 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? Training and Documentation • 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?
  • 26. 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
  • 27. 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 Changes to Existing Systems New Custom Developed Applications Acquired and Customised Software Products System Integrations/ Data Transfers/ Exchanges Reporting and Analysis Facilities Sets of Installation and Implementation Services Information Storage Facilities Existing Data Conversions/ Migrations New Data Loads Central, Distributed and Communications Infrastructure Cutover/ Transfer to Production And Support Operational Functions and Processes Parallel Runs Enhanced Support/ Hypercare Sets of Maintenance, Service Management and Support Services Application Hosting and Management Services Changes to Existing Business Processes New Business Processes Organisational Changes, Knowledge Management Training and Documentation
  • 28. 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
  • 29. 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 Changes to Existing Systems New Custom Developed Applications Acquired and Customised Software Products System Integrations/ Data Transfers/ Exchanges Reporting and Analysis Facilities Sets of Installation and Implementation Services Information Storage Facilities Existing Data Conversions/ Migrations New Data Loads Central, Distributed and Communications Infrastructure Cutover/ Transfer to Production And Support Operational Functions and Processes Parallel Runs Enhanced Support/ Hypercare Sets of Maintenance, Service Management and Support Services Application Hosting and Management Services Changes to Existing Business Processes New Business Processes Organisational Changes, Knowledge Management Cutover/ Transfer to Production And Support
  • 30. 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
  • 31. 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
  • 32. 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
  • 33. 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
  • 34. 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
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. 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
  • 40. 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
  • 41. 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
  • 42. 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
  • 43. 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
  • 44. 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
  • 45. 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
  • 46. 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
  • 47. 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
  • 48. 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
  • 49. 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
  • 50. 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
  • 51. 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
  • 52. 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
  • 53. 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
  • 54. 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 …
  • 55. Organisation Solution Design And Delivery Waste May 4, 2020 55
  • 56. 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
  • 57. 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
  • 58. Organisation Inflation And Solution Design And 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
  • 59. Organisation Inflation And Solution Design And 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
  • 60. 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
  • 61. 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.”
  • 62. 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
  • 63. 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
  • 64. 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
  • 65. 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
  • 66. 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
  • 67. 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
  • 68. 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
  • 69. 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
  • 70. Integrated Solution Design And Delivery May 4, 2020 70
  • 71. 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
  • 72. 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
  • 73. 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
  • 74. 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
  • 75. 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
  • 76. 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
  • 77. Agile Solution Design And Delivery May 4, 2020 77
  • 78. 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
  • 79. 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
  • 80. May 4, 2020 80 Post- Solution Design And Delivery Overall Solution Architecture Design Solution Components Design And 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
  • 81. 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
  • 82. 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
  • 83. 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 Overall Solution Architecture Design Solution Components Design And Implementation Pre- Solution Design And Delivery Solution Feasibility Analysis And Study Solution Design Framework And Scope Definition 2 3 4 5 7 10
  • 84. 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
  • 85. 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 Overall Solution Architecture Design Solution Components Design And 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
  • 86. 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 Overall Solution Architecture Design Solution Components Design And Implementation
  • 87. 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 Overall Solution Architecture Design Solution Components Design And Implementation Phase Offset Degree
  • 88. 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 Overall Solution Architecture Design Solution Components Design And Implementation Pre- Solution Design And Delivery Solution Feasibility Analysis And Study Solution Design Framework And Scope Definition 2 3 4 5 7 10
  • 89. 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
  • 90. 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
  • 91. 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
  • 92. 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 New Custom Developed Applications Acquired and Customised Software Products System Integrations/ Data Transfers/ Exchanges Reporting and Analysis Facilities Sets of Installation and Implementation Services Information Storage Facilities Existing Data Conversions/ Migrations New Data Loads Central, Distributed and Communications Infrastructure Cutover/ Transfer to Production And Support Operational Functions and Processes Parallel Runs Enhanced Support/ Hypercare Sets of Maintenance, Service Management and Support Services Application Hosting and Management Services Changes to Existing Business Processes New Business Processes Organisational Changes, Knowledge Management Training and Documentation
  • 93. 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 Component Component Component Component Component Component Component Component Component Component
  • 94. 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
  • 95. 1 Agile Techniques, Controls And Principles Structure Contents May 4, 2020 95
  • 96. 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
  • 97. 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
  • 98. May 4, 2020 98 Principle 1 – Active Solution Consumer Involvement Is Essential For Success • Agile is solution consumer-centered − Solutions have multiple consumer types: • Functional consumers at different levels • Operations consumers - support, maintenance − Understand the solution consumer landscape and involve them • Solution consumers may feel that the final solution is imposed by the solution design and delivery team and/or their own management • Solution consumers are not outside the solution design and delivery team acting as passive suppliers of information and reviewers of results but are active participants in the solution design and delivery process • Solution consumer and thus business commitment is fundamental to success
  • 99. 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
  • 100. 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
  • 101. 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
  • 102. 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
  • 103. 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
  • 104. 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
  • 105. 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
  • 106. 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
  • 107. 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
  • 108. 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
  • 109. 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
  • 110. 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
  • 111. 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
  • 112. 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?
  • 113. 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?
  • 114. 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
  • 115. Solution Requirements • 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
  • 116. Solution Requirements • 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
  • 117. 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
  • 118. 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
  • 119. 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
  • 120. MoSCoW Prioritisation Of Solution Requirements 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
  • 121. May 4, 2020 121 MoSCoW Prioritisation Of Solution Requirements 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
  • 122. 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
  • 123. 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
  • 124. 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
  • 125. Estimation During Solution Design And Delivery Phases May 4, 2020 125 Pre-Solution Design And Delivery Solution Feasibility Analysis And Study Solution Design Framework And Scope Definition Before solution design and delivery starts properly an estimate must be prepared for the work to be done during Solution Feasibility Analysis And Study and the required effort Estimate could be a define amount of time and effort - a fixed team for a fixed period - or could be based on a schedule of workshops and other activities and the associated effort to complete the products First estimate for the whole solution design and delivery is prepared towards the end of Solution Feasibility Analysis And Study Rough estimate, based on high level solution needs – designed to assist management to assess the value and practicality of continuing with the solution design and delivery activity Second estimate is produced at the end of the Solution Design Framework And Scope Definition - scope of the solution is reasonably well-defined and agreed, the necessary business and solution consumer functionality to be delivered is defined and prioritised, and the solution architecture and design is outlined This should be a detailed estimate as it based on the likely major components of the delivered solution identified from the prioritised requirements Estimate must reflect a level of risk and confidence that is acceptable to the relevant solution stakeholders Purpose of this estimate is to plan and schedule solution design and delivery and used to re-evaluate the business case to assess whether the solution is still viable