Successfully reported this slideshow.

Agile Solution Architecture and Design

7

Share

1 of 246
1 of 246

Agile Solution Architecture and Design

7

Share

Download to read offline

This presentation 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 and used for solution design and delivery. This approach ensures consistency in the assessment of solution design options and in subsequent solution design and solution delivery activities. This process leads to the rapid design and delivery of realistic and achievable solutions that meet real solution consumer needs. The approach provides for effective solution decision-making. It generates options and results quickly and consistently. Implementing a framework such as this provides for the creation of a knowledgebase of previous solution design and delivery exercises that leads to an accumulated body of knowledge within the organisation.

This presentation 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 and used for solution design and delivery. This approach ensures consistency in the assessment of solution design options and in subsequent solution design and solution delivery activities. This process leads to the rapid design and delivery of realistic and achievable solutions that meet real solution consumer needs. The approach provides for effective solution decision-making. It generates options and results quickly and consistently. Implementing a framework such as this provides for the creation of a knowledgebase of previous solution design and delivery exercises that leads to an accumulated body of knowledge within the organisation.

More Related Content

More from Alan McSweeney

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Agile Solution Architecture and Design

  1. 1. Agile Solution Architecture and Design Alan McSweeney http://ie.linkedin.com/in/alanmcsweeney https://www.amazon.com/dp/1797567616
  2. 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. 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. 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
  5. 5. The Solution May 4, 2020 5
  6. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  35. 35. The Agile Solution May 4, 2020 35
  36. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 55. Organisation Solution Design And Delivery Waste May 4, 2020 55
  56. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 70. Integrated Solution Design And Delivery May 4, 2020 70
  71. 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. 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. 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. 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. 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. 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. 77. Agile Solution Design And Delivery May 4, 2020 77
  78. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 95. 1 Agile Techniques, Controls And Principles Structure Contents May 4, 2020 95
  96. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×