Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

The Need For Effective Early Engagement In Solution Architecture And Design

2.217 visualizaciones

Publicado el

Early engagement in the solution delivery process needs to occur before any solution delivery project is initiated. Its objective is to understand the scope, requirements, objectives, approach, options and to get a high-level understanding of the likely resources, timescale and cost required before starting the project

Fundamentally, early engagement is about managing risk:

• Risk of doing the wrong thing
• Risk of doing it in the wrong way
• Risk of underestimating complexity and scope of work
• Risk of higher than expected cost of operation and maintenance
• Risk of underestimating organisation change impact and organisation resistance
• Risk through uncertainty

Early engagement is not a requirements gathering exercise. Traditional requirements gathering requires substantial initial effort, resources and cost and for the business to commit without doubts, uncertainties and ambiguities being known.

Early Engagement involves taking a not necessarily well-defined request from the business and creating an unambiguous set of solution options including their delivery and operation quickly and accurately

This paper describes an approach to early engagement in the solution definition process.

Publicado en: Tecnología

The Need For Effective Early Engagement In Solution Architecture And Design

  1. 1. The Need For Effective Early Engagement In Solution Architecture And Design Alan McSweeney http://ie.linkedin.com/in/alanmcsweeney
  2. 2. The Importance Of Early Engagement In Solution Architecture • Early engagement in the solution delivery process needs to occur before any solution delivery project is initiated • It needs to be at the vanguard of solution design • The objective is to understand the scope, requirements, objectives, approach, options and to get a high-level understanding of the likely resources, timescale and cost required before starting the project • Allow the feasibility of the solution options to be assessed • Converts a request from the business to an explored and refined high-level solution proposal that facilities informed decision-making • Early engagement is the IT function providing true consulting services and value to the business − Being a partner to the business − Offering the business a consulting and advisory service − IT function gets early sight of likely demand − Business gains confidence in IT − Solutions more likely to be compliant with IT standards − Reduces shadow IT expenditure 08 January 2018 2
  3. 3. Solution Delivery Phases And Early Engagement Project Stages/ Timeline ProjectActivity/Function Early Engagement Concept Initiate Plan Design Build Test Deploy Manage and Operate Project Management Business Function Business Analysis Solution Architecture Implementation and Delivery Test and Quality Organisation Readiness Service Management Infrastructure and Communications Time Business Functions/ Roles Solution Design, Delivery, Transfer to Production 08 January 2018 3
  4. 4. Solutions vs. Projects • Users do not look for projects • They want solutions that support and operate their processes and create value when used 08 January 2018 4
  5. 5. An Effective Early Engagement Process Requires … • A consistent, organised and controlled approach to performing such engagements • A standard method for performing analysis, collecting information, engaging with the business, making assessment and solution option identification • A process for managing early engagements from resources required to engagement with the business to prioritisation to quality management, assurance and control • A standard and consistent approach for representing the results of the engagement • Quick delivery of results 08 January 2018 5
  6. 6. Find The Engagement Effort And Results Saddle Point • Do as little as possible to achieve as much as possible to make an informed decision on whether and how to proceed at gate stage in resolution journey • Key principle at this stage is satisficing – optimise effort and resources during early engagement - satisfy expectations sufficiently 08 January 2018 6 Minimise Effort Maximise Results
  7. 7. Engagement Means Learning About The Situation • To be able to offer improvements and possible solution options • Understand the complexity and confusion that exists in the current condition and situation • Understand the external complexities - economic, social, legal • Understand how different participants and stakeholders view the current condition and situation and view what is needed to achieve a resolution 08 January 2018 7
  8. 8. Fundamentally, Early Engagement Is About … • Managing risk − Risk of doing the wrong thing − Risk of doing it in the wrong way − Risk of underestimating complexity and scope of work − Risk of higher than expected cost of operation and maintenance − Risk of underestimating organisation change impact and organisation resistance − Risk through uncertainty and unpredictability 08 January 2018 8
  9. 9. Early Engagement … • Is not a requirements gathering exercise − Traditional requirements gathering requires substantial initial effort, resources and cost and for the business to commit without doubts, uncertainties and ambiguities being known • It involves taking a not necessarily well-defined request from the business and create an unambiguous set of solution options including their delivery and operation quickly and accurately 08 January 2018 9
  10. 10. Early Engagement • Defines and validates resolution hypotheses at an early stage • Reduces doubts, uncertainties and ambiguities • Reduces risk • It focusses on understanding the overall problem and determining realistic options for viable resolutions • It seeks to address the end-to-end experience • Looks to eliminate the over-the-wall practices associated with standard solution delivery with multiple independent phases and roles and handoffs between then 08 January 2018 10
  11. 11. Getting The Scopes Right • Need clarity in the scope of engagement and the scope of the problematic situation to be resolved • Needs to be defined and agreed in advance in order to optimise results and benefits Scope Of Engagement Scope Of Situation To Be Resolved 08 January 2018 11
  12. 12. Getting The Scopes Right • Unsure Scope – effort wasted in clarifying scope • Scope Too Wide – too much to do, takes too long, results not delivered quickly • Scope Too Narrow – underlying problematic situation will not be resolved 08 January 2018 12
  13. 13. Early Engagement Principles • Look to address the entire problematic situation, from start to end • Understand what participants need • Collect and use data to make decisions • Maximise simplicity of resolution • Keep the engagement team small, skilled and focussed • Automate elements of resolution where possible 08 January 2018 13
  14. 14. Resolution Identification Can Be Difficult • Uncertain, undefined or multiple mixed objectives • Lack of coherence on what is needed among stakeholders and affected parties • Unarticulated needs • Lack of clarity of what is really needed • Complexity – large number of components, interactions, connections, processes, stakeholders • Heterogeneity among stakeholders and affected parties • Opposition from some stakeholders and affected parties • Time and cost constraints • Unpredictability, uncertainty and change in what is being analysed 08 January 2018 14
  15. 15. Why Have Early Engagement? 08 January 2018 15 Business Objectives Business Operational Model Solution Portfolio Realisation And Delivery Solution Usage, Management , Support And Operations Business Strategy Business IT Strategy Solution Portfolio Design And Specification External Suppliers and Service Providers Business shadow IT expenditure External Suppliers and Service Providers External Suppliers and Service Providers Business-perceived barriers to solution delivery by IT function Shadow IT solutions passed to support function At least 40% of technology spending is diverted from IT Over 30% of CIOs routinely not consulted on IT solution acquisition and expenditure Remove The Barrier That Prevents Continuity From Business Need To IT Solution
  16. 16. Early Engagement Model 08 January 2018 16 Requirements Gathering Business Analysis Solution Architecture and Design Business Analyst Solution Architect • Compress standard requirements gathering and solution architecture and design processes • Collapse the separate roles of business analyst and solution architect into single resolution analyst team Early Engagement Early Engagement Team
  17. 17. Outputs Of Early Engagement • Understand the business need and drivers • Understand the full scope of any solution • Under solution options and benefits • Understand likely scope of solution delivery effort – cost, time, resources • Understand the organisation impact of solution operation – organisation change, staffing • Understand the overall complexity • Statement of possible delivery options • Be presented with sufficient information to enable an informed decision to be made 08 January 2018 17
  18. 18. Benefits Of Early Engagement • Ensure that the business and IT invest in the right solutions in the right way and at the right time • Validate assumptions early • Improve the accuracy of planning and forecasting • Increase the volume of knowledge available • Subsequent solution delivery is optimised • Allows evidence-based decision making 08 January 2018 18
  19. 19. Outcomes Of An Effective Early Engagement Process • Reduce probability of creating poor solution design • Better business case • Increase probability of effective design and reduced subsequent rework and change • Increased user satisfaction with the solution ultimately delivered 08 January 2018 19
  20. 20. Need For Solution Analysis Exists Because … • I have a problematic situation or condition or state • There is an opportunity • I have received a directive • I want to be able to do what I am currently unable to do • I cannot do what I want • I need to be able to do something • A solution is a Resolver, a Provider or an Enabler • An originator will identify the need for a solution • The IT function must work with the originator to provide a usable answer to the solution need 08 January 2018 20
  21. 21. Engagement Definition Journey Stages WHY? WHAT? HOW? 08 January 2018 21
  22. 22. Why, What And How • WHY? − Why is the solution being looked for: a problem, an opportunity, an obligation? − Why has the situation requiring a solution arisen? − Why are we here? − Why do it? − Why not do it? • WHAT − What are the options? − What can be done? − What is being looked for? − What must it do? • HOW − How should it be done? − How should it operate? − How can it be delivered? 08 January 2018 22
  23. 23. The Complete Solution Is Always Much More Than Just … • … Just a bunch of software • Complete solution is the entire set of components needed to operate the associated business processes • Successful solution requires the interoperation of all these components and that the components are properly designed and implemented • Overall solution usage experience is the sum of the experience of the usage of the components 08 January 2018 23
  24. 24. Scope Of Complete Resolution Changes to Existing Systems New Custom Developed Applications Information Storage Facilities System Integrations/Data Transfers/Exchanges Changes to Existing Business Processes Organisational Changes Existing Data Conversions/ Migrations New Data Loads Training and Documentation Central, Distributed and Communications Infrastructure Sets of Installation and Implementation Services Cutover/Transfer to Production Operational Functions and Processes Parallel Runs New Business Processes Reporting and Analysis Facilities Sets of Maintenance, Service Management and Support Services Application Hosting and Management Services Acquired and Customised Software Products 08 January 2018 24
  25. 25. Any Complete Resolution Consists of: • Zero or more of {Changes to Existing Systems} • + Zero or more of {New Custom Developed Applications} • + Zero or more of {Information Storage Facilities} • + Zero or more of {Acquired and Customised Software Products} • + Zero or more of {System Integrations/Data Transfers/Exchanges} • + Zero or more of {Changes to Existing Business Processes} • + Zero or more of {New Business Processes} • + Zero or more of {Organisational Changes} • + Zero or more of {Reporting and Analysis Facilities} • + Zero or more of {Existing Data Conversions/Migrations} • + Zero or more of {New Data Loads} • + Zero or more of {Training and Documentation} • + Zero or more of {Central, Distributed and Communications Infrastructure} • + Zero or more of {Sets of Installation and Implementation Services} • + Zero or more of {Cutover/Transfer to Production} • + Zero or more of {Operational Functions and Processes} • + Zero or more of {Parallel Runs} • + Zero or more of {Sets of Maintenance, Service Management and Support Services} • + Zero or more of {Application Hosting and Management Services} 08 January 2018 25
  26. 26. Resolution Options • Scenarios and options of the to-be condition/situation/state that improve the initial problematic situation with comparisons • All solution options have impacts and involve changes: people, organisation • Changes do not necessarily need or need to be limited to IT systems − Problem analysis may be performed by IT but the IT function needs to look outside its core capabilities and its comfort zone − A solution does not necessarily consist of a system • Define approaches to implementing scenarios and options 08 January 2018 26
  27. 27. Resolution Options • There will always be multiple resolution options, each of which will have a different component profile 08 January 2018 27
  28. 28. Sample Resolution Profile 1 08 January 2018 28
  29. 29. Sample Resolution Profile 2 08 January 2018 29
  30. 30. Resolution Needs To Be Bridge From Current Situation • Solution needs to be a staged transition from the as-is situation to the to-be transformed situation from where we are to where we want or need to be Stage 1 Where We Are Where We Want Or Need To Be Stage 2 Stage 3 Stage 4 08 January 2018 30 Improvement Leading To Better Outcomes Objective of Engagement is to Identify Options for Transition
  31. 31. Early Engagement Is About Navigating The Problem Landscape And Moving And Being Lead Towards A Resolution Consensus 08 January 2018 31
  32. 32. Early Engagement Processes 08 January 2018 32 Early Engagement Process Early Engagement Management Process Management of Portfolio of Engagements Process
  33. 33. Early Engagement Process • The act of collecting information and analysing it, engaging with the business has a benefit in term of imposing order on a disordered situation • The output and the act of its generation requires that the collected and analysed information is presented in a structured and coherent form that can withstand rigorous interrogation • Generate confidence • Avoid dogmatic positions 08 January 2018 33
  34. 34. Core Early Engagement Process 08 January 2018 34 Investigation, Information Gathering Building Activity Models Questioning, Verification, Validation, Elaboration Defining Actions Defining Implementation Time
  35. 35. Core Early Engagement Process • Investigation, Information Gathering – meeting with business function stakeholders to understand different views of current problem state and desired/idealised future state • Building Activity Models – describe views of as-is and to- be actions and their sequence • Questioning, Verification, Validation, Elaboration – review activity models with business function stakeholders • Defining Actions – define actions to implement target to- be activity model • Defining Implementation – define implementation activities to actualise target to-be activity model 08 January 2018 35
  36. 36. Core Principles And Business Engagement Model • A engagement model is needed to breathe life into and operationalise the early engagement process • Can be part of the internal IT organisation’s consulting function IT Organisation Consulting Function Engagement Team Skills, Capabilities and Experience IT Consulting Function Management Consulting and Engagement Process Tools and Methodologies 08 January 2018 36
  37. 37. Business Engagement Model • Achieve potential for IT consulting for the IT organisation and for the business − IT Consulting Function Management – integrating IT consulting practices and skills into a whole, being able to represent the benefits of these skills and experiences to the IT organisation and wider business and being able to manage the delivery of services that contribute to success − Engagement Team - an engagement team that can work together in a consulting environment − Skills, Capabilities and Experience – appropriate sets of skills and experiences across all technology and service areas to deliver the services − Consulting and Engagement Process – an engagement process that delivers quality results and outputs quickly, speaking the language of business − Tools and Methodologies – select, develop and use appropriate toolsets and frameworks to underpin the consistent and reliable delivery of consulting services and to convert the language of business problems into the language of resolution 08 January 2018 37
  38. 38. Activity Model Of As-Is And To-Be Situations • Define initial high-level as-is and to-be activity models • Generic model consists of three sets of concentric activities 1. Operational – what gets done, in what sequence, with what dependencies, with what resources 2. Monitoring, Management, Administration, Control – control of flow, allocation and reallocation, reporting on throughput, respond to change 3. Improvement, Optimisation – ensure activities are fit for purpose, delivering benefits, achieving expected outcomes, activity modification and enhancement 08 January 2018 38
  39. 39. As-Is and To-Be Activity Models 08 January 2018 39 Activity 1 Activity 2 Activity 3 Activity 5 Activity 4 Activity 6 Operational Monitoring, Management, Administration, Control Improvement, Optimisation
  40. 40. Layers Of Activity Models • There will be layers of activity models • Keep model definition at a high-level initially • Detail can be added later 08 January 2018 40 Activity 1 Activity 2 Activity 3 Activity 5 Activity 4 Activity 6 Activity 1 Activity 2 Activity 3 Activity 5 Activity 4 Activity 6 Activity 1 Activity 2 Activity 3 Activity 5 Activity 4 Activity 6
  41. 41. Using Activity Model To Derive Structured Questions • Use the activity models derived from investigations to create a structured set of questions to allow activity details be elaborated, explored, understood and refined 08 January 2018 41 Activity Trigger(s) Dependencies Required Input(s) Expected Output(s) Next Step(s) Expected Outcome(s) Who and How Performed What Skills Required How Monitored How Quality Maintained Activity 1 Activity 2 Activity 3 Activity 4 Activity 5 Activity 6
  42. 42. Participants And Views Of Activities • Different resolution participants may have different views of the activity models of the current as-is and desired to-be situation • Document these separately initially 08 January 2018 42 Resolution Definition Participants Views
  43. 43. As-Is and To-Be Activity Model • Create initial activity model and refine it through the engagement process • Models are simplifications of the underlying real world situation − Simplification is necessary to capture information − Complexity can be added during refinement • Use the model as a framework to ask informed questions, gather information • Different stakeholders may have different views of activity model − May need to create several activity modes initially and combine them later 08 January 2018 43
  44. 44. Rich Pictures • Detailed visualisations represent information more effectively than lengthy narrative text • Show relationships, interactions • Provides a more concise illustration of state • Better tool to elicit information • Gaps, errors and omissions more easily identified • Assists informed discussions • Evolve and refine rich picture representations of as-in and to- be situations throughout the engagement exercise • Cannot expect to capture every piece of information – focus on the important elements 08 January 2018 44
  45. 45. Rich Pictures – Typical Contents • Not all picture need have all elements • You can have multiple pictures and pictures can evolve 08 January 2018 45 Element Description Core Objective(s) Brief statement of the core purpose(s) of the situation where there is perceived to be a problem – what the associated service is looking to achieve Actor Persons or groups within the organisation or externally providing services to the organisation involved in the delivery of the overall service Consumer Persons or groups at whom the service is being directed or who use the service Entities, Types and Roles Functional collections of persons or groups within the organisation or externally providing services Locations and Facilities Locations or interaction points where consumers avail of or are provided with services Viewpoints Views or opinions of actors on the provision and operation of the service Relationships and Dependencies Relationships and dependencies between other elements of the rich picture Interactions Dealings and relations between entities, actors and consumers Processes Processes that are used to deliver service or support its delivery Options, Questions Options and questions relating to the core service objectives Requirements, Obligations Requirements and obligations of actors and entities, relating to the core service objectives Core Issues and Owners Issues relating to the core service objectives Constraints, Limitations Any actual or perceived constraints and limitations relating to the provision and operation of the service
  46. 46. Rich Picture Example 08 January 2018 46 Entity 1 Entity 2 Entity 3 Entity 10 Entity 11 Entity 7 Entity 8 Entity 9 Entity 5 Entity 6 Entity 4 Location 1 Issue 1 Issue 2 Issue 3 Location 2 Viewpoint 1 Requirement 1 Requirement 6 Requirement 3 Requirement 4 Requirement 2 Viewpoint 2 Viewpoint 4 Viewpoint 3 Interaction Interaction Interaction Interaction Process 1 Process 2 Process 3 Viewpoint 5 Interaction Interaction Constraint 1 Constraint 2 Constraint 3 Requirement 5 Location 3 Core Objectives Consumer 1 Consumer 2
  47. 47. Rich Pictures • Are not systematic views (yet) • They do not contains system-related components such as IT applications, infrastructure and data flows at this stage − These are solution and implementation-related elements • Resist the temptation to include systematic parts at the investigation stage and pre-judge options for resolution and transformation − Transformation with a small “t” • Jumping to conclusions at this stage will limit the scope of information gathered 08 January 2018 47
  48. 48. Resolution Attributes And Evaluation Factors • Achievable – can it be implemented? • Realistic – is the resolution practical? • Desirable – is the resolution required and suitable? • Affordable – can the organisation afford the the likely cost of the resolution • Operable – is the resolution workable? • Usable – can the resolution be used by its participants? • Effective – is the resolution delivering what is expected and required? • Efficient – can the resolution be implemented and operated with a minimum of resources? 08 January 2018 48
  49. 49. Dimensions Of Implementation Scenarios • There will be two dimension to any resolution 1. Target resolution and transformation scenarios/options 2. Options for implementing target scenarios/options • Engagement need to consider both the resolution and how it can be achieved 08 January 2018 49
  50. 50. Paths To Resolution 08 January 2018 50 From As-Is To Ro-Be Target Resolution scenarios/Options Delivery Stages and Options
  51. 51. Human Dimensions To Engagement • A person or group of people have requested the engagement or have been compelled to accept the engagement − There will be an agenda to this • Participants are involved in the current problem state • Participants will be affected by changes to the current state • There may be conflicting views and opinions between these participants • There will be different agendas at play • The engagement process must be aware of these personal aspects − A lack of awareness may cause the engagement to fail 08 January 2018 51
  52. 52. There Is Never Just One Resolution • The choice of resolution depends on multiple business factors: − Degree of automation − Sourcing options − Resources and their availability − Timescale and urgency of solution − Cost and available finance − Likely duration of solution − Solution quality factors − Organisational impact 08 January 2018 52
  53. 53. Change Can Only Really Happen … • When there is a perception and an acceptance that there is a problem or challenge or opportunity that can only be resolved by a change • Organisation and business functions impacted must be willing and able to accept change • Management must support change • Engagement process must be aware of the culture and politics of the organisation and the impacted business functions • Identifying issues around and resistance to change needs to be a part of the engagement process 08 January 2018 53
  54. 54. Information and Data Applications and Systems Organisation and Structure Locations and Offices Technology, Infrastructure and Communications Business Processes Organisation Change Organisation Change – Core Internal Organisation Areas • Overall organisation change is concerned one or more of aspects or change and co- ordinating changes across these areas to deliver the greatest benefit • Each resolution will have a different organisation change profile • Resolution options will depend on the ability of the organisation to change 08 January 2018 54
  55. 55. Dimensions Of Organisation Change • Business Oriented Dimensions Of Change − Location and Offices – existing and new locations and facilities of the organisation, their types and functions and the principles that govern the selection of new locations − Business Processes – current and future business process definitions, requirements, characteristics, performance − Organisation and Structure – organisation resources and arrangement, business unit, function and team structures and composition, relationships, reporting and management, roles and skills • Technology Oriented Dimensions Of Change − Technology, Infrastructure and Communications – current and future technical infrastructure including security, constraints, standards, technology trends, characteristics, performance requirements − Applications and Systems – current and future applications and systems, characteristics, constraints, assumptions, requirements, design principles, interface standards, connectivity to business processes − Information and Data – data and information architecture, data integration, master and reference data, data access and management 08 January 2018 55
  56. 56. Dimensions Of Organisation Change • Each resolution will involve different sets of organisation changes • Be realistic about the organisation’s ability to accept change 08 January 2018 56 Information and Data Applications and Systems Organisation and Structure Locations and Offices Technology, Infrastructure And Communications Business Processes Organisation Change Information and Data Applications and Systems Organisation and Structure Locations And Offices Technology, Infrastructure and Communications Business Processes Organisation Change
  57. 57. How Do You Define The Measurement Of Success Of The Resolution/Transformation? • Efficacy – is it working and delivering the required results? • Efficiency – can it be delivered and operated with the minimum or an acceptable level of resources? • Effectiveness – is the resolution/transformation contributing to a wider, longer-term or greater success or improvement? 08 January 2018 57 Efficacy EffectivenessEfficiency
  58. 58. Bringing It All Together And Presenting The Results • Early engagement process is not just about gathering information • The output must be a set of resolution options and their implementation • Resolutions must exist within a real-world context with all its constraints, limitations and boundaries • Where the resolution includes IT changes, in addition to solution options there will be organisation IT restrictions based on the organisation’s enterprise architecture standards • Early engagement process must include delivery and operation options to allow informed decision be made on the true scope of the resolution 08 January 2018 58
  59. 59. Superset Of Constraints Sets Will Narrow Range Of Available, Realistic And Achievable Options Organisation’s Enterprise Architecture Organisation Change Profile Resolution Attributes Resolution Component Characteristics Resolution Implementation Options Resolution Qualities
  60. 60. Moving From The As-Is To The Target To-Be Process • Goal of the engagement process is to describe the resolved situation and the options for achieving the transformation 08 January 2018 60 As-Is Situation To-Be Transformed SituationTransformation Process
  61. 61. Systematising The Resolution • Ultimately the resolution needs to be translated into an implementable and operable solution − Define systems and processes − Identify data implications − Identify gaps and options for reuse • The engagement process needs to present systematised solutions that can form the basis for decisions 08 January 2018 61
  62. 62. Approach To Solution Definition • Want an approach that quickly identifies the likely scope of the solution, the options and the decisions that need to be made • Key elements of initial solution scope and design: − Systems/Applications – new and existing systems that must be developed/changed to deliver functions − System Interfaces – links between systems − Actors – business functions and roles that will interact with the overall solution and its components − Actor-System Interactions – interactions between Actors and Systems/Applications − Actor-Actor Interactions – interactions between Actors − Functions – functions that must be delivered by the overall solution − Processes – business processes required to operate the solution − Journey – standard journey through processes/functions and exceptions/deviations from “happy path” − Logical Data View – data elements required − Data Exchanges – movement of data between Systems/Applications • These combine to provide a comprehensive view of the potential solution at this early stage 08 January 2018 62
  63. 63. Approach To Initial Solution Architecture Definition • Start with identifying core solution definition elements – those elements directly involved in the solution • Expand initial solution definition with extended elements – element interactions and data storage and exchange 08 January 2018 63 Core Definition Elements Extended Definition Elements Processes Functions Actors Systems/Applications System Interfaces Actor-System Interactions Actor-Actor Interactions Solution Usage Journeys Logical Data View Data Exchange
  64. 64. Initial Solution Architecture Definition • This allows: − System changes and developments required to be defined − Potential options for reuse of existing systems to be determined − Options for manual or automated operation to be pinpointed − Effort to be estimated − Organisational impact to be quantified including staffing, training, support, cutover, parallel run and documentation − Dependencies to be identified − Informed decision to proceed to be made • Provides a worklist/table of contents of further work if decision to continue is made 08 January 2018 64
  65. 65. Core Elements Of Initial Solution Architecture Definition 08 January 2018 65 Systems/ Applications Actors Functions Processes
  66. 66. Initial Solution Architecture Definition – Identify Key Existing Business Processes Affected Or New Ones Required 08 January 2018 66
  67. 67. Identify Functions Required To Enable Processes 08 January 2018 67
  68. 68. Identify Actors Who Will Use Functions And Participate In Processes 08 January 2018 68
  69. 69. Identify New Systems/Applications And Changes To Existing Systems/Applications To Deliver Functions 08 January 2018 69
  70. 70. Sample Representation Of Core Solution Elements 08 January 2018 70
  71. 71. Sample Representation Of Core Solution Elements 08 January 2018 71
  72. 72. Sample Representation Of Core Solution Elements 08 January 2018 72
  73. 73. Sample Representation Of Core Solution Elements 08 January 2018 73
  74. 74. Required System Interfaces And Interactions 08 January 2018 74
  75. 75. Required Actor System Interfaces And Interactions 08 January 2018 75
  76. 76. Required Actor-Actor Interactions 08 January 2018 76
  77. 77. Core and Extended Solution Elements 08 January 2018 77
  78. 78. Data Elements Required Within Systems/ Applications 08 January 2018 78
  79. 79. Data Exchanges Required Between Systems/ Applications 08 January 2018 79
  80. 80. Solution Usage Journeys • For every solution there will be one or more “happy paths” – standard paths through the solution without exception/problem/deviation handling • Exceptions may occur at each step in these happy paths • High-level solution should identify solution usage journeys and their possible exceptions 08 January 2018 80
  81. 81. Solution Definition Summary • Forms the basis of an inventory of work needed to implement solution − Subsequent detailed solution design will specify each component • Enables decisions to be made on how to proceed 08 January 2018 81 Core Definition Elements Extended Definition Elements Processes Process 1 ... Functions Function 1 ... Actors Actor 1 ... Systems/Applications Systems/Applications 1 ... System Interfaces Interface 1 ... Actor-System Interactions Actor-Actor Interactions Solution Usage Journeys Logical Data View Data Impact 1 ... Data Exchange Data Exchange 1 ....
  82. 82. Maximise The Known Knowns Of The Potential Solution • Solution unkowns are the source of potential problems during solution delivery • The goal of solution design is no surprises 08 January 2018 82 What Can Be Known Known Unknown What We Know Known Here Be Dragons Unknown
  83. 83. Maximise The Known Knowns Of The Potential Solution 08 January 2018 83 Known Knowns Known Unknowns Unknown Unknowns • The more that is known about the solution design the fewer the problems relating to scope and changes will occur later
  84. 84. More Information Alan McSweeney http://ie.linkedin.com/in/alanmcsweeney 08 January 2018 84

×