Introduction to Solution Architecture

Copyright © 2019 Alan McSweeney

All rights reserved.

ISBN-13: 9781797567617

Page 1 of 540
 Introduction to Solution Architecture

Contents

................................................................
Chapter 1. Introduction, Purpose and Scope ................................ .................................................
................................ ................. 16
1.1 Introduction ................................................................................................................................................................................................ 16
1.2 Who This Book Is Aimed At ................................................................................................................................................................... 18
1.3 Terminology ................................................................................................................................................................................................ 19
1.4 Structure and Contents of This Book .................................................................................................................................................... 19
1.5 Checklists ..................................................................................................................................................................................................... 22

................................................................
Chapter 2. Solution Architecture and Solution Design ................................ .................................... 25
................................
2.1 Introduction ................................................................................................................................................................................................ 25
2.2 Solution Architecture – A Lesson From History................................................................................................................................ 29
2.3 Evolution of Solution Architecture and Solution Architect Role ................................................................................................... 30
2.4 What Is a Solution?.................................................................................................................................................................................... 33
2.4.1 Introduction ...................................................................................................................................................................................................... 33
2.4.2 Scope of Complete Solution ............................................................................................................................................................................ 33
2.4.3 Solutions and Organisation Change .............................................................................................................................................................. 40
2.4.4 Solution Components and Organisation Change ........................................................................................................................................ 41
2.4.5 Solution Decomposition .................................................................................................................................................................................. 42
2.4.6 Solution Cost ..................................................................................................................................................................................................... 44
2.4.7 Solution Options, Boundaries and Constraints ........................................................................................................................................... 48
2.5 Getting the Solution Design Right ......................................................................................................................................................... 50
2.6 The Solution Delivery Process in Context ........................................................................................................................................... 50

Chapter 3. Business Strategy, Architecture Strategy and Solution Design and Delivery .............. 57
3.1 Why Solutions Fail .................................................................................................................................................................................... 57
3.1.1 The Business Value of Solution Architecture ............................................................................................................................................... 71
3.2 Solution Architecture and Risk Management ..................................................................................................................................... 71
3.3 Architecture Disciplines, Context and Interactions .......................................................................................................................... 75
3.3.1 Introduction ...................................................................................................................................................................................................... 75
3.3.2 Run the Business and Change the Business .................................................................................................................................................. 80
3.3.3 IT Architecture Principles ............................................................................................................................................................................... 81
3.3.4 Problems with IT Architecture Operation.................................................................................................................................................... 83
3.3.5 Shadow IT .......................................................................................................................................................................................................... 86

Chapter 4. Solution Architecture Engagement and the Solution Design Process ......................... 91
4.1 Introduction ................................................................................................................................................................................................ 91
4.2 Problem and Solution Knowledge and Complexity .......................................................................................................................... 95
4.2.1 Problem and Solution Knowledge ................................................................................................................................................................. 95
4.2.2 Solution Complexity....................................................................................................................................................................................... 100
4.3 Solution Design, Delivery and Operation Context .......................................................................................................................... 112
4.4 Solution Architecture Interface with the Business Analysis Function, Requirements Gathering and Process Analysis 124
4.4.1 Requirements Engineering ............................................................................................................................................................................ 129
4.4.2 Business Processes .......................................................................................................................................................................................... 134
4.4.2.1 Business Process Modelling Notation (BPMN)................................................................................................................................. 151
4.5 Solution Architecture Engagement Process ...................................................................................................................................... 158
4.6 Solution Architecture Engagements .................................................................................................................................................... 161

Page 2 of 540
 Introduction to Solution Architecture

4.6.1 Business Engagement ..................................................................................................................................................................................... 161

4.6.1.1 Introduction ............................................................................................................................................................................................ 161
4.6.1.2 Workshops............................................................................................................................................................................................... 166
4.6.1.3 High Level Activities and Their Logical Sequence ............................................................................................................................ 167
4.6.1.4 Business Engagement Activity 0. Define And Agree Engagement Scope ...................................................................................... 168
4.6.1.4.1 Step 0.1 Preparation and Planning .............................................................................................................................................. 169
4.6.1.4.2 Step 0.2 Mobilise and Present Approach to Sponsorship, Stakeholder and Core Project Team ....................................... 170
4.6.1.4.3 Step 0.3 Review Any Previous Work, if Any.............................................................................................................................. 170
4.6.1.4.4 Step 0.4 Perform Initial Informal Information Gathering....................................................................................................... 171
4.6.1.4.5 Step 0.5 Review Information and Define Scope of Introductory Workshop(s) ................................................................... 171
4.6.1.4.6 Step 0.6 Define Team and Facilities Required ........................................................................................................................... 172
4.6.1.4.7 Step 0.7 Create Table of Contents (Scope) of Engagement Deliverable ................................................................................ 173
4.6.1.4.8 Step 0.8 Conduct Introductory Workshop(s)............................................................................................................................ 174
4.6.1.4.9 Step 0.9 Update Scope of Deliverables ........................................................................................................................................ 174
4.6.1.5 Business Engagement Activity 1. Information Collection And Assessment ................................................................................. 175
4.6.1.5.1 Step 1.1 Current Business Review ............................................................................................................................................... 175
4.6.1.5.2 Step 1.2 Assess Customer (Or External Party) Perceptions .................................................................................................... 177
4.6.1.5.3 Step 1.3 Review Current Industry Best Practices And Technology Changes ....................................................................... 178
4.6.1.5.4 Step 1.4 Analyse Current Business Systems ............................................................................................................................... 180
4.6.1.5.5 Step 1.5 Analyse Available Solutions And Products ................................................................................................................. 182
4.6.1.6 Business Engagement Activity 2. Define Vision, Business Principles And System Principles ................................................... 183
4.6.1.6.1 Step 2.1 Define Vision For Functional Business Area .............................................................................................................. 183
4.6.1.6.2 Step 2.2 Describe Functional Business Area Principles, Assumptions and Limitations ..................................................... 187
4.6.1.6.3 Step 2.3 Describe System Principles, Assumptions and Limitations ..................................................................................... 188
4.6.1.7 Business Engagement Activity 3. Document Business Processes, Entity Model, Capacity Planning And Solution Approach
................................................................................................................................................................................................................................ 190
4.6.1.7.1 Step 3.1 Define And Document Business Processes ................................................................................................................. 191
4.6.1.7.2 Step 3.2 Create Conceptual Entity Model .................................................................................................................................. 197
4.6.1.7.3 Step 3.3 Gather Capacity Planning Information ....................................................................................................................... 197
4.6.1.7.4 Step 3.4 Define Solution And System Approach ....................................................................................................................... 199
4.6.1.7.5 Step 3.5 Develop And Validate Feasibility Prototype(s) .......................................................................................................... 205
4.6.1.8 Business Engagement Activity 4. Document Solutions, Applications And Functions ................................................................ 205
4.6.1.8.1 Step 4.1 Document Systems, Applications And Functions ..................................................................................................... 205
4.6.1.9 Business Engagement Activity 5. Define Organisation, Infrastructure And Data ....................................................................... 208
4.6.1.9.1 Step 5.1 Define Organisation And Resource Requirements And Structure ......................................................................... 208
4.6.1.9.2 Step 5.2 Define Application And Data Organisation ............................................................................................................... 209
4.6.1.9.3 Step 5.3 Define Infrastructure Requirements ............................................................................................................................ 211
4.6.1.10 Business Engagement Activity 6. Conduct Solution And Product Evaluation And Selection ................................................. 212
4.6.1.10.1 Step 6.1 Conduct Solution And Product Evaluation And Selection .................................................................................... 213
4.6.1.11 Business Engagement Activity 7. Design Model Architecture ...................................................................................................... 221
4.6.1.11.1 Step 7.1 Design Infrastructure Model Architecture ............................................................................................................... 221
4.6.1.12 Business Engagement Activity 8. Consolidate, Finalise And Review Design.............................................................................. 224
4.6.1.12.1 Step 8.1 Finalise Application Architecture .............................................................................................................................. 225
4.6.1.12.2 Step 8.2 Define Benefits And Costs ........................................................................................................................................... 225
4.6.1.12.3 Step 8.3 Create High Level Phased Delivery Plan ................................................................................................................... 225
4.6.1.12.4 Step 8.4 Review And Agree Business Architecture Engagement .......................................................................................... 226
4.6.2 Solution Design Process ................................................................................................................................................................................. 226
4.6.3 Solution Design Engagement Types............................................................................................................................................................. 234
4.6.4 Early Engagement ........................................................................................................................................................................................... 235
4.6.4.1 Introduction ............................................................................................................................................................................................ 235
4.6.4.2 What Is A Problem? ............................................................................................................................................................................... 240
4.6.4.3 Early Engagement Aspects .................................................................................................................................................................... 242
4.6.4.4 Early Engagement Questions ................................................................................................................................................................ 245
4.6.4.5 Building Activity Model Stream ........................................................................................................................................................... 246
4.6.4.6 Rich Pictures............................................................................................................................................................................................ 249
4.6.4.7 Resolution Options ................................................................................................................................................................................ 251
4.6.4.8 Problem Resolution and Organisation Change ................................................................................................................................. 253
4.6.4.9 Bringing It All Together And Presenting The Results ...................................................................................................................... 256
4.6.5 Rapid Solution Design Option Engagement ............................................................................................................................................... 257
4.6.5.1 Introduction ............................................................................................................................................................................................ 258
4.6.5.2 Step 1 – Identify New and Impacted Existing Business Processes .................................................................................................. 260
4.6.5.3 Step 2 – Identify Key Functions ........................................................................................................................................................... 261

Page 3 of 540
 Introduction to Solution Architecture

4.6.5.4 Step 3 – Identify Actors ......................................................................................................................................................................... 264

4.6.5.5 Step 4 – Identify New and Existing Applications .............................................................................................................................. 265
4.6.5.6 Step 5 – Identify Data Integrations, Transfers and Exchanges ....................................................................................................... 266
4.6.5.7 Step 6 – Identify Actor and Application Interactions....................................................................................................................... 268
4.6.5.8 Step 7 – Identify Actor/Actor Interactions......................................................................................................................................... 269
4.6.5.9 Steps 1-7 – Solution on a Page ............................................................................................................................................................. 270
4.6.5.10 Steps 8 and 9 – Identify Data Sets, Data Impacts and Data Movements ..................................................................................... 270
4.6.5.11 Step 10 – Create Inventory of Solution Usage Journeys ................................................................................................................ 272
4.6.5.12 Summary ............................................................................................................................................................................................... 275
4.6.6 Structured Solution Design Engagement .................................................................................................................................................... 276
4.6.6.1 Introduction ............................................................................................................................................................................................ 276
4.6.6.2 Structured Solution Design Approach and TOGAF......................................................................................................................... 279
4.6.6.3 Business and Process View ................................................................................................................................................................... 282
4.6.6.3.1 Adapting TOGAF Business Phase to the Business and Process View ................................................................................... 285
4.6.6.4 Functional View ..................................................................................................................................................................................... 287
4.6.6.4.1 Adapting TOGAF Information Systems Architecture Phase to the Functional View........................................................ 288
4.6.6.5 Data View ................................................................................................................................................................................................ 291
4.6.6.5.1 Adapting TOGAF Information Systems Architecture Phase to the Data View .................................................................. 293
4.6.6.6 Technical View ....................................................................................................................................................................................... 295
4.6.6.6.1 Adapting TOGAF Technology Architecture Phase to the Technical View .......................................................................... 297
4.6.6.7 Implementation View ............................................................................................................................................................................ 300
4.6.6.7.1 Adapting TOGAF Technology Architecture Phase to the Implementation View .............................................................. 302
4.6.6.8 Management and Operations View..................................................................................................................................................... 304
4.6.6.8.1 Adapting TOGAF Technology Architecture Phase to the Management and Operations View ....................................... 308
4.7 Solution Architecture and Solution Experience and Usability ..................................................................................................... 311
4.8 Data Architectural Aspects of Solution Architecture ...................................................................................................................... 321
4.8.1 Data Management Book of Knowledge (DMBOK) Data Architecture Framework ............................................................................ 321
4.8.2 Solution Data Landscape ............................................................................................................................................................................... 326
4.8.3 Solution Data Quality..................................................................................................................................................................................... 336
4.8.4 Data Lifecycle .................................................................................................................................................................................................. 337
4.8.5 Data Integration .............................................................................................................................................................................................. 339
4.8.6 Data Audit and Data Profiling ...................................................................................................................................................................... 351
4.8.6.1 Data Landscape View ............................................................................................................................................................................ 351
4.8.6.2 Data Supply Chain View ....................................................................................................................................................................... 351
4.8.6.3 Data Model View.................................................................................................................................................................................... 351
4.8.6.4 Data Lifecycle View................................................................................................................................................................................ 352
4.8.6.5 Solution Data Audit Approach ............................................................................................................................................................ 352
4.9 Security and Privacy ................................................................................................................................................................................ 352
4.9.1 Solution Security ............................................................................................................................................................................................. 352
4.9.2 Solution Data Privacy..................................................................................................................................................................................... 363
4.9.2.1 Overview .................................................................................................................................................................................................. 363
4.9.2.2 Personal Information............................................................................................................................................................................. 364
4.9.2.3 Personal Data Related Processes and Impact on Solution Design.................................................................................................. 366
4.9.2.4 GDPR Related Metadata ....................................................................................................................................................................... 369
4.9.2.5 Solution Data Protection Impact Assessment (DPIA) ..................................................................................................................... 370
4.9.2.6 Data Pseudonymisation ........................................................................................................................................................................ 371
4.9.3 Data and Hosted Applications and XaaS/Cloud-Based Services ............................................................................................................. 374
4.10 Solution Architecture and Design Artefacts ................................................................................................................................... 377
4.11 Solution Assessment and Review ....................................................................................................................................................... 381
4.11.1 Solution Benefits Review ............................................................................................................................................................................. 381
4.11.2 Solution Design Review ............................................................................................................................................................................... 383
4.11.3 Solution Architectural Review .................................................................................................................................................................... 386
4.11.4 Solution Implementability Review ............................................................................................................................................................. 386
4.12 Solution Architecture and Estimation .............................................................................................................................................. 387

Transformation................................
Chapter 5. Solution Architecture and Digital Transformation ....................................................
................................ .................... 391
5.1 Introduction .............................................................................................................................................................................................. 391

Page 4 of 540
 Introduction to Solution Architecture

5.2 Digital Strategy in Business and Information Technology Context ............................................................................................ 396
5.3 Digital Target Architecture ................................................................................................................................................................... 399
5.4 Digital and Solution Architecture ........................................................................................................................................................ 415
5.4.1 Digital Solution Integration........................................................................................................................................................................... 416
5.4.2 Range of Solutions Within Digital Transformation .................................................................................................................................. 417
5.4.3 Digital Design Principles ............................................................................................................................................................................... 418
5.4.4 Digital Solution Architecture Interactions With Other Architecture Functions .................................................................................. 420

................................................................
Chapter 6. Agile Solution Design and Delivery ................................ ............................................
................................ ............ 422
6.1 Introduction .............................................................................................................................................................................................. 422
6.2 Agile Approach to Solution Delivery .................................................................................................................................................. 423
6.3 Using Agile Solution Delivery Effectively .......................................................................................................................................... 426
6.4 Agile Solution Delivery Pillar One - Solution Delivery Selection and Validation ................................................................... 427
6.5 Agile Solution Delivery Pillar Two - Control Components of Agile Process ............................................................................ 431
6.6 Agile Solution Delivery Pillar Three - Agile Tools and Techniques ............................................................................................ 434
6.7 Agile Solution Delivery Pillar Four - Agile Solution Delivery Phases ......................................................................................... 435
6.7.1 Agile Solution Delivery Phase 1 - Pre-Project Phase ................................................................................................................................. 437
6.7.2 Agile Solution Delivery Phase 2 - Feasibility Analysis and Study Phase ................................................................................................ 438
6.7.3 Agile Solution Delivery Phase 3 - Business Study Phase........................................................................................................................... 439
6.7.4 Agile Solution Delivery Phase 4 - Functional Model Iteration Phase ..................................................................................................... 441
6.7.5 Agile Solution Delivery Phase 5 - Design and Build Iteration Phase ...................................................................................................... 442
6.7.6 Agile Solution Delivery Phase 6 - Implementation Phase ........................................................................................................................ 444
6.7.7 Agile Solution Delivery Phase 7 - Post-Project Phase ............................................................................................................................... 445

........................................................
Chapter 7. Solution Architecture and Solution Acquisition ................................ ........................ 447
7.1 Introduction .............................................................................................................................................................................................. 447
7.1.1 Service Planning and Initiation/Transfer Approach ................................................................................................................................. 452
7.1.1.1 Activities for Initiation/Transition and Service Delivery Phases .................................................................................................... 454
7.1.1.2 Activities for Ongoing Phases............................................................................................................................................................... 459
7.1.2 Supplier Assessment and Validation............................................................................................................................................................ 466

................................................................
Chapter 8. The Solution Architecture Function ................................ ...........................................
................................ ........... 472
8.1 Introduction .............................................................................................................................................................................................. 472
8.2 Solution Architecture Skills, Capabilities and Experience ............................................................................................................. 472
8.2.1 Technical Skills ................................................................................................................................................................................................ 474
8.2.2 Analytical Thinking and Resolution Identification ................................................................................................................................... 476
8.2.3 Behavioural Characteristics ........................................................................................................................................................................... 478
8.2.4 Business Knowledge ....................................................................................................................................................................................... 480
8.2.5 Collaboration Skills ......................................................................................................................................................................................... 483
8.2.6 Communication Skills .................................................................................................................................................................................... 485
8.2.7 Tools and Techniques .................................................................................................................................................................................... 486
8.3 Solution Architecture Function............................................................................................................................................................ 487
8.3.1 Solution Architecture Function Context ..................................................................................................................................................... 487
8.3.2 Solution Architecture Function Structure................................................................................................................................................... 489
8.3.3 Solution Architecture Centre of Excellence ................................................................................................................................................ 492
8.3.4 Some Solution Architecture Function Issues.............................................................................................................................................. 504
8.3.4.1 Conway’s Law.......................................................................................................................................................................................... 505
8.3.4.2 Cognitive Diversity................................................................................................................................................................................. 506
8.3.5 Solution Architecture Tools .......................................................................................................................................................................... 511
8.3.5.1 Solution Architecture Design Tools .................................................................................................................................................... 512
8.3.5.1.1 Structured Systems Analysis and Design Methodology (SSADM) ........................................................................................ 516
8.3.5.1.1.1 Solution Survey and Feasibility Study ................................................................................................................................ 517
8.3.5.1.1.2 Structured Analysis ............................................................................................................................................................... 518
8.3.5.1.1.3 Structured Design .................................................................................................................................................................. 518

Page 5 of 540
 Introduction to Solution Architecture

8.3.5.1.1.4 Infrastructure Configuration Study.................................................................................................................................... 518

8.3.5.1.1.5 Solution Construction and Implementation..................................................................................................................... 518
8.3.5.1.1.6 Solution Operation and Maintenance................................................................................................................................ 518
8.3.5.1.2 Archimate ....................................................................................................................................................................................... 518
8.3.5.2 IT Architecture Frameworks, Methodologies and Description Languages .................................................................................. 528

Architecture
Chapter 9. Solution Archit ................................................................
ecture and Innovation ................................ ........................................
................................ ........ 534

Page 6 of 540
 Introduction to Solution Architecture

List of Tables

Table 1 – Solution Architecture-Related Checklists Contained in the Book ............................................................................................................... 24

Table 2 – Overlapping Solution Architecture Capabilities and Areas of Solution Involvement and Knowledge.................................................. 27
Table 3 – Vitruvius’ Architecture Principles..................................................................................................................................................................... 30
Table 4 – Components of Complete Solution .................................................................................................................................................................. 35
Table 5 – Mapping Solution Components to Business Change Domains.................................................................................................................... 42
Table 6 – Sources of Good and Poor Solution Delivery Estimates ................................................................................................................................ 48
Table 7 – Solution Design Constraints .............................................................................................................................................................................. 49
Table 8 – High-Level Steps of Individual Discipline Solution Delivery Journeys ....................................................................................................... 53
Table 9 – Field of Solution Delivery Project Success and Failure .................................................................................................................................. 61
Table 10 – Standish Group CHAOS Report Project Outcome Results 1994-2015 ..................................................................................................... 63
Table 11 – Causes of Project Failure from What went wrong? Unsuccessful information technology projects.................................................... 64
Table 12 – Standish Group Project Success Factors Over Time .................................................................................................................................... 65
Table 13 – Budzier and Flyvbjerg Project Organisational Challenges .......................................................................................................................... 66
Table 14 – Solution Architecture Contribution to the Standish Group Solution Delivery Success Factors ........................................................... 67
Table 15 – Solution Architecture Contribution to Budzier and Flyvbjerg Organisational Challenges ................................................................... 68
Table 16 – Errors in End User Computing Applications Leading to Financial Losses .............................................................................................. 90
Table 17 – Solution Complexity Factors.......................................................................................................................................................................... 106
Table 18 – Sample Solution Complexity Scores ............................................................................................................................................................. 109
Table 19 – Complexity Scores and Resource Uplifts ..................................................................................................................................................... 110
Table 20 – Sample Solution Complexity Dashboard Elements .................................................................................................................................... 112
Table 21 – Set of Solution Delivery Artefacts ................................................................................................................................................................. 122
Table 22 – Lessons Learned from Large Solutions Implementations ......................................................................................................................... 137
Table 23 – Applying Waste Elimination Principles to Process Optimisation ........................................................................................................... 139
Table 24 – Primary and Support Processes Example .................................................................................................................................................... 146
Table 25 – Business Process Analysis High-Level Steps................................................................................................................................................ 147
Table 26 – Process Analysis Information Structure....................................................................................................................................................... 148
Table 27 – Business Process Design Success Factors ..................................................................................................................................................... 149
Table 28 – Business Process Design Standards and Approaches ................................................................................................................................. 151
Table 29 – BPMN Flow Objects ........................................................................................................................................................................................ 154
Table 30 – BPMN Graphics for Combinations of Task Type and Loop Type........................................................................................................... 155
Table 31 – BPMN Graphics for Sub-Processes............................................................................................................................................................... 156
Table 32 – BPMN Event Modifications ........................................................................................................................................................................... 157
Table 33 – BPMN Gateway Symbols ................................................................................................................................................................................ 157
Table 34 – BPMN Data Symbols ....................................................................................................................................................................................... 158
Table 35 – Mapping Business Need to Engagement Types .......................................................................................................................................... 160
Table 36 – Architecture Engagement Extended Factors ............................................................................................................................................... 165
Table 37 – Introductory Workshop Topics .................................................................................................................................................................... 172
Table 38 – Sample Table of Contents for Architecture Engagement Main Deliverable .......................................................................................... 174
Table 39 – Vision Development Factors.......................................................................................................................................................................... 185
Table 40 – Inventory of Interfaces, Exchanges and Transfers...................................................................................................................................... 207
Table 41 – High Level Steps of Product/Service Evaluation And Selection Process ................................................................................................. 221
Table 42 – Generalised Solution Design Process Steps ................................................................................................................................................. 228
Table 43 – Early Engagement Aspect Sample Questions .............................................................................................................................................. 245
Table 44 – Activity Model Details .................................................................................................................................................................................... 248
Table 45 – Elements of a Rich Picture.............................................................................................................................................................................. 250
Table 46 – Rapid Solution Design Core and Extended Design Elements................................................................................................................... 260
Table 47 – Sample Process and Function Breakdown – Buy a Product or Service ................................................................................................... 264
Table 48 – List of System Interactions ............................................................................................................................................................................. 267
Table 49 – Actor System Interactions .............................................................................................................................................................................. 268
Table 50 – Actor Actor Interactions................................................................................................................................................................................. 269
Table 51 – Data Exchanges Between Systems ................................................................................................................................................................. 272
Table 52 – Mapping TOGAF Architecture Development Method (ADM) Steps to Solution Design................................................................... 281
Table 53 – Business and Process View Information Structure .................................................................................................................................... 285
Table 54 – Adapting TOGAF Business Phase to the Business and Process View ..................................................................................................... 287
Table 55 – Functional View Information Structure....................................................................................................................................................... 288
Table 56 – Adapting TOGAF Business Phase to the Functional View ....................................................................................................................... 291
Table 57 – Data View Information Structure ................................................................................................................................................................. 292
Table 58 – Adapting TOGAF Business Phase to the Data View .................................................................................................................................. 295
Table 59 – Technical View Information Structure ........................................................................................................................................................ 297
Table 60 – Adapting TOGAF Business Phase to the Technical View ......................................................................................................................... 300

Page 7 of 540
 Introduction to Solution Architecture

Table 61 – Implementation View Information Structure............................................................................................................................................. 302

Table 62 – Adapting TOGAF Business Phase to the Implementation View ............................................................................................................. 304
Table 63 – Management and Operations View Information Structure ..................................................................................................................... 307
Table 64 – Adapting TOGAF Business Phase to the Management and Operations View ...................................................................................... 311
Table 65 – Data Management Book of Knowledge (DMBOK) Subject Areas .......................................................................................................... 324
Table 66 – Solution Design Data Completeness Checks .............................................................................................................................................. 325
Table 67 – Data Management Book of Knowledge (DMBOK) Subject Areas Solution Design Considerations ................................................. 326
Table 68 – Components of Conceptual Solution Design Data Landscape ................................................................................................................ 332
Table 69 – Solution Data Landscape Component Linkages ......................................................................................................................................... 334
Table 70 – Data Integration Patterns ............................................................................................................................................................................... 346
Table 71 – Sample Extended Integration Specifications ............................................................................................................................................... 348
Table 72 – Examples of Personal Data............................................................................................................................................................................. 366
Table 73 – GDPR Processes and Their Impact on Solution Design ........................................................................................................................... 369
Table 74 – Personal Data Metadata.................................................................................................................................................................................. 369
Table 75 – ISO/IEC 25010 Quality Model Applied to Solution Design Reviews ...................................................................................................... 386
Table 76 – Sample Solution Component Type List ....................................................................................................................................................... 389
Table 77 – Fallacies of Distributed Computing Applied to Digital Solutions ........................................................................................................... 396
Table 78 – Linkages Between Components of Digital Target Architecture............................................................................................................... 404
Table 79 – Level 2 Elements of Level 1 Component Group External Party Interaction Zones, Channels and Facilities ................................... 405
Table 80 – Level 2 Elements of Level 1 Component Group Security, Identity, Access and Profile Management ............................................... 406
Table 81 – Level 2 Elements of Level 1 Component Group Digital Specific Applications and Tools ................................................................... 408
Table 82 – Level 2 Elements of Level 1 Component Group Responsive Infrastructure .......................................................................................... 409
Table 83 – Level 2 Elements of Level 1 Component Internal Interaction Management ......................................................................................... 409
Table 84 – Level 2 Elements of Level 1 Component Integration ................................................................................................................................. 410
Table 85 – Level 2 Elements of Level 1 Component Operational and Business Systems ........................................................................................ 411
Table 86 – Level 2 Elements of Level 1 Component Applications Delivery and Management Tools and Frameworks .................................... 413
Table 87 – Level 2 Elements of Level 1 Component System Development, Deployment and Management ....................................................... 415
Table 88 – Digital Solution Common Characteristics .................................................................................................................................................. 420
Table 89 – Pillars of Generalised Approach to Agile Iterative Solution Delivery ..................................................................................................... 427
Table 90 – Solutions and Projects When to Use Agile .................................................................................................................................................. 429
Table 91 – Key Principles of Iterative Agile Approach ................................................................................................................................................. 431
Table 92 – Agile Solution Delivery Pillar Two - Control Components of Agile Process ........................................................................................ 434
Table 93 – Agile Solution Delivery Pillar Three - Agile Tools and Techniques ........................................................................................................ 435
Table 94 – Activities During Initiation/Transition and Service Delivery Phases ..................................................................................................... 459
Table 95 – Ongoing Phase Governance Focussed Activities........................................................................................................................................ 463
Table 96 – Ongoing Phase Competency and Change Focussed Activities ................................................................................................................ 465
Table 97 – Ongoing Phase Operations Focussed Activities ......................................................................................................................................... 466
Table 98 – Service Organisation Controls....................................................................................................................................................................... 471
Table 99 – Solution Architect Technical Skills ............................................................................................................................................................... 476
Table 100 – Solution Architect Analytical Thinking and Resolution Identification Skills...................................................................................... 478
Table 101 – Solution Architect Behavioural Characteristics ........................................................................................................................................ 480
Table 102 – Solution Architect Business Knowledge .................................................................................................................................................... 483
Table 103 – Solution Architect Collaboration Skills ..................................................................................................................................................... 485
Table 104 – Solution Architect Communication Skills ................................................................................................................................................. 486
Table 105 – Solution Architect Tools and Techniques Skills ....................................................................................................................................... 487
Table 106 – Applying the Business Function Domain Model to the Solution Architecture Function.................................................................. 491
Table 107 – SACOE Functions ......................................................................................................................................................................................... 494
Table 108 – Possible Solution Architecture Maturity Model ....................................................................................................................................... 496
Table 109 – Knowledge Type and Application Classification ..................................................................................................................................... 497
Table 110 – Knowledge Types Applied to Solution Architecture ............................................................................................................................... 498
Table 111 – Skills Framework for the Information Age (SFIA) Skill Level and Attribute Matrix ......................................................................... 499
Table 112 – SFIA Skills Categories and Individual Skills ............................................................................................................................................. 501
Table 113 – SFIA Skill Levels 4 to 6 Specification for Solution Architecture ............................................................................................................ 502
Table 114 – SFIA Skill Attributes for Solution Architecture Skill Level 4.................................................................................................................. 503
Table 115 – SFIA Skill Attributes for Solution Architecture Skill Level 5.................................................................................................................. 504
Table 116 – SFIA Skill Attributes for Solution Architecture Skill Level 6.................................................................................................................. 504
Table 117 – Partial List of Solution Architecture Description Languages ................................................................................................................. 516
Table 118 – Archimate Layers........................................................................................................................................................................................... 520
Table 119 – Archimate Strategy Layer Elements ........................................................................................................................................................... 521
Table 120 – Archimate Business Layer Elements........................................................................................................................................................... 522
Table 121 – Archimate Application Layer Elements ..................................................................................................................................................... 523
Table 122 – Archimate Technology Layer Elements ..................................................................................................................................................... 525

Page 8 of 540
 Introduction to Solution Architecture

Table 123 – Archimate Physical Layer Elements............................................................................................................................................................ 525

Table 124 – Archimate Motivation Aspect Elements .................................................................................................................................................... 526
Table 125 – Enterprise Architecture Frameworks and Languages .............................................................................................................................. 533
Table 126 – Areas To Look For Innovation .................................................................................................................................................................... 539

Page 9 of 540
 Introduction to Solution Architecture

List of Figures

Figure 1 – Solution Architecture Focus of the Book ....................................................................................................................................................... 18

Figure 2 – Summary Structure of this Book ..................................................................................................................................................................... 20
Figure 3 – Overlapping Solution Architecture Capabilities and Areas of Solution Involvement and Knowledge ................................................ 26
Figure 4 – High Level Context of Solution Design .......................................................................................................................................................... 28
Figure 5 – Vitruvius’ Architecture Principles ................................................................................................................................................................... 29
Figure 6 – High-Level Logical Mainframe IT Architecture ........................................................................................................................................... 31
Figure 7 – Scope of Complete Solution ............................................................................................................................................................................. 36
Figure 8 – Scope of Partial and Incomplete Solution ...................................................................................................................................................... 37
Figure 9 – Solution Delivery Externalities ........................................................................................................................................................................ 38
Figure 10 – Omission of Components from Solution Design Scope ............................................................................................................................ 38
Figure 11 – Convergence of Solution Components to Create Complete Operational Solution ............................................................................... 39
Figure 12 – Staged Delivery of Solution Components .................................................................................................................................................... 39
Figure 13 – Organisation Core Change Domains ............................................................................................................................................................ 40
Figure 14 – Extended Organisation Change Domain ..................................................................................................................................................... 41
Figure 15 – Solution Components Mapped to Organisation Change Domains ......................................................................................................... 41
Figure 16 – Solution Component Levels ........................................................................................................................................................................... 43
Figure 17 – Sample Level 1 to Level 4 Solution Breakdown ........................................................................................................................................... 44
Figure 18 – Solution Components Contributing to Solution Delivery and Operation Costs ................................................................................... 45
Figure 19 – Total Solution Lifetime Costs......................................................................................................................................................................... 45
Figure 20 – Solution Acquisition and Lifetime Operating Costs .................................................................................................................................. 46
Figure 21 – Sample Solution Lifetime Cumulative Cost Profile .................................................................................................................................... 46
Figure 22 – Sources of Good and Poor Solution Delivery Estimates ............................................................................................................................ 47
Figure 23 – Solution Design Boundaries ........................................................................................................................................................................... 48
Figure 24 – Solution Design Constraints .......................................................................................................................................................................... 49
Figure 25 – Solution Delivery Journey .............................................................................................................................................................................. 50
Figure 26 – IT Function as a Lens Focussing Business Needs On To Solutions ......................................................................................................... 51
Figure 27 – Multiple Partially Overlapping Solution Delivery Journeys...................................................................................................................... 52
Figure 28 – Overall Solution Delivery Journey ................................................................................................................................................................ 54
Figure 29 – Solution Delivery Failure ................................................................................................................................................................................ 54
Figure 30 – Information Loss Due to Multiple Handoffs During Solution Delivery ................................................................................................. 55
Figure 31 – Siloed Operation of Solution Delivery Disciplines ..................................................................................................................................... 55
Figure 32 – Goal of Solution Delivery – the Right Solution Implemented Successfully ............................................................................................ 58
Figure 33 – Right Solution Delivered Successfully is in the Minority of all Solution Delivery Outcomes ............................................................. 58
Figure 34 – Field of Solution Delivery Project Success and Failure .............................................................................................................................. 60
Figure 35 – Operational Solution Deficit – Degrees of Less for More .......................................................................................................................... 61
Figure 36 – Standish Group CHAOS Report Project Outcome Results 1994-2015 ................................................................................................... 62
Figure 37 – Factors Affecting Good Solution Delivery Decisions ................................................................................................................................. 68
Figure 38 – Characteristics of Groupthink ....................................................................................................................................................................... 70
Figure 39 – Scale and Complexity of Product Changes and Enhancements ............................................................................................................... 73
Figure 40 – IT Architecture Disciplines ............................................................................................................................................................................ 75
Figure 41 – IT Architecture Two-Way Contribution to the Business .......................................................................................................................... 76
Figure 42 – IT Architecture Discipline Involvement Throughout Solution Portfolio Delivery ............................................................................... 77
Figure 43 – Interactions Between IT Architecture Disciplines ...................................................................................................................................... 77
Figure 44 – Solution Architecture – Bringing It All Together ....................................................................................................................................... 78
Figure 45 – Siloed Operation of Information Architecture Disciplines ....................................................................................................................... 79
Figure 46 – Nesting of Siloed Operations Within Solution Delivery and Within IT Architecture Disciplines ..................................................... 80
Figure 47 – Balance Between Run the Business and Change the Business Activities................................................................................................. 81
Figure 48 – IT Architecture Principles .............................................................................................................................................................................. 82
Figure 49 – IT Architecture Failings .................................................................................................................................................................................. 83
Figure 50 – IT and Business Relationship Failings .......................................................................................................................................................... 85
Figure 51 – Consequences of Failing Business and IT Relationship ............................................................................................................................. 85
Figure 52 – Growth of Shadow IT ...................................................................................................................................................................................... 86
Figure 53 – Solution Design in an Outline Organisation Framework .......................................................................................................................... 92
Figure 54 – Organisation Context of Solution Architecture .......................................................................................................................................... 93
Figure 55 – Interrelated Strategies – Business Strategy, Overall Organisation IT Strategy and Internal IT Function Strategy .......................... 95
Figure 56 – Problem and Solution Knowledge in the Solution Design Process .......................................................................................................... 96
Figure 57 – Problem and Solution Knowledge and Solution Design Complexity ...................................................................................................... 96
Figure 58 – Problem and Solution Knowledge and Solution Design Options ............................................................................................................ 97
Figure 59 – Options for Problems and Solution Knowledge Options .......................................................................................................................... 98
Figure 60 – Problem and Solution Knowns and Unknowns .......................................................................................................................................... 98

Page 10 of 540
 Introduction to Solution Architecture

Figure 61 – Maximising the Solution Knowns and Minimising the Unknowns ......................................................................................................... 99
Figure 62 – Solution Option Definition Steps .................................................................................................................................................................. 99
Figure 63 – Solution Design Complexity Heatmap ....................................................................................................................................................... 100
Figure 64 – The Waterbed Analogy of Necessary Solution Complexity .................................................................................................................... 102
Figure 65 – Accumulating Solution Complexity ............................................................................................................................................................ 103
Figure 66 – Simple and Complex Problems and Solutions........................................................................................................................................... 103
Figure 67 – Solution Complexity and Time to Deliver ................................................................................................................................................. 104
Figure 68 – Non-Linear Nature of Solution Delivery Complexity .............................................................................................................................. 107
Figure 69 – Adjusted Complexity Curve ......................................................................................................................................................................... 107
Figure 70 – Sample Solution Complexity Score on Solution Complexity Curve ...................................................................................................... 110
Figure 71 – Sample Solution Complexity Dashboard.................................................................................................................................................... 111
Figure 72 – Solution Complexity Dashboard With Not Applicable Complexity Factors ........................................................................................ 112
Figure 73 – Iterated Solution Delivery Phases ................................................................................................................................................................ 113
Figure 74 – Expanded Set of Solution Delivery Steps .................................................................................................................................................... 114
Figure 75 – Solution Delivery Process with Solution Delivery Phase and Role Dimensions .................................................................................. 115
Figure 76 – Progress of Solution Delivery Through Phases and Roles ....................................................................................................................... 123
Figure 77 – Foundational Solution Delivery Activities ................................................................................................................................................. 124
Figure 78 – Sparse Business Stakeholder Requirements and the Complete Set of Solution Requirements .......................................................... 127
Figure 79 – Mapping the Requirements Space to the Solution Space ......................................................................................................................... 129
Figure 80 – Wider Requirements Engineering Landscape ........................................................................................................................................... 130
Figure 81 – Hierarchy of Information Technology, Business Processes and Value Achieved ................................................................................ 135
Figure 82 – Lessons Learned from Large Solutions Implementations ........................................................................................................................ 137
Figure 83 – Process Optimisation Through Compression of Steps and Collapse of Handoffs............................................................................... 138
Figure 84 – Generic Representation of a Process ........................................................................................................................................................... 140
Figure 85 – Process Decomposition ................................................................................................................................................................................. 141
Figure 86 – Process Decomposition Example................................................................................................................................................................. 141
Figure 87 – Identification of Fundamental Business Process Activity Sets ................................................................................................................ 142
Figure 88 – Activity Linkage within Processes ............................................................................................................................................................... 143
Figure 89 – Process Inputs, Rules, Actions, Decisions and Results ............................................................................................................................. 143
Figure 90 – Process Groups ............................................................................................................................................................................................... 144
Figure 91 – Business Process Analysis High-Level Steps .............................................................................................................................................. 146
Figure 92 – Process Analysis Information Structure ..................................................................................................................................................... 147
Figure 93 – Business Process Design Success Factors ................................................................................................................................................... 148
Figure 94 – Business Process Design Standards and Approaches – Part 1 ................................................................................................................ 150
Figure 95 – Business Process Design Standards and Approaches – Part 2 ................................................................................................................ 150
Figure 96 – BPMN Pools and Lanes ................................................................................................................................................................................. 152
Figure 97 – BPMN Structure ............................................................................................................................................................................................. 152
Figure 98 – BPMN Flow Objects ...................................................................................................................................................................................... 153
Figure 99 – Modifying BPMN ........................................................................................................................................................................................... 154
Figure 100 – BPMN Event Modification ......................................................................................................................................................................... 156
Figure 101 – Solution Architecture Engagement Models ............................................................................................................................................. 159
Figure 102 – Mapping Business Need to Engagement Types....................................................................................................................................... 160
Figure 103 – Generalised Business Engagement Structure........................................................................................................................................... 161
Figure 104 – Creating Customised Set of Activities, Roles and Deliverables............................................................................................................. 162
Figure 105 – Possible Factors Driving the Need for a Business Engagement ............................................................................................................ 163
Figure 106 – Business Engagement Change Domains .................................................................................................................................................. 164
Figure 107 – Architecture Engagement Extended Factors ........................................................................................................................................... 165
Figure 108 – Core and Extended Engagement Teams................................................................................................................................................... 166
Figure 109 – Business Engagement High Level Activities and Their Logical Sequence .......................................................................................... 167
Figure 110 – Business Engagement Activity Sequencing .............................................................................................................................................. 168
Figure 111 – Steps Within Business Engagement Activity 0. Define And Agree Engagement Scope ................................................................... 169
Figure 112 – Sample Table of Contents for Architecture Engagement Main Deliverable ....................................................................................... 174
Figure 113 – Steps Within Business Engagement Activity 1. Information Collection And Assessment .............................................................. 175
Figure 114 – What Customers Want ............................................................................................................................................................................... 178
Figure 115 – Data Relationship Diagram ........................................................................................................................................................................ 180
Figure 116 – Business Solution Classification ................................................................................................................................................................ 182
Figure 117 – Steps Within Business Engagement Activity 2. Define Vision, Business Principles And System Principles ................................ 183
Figure 118 – Business Model Canvass ............................................................................................................................................................................. 186
Figure 119 – Principles, Limitations and Assumptions Across Core Business Domains. ....................................................................................... 188
Figure 120 – Steps Within Business Engagement Activity 3. Document Business Processes, Entity Model, Capacity Planning And Solution
Approach .............................................................................................................................................................................................................................. 191
Figure 121 – Right-to-Left BPI and Left-to-Right BPR ................................................................................................................................................. 192

Page 11 of 540
 Introduction to Solution Architecture

Figure 122 – Process Decomposition............................................................................................................................................................................... 193

Figure 123 – Doing and Managing Processes ................................................................................................................................................................. 194
Figure 124 – Process Attributes ........................................................................................................................................................................................ 194
Figure 125 – Extended Process Definition ...................................................................................................................................................................... 196
Figure 126 – Sample Entity Relationship Diagram for Conceptual Model ............................................................................................................... 197
Figure 127 – Sample Resource Entity Model .................................................................................................................................................................. 199
Figure 128 – Sample Capacity Planning Model View ................................................................................................................................................... 199
Figure 129 – Spectrum of Solution Component Acquisition Options ....................................................................................................................... 200
Figure 130 – Combinations of Options ........................................................................................................................................................................... 200
Figure 131 – Cost Estimation Process ............................................................................................................................................................................. 202
Figure 132 – Steps Within Business Engagement Activity 4. Document Systems, Applications And Functions ............................................... 205
Figure 133 – Inventory of Interfaces, Exchanges and Transfers .................................................................................................................................. 206
Figure 134 – Steps Within Business Engagement Activity 5. Define Organisation, Infrastructure And Data..................................................... 208
Figure 135 – Steps Within Business Engagement Activity 6. Conduct Solution And Product Evaluation And Selection ................................ 213
Figure 136 – Approaches To Product and Service Evaluation And Selection ........................................................................................................... 214
Figure 137 – Core Elements of the Product and Service Evaluation And Selection Process .................................................................................. 215
Figure 138 – High Level Steps of Product/Service Evaluation And Selection Process ............................................................................................. 216
Figure 139 – Steps Within Business Engagement Activity 7. Design Model Architecture ..................................................................................... 221
Figure 140 – Options for Existing Technical Infrastructure ........................................................................................................................................ 223
Figure 141 – Dimensions of Verification of Target Architecture................................................................................................................................ 224
Figure 142 – Steps Within Business Engagement Activity 8. Consolidate, Finalise And Review Design ............................................................. 225
Figure 143 – Generalised Solution Design Process........................................................................................................................................................ 226
Figure 144 – Generalised Solution Design Process Mapped to Engagement Types................................................................................................. 227
Figure 145 – Function Involvement During Solution Design ..................................................................................................................................... 229
Figure 146 – Decision Points Within the Solution Design Process ............................................................................................................................ 230
Figure 147 – Solution Design Work Not Proceed With During the Design Process ............................................................................................... 231
Figure 148 – Iterations During Solution Design Process.............................................................................................................................................. 232
Figure 149 – Representation of Complete Generalised Solution Design Process ..................................................................................................... 232
Figure 150 – Analysis and Decision Loops ..................................................................................................................................................................... 233
Figure 151 – Analysis Paralysis And Decision Avoidance ........................................................................................................................................... 233
Figure 152 – Solution Design Journey and Solution Architecture Engagement Types ........................................................................................... 234
Figure 153 – Path from Problematic Situation to Solution .......................................................................................................................................... 236
Figure 154 – Getting the Scope of the Early Engagement Right .................................................................................................................................. 238
Figure 155 – Resolution Needs To Be Bridge From the As-Is Problematic Situation to a To-Be Improved Situation ...................................... 239
Figure 156 – Core Early Engagement Process ................................................................................................................................................................ 240
Figure 157 – Problem and Resolution Options .............................................................................................................................................................. 241
Figure 158 – Early Engagement Information Gathering Aspects ............................................................................................................................... 242
Figure 159 – Activity Model Layers ................................................................................................................................................................................. 247
Figure 160 – Layers of Detail in Activity Models ........................................................................................................................................................... 248
Figure 161 – Different Activity Views by Different Engagement Business Participants ......................................................................................... 249
Figure 162 – Sample Rich Picture .................................................................................................................................................................................... 251
Figure 163 – Resolutions and Their Paths to Implementation .................................................................................................................................... 253
Figure 164 – Dimensions of Internal Organisation Change ........................................................................................................................................ 254
Figure 165 – Different Profiles of Organisation Changes for Different Resolution Options .................................................................................. 255
Figure 166 – Solution Value Equation ............................................................................................................................................................................. 256
Figure 167 – Resolution Success Factors ......................................................................................................................................................................... 256
Figure 168 – Superset Of Constraints Sets Will Narrow Range Of Available, Realistic And Achievable Resolution Options.......................... 257
Figure 169 – Moving From The As-Is To The Target To-Be Situation...................................................................................................................... 257
Figure 170 – Attrition from Initial Business Concept to Operational Solution ........................................................................................................ 258
Figure 171 – Decision Making During the Solution Design Journey ......................................................................................................................... 258
Figure 172 – Step 1 – Define Existing and New Business Processes ........................................................................................................................... 261
Figure 173 – Step 2 – Define New and Existing Functions .......................................................................................................................................... 262
Figure 174 – Sample Process and Function Breakdown – Buy a Product or Service ............................................................................................... 263
Figure 175 – Step 3 – Define New and Existing Actors ................................................................................................................................................ 264
Figure 176 – Step 4 – Existing or New Systems and Applications .............................................................................................................................. 265
Figure 177 – Examples of Levels of Detail of System Components ............................................................................................................................ 266
Figure 178 – Step 5 – List Interfaces and Data Exchanges Between System Components ...................................................................................... 267
Figure 179 – Step 6 – Identify Actor System Interactions ............................................................................................................................................ 268
Figure 180 – Step 7 – Identify Actor Actor Interactions ............................................................................................................................................... 269
Figure 181 – Basic Solution on a Page ............................................................................................................................................................................. 270
Figure 182 – Step 8 – List Data Impacts .......................................................................................................................................................................... 271
Figure 183 – Step 9 – Data Exchanges Required Between Systems............................................................................................................................. 272

Page 12 of 540
 Introduction to Solution Architecture

Figure 184 – Step 10 – Solution Usage Journeys ............................................................................................................................................................ 273

Figure 185 – Sample Solution Usage Journey ................................................................................................................................................................. 273
Figure 186 – Sample Solution Usage Journey Mapped to Business Processes........................................................................................................... 274
Figure 187 – Sample Solution Usage Journey with Exceptions.................................................................................................................................... 275
Figure 188 – Combined Rapid Solution Architecture Scoping Views ........................................................................................................................ 276
Figure 189 – Core and Extended Solution Views ........................................................................................................................................................... 277
Figure 190 – Core Solution Views Contents ................................................................................................................................................................... 277
Figure 191 – Extended Solution Views Contents ........................................................................................................................................................... 278
Figure 192 – High-Level Structure of Information Collected from Views................................................................................................................. 278
Figure 193 – Combined Core and Extended Solution Views ....................................................................................................................................... 279
Figure 194 – Structured Solution Design Approach and TOGAF .............................................................................................................................. 280
Figure 195 – Mapping TOGAF Architecture Development Method (ADM) Phases to Solution Design Views................................................. 280
Figure 196 – Business and Process View Information Structure ................................................................................................................................. 282
Figure 197 – Functional View Information Structure ................................................................................................................................................... 287
Figure 198 – Data View Information Structure.............................................................................................................................................................. 291
Figure 199 – Technical View Information Structure ..................................................................................................................................................... 296
Figure 200 – Implementation View Information Structure ......................................................................................................................................... 300
Figure 201 – Management and Operations View Information Structure .................................................................................................................. 305
Figure 202 – Information Technology Service Management Framework ................................................................................................................. 308
Figure 203 – End to End View of Solution Usability ..................................................................................................................................................... 311
Figure 204 – Solution Design and Usability Gulfs ......................................................................................................................................................... 313
Figure 205 – Gulf Between Corporate and Social Media and Other Consumer Applications................................................................................ 313
Figure 206 – Solution Usability Pyramid......................................................................................................................................................................... 314
Figure 207 – Dimensions of Solution Usability .............................................................................................................................................................. 315
Figure 208 – Solution Business Processes........................................................................................................................................................................ 316
Figure 209 – Wider Context of Solution Usability......................................................................................................................................................... 317
Figure 210 – IT Architecture Context of Solution Usability ........................................................................................................................................ 318
Figure 211 – Solutions and Customer Experiences of the Organisation .................................................................................................................... 318
Figure 212 – Design, Usability and Experience .............................................................................................................................................................. 319
Figure 213 – COBIT, TOGAF and DMBOK Data Management Frameworks ......................................................................................................... 322
Figure 214 – Data Management Scope of DMBOK, TOGAF and COBIT Frameworks ......................................................................................... 322
Figure 215 – Data Management Book of Knowledge (DMBOK) Subject Areas ....................................................................................................... 323
Figure 216 – Using the DMBOK Framework to Ensure the Data Completeness of the Solution Design............................................................. 324
Figure 217 – Conceptual Solution Design Data Landscape.......................................................................................................................................... 327
Figure 218 – Data Landscape and Data Related Actions .............................................................................................................................................. 335
Figure 219 – Data Landscape Components Used by Sample Solution ....................................................................................................................... 336
Figure 220 – Generalised Data Lifecycle.......................................................................................................................................................................... 337
Figure 221 – Data Asset Lifecycle for Different Data Types ......................................................................................................................................... 339
Figure 222 – Data Assets for Different Solution Components Across........................................................................................................................ 339
Figure 223 – Data Integration – Possible Scope of Data Migration ............................................................................................................................ 340
Figure 224 – Data Integration – Data Aggregation........................................................................................................................................................ 341
Figure 225 – Data Integration – Data Transfers and Exchanges ................................................................................................................................. 342
Figure 226 – Data Integration – Data Synchronisation ................................................................................................................................................ 343
Figure 227 – Sample Data Integrations............................................................................................................................................................................ 346
Figure 228 – Data Integration With Integration Layer Transformation .................................................................................................................... 349
Figure 229 – Data Integration with Transformation at Target .................................................................................................................................... 349
Figure 230 – Data Integration with Preservation of the Original Data Format Content ......................................................................................... 350
Figure 231 – Solution Domains Impacted by Security Controls ................................................................................................................................. 355
Figure 232 – Security Controls Spanning Solution Domains....................................................................................................................................... 356
Figure 233 – Security Control Checks for Solution User Access ................................................................................................................................. 360
Figure 234 – Security Control Checks for Data Exchange, Transfer or Integration................................................................................................. 361
Figure 235 – Security Control Checks for Cloud or Hosted Application Assess ...................................................................................................... 362
Figure 236 – Consolidated/Federated Personal Data .................................................................................................................................................... 370
Figure 237 – Data Encryption and Decryption Using Public and Private Keys ........................................................................................................ 372
Figure 238 – Reading and Writing Data Using Single Public/Private Key Pair ........................................................................................................ 372
Figure 239 – Reading and Writing Data Using Two Key Pairs.................................................................................................................................... 373
Figure 240 – Granular Data Encryption .......................................................................................................................................................................... 373
Figure 241 – Granular Data Decryption .......................................................................................................................................................................... 374
Figure 242 – Relationship Between Data Privacy and Data Security Compliance and Verification Standards ................................................... 377
Figure 243 – Solution Potential Benefits ......................................................................................................................................................................... 382
Figure 244 – ISO/IEC 25010 Quality Model ................................................................................................................................................................... 384
Figure 245 – Sample Solution Components and Their Delivery Scheduling............................................................................................................. 389

Page 13 of 540
 Introduction to Solution Architecture

Figure 246 – Granular Solution Delivery Estimate Structure ...................................................................................................................................... 390

Figure 247 – Digital Buzzword Bingo .............................................................................................................................................................................. 392
Figure 248 – Organisation Transformation Journey ..................................................................................................................................................... 393
Figure 249 – Digital Transformation Iceberg ................................................................................................................................................................. 393
Figure 250 – The Digital Elephant in the Room ............................................................................................................................................................ 395
Figure 251 – Organisation Context of Digital Strategy and Digital Architecture ..................................................................................................... 397
Figure 252 – Digital Strategy And Business Processes – Extending The Organisation’s Boundaries ................................................................... 397
Figure 253 – User Expectations of Response With Digital Platforms ........................................................................................................................ 398
Figure 254 – Digital Solution Consumer Expectations ................................................................................................................................................. 398
Figure 255 – Digital Platform Level 1 Component Groups ......................................................................................................................................... 400
Figure 256 – Digital Platform Component Groups Constituent Items ...................................................................................................................... 402
Figure 257 – Linkages Between Components of Digital Target Architecture ........................................................................................................... 403
Figure 258 – Level 2 Elements of Level 1 Component Group External Party Interaction Zones, Channels and Facilities................................ 404
Figure 259 – Level 2 Elements of Level 1 Component Group Security, Identity, Access and Profile Management ........................................... 406
Figure 260 – Level 2 Elements of Level 1 Component Group Digital Specific Applications and Tools................................................................ 407
Figure 261 – Level 2 Elements of Level 1 Component Group Responsive Infrastructure ....................................................................................... 408
Figure 262 – Level 2 Elements of Level 1 Component Internal Interaction Management ...................................................................................... 409
Figure 263 – Level 2 Elements of Level 1 Component Integration ............................................................................................................................. 410
Figure 264 – Level 2 Elements of Level 1 Component Operational and Business Systems ..................................................................................... 411
Figure 265 – Level 2 Elements of Level 1 Component Applications Delivery and Management Tools and Frameworks ................................. 412
Figure 266 – Level 2 Elements of Level 1 Component System Development, Deployment and Management.................................................... 414
Figure 267 – Solution Architecture and Digital Architecture – Key Solution Design Process Characteristics.................................................... 415
Figure 268 – Access, Application and Data Integration Triad..................................................................................................................................... 416
Figure 269 – Wider Integration Across Solution Designs and Other Architecture Teams ..................................................................................... 417
Figure 270 – Business Solutions of Digital Framework ................................................................................................................................................ 418
Figure 271 – Digital Solution Common Characteristics ............................................................................................................................................... 419
Figure 272 – Solution Architecture Interfaces to Other IT Architecture Functions ................................................................................................ 420
Figure 273 – Solution Delivery Phases, Activities and Solution Components .......................................................................................................... 423
Figure 274 – Classification of Projects and Their Suitability for an Agile Delivery Approach............................................................................... 425
Figure 275 – Pillars of Generalised Approach to Agile Iterative Solution Delivery ................................................................................................. 426
Figure 276 – Using Agile Delivery Approach Effectively ............................................................................................................................................. 428
Figure 277 – Agile Delivery Phases and Their Interactions ......................................................................................................................................... 436
Figure 278 – Iterated Phases Within Agile Solution Delivery...................................................................................................................................... 437
Figure 279 – Increments Delivered Within Agile Delivery Process Iterated Phases ................................................................................................ 437
Figure 280 – Agile Solution Delivery Phase 4 - Functional Model Iteration Phase.................................................................................................. 441
Figure 281 – Iterations During Functional Model Iteration Phase ............................................................................................................................. 442
Figure 282 – Agile Solution Delivery Phase 5 - Design and Build Iteration Phase................................................................................................... 443
Figure 283 – Iterations During Design and Build Iteration Phase .............................................................................................................................. 443
Figure 284 – Agile Solution Delivery Phase 6 - Implementation Phase ..................................................................................................................... 444
Figure 285 – Iterations During Implementation Phase ................................................................................................................................................ 445
Figure 286 – Key Aspects of a Service .............................................................................................................................................................................. 451
Figure 287 – Sample Assessment of Service.................................................................................................................................................................... 452
Figure 288 – Sourcing Phases and Activities .................................................................................................................................................................. 453
Figure 289 – Possible Solution Architecture Activities During Initiation/Transition and Service Delivery Phases ........................................... 455
Figure 290 – Possible Solution Architecture Activities During Ongoing Service Phase ......................................................................................... 460
Figure 291 – Service Organisation Controls Structure ................................................................................................................................................. 467
Figure 292 – Solution Architect Skills, Capabilities and Experience .......................................................................................................................... 473
Figure 293 – Organisation Context of Solution Architecture ...................................................................................................................................... 488
Figure 294 – Solution Architecture – Linkages to Other Information Technology Functions .............................................................................. 489
Figure 295 – Solution Architecture Function Management ........................................................................................................................................ 491
Figure 296 – Solution Architecture Centre Of Excellence (SACOE) Functions ....................................................................................................... 493
Figure 297 – Solution Architecture Principles ............................................................................................................................................................... 494
Figure 298 – Possible Solution Architecture Maturity Model ..................................................................................................................................... 495
Figure 299 – Skills Framework for the Information Age (SFIA) Skills Categories and Individual Skills ............................................................. 499
Figure 300 – Solution Delivery Process Failings and Conway’s Law .......................................................................................................................... 506
Figure 301 – Solutions To Problems Can Be Represented As Minima On A Graph ............................................................................................... 507
Figure 302 – Solutions To Problems Can Be Represented As Minima In Graph ..................................................................................................... 507
Figure 303 – Solution Identification Where the Team Has a Narrowly Focussed Set of Skills .............................................................................. 508
Figure 304 – Solution Identification Where the Team Has a Broad Range Of Skills ............................................................................................... 508
Figure 305 – Generalised Organisation Business Process Structure ........................................................................................................................... 509
Figure 306 – Approach to Increasing Organisation Cognitive Diversity ................................................................................................................... 510
Figure 307 – Cognitive Diversity Balancing Act ............................................................................................................................................................ 511

Page 14 of 540
 Introduction to Solution Architecture

Figure 308 – Finding The Right Balance Of Cognitive Diversity ................................................................................................................................ 511
Figure 309 – SSADM Design Approach .......................................................................................................................................................................... 517
Figure 310 – Archimate Structure .................................................................................................................................................................................... 519
Figure 311 – Archimate Strategy Layer Elements .......................................................................................................................................................... 520
Figure 312 – Archimate Business Layer Elements ......................................................................................................................................................... 521
Figure 313 – Archimate Application Layer Elements.................................................................................................................................................... 522
Figure 314 – Archimate Technology Layer Elements.................................................................................................................................................... 524
Figure 315 – Archimate Physical Layer Elements .......................................................................................................................................................... 525
Figure 316 – Archimate Motivation Aspect Elements .................................................................................................................................................. 526
Figure 317 – Archimate Representation of the Solution on a Page ............................................................................................................................. 527
Figure 318 – Archimate Representation of Sample Data Integration and Exchange Options ................................................................................ 527
Figure 319 – Archimate Representation of Solution Data Landscape ........................................................................................................................ 528
Figure 320 – Innovation Formula..................................................................................................................................................................................... 534
Figure 321 – Complete Innovation Process .................................................................................................................................................................... 535
Figure 322 – Types of Innovation ..................................................................................................................................................................................... 535
Figure 323 – Innovation Value Equation ........................................................................................................................................................................ 536
Figure 324 – Being Good At Innovation Means Being Good At Change .................................................................................................................. 536
Figure 325 – Solution Architecture and Innovation ...................................................................................................................................................... 537
Figure 326 – Sample Technology Radar .......................................................................................................................................................................... 538
Figure 327 – Profile Of Investment In Innovation Across Innovation Areas............................................................................................................ 539
Figure 328 – Profile Of Return on Investment In Innovation Across Innovation Areas ........................................................................................ 539
Figure 329 – Comparison of Investment and Return on Investment In Innovation Across Innovation Areas................................................... 540

Page 15 of 540
 Introduction to Solution Architecture

Chapter 1. Introduction, Purpose and Scope

1.1 Introduction

This book describes solution architecture as a value-adding information technology consulting service. Solution architecture
is concerned with the design and definition of (information technology) solutions so they can be subsequently implemented,
used, operated and supported securely and efficiently. The solution exists to operate business processes in order to achieve
business objectives, meet a business need and deliver business value. Solution architecture is concerned with engaging with
the originating business function looking for the solution to create a solution vision and design a solution that meet their
needs, subject to a range of constraints such as cost and affordability, time to deliver and organisational standards. The
solution must exist as a coherent whole.

Solutions must be designed consistently across the solution landscape and make optimum use of appropriate technologies.

Solution architecture must focus on creating usable and useful solutions. Solution architecture must have a standard reliable
approach to business engagements and the design of solution that emerge from them.

Solution architecture must work collaboratively with other information technology functions – other architecture roles,
business analysis and service management – to ensure continuity along the solution delivery journey.

Effective solution architecture means:

• Having a depth and breadth of solution delivery and technical experience to be able to identify solution design options
quickly

• Being able to understand the detail of the solution while maintaining a view of the wider (and higher) context of the
business need for the solution and being able to explain both these views of sets of information

Page 16 of 540
 Introduction to Solution Architecture

• Being able to communicate effectively with all parties – technical and business – involved in the solution design and
delivery journey, assist with decision-making, be realistic and make appropriate compromises and design choices in
order to create the best solution design

• Being able to apply technology appropriately and with selective innovation (and the desire to constantly acquire new
knowledge and ways of applying technology)

• Being involved in the solution delivery journey along its entire length

• Being able to be the solution advocate and subject matter expert

A solution is almost never just a custom-developed software component. The complete span of a solution consists of many
components that must be designed and delivered in order to create a usable and operable solution. These solution
components can consist acquired or developed software, new and changed existing business processes, data migrations and
new data loads, organisation changes, infrastructure, service management processes, maintenance and support services, initial
period of hypercare and others.

This book has a number of themes:

• The need for solution architecture to concern itself with the full breadth and depth of the solution

• The way in which solution architecture can contribute to ensuring the success of solution delivery

• Solution architecture is or has the potential to be a value-adding information technology consulting service

• That solution architecture should be involved during the solution delivery journey

• The need for solution architecture to have skills in other information technology areas such as data architecture, security
and external solution component acquisition

• The importance for solution architecture to work closely with other information technology functions such as business
analysis, solution delivery, other information technology architecture functions and service management

• The need for solution architecture to be able to engage flexibly and in different ways with the business function where the
need for a solution originates to offer consulting and value-adding services to the business organisation

• The importance of data in solution architecture and design

• The way in which the solution architecture function can structure itself to be able to provide such value

• The need for solution architecture to be aware of and be able to respond to information technology and business trends
and changes

The purposes of this book are:

• To articulate a vision for solution architecture

• To express a complete end-to-end solution design approach, from initial idea to steady state solution operation

• To describe the process by which solution designs are created

• To describe the wider context of solution architecture and solution design within the information technology function
and the business, including how solution architecture can assist with addressing the issue of solution delivery failure

• To create an understanding of the actual scope of solutions

Page 17 of 540
 Introduction to Solution Architecture

• To describe the importance of solution architecture in the successful delivery of operable, useful, usable, maintainable
and supportable solutions

• To detail a set of solution architecture engagements where the solution architect can work with the business in a variety
of ways to create designs to resolve problems or address challenges of opportunities

• To examine specific solution architecture areas of concern such as data architecture, security or digital transformation

• To define the concept of a Solution Architecture Centre of Excellence and to describe its possible structure and operation

• To identify existing well-defined and well-proven frameworks, standards and approaches that can be successfully applied
to solution architecture

The book is not about specific technologies that are included in solutions. There are simply too many technologies to cover
across the span of an information technology solution. Those technologies are constantly changing. The way in which those
technologies are implemented and deployed is also changing. An increasing number of the application components of
solutions consists of acquired products or services rather than developed software. The span of any book on solution
architecture can be located along two dimensions: its technology and solution emphasis ranging from narrow to broad and its
engagement emphasis from an internally-focussed technical approach to a wider consulting one. This book is very definitely
located in the domain that is the combination of broad solution and consulting areas.

Figure 1 – Solution Architecture Focus of the Book

1.2 Who This Book Is Aimed At

This book is aimed at a variety of potential readers:

• Existing solution architects who want to have a more theoretical and a broader understanding of their role

Page 18 of 540
 Introduction to Solution Architecture

• Existing or new managers of solution architecture functions who want to create a high-performing practice within their
organisations and who want to articulate the benefits and value solution architect can contribute both to the information
technology function and the wider business and the potential it can offer to the business organisation

• Mangers of information technology functions who want to understand what solution architecture is, where it fits into the
wider architecture context and disciplines and solution delivery and operation and the value it can contribute to both the
information technology function and the wider business

• Other information technology architects who want to understand how the architecture disciplines can work together to
deliver value

• Business analysts and managers of business analysis functions who want to understand how they can work more closely
with the solution architecture function in order to provide the business with a better overall solution analysis, design and
delivery service

• Other information technology personnel who are interested in moving into solution architecture and who want to
understand what it is

• Consulting organisations and individuals who want to develop and offer value-adding solution architecture services

• Students who are interested in understanding the principles of solution architecture and solution design from a business-
oriented viewpoint

1.3 Terminology

In this book, solution architecture means the function and the process that creates solution designs. Solution designs are the
specification for solutions. These designs can be at various levels of detail.

The phrases solution architect and solution designer have the same meaning. This is the role that creates solution designs and
participates in business engagements that resolve problems or address challenges and opportunities.

1.4 Structure and Contents of This Book

I have numbered the chapters and sections of this book to allow them to be referred easily. While this may seem cumbersome
it makes for easy identification of and cross-referencing between sections and avoids duplication of information.

In summary the structure of this book is illustrated below.

Page 19 of 540
 Introduction to Solution Architecture

Figure 2 – Summary Structure of this Book

This structure is:

• Solution Architecture and Solution Chapter 2 on page 25 - Summarises the capabilities of solution
Design architecture and provides a context for solution design

o Evolution of Solution Section 2.3 on page 30 - Briefly provides background information to the
Architecture and Solution evolution of the solution architect role
Architect Role
o What Is a Solution Section 2.4 on page 33 - Defines what exact a complete solution consists
of, the true cost of a solution, the solution boundaries and options and
the underlying need for organisational change

o Getting the Solution Design Section 2.5 on page 50 - What is involved in getting the solution design
Right right

o The Solution Delivery Process Section 2.6 on page 50 - What is involved in delivering the solution
in Context
• Business Strategy, Architecture Strategy Chapter 3 on page 57 - Contains details on where solution architecture
and Solution Design And Delivery fits into the organisation's over strategy

o Why Solutions Fail Section 3.1 on page 57 - Describes how the delivery of solutions fail and
how solution architecture can mitigate against solution failure

Page 20 of 540
 Introduction to Solution Architecture

o Solution Architecture and Risk Section 3.2 on page 71 - Describes how solution architecture can address
Management solution delivery risks

o Architecture Disciplines, Section 3.3 on page 75 - Provides information on the interfaces and
Context and Interactions interactions between solution architecture and the other IT architecture
disciplines, defines solution architecture principles, identifies the
problems that can exist with IT architecture operation and describes how
these problems can contribute to the growth of Shadow IT

• Solution Architecture Engagement And Chapter 4 on page 91 - Details the various approaches to creating
The Solution Design Process solution designs and describes a number of engagement processes to suit
different sets of circumstances

o Problem and Solution Section 4.2 on page 95 - Describes the concepts of problems and solution
Knowledge and Complexity knowledge and the concept of necessary and unnecessary complexity

o Solution Design, Delivery and Section 4.3 on page 112 - Outlines the general approach to delivering
Operation Context solutions

o Solution Architecture Interface Section 4.4 on page 124 - Identifies the importance of the solution
With The Business Analysis architecture function working closely with the business analysis function,
Function problems with traditional requirements gathering and describes the
importance of business processes in solution design

o Solution Architecture Section 4.5 on page 158 - Discusses the need for different ways the
Engagement Process solution architecture function can engage with the business organisation
to design solutions

 Business Engagement Section 4.6.1 on page 161 - Details a business consulting service the
solution architecture function can offer in advance of any formal solution
design engagement

 Early Engagement Section 4.6.4 on page 235 - Describes a process for helping the business
organisation put a structure on an ill-defined problematic situation and
determining solution options

 Rapid Solution Design Section 4.6.5 on page 257 - Describes a process for creating a high-level
Option Engagement solution design quickly to assist with effective decision making

 Structured Solution Section 4.6.6 on page 276 - Details a formal and structured solution
Design Engagement design process

o Solution Architecture and Section 4.7 on page 311 - Discusses the importance of solution usability
Solution Experience and in the solution design process
Usability
o Data Architectural Aspects of Section 4.8 on page 321 - Details the need to include data architecture
Solution Architecture and especially data integration, transfers and interfaces in the solution
design process and defines a detailed approach to perform this work

o Security and Privacy Section 4.9 on page 352 - Discusses the need to include security and
privacy in the solution design from the start of the process

o Solution Architecture and Section 4.10 on page 377 - Outlines the various artefacts that can be
Design Artefacts produced during the various solution design engagements and processes

o Solution Assessment and Section 4.11 on page 381 - Describes the need to and a framework for

Page 21 of 540
 Introduction to Solution Architecture

Review validating a solution design

• Solution Architecture and Digital Chapter 5 on page 391 - Describes the contribution solution architecture
Transformation can make to designing solutions that achieve digital transformation

• Agile Solution Design and Delivery Chapter 6 on page 422 - Outlines an iterative and flexible approach to
solution design and delivery

• Solution Architecture and Solution Chapter 7 on page 447 - Details the approach to the procurement of
Acquisition packaged solution components

• The Solution Architecture Function Chapter 8 on page 472 - Contains information on the structure of the
solution architecture function, defines a solution architecture capability
model, introduces the concept of the Solution Architecture of Excellence
and highlights potential issues that can arise with the solution
architecture function

o Solution Architecture Skills, Section 8.2 on page 472 - Describes a set of skills that are required for a
Capabilities and Experience solution architect and defines a capability model

o Solution Architecture Function Section 8.3 on page 487 - Discusses the structure of the solution
architecture function

o Solution Architecture Tools Section 8.3.5 on page 511 - Outlines various tools and techniques that can
be used by solution architects

• Solution Architecture and Innovation Chapter 9 on page 534 - Describes how the solution architecture function
can assist the organisation with solution and technology innovation

1.5 Checklists

This book contains a lot of information in the form of tables and lists. While densely-presented material in this format may be
more difficult to read than narrative text, this information can be applied in the form of checklists. These can be used during
different stages of the business engagement and solution design processes. The following table lists some of these checklists.

Section Checklist Description

Section 2.4.2 on page 33 Scope of Complete Solution List of component types of solution
Section 3.1 on page 57 Challenge Reasons List of reasons why solution delivery projects are
challenged
Success Factors List of factors that lead to successful solution
delivery
Section 3.2 on page 71 Solution Risk Factors List of risks associated with solution design
Section 3.3.3 on page 81 IT Architecture Principles List of principles underpinning solution
architecture
Section 3.3.4 on page 83 Problems with IT Architecture Operation List of problems that can occur with the
operation of IT architecture functions
Section 4.2.2 on page 100 Complexity Factors List of factors that affect solution complexity
and method for assessing the complexity of a
solution
Section 4.3 on page 112 Solution Delivery Stages List of stages involved in the delivery of a
solution
Solution Delivery Artefacts List of artefacts that can be created during the
delivery of a solution

Page 22 of 540
 Introduction to Solution Architecture

Section 4.4.2 Lessons Learned from System List of lessons learned when implementing large
Implementation systems
Causes Of Waste Causes of waste in business process design and
operation
Business Process Design Success Factors List of factors that lead to successful business
process design
Business Process Design Standards and List of standards to use when designing business
Approaches processes
Section 4.6.1.1 Factors Driving the Need for a Business List of reasons that give rise to the need for a
Engagement solution architecture engagement with the
business
Architecture Engagement Extended List of factors that govern the scope of the
Factors solution architecture engagement with the
business
Section 4.6.1.3 on page 167 Business Engagement High Level List of stages in the solution architecture
Activities engagement with the business
Section 4.6.1.6.1 on page Business Vision Factors List of factors to be considered when developing
183 the initial business vision
Section 4.6.1.6.3 on page Business Domain Principles List of current and target application and
188 system, business process, organisation and
structure and locations and offices principles
Section 4.6.1.7.4 on page Cost Estimation Process List of steps involved in creating a solution cost
199 estimate
Section 4.6.1.9.2 on page Factors Affecting Application And Data List of factors to use when analysing and
209 Organisation defining the business application and data
structures
Section 4.6.1.10.1 on page Product and Service Evaluation And List of factors to use when evaluating products
213 Selection and services
Section 4.6.1.11.1 on page Activities to Design Infrastructure Model List of steps to perform when designing the
221 Architecture business infrastructure architecture
Section 4.6.2 on page 226 Steps in Solution Design Process List of steps to following in the solution design
process
Section 4.6.4.7 on page 251 Resolution Options List of options to evaluate the available
resolution options
Solution Quality Factors List of solution quality and operational factors
Section 4.6.5 on page 257 Rapid Solution Design Steps List of steps to follow when creating an initial
high-level solution design
Section 4.6.6 on page 276 Solution Design Activities Across List of steps to follow and information to gather
Solution Views when creating a detailed solution design
Section 4.7 on page 311 Solution Usability Factors List of factors to consider when assessing the
usability of a solution
Solution Usability Standards List of standards and methodologies developed
for solution usability
Section 4.8.1 on page 321 Solution Data Management Framework List of data management framework
components that can be used to validate the data
aspects of a solution
Section 4.8.2 on page 326 Components in Solution Data Landscape List of possible component types and their
interactions in a solution data landscape
Section 4.8.4 on page 337 Data Lifecycle Stages Set of stages in the data lifecycle
Section 4.8.5 on page 339 Data Integration Types and Solution List of data integration option, components and
Components interactions
Section 4.9.1 on page 352 Solution Security Controls List of security controls to use the check the
security of a solution
Security Standards List of security standards and frameworks

Page 23 of 540
 Introduction to Solution Architecture

Section 4.9.2.3 on page 366 Privacy and Personal Data Related List of data privacy processes that apply to
Processes and Impact on Solution Design personal data and how they will impact solution
design
Section 4.10 on page 377 Solution Design Table of Contents Table of contents of a solution design artefact
Section 4.11.1 on page 381 Solution Benefits Review Checklist Checklist of potential solution benefits
Section 4.11.2 on page 383 Solution Design Review Checklist Checklist of design factors to be used in solution
design reviews
Section 5.3 on page 399 Digital Target Architecture Components List of components of a digital reference
architecture
Section 5.4.3 on page 418 Digital Solution Common Characteristics Set of principles to consider when designing
and Principles solutions with a digital focus
Section 6.3 on page 426 Agile Solution Design and Delivery List of solution design principles to apply when
Principles using an agile approach
Section 6.4 on page 427 Agile Approach Suitability Checklist Checklist of questions to assess if a solution is
suitable for an agile process
Key Principles of Iterative Agile Set of principles to apply when using an agile
Approach solution design and delivery approach
Section 6.5 on page 431 Control Components of Agile Process Set of controls to use when following an agile
solution design and delivery approach
Section 6.7.2 on page 438 Agile Feasibility Analysis and Study Checklists on the initial study and feasibility
Checklists plan
Section 7.1 on page 447 Solution Architecture and Solution List of standards and methodologies that can be
Acquisition Approaches applied for solution procurement
Aspects of a Solution or Service List of characteristics of a solution or service
being procured
Section 7.1.1 on page 452 Sourcing Phases and Activities Set of activities to be performed when sourcing a
solution
Section 7.1.1.1 on page 454 Solution Architecture Activities During Set of activities to be performed when
Initiation/Transition and Service transitioning to a newly acquired product or
Delivery Phases service
Section 7.1.1.2 on page 459 Solution Architecture Activities During Set of activities to be performed during the life
Ongoing Service Phase of an acquired product or service
Section 7.1.2 on page 466 Service Organisation Controls Structure Set of controls to be applied to an organisation
providing a service
Section 8.2 on page 472 Solution Architect Skills, Capabilities and Checklist of solution architecture skills and
Experience capabilities
Section 8.3.2 on page 489 Solution Architecture Function Structure Set of capabilities of a solution architecture
function
Section 8.3.3 on page 492 Solution Architecture Centre Of Set of capabilities of a solution architecture
Excellence (SACOE) Functions centre of excellence
Solution Architecture Knowledge and Checklist for assessing the skills, experience,
Skills knowledge and capabilities of solution architects
Section 8.3.5.1 on page 512 Solution Architecture Design Tools List of architecture design tools
Section 8.3.5.2 on page 528 IT Architecture Frameworks, List of architecture standards, methodologies
Methodologies and Description and design languages
Languages
Chapter 9 on page 534 Areas To Look For Innovation List of potential areas where to look for and
apply innovation

Table 1 – Solution Architecture-

Architecture-Related Checklists Contained in the Book

Page 24 of 540
 Introduction to Solution Architecture

Chapter 2. Solution Architecture and Solution Design

2.1 Introduction

Solution architecture and design is concerned with the definition and description of new (Information Technology) solution
designs to resolve problems or address opportunities through engagement with the business. The solution may or may not
include a technology component. For example, the optimum solution could involve just business process and organisation
changes.

Generally there are many potential resolutions to a problem with varying degrees of suitability and cost. All solutions are
subject to constraints. The solution constraints need to be included in the solution design process.

These resolutions can be standard solutions where the knowledge – problem knowledge and solution knowledge - required to
create the design is known and available or new and innovative where there are knowledge gaps that must be identified and
completed.

Solution architecture requires a (changing) combination of technical, leadership, interpersonal skills, experience, analysis,
appropriate creativity, reflection and intuition applied in a structured manner to derive the most suitable solution.

Solution architecture involves a number of overlapping foundational capabilities, sets of knowledge and areas of interaction
and involvement with other areas of the organisation.

Page 25 of 540
 Introduction to Solution Architecture

Figure 3 – Overlapping Solution Architecture Capabilities and Areas of Solution Involvement and Knowledge

These overlapping foundational capabilities are listed in the table below.

Solution Architecture Description

Capabilities
Business Strategy And The organisation will have an overall business strategy and underpinning objectives.
Information Technology The organisation’s information technology strategy will follow from this as a means
Strategy And Information of achieving the business strategy and objectives. The information technology
Technology Function Strategy,function will have its own internal strategy that will detail how it will structure and
Compliance With Enterprise organise itself to deliver the organisation’s overall information technology strategy.
And Other Information The solution architecture function must have an understanding of this organisation
Technology Architecture context within which solutions will operate. The information technology function
Standards will define a set of technology standards in the areas of enterprise, security, data and
service architectures that solutions must comply with. The solution architecture
function must understand these core technology standards.
Business Architecture And Solutions must be designed to operate in a business context. Solutions consist of
Solution And Problem more than just software components. There is a greater solution operational
Resolution Needs, Including environment that includes integration across a number of elements, organisation
Existing Business Systems change, data migration, service introduction, maintenance and support, training
Landscape and documentation and other areas. The solution architect must design solutions
with this larger perspective in mind.
Business Engagement
Engagement Across A The nature of the solution required by the originating and requesting business
Range Of Approaches And function can take several forms, from a standard solution specification to a
Techniques consulting engagement that refines and defines a problem to be resolved or a
challenge or opportunity to be addressed. Also, not all solutions proceed to
implementation. The solution architecture function must possess the necessary

Page 26 of 540
 Introduction to Solution Architecture

Solution Architecture Description

Capabilities
engagement skills and techniques to handle these different assignment types.
Solution Architecture Function The solution architecture function needs to have three central areas of work

1. External – making the skills and capabilities of the function known to the
wider business, handling requests from business functions for consulting and
solution design engagements, managing the progress and the quality of the
work done and any deliverables created, handling and resolving issues and
establishing and maintaining relationships. The management can also advertise
the work of the function and conduct regular showcase events where new
technologies and technical capabilities that might be of potential use are
demonstrated to the business.

2. Internal – developing and managing the team, allocating work, overseeing

quality reviews, providing assistance with business engagement, recruiting,
training and mentoring the team and managing talent and succession.

Other
Other Information Technology Functions – developing and maintaining
3.
relationships with information technology management, other architecture
functions, business analysis, solution delivery and service management.
Specific Solution Information The solution business stakeholders will provide details on some of the solution
Gathering, Requirements
Requirements requirements. The solution architect must be able to work with the business analysis
Specification And Business function define the full set of solution requirements, including operational and
Processes quality ones. The solution architect must understand the underlying existing and
new business processes that the solution aims to enable and operate.
Solution Design And The solution architect must be able to specify the design of the complete solution
Specification that includes all the areas that must be worked on to create a full operable, usable,
maintainable and supportable solution. The solution architect must have the
necessary technical skills to define the technology aspects of the solution in
sufficient detail to allow the design to be implemented.
Data, Security And Integration Data across all its dimensions of generation, transportation, processing and
retention breathes life into the solution. The solution architect must specify the
solution data landscape in sufficient detail to ensure that the solution can work and
handle the required data interactions and volumes. The solution and its data must
be secure across all its components. The solution will be required to integrate with
other components, other systems and solutions and other entities. The solution
architect must understand and describe this integration environment.
Solution Delivery And The solution architecture function must provide solution leadership and solution
Implementation Including subject matter expertise as the solution and its individual components are
Testing, Infrastructure And implemented and integrated. This includes working to define the necessary
Communications, Acquisition infrastructure and acquire the necessary external products and services.
Service Management, Transition The solution must be transitioned to production. The necessary service
To Production management processes must be put in place to allow this. The solution architecture
function must work with service management early during solution design to
ensure this work is understood and specified.
Ongoing Enhancement And After the solution is operational, it will be subject to ongoing requests for
Change enhancements and fixes. The solution architecture function can provide solution
leadership and solution subject matter expertise to assist with this.

Table 2 – Overlapping Solution Architecture Capabilities and Areas of Solution Involvement and Knowledge

Solution architecture needs to be an operational and transactional function within information technology. It needs to be
capable to doing work and achieving results and value to the organisation. It is a doing as well as a thinking function.

Page 27 of 540
 Introduction to Solution Architecture

Solutions are designed, delivered and operated on these foundational pillars. Chapter 8 on page 472 looks at the structure of
the solution architecture function and the capabilities of a solution architect in more detail needed to achieve this.

The purpose of the solution architecture deliverable – the solution design – is to enable the solution to be implemented and
operated. The design is a specification of an IT-oriented solution whose purpose is to realise a defined set of end states and
generate a set of outputs. The solution is intended to operate in a defined environment. The solution is designed to satisfy a
set of requirements and to meet a set of expectations. The solution and its design are subject to a variety of environment-
specific constraints and limitations.

The means by which the design is arrived at is not necessarily straightforward and linear. The design process may involve
different engagements with the business and business stakeholders as the problem being resolved or the challenge being
addressed is expanded on, clarified and ultimately defined to a sufficiently detailed extent that it can be passed to delivery.

Solutions are typically described and defined in the context of individual solution delivery projects. That is, solutions are
implemented individually by separate projects or as a collection of solutions implemented as a programme. The solution is
intrinsically concerned with solving one problem.

The high-level context of an individual solution design incorporates the aspects of:

• The functionality of the solution – what is how and how the functionality is to be delivered and operated, how it is
implemented and subsequently supported and maintained

• How the solution appears to users, how users access and interact with and use it

• The operating landscape of the solution in terms of the business processes, organisation structures and users (and its
external users, if relevant)

Figure 4 – High Level Context of Solution Design

However, the solution architecture practice or function within an organisation must be able to co-ordinate and manage the
creation of multiple solutions designs that work in an integrated business and information technology organisation context.
The individual solution designs create by the members of the solution architecture team must maximise the use of
organisation technical resources and comply with organisation standards. One of the key roles of the solution architecture
function and the individual solution architects is to avoid the creation of multiple point solutions with little commonality and
reuse that increase long-term information technology costs for the organisation.

Page 28 of 540
 Introduction to Solution Architecture

The theory and practice of project management is mature, well-proven and clearly defined. The benefits of project
management are understood and appreciated. The necessary costs of a project management overhead to a delivery project are
accepted. Likewise, business analysis is reasonably well-defined, though not to the same extent as project management.
Business analysts tend to be siloed into the requirements gathering phase of solution delivery. Solution architecture is as not
well-defined or understood as these other practices.

The project is the temporary engagement to get the solution operational. The solution will endure long after its delivery
project has come to an end. The solution will continue to be used and to incur ongoing costs in terms of its operation,
support and maintenance. Problems with and inefficiencies in the solution will have long-term consequences.

2.2 Solution Architecture – A Lesson From History

In Book 1, Chapter 2 of The Fundamental Principles Of Architecture 1, Vitruvius gives the core principles of architecture
as:

Architectura autem constat ex ordinatione et ex dispositione et eurythmia et symmetria et decore et

distributione.

Architecture depends on Order, Arrangement, Eurythmy, Symmetry, Propriety, and Economy.

He then expands on each of these principles to describe a more detailed framework and set of values for architectural designs.
This expansion can be described as follows:

Figure 5 – Vitruvius’ Architecture Principles

1
Ten Books on Architecture Marcus Vitruvius Pollio, http://www.gutenberg.org/files/20239/20239-h/20239-h.htm

Page 29 of 540
 Introduction to Solution Architecture

These expanded principles are:

Design of the individual building blocks that comprise the entire

Individual
design
Order Components Quantity Numbers of each of the building blocks in the entire design
Entire Design Design of the whole based on its constituent building blocks
Layers
Proper placing of components in layers
Proper placing of components and their layers in external overall
Expression External View
view
Proper placing of components and their whole in wider design
Arrangement Context
landscape context
Careful thought and attention to detail, especially of the design
Reflection
consequences
Invention Solving problems through diligence, discovery and versatility
Beauty Components fit together into a whole
Eurythmy
Fitness Components are fit for purpose
Integration Components operate and integrate with one another
Symmetry
Standards Components are standardised and in proportion to one another
Design Principles Design is constructed using agreed principles
Components are appropriate and matched to one another and to
Propriety Appropriate to Usage
overall usage and scope of the requirements
Landscape The solution is appropriate to its overall landscape and position
Resources needed to implement the design are carefully managed
Resource Management
and the design optimises resource usage
Design implementation costs are managed the design optimises
Cost Control
cost
Economy Common Sense Common sense is applied when implementing the design
Resources and facilities are reused where possible the design
Reuse
optimises reuse
The implementation approach used is appropriate to the scope of
Appropriate Approach
the design

Table 3 – Vitruvius’ Architecture Principles

These principles are just as relevant and today and applicable to the design of information technology solutions.

The overall solution must be designed in the context of its components. Each component needs to be designed within the
overall solution setting. The overall design must be described in a number of different views. The approach to creating a
design involves both the application of thought, principles and standards and the application of creativity. The components of
the design must fit and worth together. The design must be appropriate to its intended usage. Finally, the design must be
created to be implemented cost effectively, optimising resource usage and available component reuse.

These are values that can be employed today. Much of this book can be said to follow from and expand on them.

2.3 Evolution of Solution Architecture and Solution Architect Role

The role of the solution architect is one that evolved as IT architecture changed from the early 1990s onwards. It continues to
evolve in the light of the major technology deployment changes that have occurred since then: from mainframe to client
server to N-tier models to web-based models to service orientation, XaaS patterns and digital transformation.

Page 30 of 540
 Introduction to Solution Architecture

Prior to the advent of client/server architecture and subsequent N-tier, distributed, service oriented, public-facing solution
and cloud architectures and the solutions deployed on them, there was effectively only one mainframe-based IT architecture
that evolved from or were similar to IBM System/360 and System/370 hardware (and from these all the way to the current
zEnterprise systems) and the various operating systems (OS/VS1, MVS/370, VM/SP, MVS/XA, VM/XA, MVS/ESA VM/ESA
up to the current zOS operating system) that ran on this hardware and provided the core work management, data
management and communications management facilities.

Figure 6 – High-
High-Level Logical Mainframe IT Architecture

In the context of this computing model, the platform was the IT architecture. The platform was homogenous, monolithic and
centralised. The IT architecture was effectively given and unvarying. All of the IT landscape was under the control of the
central platform. There was a master/slave relationship between the mainframe and attached components. The issues
regarding the design of solutions related to implementation factors such as batch or online processing or a combination of
both in a suite of applications, choice of development language (from a limited set), use of transaction processing facility as an
application development and deployment framework, the method of data storage and the functionality to be delivered.

In parallel to the relative lack of complexity in the IT landscape, concepts such as workflow and business process management
and design were very new and seldom applied.

In this context, the core solution design role was performed by the systems analysis function that was involved in the analysis,
design and assisted with the subsequent implementation and transfer to operation of information system solutions. The
systems analyst was both business-facing, working with the business function to understand their requirements and IT-
facing, designing IT solutions and working with developers to implement them and participating in their development and
testing. The work of the systems analyst was divided into two parts: systems analysis and systems design. Systems analysis
involves gathering information on how the work targeted for the proposed solution is being performed, what problems occur
and the options for the resolution. Systems design involves design the solution to replace or complement the existing work

Page 31 of 540
 Introduction to Solution Architecture

processes. The Structured Systems Analysis and Design Methodology (SSADM) briefly described in section 8.3.5.1.1 on page
516 was typically used in systems analysis.

The move from a centralised mainframe platform to one incorporating distributed and heterogeneous system components
requiring application and data integration gave rise to the need for a solution architect role to design solutions that
incorporated multiple components across this more diverse IT topography.

The systems analyst role split into separate roles: the business analysis that performed the business facing role and the
solution architect that performed the solution design role. While the systems analyst role continues in many incarnations it
does not have the same broad spread of activities that it had in the past.

The loss of the systems analyst role as a function that worked across analysing business requirements, designing solutions to
meet those requirements and subsequently on the development and implementation of those solutions means that this broad
view is all too frequently absent from the current analysis and design processes. The platform nature of the mainframe-based
IT architecture for which solutions were designed and on which they were deployed and operated allowed for one role to
encompass the full scope of the solution journey. The complexity and heterogeneity of current IT architectures means that
this is more difficult.

The existence of separate functions means that there are handoffs between functions of information related to solution design
rather than the previous continuity. This issue is discussed more in section 2.6 on page 50.

The functional specification artefact that was produced by the systems analyst that specified the detailed design and operation
of the solution has now also almost disappeared from the current solution design process and the associated set of artefacts
now produced.

The current process frequently involves multiple handoffs and associated artefacts are passed between the separate roles, from
the business requirements specification produced by the business analyst to the solution design produced by the solution
architect to the technical design produced by the technical architect or the technical team lead.

The topic of the interface between the business analysis and solution architecture functions is covered in more detail in
section 4.4 on page 124.

The concept of the platform as the IT architecture for the organisation is discussed further in Chapter 5 on page 391 where
the future of solution architecture in the context of organisation digital transformation is examined. The question of whether
the digital framework to support the digital organisation represents a new platform that reduces or removes the need for
solution architecture is considered.

The monolithic centralised IT architecture meant that changes and new solutions were introduced slowly and expensively. It
was inflexible in responding quickly to business needs. The only data that was available was that obtained or presented
through reports.

This monolithic IT architecture has been replaced in many organisations by monolithic applications – large, apparently all-
encompassing systems such as ERP – that have the same characteristics of being inflexible, unyielding, slow and expensive to
change as large centralised systems.

This monumental approach to IT systems and the design of solutions that operate within this uniform and rigid context has
led in the past and continues to lead to the growth of Shadow IT. This is addressed further in section 3.3.5 on page 86.

The digital platform referred to in Chapter 5 on page 391 needs to avoid becoming another such monolithic information
technology system.

The solution architecture function could look to restore the depth and breadth of the systems analyst role in the way it
approaches being involved both in working with the business to define a solution and in subsequent solution delivery.

Page 32 of 540
 Introduction to Solution Architecture

2.4 What Is a Solution?

Solution?

2.4.1 Introduction

An (Information Technology) solution is a Resolver, a Provider or an Enabler. It fixes an existing set of problems. It
provides a new set of functions. It enables the consumers of the solutions to work in different ways to operate business
processes and provide new products and services or to provide existing products and services differently or take advantage of
a new opportunity.

The need for a solution arises because of one (or more) of the following occurs:

• There is an opportunity I want to take advantage of

• I have received a directive or need to respond to a new regulation
• 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
• The current solution is too manual, inefficient, costly to operate or not scalable or needs to be replaced or upgraded
because it uses unsupported technology

An originator will identify the need for a solution. Solution architecture must then work with the originator to provide a
usable response to the solution need. The resulting business solutions should be must haves rather than nice to haves in terms
of functionality and the requirements that are delivered.

2.4.2 Scope of Complete Solution

The complete solution required is rarely, if ever, just a collection of software components. The whole solution comprises the
entire set of components needed to operate the business processes associated with delivering the service for which the
solution has been designed. Ultimately, a successful solution requires the interoperation of all these components and that the
components are properly designed and implemented.

Any complete solution will consist of zero or more instances of the following components types:

Component Type Description

Changes to Existing software components, either custom-developed applications or products sourced from
Existing Systems external suppliers, both installed on the organisation’s IT infrastructure or hosted externally, and
configured or customised, may need to be changed in some way to accommodate the
requirements of the new solution.

The affected applications will need to be identified and the nature of the changes required will
need to be described.

These will need to be tested during their implementation and the results of the testing actioned as
required.
New Custom New software components will need to be developed.
Developed
Applications The list of these components will need to be identified.

This may include the development of prototypes to validate their functionality and/or their
appearance and navigation.

These will need to be tested during their implementation and the results of the testing actioned as
required.

Page 33 of 540
 Introduction to Solution Architecture

Component Type Description

Information The various application components will generate data at different rates that will need to be stored
Storage Facilities for various intervals. This includes interim data storage, operational data storage and derived data
storage for reporting and analysis.

The volume of data to be stored and the types of storage required to deliver the required access
times will need to be quantified.
Acquired, New software products that are intended to be installed on the organisation’s information
Configured and technology infrastructure will need to be acquired and then configured or customised.
Customised
Software Products The products required by the solution will need to be ascertained and the nature of the
configuration or customisation will need to be defined.

These will need to be tested during their implementation and the results of the testing actioned as
required.
System Data may be supplied to or exchanged between solution components. These integrations, transfers
Integrations/ Data or exchanges can take many forms, from file transfer to messages exchanged using a message
Transfers/ queueing facility to data supplied by an application programming interface to data exchanged via
Exchanges a mailbox to email integration.

The precise method by which the data integrations, data transformations, transfers or exchanges
take place should be listed. The content and format of the data being exchanged, the protocols to
be used and the security to be applied should be defined.

If the infrastructural applications required to perform the data integrations, transfers or exchanges
are new then they should be listed as a member of Acquired and Customised Software Products.

If existing facilities are being used, their reuse should be stated.

These will need to be tested during their implementation.

Changes to Existing business processes may need to be changed to take advantage of or in response to the new
Existing Business solution. These business processes should be listed with a description of the changes required.
Processes
New Business New business processes may need to be defined to allow the solution to be operated. These
Processes processes should be identified.
Organisational The organisation may need to be changed. New roles and staff may need to be created. Existing
Changes roles and staff may need to be changed. New offices and facilities may need to be acquired.
Existing offices, locations and facilities may need to be changed.
Reporting and All applications generate new data and use existing data. The solution will typically need facilities
Analysis Facilities to report on this data, to report on the operation and use of the solution itself and will need
facilities to analyse data. The organisation may have an existing report and analysis set of tools
that can be reused.

Solution data stores are typically operational and do not store historical time-oriented data. The
reporting and analysis component may require a data warehouse.

The definition of reporting and analysis is frequently either an afterthought in solution design,
dropped from solution delivery because of schedule and cost pressures or is specified in a non-
integrated way using solution-specific tools.

These will need to be tested during their implementation.

Existing Data Data from existing application components may need to be migrated to the new platforms to
Conversions/ avoid data loss and to make the new system usable. The migration activities may include data
Migrations reformatting, mapping to new data structures, data enrichment and data cleansing.

Page 34 of 540
 Introduction to Solution Architecture

Component Type Description

These will need to be validated.
New Data Loads New data loads may be required to populate some of the data structures of the new solution to
make the new system usable.

These will need to be validated.

Training and Internal users and external partner and service provider users may need to be trained in the
Documentation operation and use of the solution and its business processes. Training documentation and other
material may be required.
Central, The solution may require additional communications infrastructure to, for example, enable
Distributed and external access by mobile users from within the organisation or by external users or service
Communications providers or to access externally hosted components. It may also require such infrastructure for
Infrastructure new locations to be defined as part of the solution.

This may also require additional security infrastructure to support these new accesses.
Sets of Installation Some of the solution components may require externally provided installation and
and implementation services to install, configure or customise these components.
Implementation
Services
Cutover/ Transfer The solution will need to be transitioned to support. The support function will need to be trained
to Production And in providing first line support. Second and third level support arrangements will need to be put in
Support place for the operational solution components.

The operational and organisational readiness for the solution may need to be assessed and any
issues resolved so the organisation is prepared and capable of taking on the solution.

There may be an operational acceptance testing phase where the operability and supportability of
the solution is verified and any issues identified during such testing are addressed.
Operational Processes may need to be defined relating to the operation of the solution and housekeeping
Functions and functions to be performed. These functions may need to be configured and tested. These can
Processes include:

• Monitoring, alerting and event management including the configuration of alerts and rules
for the handling
• Backup and recovery
• Business continuity and availability
• Capacity planning and management
Parallel Runs The existing and new solutions may need to be run in parallel for an interval. The results of the
parallel runs may need to be compared.
Enhanced After the solution has gone live, an initial period of enhanced support or hypercare may be needed
Support/ where problems receive special attention to ensure they are resolved quickly. This may require
Hypercare special arrangements with suppliers.
Sets of The components of the solution will need to be supported and maintained. Agreements may need
Maintenance, to be put in place with suppliers of these services.
Service
Management and
Support Services
Application Elements of the solution may be hosted externally or provided entirely as an outsourced service.
Hosting and These elements will need to be established. Infrastructure may be needed to enable secure
Management communications and the exchange of data between these external components.
Services

Table 4 – Components of Complete Solution

Page 35 of 540
 Introduction to Solution Architecture

This is just one view of the components of a solution. Other categorisations and breakdowns are possible. Testing could be
specified as a separate component rather than being allocated as an activity associated with each applicable component. This
is the itemisation approach used in this book as a way of defining the scope of a solution.

So, while not all solutions will have all these component types, all solutions will have at least some of them. Each of these
component types and the individual components within each type give rise to work and cost. Omitting them from the
solution scope (and therefore from the solution design) does not mean that they are not required or should not or will not be
part of the solution as ultimately implemented. In some cases, their omission can be regarded as a form of strategic
misrepresentation where the person or group responsible for the solution does not want to represent the actual solution scope
or cost or resources or time required, at least during the initial solution approval and agreement stages. This, the design work
of the solution architect is not allowed to encompass the complete solution.

The solution design therefore needs to include the full scope of the solution. It does not have to include all the components in
a fully defined state. But it needs to include them to such an extent and level of detail so they are known about and included in
subsequent time and resource planning and cost estimates.

Figure 7 – Scope of Complete Solution

One further advantage of this complete, end-to-end view is that the solution as a whole is visible to all. Where the solution is
broken down into individual components, the individuals involved just see and focus on their areas of expertise. The
individuals design the components as isolated items. The can lead to poor overall performance, throughput, operation,
usability and consumer experience. No one is responsible for the integrity of the solution in its entirety. This end-to-end view
means that the solution is designed and implemented as a whole from the start. The impact of a decision to delay or remove
functionality from a component can be seen in terms of the effect it has on the entire solution. The solution is considered as
the sum of its components operating together. The solution is viewed as an organised set of interconnected components.2

2
The end-to-end entire solution view is similar to the concepts of internal and external integrity introduced in The Power of Product
Integrity Kim B. Clark and Takahiro Fujimoto https://hbr.org/1990/11/the-power-of-product-integrity . External integrity means that the
entirety of the solution represents a balance of form, function, usability and reliability that consumers want. Internal integrity means that
the solution’s components operate together as a complete whole.

Product integrity has both an internal and an external dimension. Internal integrity refers to the consistency between a
product’s function and its structure: the parts fit smoothly, the components match and work well together, the layout
maximizes the available space. Organizationally, internal integrity is achieved mainly through cross-functional coordination
within the company and with suppliers.

Page 36 of 540
 Introduction to Solution Architecture

Omitting solution elements such as, for example, process and organisation changes from the solution design does not remove
them from the scope of the solution that is ultimately required. They are still needed in order to create a fully operational
solution. They do not go away just because they have been ignored. More likely, they will be added later during solution
delivery, either explicitly or implicitly as a form of shadow project work or as a change request, where they will add ostensibly
unforeseen (but not unforeseeable) cost, time and resources to the project. In reality, this is not a change but the correction of
an omission.

Figure 8 – Scope
Scope of Partial and Incomplete Solution

An all too frequent occurrence is the descoping of the solution and its components during its implementation project.
Because of pressures on budget, schedule or resources, components of the solution or functionality within components are
removed from its scope in order to reduce those pressures. This descoping removes functionality that is needed for the
solution to work fully. The implementation of these components is deferred to (a sometimes non-specific or even non-
existent) future stage. The result is a partially completed solution with manual workarounds and its associated inefficiencies
and extra cost and with a backlog of rework. For example, the delivery of reporting and analysis facilities and the associated
data infrastructure is one that is commonly deferred.

Solution delivery too often takes a middle- to--middle rather than an end
middle -to end--to
to--end view of what needs to be implemented in
order to create a fully operational solution. Solution delivery assumes that the components outside the middle-to-middle
solution delivery scope will be implemented by others. These components can be regarded as solution negative externalities3.
These are costs that the solution delivery imposes on others because of the limited solution scope it chooses to implement.

External integrity refers to the consistency between a product’s performance and customers’ expectations. ... external
integrity is critical to a new product’s competitiveness. Yet for the most part, external integrity is an underexploited
opportunity. Companies assign responsibility for anticipating what customers will want to one or more functional groups
(the product planners in marketing, for example, or the testers in product engineering). But they give little or no attention
to integrating a clear sense of customer expectations into the work of the product development organization as a whole.

The article is derived from a larger publication Product Development in the World Auto Industry, KIM B. CLARK, W. BRUCE
CHEW, TAKAHIRO FUJIMOTO - https://pdfs.semanticscholar.org/90f2/15d9f0c0e49e3ea2a366b8b06de3b81d094f.pdf.
3
See:
https://en.wikipedia.org/wiki/Externality.

Page 37 of 540
 Introduction to Solution Architecture

Figure 9 – Solution Delivery Externalities

Be aware of and beware of solution externalities. These are hidden solution delivery costs and responsibilities.

The relative size and contribution to the overall project scope of each of the solution component types will depend on the
profile of the project. So, the impact of the omission of some components will therefore depend, at least indirectly, on their
size.

Figure 10 – Omission of Components

Components from Solution Design Scope

The omission of components from the solution design can be viewed as red flags, indicating the potential for future problems.

Page 38 of 540
 Introduction to Solution Architecture

The solution can only really be regarded as delivered and operational when all the required components have been delivered
successfully and that they work. 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.

Figure 11 – Convergence of Solution Components to Create Complete Operational Solution

Once this convergence of solution components is understood then informed decisions can be made about the staging of the
components and their constituent elements along the following lines:

Figure 12 – Staged Delivery of Solution Components

It is an inconvenient truth that complete and accurate information is rarely available. So, decisions such as the scheduling of
solution component delivery and functionality to be included within solution components within a phased delivery be made
on the available information.

The topic of solution delivery are discussed further in section 4.3 on page 112 and Chapter 6 on page 422.

Page 39 of 540
 Introduction to Solution Architecture

2.4.3 Solutions and Organisation Change

Every solution involves internal organisation change. These changes typically occur across one or more of six core domains.

Figure 13 – Organisation Core Change Domains

These six core change domains are divided into two groups: those relating to the business and those relating to information
technology

• Business-
Business-O riented Change Areas

• 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
Tech nology-
nology-O riented Change Areas

• 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, data security and privacy

These six core change domains affect the organisation or business function where the solution will be operated. There is a
seventh change domain for changes that occur outside the organisation such as the external business landscape that the
solution must react to or solution users who are located outside the organisation.

Page 40 of 540
 Introduction to Solution Architecture

Figure 14 – Extended Organisation Change Domain

While the organisation generally has control around internal changes and the reaction to them, externally-facing changes and
the response to them are more difficult to anticipate, control and manage.

The topic of the organisation changes cause by the introduction of solutions is covered in more detail in section 4.6.4.8 on
page 253.

2.4.4 Solution Components and Organisation Change

The generic component types of which every solution is composed can be allocated across these six change domains.

Figure 15 – Solution Components Mapped to Organisation Change Domains

Page 41 of 540
 Introduction to Solution Architecture

The information in this diagram is:

Business Change Domain Group Business Change Domain Description

Business-Oriented Change Location and Offices This is not explicitly included. It is
implicitly included in the organisation
changes domain.
Business Processes Changes to Existing Business Processes
New Business Processes
Operational Functions and Processes
Organisation Structures, People and Organisational Changes
Teams Training and Documentation
Technology-Oriented Change Technology, Infrastructure and Application Hosting and Management
Communications Services
Central, Distributed and
Communications Infrastructure
Information Storage Facilities
Applications and Systems 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
Cutover/ Transfer to Production
Parallel Runs
Enhanced Support/ Hypercare
Sets of Maintenance, Service
Management and Support Services
Information and Data Existing Data Conversions/ Migrations
New Data Loads

Table 5 – Mapping Solution Components to Business Change Domains

This mapping can be used to identify the business domains that will be most affected by the solution based on its profile in
terms of its number and complexity of its constituent components in each of the component categories.

2.4.5 Solution Decomposition

Within these component types, there can be multiple lower levels. In the following example, Level 0 represents the entire
solution. Level 1 is the business change domain. Level 3 is the solution component type. Level 4 represents the individual
components within each component type. Level 4 represents a more detailed level of solution design granularity where the
items contained within each individual component are identified.

Page 42 of 540
 Introduction to Solution Architecture

Figure 16 – Solution Component Levels

For example, the following component types are at level 3:

• Changes to Existing Business Processes

• New Business Processes
• Operational Functions and Processes

The level 4 breakdown for these would be the individual business processes affected.

The component type Organisational Changes is at level 2. The level 3 detail breakdown could be:

• Personnel Changes
• Organisation Structure Changes
• Location and Office Changes

In this example, level 4 could list the individual personnel and organisation changes.

Page 43 of 540
 Introduction to Solution Architecture

Figure 17 – Sample Level 1 to Level 4 Solution Breakdown

The greater the level of detail that is contained in the solution design allows greater certainty about the design and its cost and
resource and time requirements. As the design is elaborated more detail can be added. Initially, the solution design to level 3
is generally sufficient to understand the full scope of the solution and thus the accuracy of the implementation cost, time and
resource estimate.

This level approach is similar to and can be used to create a solution delivery work breakdown structure that can in turn be
used for project planning and its related estimation and resource planning. This means that the solution delivery plan is
explicitly linked to the solution design structure.

2.4.6 Solution Cost

Cost

Each of the components of the solution will give rise to a cost, either directly or indirectly. The real solution delivery costs are
the costs of all the components required to make the solution operational and to keep it operational thereafter.

Page 44 of 540
 Introduction to Solution Architecture

Figure
Fi gure 18 – Solution Components Contributing to Solution Delivery and Operation Costs

Throughout the lifetime of the solution, these components will give rise to costs and resource requirements. If the true
lifetime costs of the solution are to be known, then the true solution scope must be accepted.

Figure 19 – Total Solution Lifetime Costs

Depending on the duration of the life of the solution, its operating costs can be or the order 1-3 times the cost of acquisition.
The total cost of ownership of the solution – the sum of the initial and ongoing costs – needs to be less than the benefits the
organisation derives from the solution – either through savings, cost avoidance, additional revenue generated or compliance
with regulations. If the cost estimates are incorrect then the cost benefit justification for the solution will also be flawed.

Page 45 of 540
 Introduction to Solution Architecture

Figure 20 – Solution Acquisition and Lifetime Operating Costs

Getting the solution design right and getting the right solution implemented contributes both to the success of the solution
delivery project and the long-term cost-effectiveness of the operation of the solution.

Each solution component contributes to the overall lifetime cost profile of the solution. Over time, these costs can be
substantial. The following diagram shows a sample cost profile of the components of a solution over its life.

Figure 21 – Sample Solution Lifetime Cumulative Cost Profile

A sufficiently detailed solution design that includes all of the components of the solution will allow the cost of the solution
delivery project to be estimated. It provides complete visibility of the solution costs. If all the components of the required
solution are known, then the solution implementation and operational cost can be quantified accurately.

Page 46 of 540
 Introduction to Solution Architecture

The absence of knowledge about the full scope of the solution will mean that the cost, resource and time estimates for the
delivery of the solution will not be accurate or reliable.

Solution delivery success is commonly assessed with respect to the money, resource and time allocated to the project and how
the project performed against these assigned resource budgets. This is discussed in section 3.1 on page 57. If the solution
design is incomplete or if the estimates omit elements of the solution design in order to make the project costs appear lower,
then the solution delivery project will be deemed to have failed to some extent. In reality, this failure is largely artificial. The
project resource requirements were knowable but either this knowledge was not acquired or allowed to be acquired during
the design process or it was excluded from the estimation process.

There are many reasons for poor solution delivery resources estimates. Many of these relate to using incomplete information
to create those estimates, either deliberately or by not using enough rigour in the estimation process.

Figure 22 – Sources of Good and Poor Solution Delivery Estimates

Sources of Good Solution Delivery Estimates Sources of Poor Solution Delivery Estimates
Effective Risk and Uncertainty Analysis Contracts Not In Place With Suppliers
Identification of a Range of Confidence Levels Omitted Solution Components
Identification of a Range of Confidence Levels Multiple Business Functions Affected
Trained and Experienced Designers and Analysts Multiple Undefined Interfaces
Adequate Contingency and Management Reserves Underestimated Organisation Change Costs
Detailed, Stable, Agreed Scope Ineffective Risk and Uncertainty Analysis
Agreed Assumptions Strategic Misrepresentation
Unfamiliar Technology or First-Time Use
Problems Getting Access to Data
Unreasonable Project Baseline
Unrealistic or Unreliable Data
Unrealistic Assumptions
Over optimism
No or Limited Comparison Data Available
New Processes
Untrained and Inexperienced Designers and Analysts
Project Instability
Complex Project or Technology

Page 47 of 540
 Introduction to Solution Architecture

Sources of Good Solution Delivery Estimates Sources of Poor Solution Delivery Estimates
Unrealistic Project Savings and Benefit

Table 6 – Sources of Good and Poor Solution Delivery Estimates

Sufficient knowledge is a safeguard against poor project estimates.

Some of these reasons are related to the subject of solution complexity. Identifying and quantifying solution complexity is
discussed further in section 4.2.2 on page 100.

2.4.7 Solution Options, Boundaries and Constraints

As stated above, there will always be many possible solution options to a business requirement or problem. All solutions are
subject to sets of constraints that will limit and restrict the ultimate solution design options. The solution architect must be
aware of these constraints and must clearly and plainly state them in any solution design artefacts so their part in the solution
design process and the effects they have on the solution design options are explicitly understood by all. These constraints
form boundaries to the solution design that is created during the design process.

Enterprise Architecture (and the related IT architecture disciplines of Security Architecture and Data Architecture) defines
the technical boundaries of the solution.

Solution Architecture then defines the scope boundary of the solution based on business and implementation constraints.
One of the objectives (and challenges) of solution architecture is to take an often fragmented and incomplete set of
requirements and to create an integrated and coherent solution based on these, filling-in the blanks during the solution
design process. The topic of requirements and the sparsity of business-provided requirements is detailed in section 4.4 on
page 124.

Figure 23 – Solution Design Boundaries

Constraints can be defined as Core – these are concerned with essential solution attributes - or Extended – these are
concerned with solution implementation and operation.

In simple terms, the Core constraints can be grouped into four sets:

Page 48 of 540
 Introduction to Solution Architecture

Figure 24 – Solution Design Constraints

Solution Constraint Description

Enterprise and Other IT Architecture These constraints relate to organisation enterprise and other architecture
Constraints standards such as what packages, tools and platforms may or may not be
used, what devices the solution can be accessed from and how security
and privacy should be implemented.

IT architecture functions such as Enterprise Architecture, Security

Architecture and Data Architecture should define standards and
approaches in these areas. These standards should be complied with (or
explicit derogations obtained for any deviations from those standards).
Solution Architecture Design Constraints The solution design process will uncover constraints based on
requirements that have been explicitly articulated or have been identified
during design. This topic of requirements in the context of solution
design covered in more detail in section 4.4 on page 124.
Use Existing Solution Components or Create There may be the opportunity to reuse existing components when
New Components, Cost, Time, Resources, implementing the solution. The reuse can be partial or complete. Partial
Business Constraints reuse involves reworking the existing components. Reuse can be more
complex and time-consuming than implementing new components.
There can be an unwarranted confidence in the level of reuse that is
possible that will cause problems during subsequent solution
implementation. Reuse options need to be validated before they are
included in the solution design.
Degree of Automation of Solution The solution can be automated to a lesser or greater extent. Greater
automation involves greater complexity, implementation cost and
validation. Automation offers advantages in terms of elimination of
manual support and operations effort. Automation needs to focus on
processes and their decisions and how to make them consistent,
repeatable and autonomous and be able to be performed in real time.

Table 7 – Solution
Solution Design Constraints

The solution should be designed according to common principles developed and maintained by the solution architecture
function. Section 5.4.3 on page 418 lists principles that can be applied when designing digital solutions. These can be applied
more generally. Section 4.11.2 on page 383 lists the principles that can be applied when reviewing a solution for completeness.
The solution should be designed with these review principles in mind.

The solution will have quality requirements and characteristics. These are described on section 4.6.4.7 on page 251.

Page 49 of 540
 Introduction to Solution Architecture

2.5 Getting the Solution Design Right

Getting the solution design right involves a number of factors:

• Understanding the core underlying problem, challenge or opportunity so the principles of the solution addresses what is
really needed are understood and that the wrong problem is not being solved

• Identifying all the components of the solution that have to be in place for the solution to operate, including options to
bypass components during the initial implementation in order to get the solution operational more quickly but that are
implemented later

• Defining the scope of the each of the components

• Identifying the correct design option for each of these components

However, getting the design right is one part of answer. The second part is getting the solution implemented successfully.
This means avoiding making incorrect decisions on solution delivery phasing, resource allocation, the removal of necessary
components to meet constraints, making unnecessary changes or leaving the design ambiguous so sub-optimal decisions are
made.

The convergence of all these solution dynamics can be very difficult. Section 3.1 on page 57 examines why solution delivery
failure occurs so frequently.

2.6 The Solution Delivery Process in Context

The solution delivery journey, from initial concept to operational, usable and used solution, is often difficult. It can involve
ups and downs, compromises and concessions until an operational solution steady state has been accomplished.

Figure 25 – Solution Delivery Journey

The solution architect must persevere during this process, focussing on the objective of creating a complete design and then
subsequently assisting with its implementation.

One objective of the IT function is to act as a lens, focussing business needs onto solutions whose components are acquired or
developed, implemented and transitioned to operations. The solution design process must assist in maintaining this focus.
The solution architecture function needs to have the capability to achieve this. Solution architecture is (or should be – see

Page 50 of 540
 Introduction to Solution Architecture

section 3.3.5 on page 86 for information on Shadow IT) the primary means by which new solutions are introduced into the
organisation. The selected solutions, either internal or external, must comply with the organisation’s overall IT architecture
standards.

Figure 26 – IT Function as a Lens Focussing Business Needs On To Solutions

Achieving the objective of the IT function focussing business needs onto solution requires that the IT function be the trusted
advisor to the business.

The end-to-end solution delivery process involves multiple partially overlapping individual journeys across different
disciplines. Each of these journeys does not span the entire length of the journey from initial concept or identification of the
need for a solution to that solution being completely operational and used.

Page 51 of 540
 Introduction to Solution Architecture

Figure 27 – Multiple Partially Overlapping Solution Delivery Journeys

The solution delivery journey can be viewed as an iceberg with many overlapping activities hidden below the apparently
simple requirement to move from the set of solutions required to operate the organisation and achieve the business objectives
to those solutions being operational, usable and in use. There evolution of the solution concept can occur earlier than shown
in this diagram – see section 4.6.4 on page 235 for more information on an early engagement process and section 4.6.5 on
page 257 for a rapid solution concept definition engagement.

The aim of the solution design process is to create solution designs that meet the needs of the solution user population. The
solution design process is one part of the overall solution delivery process.

The solution journey therefore both starts with and ends with the solution consumer.

The high-level sets of steps for each of these journeys are listed below.

Discipline Journey
Journey Step
Business Architecture Business Strategy
Business Objectives
Business Operating Model
Business Processes
Required Operational Business Systems
Business Planning Business Concept
Initial Discovery
Requirements Elicitation
Decision to Proceed

Page 52 of 540
 Introduction to Solution Architecture

Discipline Journey
Journey Step
Business Analysis Requirements Elicitation
Requirements Analysis, Consolidation and Documentation
Process Analysis and Definition
Requirements Management
Solution Design Solution Architecture - Business, Application, Data, Security, Infrastructure
Solution Design
Solution Specification and Change Management
Project Management Initiate
Plan
Design
Build
Test
Deploy
Solution Development Setup and Prepare
Develop and Build
Test
Package and Deploy
Manage
Product Configuration Setup and Prepare
and Customisation Configure and Customise Test
Package and Deploy
Manage
Data Management Data Migration and Load Planning
Data Migration and Data Load
Test
Final Data Migration and Load
Service Management Service Design
Service Transition
Service Operation
Continual Service Improvement

Table 8 – High-
High-Level Steps of Individual Discipline Solution Delivery Journeys

Not all disciplines are involved in the delivery of all solutions. For example, the involvement of the Business Architecture area
tends to intermittent and based on specific engagements. Most organisations will not have a Business Architecture function
or capability. Where the need for such an engagement arises, it tends to be outsourced to a consulting service provider. Most
of the other disciplines will be involved in most solutions. This list of disciplines is high-level and does not explicitly reference
ones such as testing, infrastructure, security, procurement, product configuration and others.

The overall high-level solution delivery journey is:

Page 53 of 540
 Introduction to Solution Architecture

Figure 28 – Overall Solution Delivery Journey

The steps in this journey are:

• Idea, Business Need, Business Benefits

• Process Definition and Solution Design
• Costing -Implementation and Operational
• Solution Implementation and Delivery
• Solution Operation
• Benefits Realised
• Solution Evolve and Change

For a wide variety of reasons, solutions often fail to achieve the benefits expected or promised (see section 3.1 on page 57 for
more information on solution delivery failures).

Figure 29 – Solution Delivery Failure

Page 54 of 540
 Introduction to Solution Architecture

One of the reasons for this failure is that there are multiple handoffs between isolated and insulated teams during the solution
delivery process. This leads to an accumulation of information losses that means that what get implemented is not what is
needed to allow the benefits to be realised.

Figure 30 – Information Loss Due to Multiple Handoffs During Solution

Solu tion Delivery

All too often the work done on the solution is passed from one architecture discipline to the next with a poor and imperfect
handoff. Each discipline operates in an isolated silo. The implementation of the solution is not seen as a continuum. There is
no end-to-end view across all disciplines. Even the project management discipline which is tasked with the delivery of the
solution does not see the complete span of the solution.

Figure 31 – Siloed Operation

Operation of Solution Delivery Disciplines

The siloed arrangement within the solution delivery journey is replicated within the communications between the individual
IT architecture functions as discussed on page 79.

Page 55 of 540
 Introduction to Solution Architecture

These siloed structures tend to be characterised by some or all of the following

• Closed, internally focussed groups with their own culture and language that discourage outsider involvement
• Individuals with the siloed functions see themselves as belonging to and identify with the group rather than the wider
organisation
• The siloes do not see themselves as responsible for organisational problems and failure to perform and deliver
• The silos measure their performance and set performance expectations using internal metrics that reinforce siloed
behaviour
• Top-down management structure with control-based behaviours and attitudes to team members

The topic of the solution architecture function and the issues that can arise with a poorly structured function is addressed in
section 8.3.4 on page 504.

Every organisation will have a solution delivery project management process such PRINCE2, PMBOK or another. The
solution architect must work within this framework and be supported by it. Section 3.1 on page 57 contains more information
on the issues that arise during solution delivery and how solution architecture can work to address these.

Section 4.3 on page 112 describes solution design in a wider solution delivery context. Chapter 6 on page 422 contains details
on the application of an agile delivery method to solution design and subsequent implementation.

Page 56 of 540
 Introduction to Solution Architecture

Chapter 3. Business Strategy, Architecture Strategy and Solution Design and

Delivery

3.1 Why Solutions Fail

This information provides a solution architecture perspective on why solution delivery fails. Getting the architecture and
design right puts the solution delivery project on a solid foundation and maximises the likelihood of success. The delivery
estimates use a realistic solution scope with all factors included. Getting the solution architecture and design wrong puts the
solution delivery project on an unstable foundation and negatively impacts on the deliverability of the solution and the
probability of success of the solution delivery project.

It is a reasonable statement that in the minds of many people failure is synonymous with information technology projects.
While this perception is an exaggeration, the outcomes of many IT solution delivery projects represent failures to at least
some extent.

It is also often true that solution delivery failure is attributed to project management failure such as the quality, skill and
experience of the project manager or the misapplication or lack of application of a project management methodology.
However, the most effective project management will not make an undeliverable, unworkable, unusable solution deliverable,
workable or usable.

The solution architect should concern himself or herself with the ultimate success of the project to deliver the designed
solution. There are several organisation characteristics that negatively affect this:

• As described in section 2.6 on page 50 the solution delivery process can be siloed with multiple hand-offs, including that
from solution architecture to project management and solution delivery

• The solution design produced by the solution architect does not or is not allowed to include the full scope of the solution

Page 57 of 540
 Introduction to Solution Architecture

These are not mutually exclusive and regularly occur together.

The goal of the solution delivery project is to successfully implement the right solution. This is a combination getting the
solution design right and then implementing this design successfully. The two areas are connected: the right solution design
includes identifying all the solution components that comprise solution delivery. The delivery project can then implement
these.

There is little, if any, merit in initiating a delivery project to implement a solution if the scope of that solution is not well-
defined. Any scope definition work needs to be moved to a separate activity focussed on just that purpose so that when
solution implementation starts, its scale and extent are well-defined and accepted or the uncertainly of the solution design
needs to be accepted and embedded into the delivery project such as in an agile process. The topic of agile solution delivery is
discussed further in Chapter 6 on page 422.

Figure 32 – Goal of Solution Delivery – the Right Solution Implemented Successfully

It is a continuing truth that the combination of the successful delivery of the right solution still occurs infrequently.

Figure 33 – Right Solution Delivered Successfully is in the Minority of all Solution Delivery Outcomes

Page 58 of 540
 Introduction to Solution Architecture

This section is not intended to be a comprehensive review of project management literature. It is intended to illustrate how
good solution design contributes to solution delivery success and reduces the prospects of solution delivery failure.

Section 4.4.2 on page 134 which describes the importance of business processes (and organisation change) to solution success
can be referred to when reading this section. The solution ultimately exists to implement the business process.

Also, the problem of Shadow IT referred to 3.3.5 on page 86 can be viewed as another form of solution delivery failure where
the business function sources the solution externally rather than from the internal IT function and without the knowledge or
involvement of the IT function. Secondly, many business-acquired solutions whose delivery was challenged do not appear in
any project failure statistics.

Over two decades has passed since the first Standish Group CHAOS report4 on the state of delivery of information
technology projects was published. The results from this study are well known and often quoted:

… staggering 31.1% of projects will be cancelled before they ever get completed. Further results indicate 52.7%
of projects will cost 189% of their original estimates.

On the success side, the average is only 16.2% for software projects that are completed on- time and on-budget.

Solution delivery success and failure are not binary options: there is a domain of outcomes between complete success and
complete failure. There are many reasons why the implementation of a solution may be regarded as less than successful.
These reasons are not exclusive: the delivery of a solution can demonstrate more than one of these characteristics. Also, they
are not binary factors: each of these solution deficiency issues can be more or less serious, representing a greater or lesser level
of solution delivery non-performance with respect to that factor.

The CHAOS reports classify projects outcomes according to three categories:

1. Success - The project is completed on time and on budget, offering all features and functions as initially specified.
2. Challenged –The project is completed and operational but over budget and over the time estimate and offers fewer
features and functions than originally specified.
3. Impaired - The project is cancelled at some point during the development cycle

The following diagram shows a simple model of solution success and failure.

4
See The CHAOS Report 1994:
https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf
There have been many comments on this and subsequent reports questioning their categorisation of project success and
failure and the calculation of the proportion of projects that fall into each category. For example, see:
• How Large Are Software Cost Overruns? A Review of the 1994 CHAOS Report -
http://www.umsl.edu/~sauterv/analysis/Standish/standish-IST.pdf
• The Rise and Fall of the Chaos Report Figures -
https://www.cs.vu.nl/~x/the_rise_and_fall_of_the_chaos_report_figures.pdf
However, for the purpose of this analysis, the Standish Group numbers are assumed to be valid.

Page 59 of 540
 Introduction to Solution Architecture

Figure 34 – Field of Solution Delivery Project Success and Failure

These are not point reasons for solution delivery challenge or failure. Each of these reasons can occupy a band of impacts of
just how challenged the delivery was from Low to Very High.

The challenged solution delivery reasons are:

Challenge Reason Likely Impact Range Description

of Challenge
Significant Rework Or Replacement High to Very High
Elements of the solution as delivered need to be
Required replaced or significantly reworked to operate as
planned or needed.
Solution Delivery Late Low to Medium The solution exceeded its original budget.
Solution Delivery Over Budget Low to Medium The solution exceeded its schedule.
Unstable and Unreliable Requiring Medium to Very High The solution does not work as automatically and
Additional Support Cost and Effort without intervention as expected or designed or is
unstable or unreliable and requires a degree of
manual support work.
More Expensive to Operate And Support Low to High The solution works but the effort and cost to
Than Planned Or Expected support and operate it is greater than planned.
Performance And/Or Operational Low to Medium The solution does not have the required throughput
Problems or response times as expected or designed.

The span of this challenge is generally low to

medium but in extreme circumstances, the impact
can be high.
Solution Has Reduced Functionality Low to Medium Some of the initially designed functionality was
Requiring Workarounds omitted from the delivered solution requiring
additional manual effort and work outside the core
solution components.
Not What Is Wanted Or What Was High to Very High The delivered solution is not what the business
Required/ Envisaged wanted or expected or does not fulfil their needs.

Page 60 of 540
 Introduction to Solution Architecture

Not All Specified Business Benefits And Low to Medium Some of the expected benefits have not been
Savings Not Delivered realised.
Functionality Delivered Does Not Meet Medium to Very High Some of the functionality contained in the solution
Business Requirements does not work exactly as the solution consumer
expected or wanted.

Table 9 – Field of Solution Delivery Project Success and Failure

At its simplest, the challenged domain includes solutions that are characterised by less for more of:

• Cost More – the original budget was exceeded or other unanticipated costs arose

• More Time – the original schedule was exceeded which means the business were late in having access to the solution

• Delivered Less – the original scope was reduced, making the solution less usable or requiring additional unplanned for
effort or the solution takes longer to use or the solution does not meet the expectations of the target solution consumers

• Achieved Less – the solution does not deliver the expected benefits and savings or the solution is less widely used that
expected or planned

Lost functionality is only really an issue if its absence leads to a problem in terms of work not done or work done elsewhere
that takes more time or costs most. Loss of unnecessary functionality is not a problem. This relates to unnecessary solution
complexity described in section 4.2.2 on page 100.

So-called challenged projects can be characterised as delivering less – less functionality, fewer benefits, less usability, less
usefulness – for more – more time and more money. The degree of the combination of how much less for how much more
can be regarded as the total operational solution deficit.

There is no easy formula to determine the total solution deficit, such as:

1 ! "#$% &%#'ℎ
)
*+ ,- . / 0 *+ ,- . / 0
1 *+ ,- . / 0
12 3 # 4# 5 6% %7# 8 '% &%#'ℎ

Such attempts at creating an arithmetic of solution delivery failure are, at best, superficial and simplistic.

Figure 35 – Operational Solution Deficit – Degrees

Degrees of Less for More

Page 61 of 540
 Introduction to Solution Architecture

These less for more

more factors overlap. If the delivery of the solution took longer, this will mean that the solution delivery team
were working longer incurring more cost than budgets. If the solution delivered less and thus either did not generate the
expected savings or benefits (see section 4.11.1 on page 381) or required manual workarounds or both this would also
increase the effective solution delivery and operations cost.

So, solution delivery success means avoiding these less for more characteristics. One way this can be achieved is to know as
much as possible of what is needed up-front, so the real effort, time and cost can be quantified.

Since the original Standish Group CHAOS report, there have been several follow-up Standish reports5, each reporting
different levels of project success, challenge or impairment. The following summarises the results of their analyses from 1994
to 2015.

Figure 36 – Standish Group CHAOS Report Project Outcome Results 1994-

1994-2015

The data in the chart is:

Year Succeeded Challenged Failed Succeeded or

Challenged
2015 36% 45% 19% 81%
2014 36% 47% 17% 83%
2013 41% 40% 19% 81%
2012 37% 46% 17% 83%
2011 39% 39% 22% 78%
2009 32% 44% 24% 76%
2006 35% 46% 19% 81%

5
For example, see the CHAOS Report 2015:
https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf

Page 62 of 540
 Introduction to Solution Architecture

Year Succeeded Challenged Failed Succeeded or

Challenged
2004 29% 53% 18% 82%
2000 28% 49% 23% 77%
1998 26% 24% 28% 50%
1996 27% 33% 40% 60%
1994 16% 53% 31% 69%

Table 10 – Standish Group CHAOS Report Project Outcome Results 1994-

1994-2015

According to these Standish Group figures, between 1994 and 2015, the relative proportions of projects that succeeded and
those that failed have effectively been transposed. Successful projects increased in proportion from 16% to 36% while failed
projects fell from 31% to 19%.

The information from the Standish Group is presented here without detailed analysis. This is beyond the scope of this book.
It is not clear if project success is assessed against the original project timescale, budget and functionality or against a
replanned project with the original scope having been changed.

Also, the degree by which a project is challenged can be very small or very large due to one of more factors with varying
degrees of severity as discussed above.

There have been other more recent analyses of project failure that generate similar outcomes6. The analysis by Brenda in 1999
Whittaker was based on a survey of 176 projects in Canada. It defined project failure as:

Project failure was defined in three ways: overrunning its budget by 30 per cent or more; overrunning its
schedule by 30 per cent or more; or failing to demonstrate the planned benefits. Of these, failure by
overrunning schedule was by far the most common. A total of 87 per cent of failed projects exceeded their
initial schedule estimates by 30 per cent or more. This compares to 56 per cent of failed projects that exceeded
their estimated budget by the same amount, and 45 per cent of failed projects which failed to produce the
expected benefits

It identified a hierarchy of project failure causes based on three core sets of reasons:

1. Poor project planning

2. A weak business case
3. Lack of senior management involvement and support

The following table summarises the hierarchy of causes identified in this paper:

Component Type Description Description

Poor project planning Risks were not addressed as part Slippage from the schedule
(specifically, risks were not of the project planning process. Change in scope of technology,
addressed or the project plan was functionality or business case
weak). Cost overruns associated with one or more
project components
Change in any key individuals such as the
business sponsor, project manager or vendor
manager
The plan was weak Incorrectly estimated activity durations

6
For some examples, see:
• Lessons for IT Project Manager Efficacy: A Review of the Literature Associated with Project Success Chuck Millhollan, Michelle
Kaarst-Brown - https://journals.sagepub.com/doi/abs/10.1177/875697281604700507?journalCode=pmxa
• What went wrong? Unsuccessful information technology projects Brenda Whittaker (1999) Information Management &
Computer Security. Vol. 7, No. 1 pp. 23-29. http://cs.mvnu.edu/twiki/pub/Main/SoftwareEngineering2010/What_went_wrong.pdf
• Six Reasons for Software Project Failure Barry Boehm, (2002) IEEE Software, September/October, pp. 97.

Page 63 of 540
 Introduction to Solution Architecture

Component Type Description Description

Incorrect assumptions regarding resource
availability
Inadequate assignment of activity
accountabilities
Missing or incomplete review and approval
activities
The business case for the project Business and operational changes needed to deliver the benefits
was weak in several areas or Clearly understood deliverables
missing several components Quantified costs and benefits
Overall scope of project
A lack of management involvement and support.
Custom-developed applications were associated with serious budget and schedule overruns.
Budget and schedule overruns Risks were not addressed in several areas
The project manager did not have the required skills or expertise
Project progress was not monitored and corrective action was not initiated
The experience, authority and stature of the project manager were inconsistent with
the nature, scope and risks of the project

Table 11 – Causes of Project Failure from What went wrong? Unsuccessful information technology projects

The paper by Barry Boehm lists the following six reasons for project failure:

1. Incomplete requirements
2. Lack of user involvement
3. Lack of resources
4. Unrealistic expectations
5. Lack of executive support
6. Changing requirements and specifications

The more recent work by Alexander Budzier and Bent Flyvbjerg7 of the BT Centre for Major Programme Management at the
Saïd Business School in the University of Oxford8 which has an academic rather than a commercial basis shows comparable
results. This analysis differs from the Standish Group as it looks at variance from planned budget and schedule and analyses
the proportion by which the actual varies from the initially planned or budgeted time or amount: (Actual Budget/Schedule –
Forecast Budget/Schedule) Forecast Budget/Schedule.

Our first statistical approximation of the collected sample has shown that on average ICT projects perform
reasonably well – +27% cost overrun, +55% schedule overrun in three out of four projects. Apart from the risk
of getting the budget cut a very high risk exists that a project turns into a Black Swan. One in six projects (17%)
with cost overruns of nearly +200% and schedule slippage of nearly 70%.

The Budzier and Flyvbjerg analysis was produced in 2011. It states that 75% of projects experienced significant budget and
schedule overruns. The Standish Group proportion of challenged projects for 2011 was just 39%.

The Budzier and Flyvbjerg analysis does not include details on the benefits shortfall of these projects that experienced cost
and budget overruns.

7
See:
• Double Whammy – How ICT Projects are Fooled by Randomness and Screwed by Political Intent -
https://arxiv.org/ftp/arxiv/papers/1304/1304.4590.pdf
• Why Your IT Project May Be Riskier Than You Think - https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-
think
• Outside
Quality Control and Due Diligence in Project Management: Getting Decisions Right by Taking the Outs ide View -
https://arxiv.org/ftp/arxiv/papers/1302/1302.2544.pdf
8
See:
https://www.sbs.ox.ac.uk/

Page 64 of 540
 Introduction to Solution Architecture

The CHAOS reports include a top ten factors that they say can be used to assess the likelihood of the success or failure of a
project. These factors have changed over time. Each of these success factors is assigned a score with the total summing to 100.
Their weightings and titles have changed over time. I have grouped similar success factors over time in the following table
and so any errors in this grouping are mine.

Success Factor 1994 1999 2000 2015

Factor Importance Score
User Involvement 19 20 16 15
Executive Management Support/ Executive Sponsorship 16 15 18 15
Emotional Maturity (Managing Expectations, Gaining 15
Consensus)
Optimisation (Clarify Objective, Divide Larger Projects Into 15
Multiple Smaller Projects)
Clear Statement of Requirements 15
Firm Basic Requirements 5 6
Clear Vision and Objectives/Clear Business Objectives 3 15 12 4
Proper Planning 11 5
Reliable Estimates 5
Realistic Expectations 10
Smaller Project Milestones 9 10
Minimised Scope 10
Modest Execution 6
Standard Software Infrastructure 8
Standard Architecture 8
Formal Methodology 6
Agile Process 7
Competent Staff/Skilled Resources 8 5 10
Experienced Project Manager/Project Management Expertise 15 14 5
Ownership 6 5
Hard-Working, Focused Staff 3
Other 5 5
Total Success Factor Score 100 100 100 100

Table 12 – Standish Group Project Success Factors Over Time

To assess the probability that the project will be a success, the project is scored with respect to the success factors. The higher
the score, the greater will be the chance of success. The lower the score, the greater will be the chance of some of project
failure.

According to the Standish Group, the two most important success factors that are common to all their analyses are:

• User Involvement
• Executive Management Support/ Executive Sponsorship

It is interesting to note that the design of the solution is not explicitly mentioned in any of these factors. It may be subsumed
into those factors that related to requirements and objectives.

Other overlapping important success factors that have been assigned different names over time are:

• Emotional Maturity (Managing Expectations, Gaining Consensus)

• Optimisation (Clarify Objective, Divide Larger Projects Into Multiple Smaller Projects)
• Clear Statement of Requirements
• Proper Planning
• Realistic Expectations

Page 65 of 540
 Introduction to Solution Architecture

• Smaller Project Milestones

The analyses performed by Budzier and Flyvbjerg identified seven organisational challenges (these are no scored) that exist
before a project starts (what they call organisational a priori challenges) that are associated with troubled projects. These are:

Organisational Challenge Scope of Impact

Political bias and ineffective project sponsorship Business
Ineffective governance structure Business, IT
Unclear goals and business cases and success criteria Business
Competing and shifting criteria Business
Lack of risk management Governance, IT
Big Bang approaches Business, IT
No user involvement Business, IT

Table 13 – Budzier and Flyvbjerg Project Organisational Challenges

These studies all tend to focus on the narrow aspects of software projects rather than on the wider aspects of a complete
solution encompassing all the components of the types listed in section 2.4.2, including but not limited to developed or
acquired and customised software.

These also tend to focus on project management failures as the root cause of the project failure. They do not consider the
wider aspects such as the incompleteness of the solution design targeted for delivery by the project or the fundamental
undeliverability of the solution as a cause. They start with the assumption that the project has been given a fundamentally
sound and deliverable solution design and scope and that it is the delivery that goes wrong.

Again, the fundamental issue of the implementability of the solution is not explicitly considered.

An effective solution architecture function and a good solution design process that produces detailed, high-quality solution
designs and identifies the complete scope of the solution will address many of these challenges and increase the likelihood of
successful solution delivery and use. Good solution design means being aware of all the options and selecting the most
appropriate one subject to all constraints. It means avoiding all the conscious and unconscious biases that lead to bad
solutions.

A solution design process that identifies the end-to-end scope of the solution means the solution delivery project starts with
an awareness of the effort, risks, scope and costs involved. The following table summarises how a solution design process can
maximise the Standish Group solution delivery success factors. Again, I have grouped similar success factors.

Success Factor Solution Design Contribution

User Involvement A comprehensive solution design with all the scope elements identified will
require user engagement. An effective user engagement process (such as those
identified in section 4.6 on page 161) will both gather information and get the
target business users involved. The business will contribute to the solution
design and be able to see and understand the real solution scope. This will allow
informed decisions to be made on what must be included and what can be
excluded or deferred.
Executive Management Support/ A solution engagement process will demonstrate management support for the
Executive Sponsorship solution. Detailed knowledge of the real project scope will allow management to
understand what they are sponsoring and to decide if the project is worthwhile.
Emotional Maturity (Managing Knowing the full and realistic extent of the project, derived from the solution
Expectations, Gaining Consensus) design, will allow expectations on what can be delivered and what is involved in
getting an operational solution to be managed.
Optimisation (Clarify Objective, Knowing the components of the entire solution will allow their delivery to be
Divide Larger Projects Into Multiple allocated to different solution delivery stages or separate delivery projects by
Smaller Projects) decision grounded in facts.
Clear Statement of Requirements The engagement process will both define requirements and embed these in the

Page 66 of 540
 Introduction to Solution Architecture

Success Factor Solution Design Contribution

Firm Basic Requirements context of a complete solution. The requirements and their delivery are shown
Clear Vision and Objectives/Clear together. The entire solution can be seen and understood.
Business Objectives
Proper Planning
Reliable Estimates Knowing the actual scope of the required full solution means that a plan to
Realistic Expectations achieve that includes all elements it can be developed. Evidence-based decisions
Smaller Project Milestones can then be made on the sequencing of solution delivery activities and the
Minimised Scope exclusion or postponement of components.
Modest Execution
Standard Software Infrastructure The solution design will identify the components of the solution, including the
Standard Architecture software components, either acquired and configured/customised or developed.
This will provide full visibility on what is required. These components can be
delivered using standard components where they are available within the
organisation’s enterprise architecture or where they can be acquired.
Formal Methodology
Agile Process
Competent Staff/Skilled Resources
Experienced Project Manager/Project A good project manager will seek to understand the full scope of the solution in
Management Expertise order to create a realistic and achievable delivery plan that includes the
Ownership necessary time, budget and resources. The project manager can then make
Hard-Working, Focused Staff rational decisions on phasing and scoping.
Other

Table 14 – Solution Architecture Contribution to the Standish Group Solution Delivery Success Factors

The following table summarises how a solution design process can address the organisational challenges expressed by Budzier
and Flyvbjerg.

Organisational Challenge Solution Design Contribution

Political bias and ineffective project
An effective and working solution design process should allow informed
sponsorship solution delivery sponsorship because the sponsors will have greater confidence
in the deliverability of the solution.
Ineffective governance structure Knowing the actual and required scope of the solution should allow the required
governance to be defined and put in place.
Unclear goals and business cases and The solution design engagement process will clarify the solution goals and link
success criteria business objectives to solution components. The engagement process will
involve the business users so they understand the solution design process and
participate in the solution design process.
Competing and shifting criteria An honest and complete solution design will present the business with what is
needed to achieve the required aims.
Lack of risk management A comprehensive solution design will allow risks to be identified and mitigating
and circumventing actions taken.
Big Bang approaches Knowing the actual scope of the required full solution means that a plan to
achieve that includes all elements it can be developed. Evidence-based decisions
can then be made on the sequencing and phasing of solution delivery activities
and the exclusion or postponement of components. Knowledge-based actions
can be performed on what to do to balance delivery.
No user involvement A comprehensive solution design with all the scope elements identified will
require user engagement. An effective user engagement process (such as those
identified in section 4.6 on page 161) will both gather information and get the
target business users involved. The business will contribute to the solution
design and be able to see and understand the real solution scope. This will allow
informed decisions to be made on what must be included and what can be
excluded or deferred.

Page 67 of 540
 Introduction to Solution Architecture

Table 15 – Solution Architecture Contribution to Budzier and Flyvbjerg Organisational Challenges

Good solution design is not the answer to all project failures and challenges. It can only go so far. It cannot protect the
organisation against other causes. Many of the reasons why solution delivery fails, either fully or partially, are due to
circumstances such as organisation or individual cognitive or other biases and other influences such as groupthink. Good
solution design cannot stop these. It may reduce their possibility or lessen their impact. Being aware of these biases and other
influences can alleviate their consequences.

Some of the causes of poor organisation decision-making are:

• Cognitive Bias – Poor or inaccurate judgements, illogical interpretations and decisions, characterised by patterns of
behaviour
• Strategic Misrepresentation – Deliberate misrepresentation in budgeting caused by distorted incentives
• Planning Fallacy – Systematic tendency to underestimate how long it will take to complete a task even when there is past
experience of similar tasks over-running
• Optimism Bias – Systematic tendency to be overly optimistic about the outcome of actions
• Focalism – Systematic tendency to become inwardly focussed and to lose situational awareness and appreciation of
wider context and display characteristics of cognitive tunnelling during times of stress
• Groupthink – The need for agreement, accord and compliance within the group results in a flawed, illogical and
inhibited decision-making processes and decisions

Figure 37 – Factors Affecting Good Solution Delivery Decisions

These factors can manifest themselves at times of solution delivery stress where the delivery project is experiencing pressure
and strain due to previous poor decisions.

There are many classifications and types of cognitive bias. They can be very difficult to avoid because of their embedded
nature in people’s personalities and their emotional and irrational basis. Cognitive biases are very real and can have damaging
effects. They can be grouped in a number of categories:

• Decision-
Decision-Making and Behavioural Biases - affecting belief formation and business decisions
• Probability and Belief Biases - affecting way in which information is gathered and assessed
• Attributional Biases - affecting the determination what was responsible for an event or action

Page 68 of 540
 Introduction to Solution Architecture

Some of the common decision-making and behavioural biases include:

• Anchoring – Relying too heavily on one piece of information when making a decision
• Attention Bias – Assigning greater weight to apparently dominant factors
• Bandwagon – Believing things because many others, believe the same
• Blind Spot – Seeing oneself as less biased than others
• Confirmation Bias – Interpreting information so as to that confirms preconceptions
• Exposure Effect – Greater preferences just because of familiarity
• Focusing Effect – Placing too much importance on one aspect
• Hyperbolic Discounting – Strong preference for immediate payoffs relative to later ones
• Information Bias – Looking for information even when it cannot affect action
• Irrational Escalation – Justifying increased investment based on the cumulative prior investment despite new evidence
suggesting that the decision was wrong
• Negativity Bias – Paying more attention and giving more weight to the negative rather than the positive
• Omission Bias – Viewing a harmful action as worse than an equally harmful omission or inaction
• Semmelweis Effect – Rejecting new evidence that contradicts an established paradigm
• Sunk Cost Effect – Assigning a higher value to disposal/loss compared with cost of acquisition
• Wishful Thinking – Making decisions based to what is pleasing to imagine instead basing decisions on evidence and
rationality
• Zero-
Zero- Risk Bias – Looking to reduce a small risk to zero rather than a greater reduction of a larger risk

Some of the common probability and belief biases include:

• Ambiguity Effect – Selecting an option for which the probability of a favourable outcome is known over an option for
which the probability of a favourable outcome is unknown
• Attentional Bias – Failure to examine all possible outcomes when making a judgment
• Availability Cascade – Belief gaining plausibility through increasing repetition
• Clustering – Perceiving patterns where none exist
• Optimism Bias – Judging future events in a more positive light than is warranted by actual experience
• Ostrich Effect – Avoidance of risk or the negative by pretending they do not exist
• Overconfidence Effect – Excessive or inflated belief one's performance, ability
• Serial Position Effect – Assigning greater weight to initial or recent events more than subsequent or later events
• Subadditivity Effect – Assigning a lower probability to the whole than the probabilities of the parts
• Subjective Validation – Considering information to be correct if it has any personal meaning or significance
• Valence Effect – Overestimating the likelihood of positive rather than negative outcomes

Some the common attributional biases include:

• Dunning–
Dunning –Kruger Effect – Where skilled underrate their abilities and unskilled overrate their abilities
• False Consensus Effect – Overestimation of agreement
• System Justification – Defending the status quo

Strategic misrepresentation is the deliberate misrepresentation in planning and budgeting caused by issues such as distorted
incentives. It is often a response to how organisations structure rewards and motivate individuals and groups. It is
characterised by:

• Deliberately underestimating costs to gain acceptance with understanding that costs will increase
• Not willing to face reality of high costs
• Overstatement or understatement of requirements
• Inclusion of ideology into planning

The underlying rewards system and processes need to be redesigned to eliminate this.

Page 69 of 540
 Introduction to Solution Architecture

Groupthink is the need for agreement, accord and compliance within the group. It results in a flawed, illogical and inhibited
decision-making processes and decisions. It happens when the group becomes dominated by small number of or single
individual who forces their beliefs on the group. There is a tendency for consensus and agreement and the desire to minimise
contention which means alternatives are not fully evaluated. The group isolates itself from information on alternatives.
Disagreement and dissent within the group are quashed or concealed through self-censorship

Figure 38 – Characteristics of Groupthink

Having written all of the above regarding the causes of solution delivery failures and challenges, there is one school of thought
that states that this concern with and focus on delivering information technology solutions on time and on budget is wrong.
It states that the more important objective is to deliver solutions that enable the organisation to transform its operations.
Some organisations have excelled at transformation and at creating entire new industries. Information technology systems are
of necessity new, untried and will involve trial-and-error to get right.

This provocative view is worth considering. But most solutions are delivered by more conventional organisations that have an
existing set of operations and an existing heterogeneous information technology landscape that needs to be maintained and
kept usable while new solutions are implemented. These organisations have limited resources that must be spent wisely. They
have a limited capacity to handle change and so must select their changes carefully. They have a limited time in which to
accomplish these changes. Finally, solution conception and design are the areas where new, untested and unproven ideas are
explored. Solution delivery should be a more matter-of-fact and routine process unless, in the case of an agile approach, there
is an element of discovery in this. Once the solution design is known, its implementation should have limited tentative,
explorational and experimental characteristics unless it is a pure research and development initiative. Some of the underlying
technologies may be new but this novelty can be allowed for. The complete solution is always much more than the sum of its
pure technology components.

Solution delivery failure is at least partially a failure of understanding the actual scope of the solution and failure to put
structures in place to achieve that delivery.

It is not really possible to create a plan to implement a solution if the complete scope of the work required in not known,
understood and accepted.

Similarly, the best project management practices will not make a poor solution design implementable, operable, usable,
supportable and maintainable. At best it will make the process for realising the deficiencies of the solution design and the
need for their remediation slightly less painful and unpleasant.

Page 70 of 540
 Introduction to Solution Architecture

3.1.1 The Business Value of Solution Architecture

The corollary to the previous section on solution delivery failure is what causes or influences solution delivery success.

The 2009 paper Business Value of Solution Architecture 9 attempted to answer this question. The authors note:

In the literature, project management, analysis & design and software development and testing, attract a lot of
attention and many methods and approaches have been devised for these activities.
…
None of these approaches recognizes explicitly the role of solution architecture, …

The paper examined 49 custom software delivery projects. About half of the projects related to software being developed for
companies in the financial sector. The remaining applied to other types such as industrial and public sector. There were a
range of project types from transformation, merger and acquisition, single function integration and lifetime extension.

Some of the authors’ key conclusions regarding the business benefits of solution architecture are:

The presence of an architecture governance process is significantly correlated with a lower expected value of
budget overrun, compared to a situation where there is no architecture governance process in the customer's
organization present. The difference in expected value is 19%.

The presence of an architect during the calculation of the technical price is significantly correlated with a lower
variance of the actual project budget, compared to a situation when there is no architect present during
technical price calculation. The difference in the standard deviation of the project budget overrun percentage is
21% (13% versus 34%)

The presence of a high-quality project architecture correlates with a decrease in time overrun of the project,
compared to a situation where there is a medium or poor quality project architecture present. The difference in
overrun is 55% (71% overrun versus 16% overrun).

Usage of solution architecture is correlated with a significant increase in customer satisfaction.

So, the involvement of high-quality solution architects in the solution design and delivery process resulted in:

1. 19% lower budget overspend

2. 21% small variance between actual and budgeted expenditure

3. 55% lower schedule overrun

4. Increased overall solution consumer satisfaction

The results of the analysis in this paper demonstrate that a high-performing solution architecture function can produce
significant business value.

3.2 Solution Architecture and Risk Management

9
Raymond Slot, Guido Dedene, and Rik Maes,
https://onderzoek.hu.nl/~/media/sharepoint/Lectoraat%20Architectuur%20voor%20Digitale%20Informatiesystemen/2009/B
usiness%20Value%20of%20Solution%20Architecture.pdf

Page 71 of 540
 Introduction to Solution Architecture

The previous section on solution delivery failures analysed some of the reasons for these failures and described how an end-
to-end approach to solution design will mitigate against the causes of failure.

A comprehensive view of the real scope of a solution that addresses all its components contributes to the management of risks
during solution delivery.

There are many risks that arise when implementing new solutions, especially ones that are large, complex and that touch
many parts of the organisation, as well as digital solutions that touch parties external to the organisation, such as:

• Product customisation
• Product functionality
• Product quality
• Vendor capability
• Solution complexity
• Solution delivery team
• Management

Risks are uncertain events that may occur with a probability that may or may not be known. If they occur, they will have
negative effect on the solution.

Solution architecture can assist with solution delivery risk management in two ways:

1. Passively – by defining all the components of the overall solution so their risks and by defining individual components
that have a low risk

2. Actively – by assisting with assessing the solution risks across all its components

The risks associated with a product or hosted or outsourced service will generally (but not always) be lower than a
development option. Product vendors tend to be specialists with more experience. The product already exists and is readily
available. It is in use by other customers and proven (or should be). These customers can be consulted. The vendor is
responsible for product support. The product is enhanced and maintained by the vendor and new functionality is typically
provided as part of maintenance and support agreement.

A product can always be changed and enhanced to suit the exact requirements of the organisation. The extent of the changes
applied affects the overall solution risk along the scale, from low to very high:

• Standard – functionality included as standard or that can be configured by business users

• Configuration – features and functions that can be added using configuration tools
• Customisation – features and functions not provided by the vendor
• Code Change, Developed Modules – code changes to the product

Page 72 of 540
 Introduction to Solution Architecture

Figure 39 – Scale and Complexity of Product Changes and Enhancements

More complex changes involve reimplementation and testing after the product has been upgraded or new releases of the
underlying base product have been applied. This is especially true of hosted or cloud-based multi-tenant solutions. Also, the
scheduling of changes on these platforms may be outside the control of the organisation. These involve cost and risk
throughout the life of the solution and delay subsequent upgrades.

There is a range of risks associated with the standard functionality provided (or supposed to be provided) by a product:

• Business requirements are not clearly articulated and subject to change

• Vendor does not understand the requirements of the business
• Business does not understand the functionality of the product
• Business cannot define the configuration and customisation changes required
• Vendor misrepresents the functionality of the product
• Product is not accepted by business users
• Product requires too much customisation to meet the business requirements
• Product cannot be configured or customised to meet the business requirements
• Product may be too complex to change to suit the needs of the business
• Product cannot interface with external systems
• Legacy data cannot be migrated to the product
• Product is not easily usable
• Product is unstable
• Product is not scalable
• Product is not secure

There are product technology risks associated with its underlying technology:

• The underlying technology is too old

• The underlying technology is too new
• The product or the technology may not meet the required performance or operations requirements

There are risks associated with vendor and their ability to supply and support the product:

• The product is new to the vendor

Page 73 of 540
 Introduction to Solution Architecture

• The vendor’s direction with respect to the development of the product is undefined or uncertain
• The vendor’s ability to support and develop the product are unclear
• The technical quality of the product is poor
• The vendor may not have sufficient implementation skills
• The quality of the vendor’s training and documentation is poor
• The vendor’s contract may impose onerous or unsatisfactory conditions

There are solution complexity risks:

• Range of technologies used

• Hardware limitations
• Process for applying customisations
• Number of components affecting integration effort
• Large number of stakeholders
• Organisation and business process change
• Scale of solution

There are solution delivery team and capability risks:

• Mixed skills of team

• Incorporating a new method, language, tool or process for the first time
• Optimistic assumptions on the functionality and ease of use of development tools
• Optimistic assumptions on productivity
• Geographically dispersed team making communication and coordination more difficult

There are management risks:

• Management is dictating an unrealistic schedule

• Not handling creeping requirements and change proactively
• Inadequate quality control, causing delays in fixing unexpected defects
• Unanticipated risks associated with package software upgrades and lack of support

The solution architect should take a proactive to identifying risks during the solution design process and also during
subsequent solution delivery. Solution design risks can be avoided or mitigated through greater solution knowledge (see
section 4.2.1 on page 95). This involves:

• Identifying the known solution design risks and their potential impact on solution delivery, implementation and
operation
• Assessing the probability that each risk will occur – beware of assigning pseudo-scientific evaluations of risk probability
• Estimating the potential negative impact if the event associated with the risk occurs
• Calculating a risk reserve that should be included in the solution delivery resource estimates to allow for risk
• Highlighting the high-priority risks and leading the development of plans to handle then
• Ensuring the that risks are recognised and managed

Risks are associated with the solution knowledge unknowns, both the known unknowns and the unknown unknowns.

The assessment of the impact and probability of occurrence of risks can be subjective. One person’s view of a risk, probability
of its occurrence and estimate of impact will be different from another’s.

Solution components will have options. Each option will have a different set of risks. These will need to be balanced against
the cost of these options. Solution architects need to be proactive in identifying risks and need to show leadership in how they
are evaluated and managed.

Page 74 of 540
 Introduction to Solution Architecture

3.3 Architecture
Architecture Disciplines, Context
Context and Interactions

3.3.1 Introduction

There are multiple overlapping logical information technology architecture disciplines that comprise the full spectrum of IT
architecture. Not all organisations will have all roles. Also, these roles can be combined.

Figure 40 – IT Architecture Disciplines

In summary, the objectives of these IT architecture roles are:

• Enterprise Architecture – this defines, maintains, manages and updates the overall set of information technology
standards, policies, principles and direction within which the organisation’s IT systems are sourced, implemented and
operated.

• Business Architecture – this is concerned with a structured approach to analysing the operation of an existing business
function or entire organisation with a view to improving its operations or developing a new business function, with a
strong focus on processes and technology.

• Information and Data Architecture – the defines the organisation’s standards for the management of data and data-
related technologies across the organisation across data types and sources including data management and governance,
data quality, data operations and reference and master data management and through its lifecycle.

• Technical Architecture – this is concerned with translating functional solution design architectures into technology-
specific detailed implementation-oriented specifications and solution delivery documentation so the software
components of a solution can be built, acting as a bridge between solution architecture and the delivery function and
designing new delivery approaches.

• Application Architecture – this is concerned with defining and managing the organisation’s portfolio of information
technology applications, their integrations, interactions and data exchanges between applications and the flow of data
into and out of applications. It aims to ensure that the application portfolio meets the current and planned future needs
of the organisation.

• Technology Infrastructure
Infrastructure Architecture – this defines and manages the organisation information technology
infrastructure across the computing, storage and communications landscape. It ensures that the infrastructure is able to
meet the current and planned future needs of the organisation.

Page 75 of 540
 Introduction to Solution Architecture

• Service Architecture – this is concerned with defining and maintaining the organisation’s service management and
service operations framework for the operational information technology applications and infrastructure including
support, new releases and changes, capacity and performance, events and alerts, service levels, continuity, resilience and
availability.

• Security Architecture – this defines, maintains, enforces and manages the architecture and set of facilities and tools to
protect and defend the organisation’s information technology hardware, software and data assets from attacks, threats
and vulnerabilities that can lead to theft, damage and disruption, both from within and from outside the organisation.

• Solution Architecture – this is concerned with the definition and description of new (Information Technology) solution
designs to resolve problems or address opportunities.

These information technology architecture disciplines all have one factor in common: they are concerned (or need to be
concerned) with providing the business with an operational, functional information technology unit that provides a set of
usable business applications and related supporting applications and processes that enable the business to work.

The IT architecture disciplines should and can contribute to the success of the business in two ways:

1. By taking the needs of the business for business systems and supporting and enabling technologies into an information
technology infrastructure and a portfolio of business solutions

2. By identifying potential uses for new technologies to enable the business to operate more effectively

Figure 41 – IT Architecture Two-

Two- Way Contribution to the Business

The topic of solution architecture’s potential to contribute to information technology and business innovation is covered in
Chapter 9 on page 534.

IT architecture in general should both enable the business respond to and realise changes in response to external and internal
pressures and should identify business opportunities in technology trends and occasions for changes and greater efficiencies.

IT architecture needs to be able to contribute to the development of business strategy and to be trusted to be able to make a
contribution. That trust has to be proven and earned.

The IT architecture functions need to be involved along the entire business application portfolio solution journey.

Page 76 of 540
 Introduction to Solution Architecture

Figure 42 – IT Architecture Discipline Involvement

Involvement Throughout Solution Portfolio Delivery

The separate IT architecture disciplines are (or should be) involved in the spectrum of activities concerned with the
translation of business strategy and objectives into an integrated portfolio of IT solutions. All too commonly, the complex
and fragmented operational IT architecture disciplines and their multiple separate views and handoffs between them
contribute to the problems between business and IT.

Design guidance will be needed throughout the solution delivery and implementation process. The solution architect should
take on the role of solution subject matter expert and provide this solution leadership.

The IT architecture disciplines need to work with one another in order to provide an effective service to the IT function and
to the wider business organisation. The business organisation needs a portfolio of business applications as well as a set of
infrastructural applications to support its business operations. The IT architecture disciplines play a crucial role in
guaranteeing that this happens effectively, efficiently and in a timely and cost-effective manner.

Figure 43 – Interactions Between IT Architecture Disciplines

In particular, the solution architecture function needs to interact with the other IT architecture disciplines in order to deliver
complete solution designs:

Page 77 of 540
 Introduction to Solution Architecture

• Enterprise Architecture – to ensure that solutions being designed comply with the overall information technology
standards and framework and to contribute to the development of these standards

• Business Architecture – to ensure that the solutions meet the needs identified during the business architecture
engagement, if solutions are being designed within that context

• Information and Data Architecture – to ensure that the data structures, flows and integrations comply with
organisation data standards and that data structures and content are reused to avoid proliferation of master and
reference data

• Application Architecture
Architecture – to ensure that the software components of the overall solution, either developed or acquired
and configured and customised, are designed to comply with the organisation’s application and integration standards

• Technical Architecture – to assist with the translation of software components of the overall solution into technical
specifications for development

• Security Architecture – to ensure that the overall solution and its components and interactions comply with the
organisation’s security standards

• Infrastructure Architecture – to ensure that the infrastructural components – hardware, communications and
infrastructural software elements - of the overall solution fit with the organisation’s infrastructure and that infrastructure
components are reused and standardised as much as possible

• Service Architecture – to ensure that the solution design includes and complies with service management standards

Additionally, the solution architecture function must interface directly with the business and with the business analysis
function during the solution design process.

The solution architecture function is the glue that joins all these elements together – business, business analysis, other IT
architecture disciplines and the teams involved in the delivery of the various solution components – to create usable and used
solutions designs that are translated into operable and usable solutions.

Figure 44 – Solution Architecture – Bringing It All Together

Solution architecture both works directly with the business organisation and the business analysis function to understand the
requirements for and the background of the desired solution. Solution architecture then incorporates the standards developed

Page 78 of 540
 Introduction to Solution Architecture

by the other architecture areas into the solution design. Solution architecture subsequently works with the solution delivery
and implementation teams as the solution design is translated into reality.

All too frequently, the information technology architecture disciplines operate in a self-contained, disintegrated and siloed
manner with no overall management, separate and inconsistent approaches to work and limited communications between
one another. The individual architecture practices throw work over the wall at one another with poor handoffs and no overall
strategy

Figure 45 – Siloed Operation of Information Architecture Disciplines

There is deficient or absent cooperation between the architecture areas. Frequently there are adversarial relationships between
disciplines that are characterised by infighting. This leads to an overall lack of efficiency and effectiveness across the IT
architectures. In turn, this contributes to poor perception of the IT function by business.

Unfortunately, the siloed operations within the IT architecture disciplines is regularly replicated in the overall solution
delivery process, as discussed in section 2.6.

Page 79 of 540
 Introduction to Solution Architecture

Figure 46 – Nesting of Siloed Operations Within Solution Delivery and Within IT Architecture Disciplines

This nesting of functions whose operations are separated from one another contributes to complexity in solution delivery and
to increased chance of solution failure.

3.3.2 Run the Business and Change the Business

Organisations in general and the information technology function in particular need to be good at two general sets of skills,
each divided into a doing and a managing the doing portion.

• Run the Business (RTB) – business as usual operations

o Doing – Run The Business
o Managing The Doing – Run The Business

• Change the Business (CTB) – changing existing operations to survive, compete, grow or expand
o Doing – Change the Business
o Managing The Doing – Change The Business

Not all these activities are of equal weight or importance to the IT function. Run The Business work will always dominate IT
resources.

Page 80 of 540
 Introduction to Solution Architecture

Figure 47 – Balance Between Run the Business and Change the Business Activities

These information technology architecture disciplines have both RTB and CTB dimensions to a greater or lesser extent.

The actual or perceived organisation run/change profile and what it really is may be different. There may be unnoticed latent
demand for solutions that is not recognised or is ignored. This can be one source of shadow IT described in section 3.3.5 on
page 86.

Solution architecture and the solution designs it develops and creates generally introduce changes to existing processes,
organisation structures, solutions, applications, technology, infrastructure and structures. These solutions are a way of
introducing innovation and change into the organisation. The solution architecture function resides largely in the Change the
Business portion of the IT function.

The extent of the need for an effective solution architecture function depends on the size of the Change the Business
workload. The solution architecture can deliver value after solutions have been implemented when those solutions need to be
enhanced and modified. If the organisation does not envisage the need for many new solutions or changes to existing
solutions, the need for and the corresponding size of the solution architecture function will be small.

The organisation needs to be honest about its need for solution architecture.

3.3.3 IT Architecture Principles

The IT architecture disciplines in general and solution architecture in particular should define a set of overlapping and
sometimes contradictory principles that underpins its operation.

Page 81 of 540
 Introduction to Solution Architecture

Figure 48 – IT Architecture Principles

These principles are:

• Focus On Generating Business Value Quickly – speed of delivery of solutions to allow the business respond to changes
and to take advantage of new opportunities quickly is important. Subject to the constraints of knowing the scope of the
solution, enable the business stakeholders make informed decisions on the options to achieve results quickly,
understanding the consequences and implications.

• It Is All About The User Experience – there can be two types of solution consumer: the internal organisation user and
the external organisation customer user. The latter may experience the solution directly or indirectly by interacting with
internal users. Solutions exist to be usable, useful and to be used. People are always part of the operation and use of any
solution. Solution usability contributes to the long-term success of a solution. Users experience the complete operational
solution across its entire scope and experience its functional and quality properties and the underlying business
processes.

• Always Look for Innovation – the solution architect should always take the larger architectural view of any solution and
seek to improve and add value through appropriate innovation.

• Speed of Delivery Is Important – the solution architect should structure the solution design to allow components be
implemented in parallel. The solution architect should structure and schedule the design work to optimise the use of the
delivery teams, keeping the delivery engine occupied and optimally engaged.

• Appropriate and Necessary Detail and Complexity Only – necessary complexity is good. Unnecessary complexity is
not. This has two applications: including only necessary and useful detail during the solution concept and exploration
stage and removing unnecessary complexity from the ultimate solution design.

• Simplify, Simplify,
Simplify, Simplify – keep solution designs as simple as possible. Question solution designs and eliminate
redundant or superfluous elements. Use common standards and infrastructural application components as much as is
practical.

• Leadership, Proactivity and Co-

Co-operation – demonstrate solution leadership to the business functions. Respond to the
concerns and issues of the business functions rather than waiting passively to be asked to contribute. Understand the
concerns of the business and their need for usable business solutions.

• Data Breathes Life Into Systems – remember that the movement of data – data input, data processing and
transformation, data outputs, data access, data reporting and analysis and data integrations – are at the heart of business
applications. Data breathes life into solutions. Data quality, speed and ease of data access and data throughput have to be
central to any solution design.

Page 82 of 540
 Introduction to Solution Architecture

• Embed Security As Standard – security cannot be an afterthought, considered after the solution has been designed and
retrofitted to the solution environment. Security needs to be embedded in all components of the solution and at all stages
in the processing pipeline, especially at the periphery. There needs to be a common set of security standards and
associated hardware and software infrastructure to support solution security across the entire landscape.

• Live With Mixed Technical Environment – while an entirely homogenous hardware and software environment is a
desirable target, it is very difficult, expensive and time-consuming to achieve. All but the youngest organisations will have
a legacy of mixed information technology solutions. While it is possible to reduce the amount of heterogeneity in the
information landscape, its complete elimination is not realistic or achievable. The benefits of simplicity in the
information technology environment are long-term and largely of direct benefit to the IT function in terms of reduced
support and operating costs. The wider business organisation will see those benefits only indirectly. Too much effort
spent on simplification of the information technology environment means fewer resources are available to work on
business solutions. The IT function should not let itself become obsessed with simplification at the expense of other
business-oriented work. Environment simplification can be contributed to by investment in infrastructural solutions –
such as data interface, data integration and exchange – that can be used commonly across multiple solutions.

3.3.4 Problems with IT Architecture Operation

The unhappy reality is that the operation and interoperation of the set of IT architecture disciplines and the groups that
perform those functions can be characterised by many of the following failings, flaws and deficiencies.

Figure 49 – IT Architecture Failings

• All To
Too Frequently Inwardly Focussed, Staffed By IT Personnel, Focussed On IT Rather Than On the Business –
the architecture functions, including business architecture (which is not a widely practiced discipline), even though they
provide a service to the business do not second business representatives to them to gain business experience and
knowledge.

• Demonstrates
Demonstrates Aspects of Groupthink and Focalism – groupthink and focalism occur where the group becomes
inwardly focussed and does not learn or believe that it can learn from anyone outside the group. The group becomes
dominated by small number or a single individual who force their beliefs on the group. This leads to decisions being
made not based on wider concerns and information. The result is cognitive tunnelling where the group disregards
external evidence and pursues its own initiatives irrespective of the damage they cause or the resources they waste.

Page 83 of 540
 Introduction to Solution Architecture

• Too Remote From Business Concerns and Not Business Oriented and Focussed – the IT architecture disciplines do
not ground their work in the context of business needs and business operations. Their work is internally focussed on
technologies rather than addressing the wants of the business.

• Concerned With Documenting Current IT IT Technology State, Standards and Processes in Detail Rather Than
Looking to the Future – IT architecture, especially enterprise architecture, is overly concerned with detailing and
recording the current IT systems and platforms rather than looking to define a target future state that addresses more
effectively business needs. The current state needs only enough information to allow its deficiencies and problems to be
identified. It is only important insofar as it contributes value to the future.

• Too Dogmatic, Rigid and Inflexible – the IT disciplines do not respond and react flexibly to business needs. They
concentrate on the internals of their practices.

• Focused on
on Compliance, Control and Governance and Adherence to Rules – the IT architecture practices value
compliance with their internal rules and on governance standards to the detriment of service delivery.

• Obsessed w ith Architecture Frameworks, Reference Models and Patterns – IT architecture, especially enterprise
architecture, looks at architecture frameworks as ends in themselves rather than as a means of adding value and
delivering a service. The merit and value of architecture patterns and their applicability to real world business concerns
and issues tend to be overestimated.

• Overly Controlling – the IT architecture disciplines seek to impose controls that they view as important and relevant
but which are driven only by internal concerns.

• Reactive – the IT architecture disciplines react to business needs and business changes rather than seeking to be
proactive in identifying problems and opportunities, either internally with their own operations or externally with the
business, especially in the value that can be derived from exploiting new technologies.

• Work Not Linked To Performance Metrics – the IT architecture functions do not measure the value of the work they
do and the results, if any, they achieve and the outcomes they generate. There is no assessment or evaluation framework
with constituent performance or results indicators that links the costs of the IT architecture functions to the value
realised.

• Speaks the Language of Technology Rather Than Business – the IT architecture disciplines communicate with the
business using the language of IT. They do not speak to the business in their own language or see to express themselves
in that way.

• Communicates To the Business Badly, If At All – the IT architecture functions do not regularly communicate what
they do, what their role in the overall organisation it and what benefits and values they provide to the organisation.

• Not Concerned With Delivery – the IT architecture disciplines do not relate their work to the delivery of operable,
usable, efficient, effective solutions and services to the business.

• Does Not Measure Its Delivery In Terms of Business Benefits Realised – the IT architecture functions do not
understand the benefits that are realised from the work they do and the contribution they make either to the IT function
or the overall business organisation. They do not have a benefits realisation measurement structure or framework.

• Slows Down Rather Than Accelerates Delivery through Disproportionate Governance

Governance – a far too common
consequence of the operation of the IT architecture disciplines is that solution delivery is slowed down. For example, the
introduction of new technologies that would contribute to business success is frequently prevented or stalled. Failure to
comply with architecture governance standards, whose value have not been established or proven, is used as an excuse to
inhibit change.

These failings within the IT architecture functions lead to failings in the relationship the business organisation has with the IT
function. IT architecture does not provide technology leadership to either the IT function or the business organisation. The

Page 84 of 540
 Introduction to Solution Architecture

business does not seek out the services of the IT architecture disciplines for advice or technology consulting services. The
business organisation wants a flexible IT function that enables it respond quickly to business needs and changes. The IT
function responds slowly and provides a poor overall service to the business.

Figure 50 – IT and Business Relationship Failings

The consequence of these failings is that the business organisation bypasses the IT function and acquires information
technology solutions and services directly from external service providers. Given the increasingly pervasive availability of
externally hosted solutions requiring no central information technology infrastructure, this has become a very easy and
progressively more common route for the business to take.

Figure 51 – Consequences of Failing Business and IT Relationship

The business organisation also bypasses the internal IT function by outsourcing the provision of IT services to external
service providers.

Page 85 of 540
 Introduction to Solution Architecture

3.3.5 Shadow IT

This bypassing of the IT function by the business organisation for IT solutions leads to the growth of Shadow IT –
information technology assets – applications, data and infrastructure - that are outside the control of the IT function. In the
medium term, Shadow IT poses substantial risks for the organisation is terms of security of data and applications, lack of
compliance with the relevant required regulatory standards, larger than anticipated costs because of the use of subscription-
based payments and because costs are not controlled and the use of service providers that may not continue in business,
leaving the organisation without the contracted service.

However, the business organisation tolerates these risks in order to get the services and solutions it requires from external
sources when it comes up against the barriers imposed by the internal IT function.

Figure 52 – Growth of Shadow IT

The size of and the growth of Shadow IT within organisation is a symptom of an IT function that the business organisation
does not trust or rely on or feels it is able to depend on to provide the right set of solutions within the right time.

Because Shadow IT is just that, in the shadows and not exposed to detailed analysis, its size is difficult to quantify.

In 2017, the Everest Group estimated that Shadow IT represented 50% of more of the total IT spending of large
organisations.10

In 2013, CEB Global (now part of the Gartner Group) estimated that the proportion of IT spending outside the IT function
was of the order of 40%.11 In the same CEB survey, the IT function estimated that this proportion of the IT spend was only
20%.

Cisco published in 2015 an analysis of cloud application usage that indicated that IT departments estimated their
organisations were using 51 cloud services on average while in reality 730 cloud services were being used, a difference of 15

10
See:
https://www.everestgrp.com/2017-04-eliminate-enterprise-shadow-sherpas-blue-shirts-39459.html/
https://www.cio.com/article/3188726/it-industry/how-to-eliminate-enterprise-shadow-it.html
11
See:
https://www.forbes.com/sites/tomgroenfeldt/2013/12/02/40-percent-of-it-spending-is-outside-cio-control/

Page 86 of 540
 Introduction to Solution Architecture

times.12 Cisco also estimates that the difference between the IT department’s understanding and the reality in terms of usage
of cloud services grew from a multiplier of 7 to 10 to 15 in one year. This demonstrates what was written earlier about the
easy availability of cloud-based solutions.

In 2015, Logicalis conducted a survey of over 400 global CIOs. 90% said there were sometimes bypassed the business. 31% of
CIOs said they were routinely bypassed when the business was making IT buying decisions.13

CipherCloud published a report on cloud adoption14 in which they identified issues with the use of unsanctioned cloud
applications:

86% of cloud applications used by enterprises are unsanctioned “Shadow IT”

Our study found that enterprises vastly underestimate the extent of Shadow IT cloud applications used by their
organizations. Various media sources claim 10% to 50% of cloud applications are not visible to IT. Our
statistics show that on average 86% of cloud applications are unsanctioned. For example, a major US enterprise
estimated 10–15 file sharing applications were in use, but discovered almost 70.

The CipherCloud report also identifies a lack of knowledge of the extent of such Shadow IT usage in organisations:

Enterprises Underestimate the Extent of Shadow IT

We all know that the use of Shadow IT within businesses is exploding, but few enterprises have been able to
accurately assess the extent of the problem. Self-reported surveys of the percent of enterprises using cloud
services range from as low as 19%1 to 50%—clearly ignoring Shadow IT. Other surveys have shown as many as
80%1 of end-users admitting to using unsanctioned applications, but without any measurements of actual
usage.

The Cloud Security Alliance published a report15 in January 2015 on the adoption of cloud applications by organisations. In
this report, they noted:

Employees are more empowered than ever before to find and use cloud applications, often with limited or no
involvement from the IT department, creating what’s called “shadow IT.” Despite the benefits of cloud
computing, companies face numerous challenges including the security and compliance of corporate data,
managing employee-led cloud usage, and even the development of necessary skills needed in the cloud era. By
understanding the cloud adoption practices and potential risks, companies can better position themselves to be
successful in their transition to the cloud.

The concerns raised by survey respondents in relation to cloud applications and Shadow IT were:

The survey respondents’ primary concerns about Shadow IT are:

• Security of corporate data in the cloud (49 percent)

• Potential compliance violations (25 percent)
• The ability to enforce policies (19 percent)

12
See:
https://blogs.cisco.com/cloud/shadow-it-and-the-cio-dilemma
https://blogs.cisco.com/cloud/shadow-it-rampant-pervasive-and-explosive
13
See:
https://www.logicalis.com/news/cios-line-up-to-transform-it-in-response-to-the-shadow-it-phenomenon/
https://www.logicalis.com/globalassets/group/cio-survey/cio-survey-2015_final3.pdf
14
Cloud Adoption & Risk Report in North America & Europe - 2014 Trends Published by CipherCloud in February 2015
http://pages.ciphercloud.com/rs/ciphercloud/images/CipherCloud-Cloud-Adoption-and-Risk-Report.pdf
15
Cloud Adoption Practices & Priorities Survey Report Published by the Cloud Security Alliance.
https://downloads.cloudsecurityalliance.org/initiatives/surveys/capp/Cloud_Adoption_Practices_Priorities_Survey_Final.pdf

Page 87 of 540
 Introduction to Solution Architecture

• Redundant services creating inefficiency (8 percent)

They also identified a lack of knowledge about the use of cloud applications:

Only 8 percent of companies know the scope of shadow IT at their organizations, and an overwhelming
majority (72 percent) of companies surveyed said they did not know the scope of shadow IT but wanted to
know. This number is even higher for enterprises with more than 5,000 employees at 80 percent. Globally, 71
percent of respondents were somewhat to very concerned over shadow IT. There are some stark geographic
differences, with 85 percent of APAC respondents concerned versus just 66 percent and 68 percent of their
Americas and European counterparts, respectively.

This range of survey and other information illustrates the scope and concerns about Shadow IT, especially in the era of cloud
applications.

The extent of the problem of Shadow IT and the bypassing of the internal IT function may be masked by IT outsourcing
which may be notionally counted as a central IT spend. Some IT outsourcing activities are caused by the business
organisation bypassing the IT function when acquiring IT services.

Shadow IT has existed since there was a centralised IT function. The original PC was effectively a form of Shadow IT, reacting
against the inflexibility, slowness and lack of access to information by providing end-user direct access to information
processing facilities.

Shadow IT in the form of end-user computing (EUC) – applications typically developed using tools such as Excel and Access
– existed long before cloud applications became pervasively available and still continues to exist. These applications are
typically developed without any formal analysis, design and testing. They evolve from the simple to the complex and become
important to the daily operations of a business function or an organisation. They are contributed to by many people over
time. They are not formally supported or documented. The well-proven risks that are associated with these EUC applications
are now being transferred to cloud-based Shadow IT applications.

There are many reports of substantial losses being attributed to EUC applications, especially Excel. The following table lists a
small number of these.

Publication Details Estimated

Amount of
Loss
https://www.reuters.com/article/u Lazard Ltd (LAZ.N), the investment bank that advised SolarCity Corp $400 million
s-solarcity-lazard- SCTY.O on its $2.6 billion sale to Tesla Motors Inc (TSLA.O), made
idUSKCN11635K an error in its analysis that discounted the value of the U.S. solar
energy company by $400 million, a regulatory filing by Tesla showed
on Wednesday.
http://ww2.cfo.com/spreadsheets/ Tibco Software shareholders will be getting $100 million less than $100 million
2014/10/spreadsheet-error-costs- originally anticipated from the company’s more than $4 billion sale to
tibco-shareholders-100m/ Vista Equity Partners as a result of a spreadsheet error that overstated
Tibco’s equity value.

According to a regulatory filing, Goldman Sachs, which is advising

Tibco on the deal, used the spreadsheet in calculating that Tibco’s
implied equity value was about $4.2 billion. The merger agreement,
reflecting that number, was announced Sept. 29.
http://calleam.com/WTPF/?p=551 Sometimes the mightiest of the mighty is humbled by the meekest of Approximate
7 the meek. Microsoft Excel may not be the most grandiose software ly $6B
tool in the market, but it’s amazing capabilities mean that it is one of
the most widely used there is. As those of us who are regularly users
know, there is however a dark side to the mathematical marvel that
Excel has become. As you are absorbed into the wizardly magic of its
number crunching capabilities, it is all too easy to make a mistake,

Page 88 of 540
 Introduction to Solution Architecture

Publication Details Estimated

Amount of
Loss
and, once your formulas are wrong, it be can be very hard to see that
you have gone wrong.

J.P. Morgan Chase, one of the world’s most mighty banking and
financial services firms, is one organization that has learned the risks
of Excel the hard way. In an incident that drew worldwide attention,
J.P. Morgan lost billions of dollars in the so called “London Whale”
incident. The London Whale was a trader based in J.P. Morgan’s
London Chief Investment Office (CIO). He had earned his nickname
because of the magnitude of the trading bets he was making. It is said
that his bets were so large his actions alone could move a market.
Despite his undeniable power, things went seriously wrong between
Apr and Jun 2012 and a poorly positioned trade resulted in losses that
eventually totalled up into the billions of dollars.

According to available reports, the part of the CIO office involved was
responsible for managing the bank’s financial risk using complex
financial hedging strategies in the derivatives markets. To support the
operations J.P. Morgan had developed a “Synthetic Credit Value at
Risk (VaR) Model” that helped them understand the level of risk they
were exposed to and hence make decisions about what trades they
should be making and when.

The tool had been developed in-house in 2011 and was built using a
series of Excel spreadsheets. According to J.P. Morgan’s own report to
their shareholders that was published following the disaster, the
spreadsheets “had to be completed manually, by a process of copying
and pasting data from one spreadsheet to another”. To pick what
appears to be an appropriate word in this particular case: YIKES!
Immediately any serious user of Excel would know that relying on
copy and paste is risky business. One minor slip and the data you
have isn’t what you thought it was. One accidental move and you can
wipe out the embedded formulas without realizing what you’ve done.
Relying on copy and paste in a tool that supported billion dollar
transactions seems unfathomable to me.
https://www.sec.gov/news/press/2 Feb. 3, 2011 – The Securities and Exchange Commission today $232 million
011/2011-37.htm charged three AXA Rosenberg entities with securities fraud for
concealing a significant error in the computer code of the quantitative
investment model that they use to manage client assets. The error
caused $217 million in investor losses.

AXA Rosenberg Group LLC (ARG), AXA Rosenberg Investment

Management LLC (ARIM), and Barr Rosenberg Research Center LLC
(BRRC) have agreed to settle the SEC's charges by paying $217
million to harmed clients plus a $25 million penalty, and hiring an
independent consultant with expertise in quantitative investment
techniques who will review disclosures and enhance the role of
compliance personnel.
https://www.theglobeandmail.co A slip of the hand in a computer spreadsheet for bidding on $24 million
m/report-on-business/human- electricity transmission contracts in New York will cost TransAlta
error-costs-transalta-24-million- Corp. $24-million (U.S.), wiping out 10 per cent of the company's
on-contract-bids/article18285651/ profit this year.

Page 89 of 540
 Introduction to Solution Architecture

Table 16 – Errors in End User Computing Applications Leading to Financial Losses

Many companies have suffered and continue to suffer very substantial financial losses due to errors and misuse of computer
applications, mainly Excel-based, developed by end users.

Chartis Research16 produced in July 201617 an analysis of the risks of such EUC applications to financial services
organisations in which they stated:

Chartis estimates that the current End User Computing (EUC) Value at Risk (VaR) for the largest 50 FIs
(Financial Institutions) is $12.1 billion (bn) (at a confidence interval of 97.5%, over a one-year period). The
estimated annual average VaR for large FIs is $285 million (m) per institution. The results of our methodology
applied to publicly disclosed loss events gave an estimate of the VaR that large FIs are exposed to, though it
does not take into account secondary effects such as regulatory fines, reputational damage, loss of customers
etc. Chartis believes there is a strong qualitative argument that the potential secondary impact of EUC risk is
significantly larger than the direct losses covered in this paper.

The problem of the business bypassing the central IT function is getting worse. The failure of IT architecture to engage with
business requirements is one cause of this. This leads to a fragmented IT solution landscape that is characterised by problems
such as:

• High variability and lack of standardisation across business units, driven by changes in business strategy, governance,
organisation and process

• Inconsistent data definitions, multiple databases, releases and configurations which result in duplication of licenses,
duplicate and inconsistent information, complexity in testing, no single version of the truth and no control of master and
reference data

• Multiple vendors, multiple instances and versions which add complexity in procurement, development and release
management, resulting in higher costs and longer time to market

• Multiple operating environments, multiple hardware vendors and types, leading to higher maintenance and personnel
costs, greater instability and time-to-fix

• No control of costs

• No control of risks associated with failure to comply with relevant regulations

• No control of risks associated with failure of external service providers

• No control of risks relating to data privacy and data protection

It may simply a matter of time before a similar set of stories regarding EUC applications starts to emerge for cloud-based
applications.

The EUC Shadow IT problem has not been resolved. So, the cloud application Shadow IT may not also be resolved easily.

The solution architecture function can at least seek to minimise both its use and the likelihood and impact of problems by
engaging with the business function earlier to identify the need for solutions.

16
See:
http://www.chartis-research.com/
17
Quantification of End User Computing Risk in Financial Services
http://www.clusterseven.com/wp-content/uploads/2016/07/Quantification-of-EUC-Risk-Final.pdf

Page 90 of 540
 Introduction to Solution Architecture

Chapter 4. Solution Architecture Engagement and the Solution Design Process

4.1 Introduction

This chapter contains details on solution architecture and the solution design processes across a range of business
engagement types. It discusses how solution architecture fits into the overall organisation and the information technology
function. It discusses the topics of:

• Problem and solution knowledge and complexity

• The solution design and delivery process

• How the solution architecture function needs to interface with the business analysis function, especially in relation to
requirements gathering and business process analysis

• The ways in which the solution architecture function can engage with the business to design solutions to resolve
problems or address opportunities, including describing a number of detailed engagement processes that can be used at
different stages of solution design

• The importance of solution usability and the solution consumers’ experience of the solution

• The need to take data architecture view of the solution from the initial stages of solution design and the approaches and
frameworks that can be used to make this easier

• The necessity to consider solution security and privacy

• The artefacts that can be created during the various engagement and design processes

Page 91 of 540
 Introduction to Solution Architecture

• The process for validating solution designs

Solution architecture and solution design needs to operate in a wider organisational context. At this high level, this context is:

Figure 53 – S olution Design in an Outline Organisation Framework

This is a generic representation. It will be different for individual organisations and businesses, such as those operating in the
public and private sectors. The organisation defines its strategy, informed by external factors such as its operating
environment, business pressures, drivers for change and the legal and regulatory framework to which it is subject. The
organisation then defines its structure and processes to achieve the strategy. The organisation then creates its overall
information technology strategy with the help of the IT function. The organisation strategy and IT strategy need to be
synchronised so the latter assists with the achievement of the former. The IT strategy leads the design, delivery and operation
of the portfolio of solutions needed to run the organisation. These solutions must harmonise with the organisation structure
and the operational business processes.

The Solution Architecture and Design function needs to be involved both in the design of the required business solutions and
in making certain that the solutions are what the business really needs to operate the business processes.

The following diagram illustrates in more detail the components and their linkages needed to make sure than the business
gets solutions that meet their needs to achieve business and information technology alignment

Page 92 of 540
 Introduction to Solution Architecture

Figure 54 – Organisation Context of Solution Architecture

The numbered elements of the diagram above are:

1. Business Strategy – the business or organisation must create an overall strategy for its operations defining what it does
and what it seeks to achieve. The business strategy provides the context in which all other activities take place.

2. Business Objectives – the business strategy is translated into a number of objectives that must be achieved in order to
realise the business strategy.

3. Business Structure and Operational Model – an organisational structure and operating needs to be defined in order to
achieve the defined set of objectives.

4. Business Processes – the operational business processes needed to actualise the achievement of the defined objectives
must be defined and implemented.

5. Business IT Strategy – the organisation needs to define an overall information technology strategy that encompasses the
solutions, systems and applications needed to operate the business processes.

6. IT Function Strategy – the organisation’s information technology function must define its own strategy to achieve the
wider organisation’s business IT strategy. This must include the information technology function structures and business
processes.

Page 93 of 540
 Introduction to Solution Architecture

7. Enterprise Architecture – the enterprise architecture and other IT architecture functions must define the information
technology standards and frameworks within which solutions, systems and applications will operate.

8. Required Operational Business Solutions – the business solutions and systems needed to implement and
operationalise the business processes must be identified.

9. Business
Business Solution Analysis and Design/Selection
Design/Selection – the required business solutions must be defined and designed.

10. Solution Implementation and Delivery – the designed solutions must be implemented and transitioned to an
operational state.

11. Management and Operations – the delivered solutions must be brought under the control of the operations function.

12. Required Structure, Capabilities and Resources – the information technology function must define and implement its
own structure and acquire the necessary capabilities and resources to implement its own strategy in order in turn to
implement the organisation’s IT strategy.

13. Required Operational Processes – the information technology function must define and implement its internal
processes.

14. Required Support Business Solutions – the information technology function must define solutions and systems needed
to implement and operationalise the business processes

15. Support Solution Analysis and Design/Selection – the solutions required to support the operation of the information
technology function

An effective solution architecture function and solution design process is needed to ensure the needs of the business are
responded to by the IT function in terms of providing a portfolio of usable and useful solutions.

As mentioned above, there are three interrelated strategies using the organisation change domain model discussed earlier:

1. Business Strategy
• Defines the strategic goals, imperatives and initiatives to direct the business
• Business strategy is the principal driver of IT strategy
• IT strategy is developed to support the business strategy
• IT can also provide opportunities to reshape the business strategy

2. Organisation IT Strategy
• Defines the strategic direction of information technology within the organisation required to support and achieve
business strategy.

3. IT Business Function Strategy

• Defines the strategic direction of the IT function to develop, deploy, operate, manage and support the IT systems
needed by the business
• Includes processes and supporting technology

Page 94 of 540
 Introduction to Solution Architecture

Figure 55 – Interrelated Strategies – Business Strategy,

Strategy, Overall Organisation IT Strategy and Internal IT Function Strategy

4.2 Problem and Solution Knowledge and Complexity

4.2.1 Problem and Solution Knowledge

One aspect of the solution design process is the acquisition of knowledge: knowledge about the problem being solved and
knowledge about the solution options. This knowledge is an input to the solution design process.

The purpose of gathering knowledge is to gain insight and make decisions. You need a systematic, structured and measurable
approach to decision making. Decision making that follows a systematic approach is more productive and results in better
decisions.

A structured decision-making approach is characterised by:

• Appropriate and sufficient problem analysis

• Definition of evaluation factors
• Identification of alternative options and solutions
• Identification and evaluation of likely positive consequences of solutions
• Identification and evaluation of likely negative consequences of solutions

You need to avoid factors that cause ineffective decision making such as:

• The real decision maker is not known or unavailable

• There are multiple, possibly conflicting, decision makers
• Objectives cannot be plainly identified and clarified
• There are trade-offs to be agreed
• The key uncertainties cannot be understood
• The available and viable options cannot be agreed
• The measures of value cannot be agreed

Page 95 of 540
 Introduction to Solution Architecture

Figure 56 – Problem and Solution Knowledge in the Solution Design Process

The amount of already known knowledge about the problem being resolved through the design of a solution and the amount
of knowledge that must be acquired governs the complexity of the solution design process.

The solution design process acquires and uses knowledge about the problem and the solution to create one or more
implementable and usable solution options.

Solutions can, simplistically, grouped into one of four categories based on a combination of the amount of problem
knowledge known and the amount of solution knowledge known.

Figure 57 – Problem and Solution Knowledge and Solution Design Complexity

This leads to four very broad categories of problem and solution knowledge and the associated solution design complexity:

Page 96 of 540
 Introduction to Solution Architecture

1. New Or Unquantified Problem/No Problem Knowledge With No Existing Solution Knowledge – where the
existing knowledge both about the problem and its resolution are low

2. Known Or Quantified Problem With No Existing Solution Knowledge

K nowledge – where the problem is largely known but the
resolution options are not

3. New Or Unquantified Problem/No Problem Knowledge Where Existing Solution Knowledge Can Be Adapted –
where the knowledge about the problem is low but where there is existing solution knowledge based on the resolution of
generally similar problems

4. Known Or Quantified Problem With Existing Solution Knowledge – where the existing knowledge about the
problem and its resolution are both high

The category of problem and resolution knowledge can be used to determine the approach to defining a resolution and an
associated implementing solution.

Figure 58 – Problem and Solution Knowledge and Solution Design Options

There are four broad categories of resolution determination approach linked to the categories of knowledge:

1. Invent or Derive New Knowledge To Create New Solution For New Problem – where the existing knowledge both
about the problem and its resolution are low, the solution approach will involve inventing or deriving new solution
design knowledge to the new problem.

2. Develop New Knowledge To Create New Solution For Known Problem – where the problem is largely known but
the resolution options are not, new solution knowledge must be developed to create a new solution design for a known
problem.

3. Adapt Or Apply Existing Solutions or Knowledge For New Problem – where the knowledge about the problem is low
but where there is existing solution knowledge based on the resolution of generally similar problems, the solution
approach will involve adapting or applying existing solution design knowledge to the new problem.

4. Adapt Or Apply Existing Solutions or Knowledge For Known Problem – where the existing knowledge about the
problem and its resolution are both high, the solution approach will involve adapting or applying existing solution design
knowledge to the problem.

This mapping is shown in the diagram below.

Page 97 of 540
 Introduction to Solution Architecture

Figure 59 – Options for Problems and Solution Knowledge

Knowledge Options

Understanding the extent of the problem and solution knowledge at the start of the solution design process allows you
understand the likely effort that will be involved in the process and the likely complexity of the work.

Solution unknowns – gaps in knowledge about either the problem or the solution - are the source of potential problems
during solution delivery, from estimation of cost, resources and time required to the performance of the work. One goal of
solution design is to minimise or even eliminate the number of surprises and unforeseen circumstances and events that occur
after the design is complete. It is concerned with removing the as much of the uncertainty from the solution design as is
possible, subject to time and resource constraints.

Potential knowledge – both about the problem and the set of solution options – must be converted into actual knowledge.
Simplistically, potential knowledge is the knowledge that can be known. Known Knowns represent knowledge that can be and
is known – potential converted to actual. Known Unknowns represent knowledge that we know that we do not know –
potential that can at some future stage be converted to actual. In terms of solution design and ultimately the delivery of the
solution, Unknown Unknowns represent a problem. They are knowledge of the problem and the solution that we do not
know about.

Figure 60 – Problem and Solution Knowns and Unknowns

The solution design process is concerned with maximising the Known Knowns and minimising the other areas of unknown
knowledge through exploration, investigation and analysis. It is about taming the solution knowledge dragons. The more that

Page 98 of 540
 Introduction to Solution Architecture

is known about the solution design the fewer the problems relating to scope and changes and associated cost, time and
resource increase will occur later in solution implementation.

Figure 61 – Maximising the Solution Knowns and Minimising the Unknowns

Greater certainty about the problem being resolved and the design of the solution required to resolve it leads to more
exactness in the estimate of resources, time and cost required to implement the solution.

The need to acquire knowledge and thus remove uncertainty cannot be used as an excuse for lack of progress towards
creating a solution design. The rapid solution design engagement process described in section4.6.5 on page 257 can be used to
create broad solution concept options quickly.

The high-level set of steps to identify solution options and to create a conceptual architecture is illustrated below.

Figure 62 – Solution Option Definition Steps

The fundamental questions to be asked are:

Page 99 of 540
 Introduction to Solution Architecture

• Why Is The Solution being Looked For?

• What Should The Solution Do?
• How Will The Solution Be Used?
• How Will The Solution Do What Is Needed?
• What Could Go Wrong With The Solution
• Could The Solution Do Anything Else?
• Are There Any Alternatives Or Other Options?

4.2.2 Solution Complexity

The likely complexity of the solution design process is partially related to the state of the problem and solution knowledge.
This can be represented as a solution design complexity heatmap.

Figure 63 – Solution Design Complexity Heatmap

The red areas indicate areas of potentially high complexity. The green areas indicate areas of potentially low complexity.
However, the problem/solution knowledge gap is just one aspect of complexity in the solution design process and in the
solution design created.

The solution is likely to be complex system if the problem to be resolved or the way which the problem can be resolved
comprises many components that can interact with one other in many different ways. Having many components in itself does
not lead to complexity. The complexity of the solution arises when those components have many relationships, dependencies
and interactions. 18

18
The eponymous Gall’s Law should be borne in mind. See page 52 of SYSTEMANTICS: How Systems Really
Really Work and How They Fail
ISBN 978-0812906745 by John Gall:

A Complex System That Works Is Invariably Found To Have Evolved From A Simple System That Works.

The parallel proposition also appears to be true:

A Complex System Designed From Scratch Never Works And Cannot Be Patched Up To Make It Work.
You Have To Start Over, Beginning With A Working Simple System.

Gall’s short book is an entertaining read if somewhat cynical and facetious. This law is not necessarily a formal statement
about complexity but it is worth remembering.

Page 100 of 540

 Introduction to Solution Architecture

Complexity arises and needs to be addressed and managed in a number of areas in the solution design process:

1. The complexity of the solution required to resolve the problem, its number of components and its interactions – the
solution’s intrinsic complexity
2. Complexity in arriving at the solution design option or options based on the amount of knowledge required and the
knowability of this knowledge
3. Complexity in the way the solution is interacted with and the ways in which the solution can or will be used – this can be
regarded as uncontrollable usage complexity

Complexity can be very enticing. Complexity makes solutions interesting and captivating. Solution architects must work hard
to avoid the fascination of complexity.

Usage complexity can be reduced by actions such as limiting the number of users and reducing the available functionality to
limit the actions that solution users can perform.

Usage complexity can arise in situations where there is substantial latent demand for the solution. This is demand that does
not currently manifest itself but becomes apparent when the solution is made available.

Such latent demand frequently occurs when solutions are implemented that are deployed to a user population outside the
organisation. The internal organisation user population is reasonably easy to know and control. It is considerably more
difficult to control external users. There can be uncertainty and unpredictability about their interactions with the solution.

The solution designer needs to ensure that the designed solution is only as complex as it needs to be to resolve the problem
and not any more complex but not any less19. Complexity and richness of features can be very seductive. Simplification and
removing unnecessary complexity in the solution design is one of the tasks of the solution designer.20 Necessary complexity is
what remains when unnecessary complexity has been removed. Necessary complexity can only be removed when the solution
functionality that leads to that complexity is explicitly removed.

The analogy of a waterbed can be used when discussing necessary and unnecessary complexity. Water is incompressible so
pressing down on one part of the waterbed will cause it to rise elsewhere. So, as with the waterbed, attempts to eliminate

19
There is a strong theoretical basis to the concept of solution complexity. In his book An Introduction
Introduction to Cybernetics
http://pespmc1.vub.ac.be/books/IntroCyb.pdf, W Ross Ahsby introduced his Law Of Requisite Variety (page 206). Essentially the system
as a regulator requires an equivalent amount of variety (processing functionality) as the information or signals it must handle. That is, the
solution must as a complex as the streams of information, inputs and actions it is designed to handle. This is further elaborated by Roger C.
Conant and W. Ross Ashby in their Good Regulator theorem - http://pespmc1.vub.ac.be/books/Conant_Ashby.pdf - which states that
"every good regulator of a system must be a model of that system ". That is, there should be a mapping from the states of the system
being handled to the states of the solution that handles that system. When applied to solution architecture, this approach views the solution
as a receiver and processor of signals – data exchanges, integrations, inputs and requests for functions to be performed. The solution must
have sufficient complexity to handle and process the range of signals it is expected to accommodate. From this it can be inferred that
complexity can be avoided by simplifying the amount of processing expected to be performed by the system.
20
The often-quoted figures from Jim Johnson of the Standish Group on product features not used is worth considering. See. ROI: It's your
job. Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineering
(XP 2002), Alghero, Sardinia, Italy. He claimed that 46% of product features implemented were never used.

Features
Used
Never 45%
Rarely 19%
Sometimes 16%
Often 13%
Always 7%

The analysis was based on just four internally developed software solutions and so the analysis may not be widely applicable. However, it
represents a warning to always question and avoid complexity.

Page 101 of 540

 Introduction to Solution Architecture

necessary complexity in one area of the solution will cause additional compensating complexity to occur or be needed
elsewhere.

Figure 64 – The Waterbed Analogy of Necessary Solution Complexity

There is a related area of complexity in the wider solution delivery process. This relates to the complexity of the project to
implement the solution. A complex solution design will invariably lead to a complex solution delivery process. This
complexity can be further increased by delivery factors such as:

• Skill level of solution delivery team

• Number of organisation locations affected by the solution
• Skill and experience of suppliers, if third parties are being used
• Newness of technologies included in the solution
• Involvement of third-parties in the delivery of the solution and the nature of the organisation’s relationships with those
third parties

There is a detailed list of complexity factors later in this section.

These factors can be outside the core solution design. But they can be included in or at least adverted to in the solution
design.

Factors that are commonly included in an assessment of the complexity of the solution delivery projects such as:

• Amount of work performed by and expected throughput of the system – number of transactions, complexity of
transactions
• Number of people that will use the solution
• Security, performance, reliability and availability requirements
• Volume of data to be migrated or initially loaded to make the solution usable
• Volume of data to be stored and processed
• Complexity in the data structures and the relationships between data elements

are not purely delivery related. These can and should be included in the solution design.

Complexity accumulates and is magnified across these contributing factors. The complexity adds to the riskiness associated
with solution implementation. Taking an end-to-end solution delivery view means that the complexity that has accumulated
across the entire path and its consequent risks can be understood.

Page 102 of 540

 Introduction to Solution Architecture

Figure 65 – Accumulating Solution Complexity

Knowing the likely complexity of the solution allows an informed decision to be made on the solution design effort and the
number and skills and experience levels of the resources required. Solutions of low complexity require few resources and can
be assigned to solution designers who are starting to gain experience. Highly complex solutions, even after unnecessary
complexity has been removed, involve greater risk along the solution design and implementation journey. This complexity
needs to be understood and managed.

However, estimating the complexity requires some initial assessment of the both the state of problem and solution knowledge
and of the number and complexity of the components and their interactions of the solution.

In general, complex problems require complex solutions. Simple solutions will not work. Similarly, simple problems do not
require and should not be given complex solutions.

Figure 66 – Simple and Complex Problems and Solutions

A further aspect of complex solutions is that they can take a long time to implement. Frequently solutions need to be
deployed, operable and usable quickly to take advantage of a changing business environment.

Page 103 of 540

 Introduction to Solution Architecture

Figure 67 – Solution Complexity and Time to Deliver

Complexity is the enemy of speed and dynamism. Reducing complexity reduces the time to get the solution operational.
However, speed and dynamism of solution delivery are themselves not without major risks:

• Higher operational costs due to manual workaround, poorly integrated solution components, poor data quality
• Unstable solution that is prone to errors and failures, leading to poor user experience, reputational damage and the
possible rejection of the solution
• Necessary components missing – the solution as implemented does not include functionality that is needed to make the
solution usable
• Cannot scale to handle volumes – the solution worked for small volumes of activity and data but cannot scale in a
production environment leading to delays, higher support costs, manual effort and rejection of the solution
• Insecure – the solution has security gaps and flaws
• Not accepted by target user population – the solution is rejected by the users for who it is intended
• Wrong solution – the solution is simply not what is needed or envisaged
• Cost of rework - the solution problems must be resolved through rework, requiring more time and cost

There is no simple answer to the question of what complexity is necessary. There is no magic bullet to kill the problem. It
requires analysis and thought. If the scope of the required solution is not understood then the risks cannot be understood.
Getting the solution wrong can be expensive.

Solution complexity is frequently assessed as a weighting factor, when creating solution delivery estimates. The overall
weighting is calculated based on scores assigned to individual factors such as:

Complexity Complexity Factor Reverse Weighting/ Simple/Few/Low/Yes/Not

Factor Weighting Importance Applicable
Group To
Complex/Large/High/No
Operational Operational Security Requirements
Factors Privacy and Confidentiality Of Data Being
Processed
Operational Performance And Throughput
Requirements
Operational Reliability And Availability
Requirements
Amount Of On-Premises Infrastructure
Required

Page 104 of 540

 Introduction to Solution Architecture

Complexity Complexity Factor Reverse Weighting/ Simple/Few/Low/Yes/Not

Factor Weighting Importance Applicable
Group To
Complex/Large/High/No
Volume Of Data Being Processed
Volume and Variability of Workload To Be
Processed
Number Of Different Types Of Transactions To
Be Processed
Number Of Internal Solution Consumers
Number Of External Solution Consumers
Technical Number Of Technologies Included In The
Factors Overall Solution
Number Of Solution Components
Number Of Solutions Integrations And
Interfaces
Number Of Application Tiers
Technologies Already Part Of The
Organisation’s Enterprise Architecture
Availability Of Skills And Experience In Y
Technologies
Amount Of Custom Development
Development Platform Productivity
Amount And Complexity Of Data To Be Loaded
Or Migrated
Reuse Of Existing Custom Components
Business Overall Business Project Size
Factors Number Of Business Functions Or Areas That
Will Use The Solution
Number And Complexity Of Underlying
Business Processes
Familiarity Of The It Function With The Y
Business Functions Or Areas
Availability Of Business Resources To Work On Y
The Solution
Number Of Locations Of Business Functions
Number Of Existing Solution Components
Being Replaced
Organisation Change Requirements
Product Number Of Products and Services Required To
Factors Deliver The Solution
Number Of Separate Suppliers Involved In The
Delivery Of The Product(s) and Service(s)
Maturity Of The Product(s) and Service(s) Y
Supplier Proven Skills And Experience In Y
Implementing Products and Services
Products and Services Are Being Provided By Y
Existing Suppliers To The Organisation
Number Of Supplier Offshore Locations
Involved In The Delivery Of The Product(s) and
Service(s)
Degree Of Configuration Of Product(s) and
Service(s)
Degree Of Customisation Of The Of Product(s)

Page 105 of 540

 Introduction to Solution Architecture

Complexity Complexity Factor Reverse Weighting/ Simple/Few/Low/Yes/Not

Factor Weighting Importance Applicable
Group To
Complex/Large/High/No
and Service(s)
Number Of Personnel From Supplier Involved
In The Product and Service Delivery
Complexity Of Outsourcing Relationship, If
Applicable, To The Delivery Of The Product(s)
and Service(s)
Amount Of New Technology Introduced By The
Product(s) and Service(s)
Project Fixed Project Implementation Deadline
Factors Expected Project Duration
Overall Solution Delivery Project Size
Number Of Outsourcing Arrangements
Included In The Overall Solution
Number Of Externally Hosted Components
Included In The Overall Solution
Size Of Implementation Project Team
Multiple Language Requirements
Number Of Jurisdictions In Which The Solution
Will Operate
Skill and Project Manager Skills And Experience Y
Experience Implementation Team Skills And Experience Y
Factors

Table 17 – Solution Complexity Factors

Individual factor scores are assigned in a range of 1 to 10 on the scale where 1 represents Simple/Few/Low/Yes/Not
Applicable to 10 representing Complex/Large/High/No .

The Reverse Weighting column indicates that the score is reversed: 10 means a very low contribution to the overall
complexity and 1 means a very high complexity score. For example, the complexity factor Number of separate suppliers
involved in the delivery of the product(s) is rated from 1 to 10 where 1 means a single supplier and 10 means a very large
number of suppliers. Where the rating of the complexity factor Maturity of the product(s) which has a reverse rating flag is
1, it means it is an immature product and a score of 10 means it is very mature.

The calculated weighting is used as an uplift to the base resource estimates.

It is also used to identify high-risk solution delivery projects that require a higher degree of governance.

These are not so much solution complexity factors as solution implementation and organisation and project complexity
factors.

Using an approach such as this can give a false sense of comfort that the solution complexity has been understood, captured
and catered for and a misleading rigour to the complexity score. Solution delivery complexity is non-linear rather than linear.
A higher complexity score indicates that the solution delivery is much more complex. A score of the 75th percentile does not
mean the solution delivery complexity is 50% greater than that of a 50th percentile score. It is more likely to be 70% more
complex. The reasoning here is that the amount by which the estimated resources should be increased to cater for solution
complexity must start to taper off. There is only so much complexity that the delivery of a solution can handle and only so
many resources that can be added to the solution delivery resources before the project cannot absorb any more.

Page 106 of 540

 Introduction to Solution Architecture

Figure 68 – Non-
Non-Linear Nature of Solution Delivery Complexity

However, the exact nature of the non-linearity is not obvious. In reality the complexity curve will be like:

Figure 69 – Adjusted Complexity Curve

A notional reduction in complexity will not lead to a reduction in the effort and resources required to deliver the solution.
The solution will always require a basic amount of resources to implement. Complexity adds to these.

The applicability of the weightings assigned to the complexity factors is unvalidated. The values assigned to the weights are
similarly not formally established. Also, complexity factors and weightings are interrelated and this relationship is not
represented in the overall complexity score. For example, the experience of the project manager assigned to a small project is
much less important that that person’s experience if the project is very large.

In some cases, these complexity factors reflect the solution implementation causes of failure listed in section 3.1 on page 57.

The following table contains an example of the application of this complexity model.

Page 107 of 540

 Introduction to Solution Architecture

Complexity Complexity Factor Reverse Weighting/ Unweighted Weighted

Factor Weighting Importance Score Score
Group
Operational Operational Security Requirements VH 6 9
Factors Privacy and Confidentiality Of Data Being VH 7 10.5
Processed
Operational Performance And Throughput H 4 5
Requirements
Operational Reliability And Availability H 6 7.5
Requirements
Amount Of On-Premises Infrastructure M 3 3
Required
Volume Of Data Being Processed H 5 6.25
Volume and Variability of Workload To Be H 4 5
Processed
Number Of Different Types Of Transactions To M 6 6
Be Processed
Number Of Internal Solution Consumers M 5 5
Number Of External Solution Consumers VH 6 9
Technical Number Of Technologies Included In The H 7 8.75
Factors Overall Solution
Number Of Solution Components H 7 8.75
Number Of Solutions Integrations And H 7 8.75
Interfaces
Number Of Application Tiers L 5 3.75
Technologies Already Part Of The M 4 4
Organisation’s Enterprise Architecture
Availability Of Skills And Experience In Y M 8 8
Technologies
Amount Of Custom Development H 6 7.5
Development Platform Productivity M 5 5
Amount And Complexity Of Data To Be Loaded H 7 8.75
Or Migrated
Reuse Of Existing Custom Components M 5 5
Business Overall Business Project Size VH 7 10.5
Factors Number Of Business Functions Or Areas That H 2 2.5
Will Use The Solution
Number And Complexity Of Underlying H 6 7.5
Business Processes
Familiarity Of The It Function With The Y M 8 8
Business Functions Or Areas
Availability Of Business Resources To Work On Y M 7 7
The Solution
Number Of Locations Of Business Functions H 4 5
Number Of Existing Solution Components M 6 6
Being Replaced
Organisation Change Requirements H 5 6.25
Product Number Of Products and Services Required To M 6 6
Factors Deliver The Solution
Number Of Separate Suppliers Involved In The H 4 5
Delivery Of The Product(s) and Service(s)
Maturity Of The Product(s) and Service(s) Y H 7 8.75
Supplier Proven Skills And Experience In Y M 9 9
Implementing Products and Services

Page 108 of 540

 Introduction to Solution Architecture

Complexity Complexity Factor Reverse Weighting/ Unweighted Weighted

Factor Weighting Importance Score Score
Group
Products and Services Are Being Provided By Y L 8 6
Existing Suppliers To The Organisation
Number Of Supplier Offshore Locations H 5 6.25
Involved In The Delivery Of The Product(s) and
Service(s)
Degree Of Configuration Of Product(s) and M 7 7
Service(s)
Degree Of Customisation Of The Of Product(s) H 7 8.75
and Service(s)
Number Of Personnel From Supplier Involved H 5 6.25
In The Product and Service Delivery
Complexity Of Outsourcing Relationship, If M 1 1
Applicable, To The Delivery Of The Product(s)
and Service(s)
Amount Of New Technology Introduced By The M 1 1
Product(s) and Service(s)
Project Fixed Project Implementation Deadline VH 1 1.5
Factors Expected Project Duration VH 4 6
Overall Solution Delivery Project Size VH 6 9
Number Of Outsourcing Arrangements VH 1 1.5
Included In The Overall Solution
Number Of Externally Hosted Components H 7 8.75
Included In The Overall Solution
Size Of Implementation Project Team H 6 7.5
Multiple Language Requirements H 1 1.25
Number Of Jurisdictions In Which The Solution H 8 10
Will Operate
Skill and Project Manager Skills And Experience Y H 8 10
Experience Implementation Team Skills And Experience Y H 8 10
Factors

Score 264 317

317.75

Table 18 – Sample Solution Complexity Scores

The example solution delivery has a weighted score of 317.75. Based on the assumption that complexity is non-linear and a
higher than average complexity score indicates a proportionally higher complexity, this project would be assigned a
complexity uplift of 1.23 to the initial project resource estimates. This assumes that the resource estimates did not already,
either implicitly or explicitly, account for solution delivery complexity.

The following shows where this complexity score is located on the proposed non-linear solution complexity curve.

Page 109 of 540

 Introduction to Solution Architecture

Figure 70 – Sample Solution Complexity Score on Solution Complexity Curve

Using this approach, the following complexity score would lead to the following resource uplifts.

Complexity Possible
Score Resource Uplift
300 1.06
350 1.44
400 1.73
450 1.89
500 1.97

Table 19 – Complexity Scores and Resource Uplifts

This is not a precise complexity determination method. It illustrates a type of approach regularly used but one which has
flaws, such as:

• The values assigned to the weights that reflect the importance of a complexity factor are not formally derived.

• The same weighting is applied to all complexity factors with the same importance.

• The validity of the complexity factors and their contribution to the overall complexity of the solution has not been
determined.

• The complexity scores assigned to each complexity factor are subjective and do not have a defined objectively defined
scale.

• The relationship between risk factors is not reflected in the model.

• In deriving the final complexity score, each individual weighted score is added without any account being taken of the
spread of scores. A low overall score could be the result of the sum of a small number of very high-risk factors combined
with a large number of very low risk factors. The small number of high-risk factors would indicate the solution delivery
had some inherent major risks that would be masked in the final score.

• Not all factors apply to all solutions. Assigning these factors a zero score would falsely underestimate the complexity of
the solution measured against the applicable complexity factors.

Page 110 of 540

 Introduction to Solution Architecture

It could be possible to create a solution complexity dashboard along the following lines. This example contains the following
numbered sections:

Figure 71 – Sample Solution Complexity Dashboard

The numbered elements of this are:

Number Description
1 This shows the complexity factor groups.
2 This shows the individual complexity factors.
3 This allows individual complexity factors to be included or excluded from the derivation of the overall
solution complexity.
4 This indicates if the score for the factor is reversed.
5 This is the weighting applied to the factor based on the scale of VL, L, M, H and VH.
6 This allows the individual complexity factor to be assigned a value.
7 This is the weighted score of the complexity factor.
8 The shows the relative value of the group of complexity factors.
9 This shows the overall complexity score against the available score.
10 This shows the estimated uplift that should be applied to the estimated based on the derived complexity of
the solution.
11 This shows the number and percentage of solution complexity factors across the different weightings. It also
shows the scores and their percentage of the overall score for each weighting category.
12 This shows the overall solution complexity score.
13 This charts the range of scores assigned to complexity factor based on their weighting where green indicates
a low score and red a high score. In this example, there is a disproportionate number of factors with a
weighting of very high assigned a high score.

Page 111 of 540

 Introduction to Solution Architecture

14 This shows where the overall solution complexity lies on the solution complexity curve.

Table 20 – Sample Solution Complexity Dashboard Elements

The following diagram shows this sample complexity dashboard with some of the factors excluded.

Figure 72 – Solution Complexity Dashboard With Not Applicable Complexity Factors

The solution architect cannot design solution in isolation without being aware of the implications of its subsequent delivery.
Inherent unnecessary complexity must be avoided. The solution architect does not have control of the wider environment in
which the solution will be delivered and that may be a source of additional complexity. But the solution architect can try to
influence this by indicating where solution delivery problems may arise due to complexity so mitigation actions can be taken.
The complexity factors can be used to assess and select solution options. The goal is, as always, no surprises.

4.3 Solution Design, Delivery and Operation Context

Every organisation will have a solution delivery process based on project management standards such as PRINCE221 or
PMBOK22 or a local variant of one of these. This process may be based on a locally developed variant of one of these
standards. Note that the project management process does not necessarily imply a specific approach to the implementation of
solution components, such as agile or waterfall. Chapter 6 on page 422 discusses the topic of solution delivery and the use of
agile delivery processes in more detail.

21
See:
https://www.axelos.com/best-practice-solutions/prince2
22
See:
https://www.pmi.org/pmbok-guide-standards

Page 112 of 540

 Introduction to Solution Architecture

The solution design process works within the wider organisational and operational solution delivery and operation context.
The objective of solution architecture and of the solution design process is to create deliverable designs that are implemented,
become operational and generate the expected business benefits and value.

Unless there is a strong solution delivery process with associated effective governance, there is little merit in having an
effective solution design process.

The core dimension of any solution delivery process is the set of phases that are followed sequentially from start to end. These
phases typically take the form of the following:

• Concept
• Initiate
• Plan
• Design
• Build
• Test
• Deploy
• Operate

These phases are not necessarily sequential. However, ultimately, the solution delivery process must deliver an operational
solution. The phases can be iterated.

Figure 73 – Iterated Solution Delivery Phases

This high-level set of solution delivery stages could be expanded to include a more detailed set of steps.

Page 113 of 540

 Introduction to Solution Architecture

Figure 74 – Expanded Set of Solution Delivery Steps

These solution delivery steps are:

• Idea or Business Concept

• Initial Discovery
• Requirements Elicitation
• Outline Solution Design
• Decision to Proceed
• Detailed Solution Research, Analysis and Design
• Design Review and Approval
• Initiate Implementation
• Implementation Planning
• Development
• Testing
• Component Procurement/ Acquisition
• Component Installation, Configuration and Customisation
• Data Interfaces and Exchanges
• Process Definition and Changes
• Organisation Change
• Infrastructure Commissioning
• Data Migration, Load and Validation
• Documentation and Training
• Deployment Planning
• Transition To Support
• Cutover To Production
• Parallel Run
• Hypercare Interval
• Operation and Use
• Evolve and Change

These solution delivery steps are not necessarily sequential and linear. They can be reordered, repeated in greater levels of
detail and performed in parallel. They represent activities to be performed and work to be done. How and when this happens
can be defined during detailed delivery planning.

Page 114 of 540

 Introduction to Solution Architecture

There may (and should) be gates at the end of each of these stages where the validity of the solution progressing to the next
stage should be assessed and a decision made. Even if the solution is sufficiently worthwhile to progress, the quality of the
work may not be sufficient to merit its advancement until it is reworked to an appropriate standard. The gate and review
process ensures that the solution delivery work remains on track.

This generic solution delivery process can be expanded to add a second dimension of the solution delivery role involved in
solution delivery stages. The following shows this expanded solution delivery process with a view of the possible artefacts that
could be created as the solution delivery process proceeds. The precise set of artefacts to be produced based on work done and
outcomes and results achieved, whether the artefacts are actually produced and when and who produces them will vary across
organisations.

Figure 75 – Solution Delivery Process with Solution Delivery Phase and Role Dimensions

The possible list of artefacts to be created is listed in the table below. This is a very comprehensive (and time consuming to
produce) set of artefacts. It includes both documentation and other items such as environments that are delivered during the
solution delivery process. Documentation artefacts are designed to serve three main functions:

1. To contain a record that the work that generated the artefact was done to a sufficient rigour and level of detail

2. To create a set of information that can be passed to subsequent delivery stages and other members of the solution
delivery team

3. To create a store of solution delivery knowledge that can be used in subsequent work such as support, solution
enhancement and evolution and other solution design work

All of these artefacts proceed from the solution architecture work at the start of solution delivery and from the solution design
created and revised throughout the delivery effort. The solution design must be able to support the creation of these artefacts.
It must provide a sufficiently firm foundation to enable this to happen. Solution architecture must be involved throughput the
solution delivery process. The siloed nature of solution delivery with multiple handoffs described in section 2.6 on page 50
must be avoided.

Page 115 of 540

 Introduction to Solution Architecture

Document artefacts must serve a purpose. There is no merit in creating large volumes of documentation unless they service a
function. These are logical artefacts are can be combined. Behind each of these artefacts is a substantial set of work. The
artefacts can be repeated for different component of the solution.

The approach to solution delivery and the set of artefacts to be created must be agreed during the planning stages.

These are specific solution delivery artefacts. In addition, there will be other artefacts created during the delivery project
relating to its management such as status reports, communications, documentation from meetings, changes requests and
record of change management activities.

Stage Artefact Type Description

Concept Solution Concept/ Document This is a high-level view what the solution is required to achieve and
Requirements of the functional and business solution options and contains a
Document description of the key business requirements for the solution.
Rough Order of Document Based on the solution concept design, this is a rough estimate of the
Magnitude Estimate likely resource, time and cost estimates to deliver the solution. This
allows a decision to be made whether to progress the solution delivery
process.
Initiate Project Charter Document This is a broad statement of the scope, objectives, goals of the project
and how they will be achieved, the reason for and the value to be
generated by the project, what is and is not in scope, the high-level
risks and their proposed mitigations, the roles and responsibilities of
those involved in the project and identifies the key stakeholders.
Project Initiation Document This acts as a reference to the project throughout its life for the
Document members of the project team. It defines the detailed scope of the
project, contains a description of the solution and its delivery
approach and defines what is and is not in scope. It describes the
project background and why the project is being undertaken. It
describes the project structure, project team and roles, organisation
and governance and control approach. It describes the approach to
project communications, finance, change and risk management,
quality and reporting. It lists known assumptions, dependencies,
constraints, issues and risks. It contains the initial solution delivery
plan.
Business Case Document This defines the justification for the solution delivery project. It
defines the expected benefits, describes how they will be achieved and
measured, quantifies their value and lists the solution delivery costs. It
outlines the alternatives considered and the benefits and values each
option would have been expected to achieve.
Plan Project Plan Document This defines the project activities and tasks, their schedule, the
resources that will perform them and the dependencies between the
activities.
Project Resource Document This is effectively a bill of materials for the project and defines how
Plan the people resources assigned to the project will be managed. It
defines the amount and types of effort, the roles and responsibilities
for each type of effort, equipment and other materials needed to
deliver the solution.
Functional Document These are the requirements that define what the solution must do and
Requirements the functionality and features it must include.
As Is Process Document This describes the current processes in use in the pre-solution
Definition landscape of the business functions that will use the solution.
Solution This is a high-level solution architecture that could be produced using
Architecture High the rapid engagement process described in section 4.6.5 on page 257.
Level Design This contains an initial view of the solution design options and
describes the scope of the required solution.

Page 116 of 540

 Introduction to Solution Architecture

Stage Artefact Type Description

Data Audit Document The objectives of the data audit are to understand the current data
management systems, structures and data processes that are to be
included in and migrated to the solution. It can contain some or all
of:

• Data landscape view - describes the entities and functional units

within and outside the organisation with which the organisation
interacts and to describe the interactions in terms of data flows
• Data supply chain view - describes the in-bound and out-bound
data paths within and outside the organisations in terms of the
applications and the data that flows along the data paths
• Data model view - data specifications that reflect data
requirements and designs and defines the critical data produced
and consumed across the organisation
• Data lifecycle view – view of data across its life from creation to
deletion
• Current information and data architecture and data strategy
view - review of current information and data architecture and
implementation and operational under the key component areas
of:
o Data Governance
o Data Architecture
o Data Modelling and Design
o Data Storage and Operations
o Data Security
o Data Quality
o Data Integration and Interoperability
o Reference and Master Data
o Data Warehousing and Business Intelligence
o Documents and Content
o Metadata
• Current data management
management view - quantify the relative
importance and current state of implementation and operation of
data management components and functional elements
Configuration Document This describes the approach to managing the configuration of the
Management solution development and delivery environment. It defines naming
Approach and Plan and control scheme, tools, approach to change management and
backup and recovery.
Detailed Estimates Document This will contain an initial view of the detailed time, cost and resource
estimates for the delivery of the solution.
Test Strategy Document This will describe the high-level approach to testing the overall
solution to achieve the testing objectives, the types of tests and the test
entry and exit criteria across the testing phases of unit testing,
integration testing, system testing, user acceptance testing and
operations acceptance testing.
Management Team Document/ This will present the initial results of the solution design work
Briefing Meeting including business need, requirements, solution design overview,
delivery estimates.
Communications Document This will describe the approach to communications during solution
Strategy and Plan delivery across the core and extended project teams, with business
stakeholders and with the wider organisation likely to be impacted by
the solution.
Service Impact Document This will contain an assessment of the impact of the introduction of
Assessment the new services contained in the solution. It will identify the existing

Page 117 of 540

 Introduction to Solution Architecture

Stage Artefact Type Description

services impacted and the new services being introduced. It will
describe how the services will be introduced and how the services will
be managed and administered.
Infrastructure Plan Document This will contain the plan for the infrastructure required by the
solution and by the solution delivery project for the duration of its
implementation.
Design Benefits Schedule Document This will describe the benefits that the solution will deliver, what has
and Benefits to be done to realise them, how this will be achieved and assessed in
Realisation Plan order to maximise the value derived from the solution delivery.

Section 4.11.1 on page 381 contains more details on solution benefits

assessment.
To Be Process Document This will contain a description of the changes to existing business
Definition processes and the new business processes required to use and operate
the solution.

Section 4.4.2 on page 134 contains more details on business process

analysis and definition.
Non-Functional Document This will define the operational service and non-functional
Requirements requirements of the solution. Section 4.6.4.7 on page 251 contains
more details on the types of solution quality factors to be defined
here.
Detailed Solution Document This will contain a detailed design of the entire solution across all the
Design/ Functional solution components. This is intended to be a specification for all
Specification subsequent solution implementation and delivery work.
Confirmed Document This contains a review and an update of the previous delivery
Estimates estimates based on additional information produced during the
Design phase.
Data Design and Document This contains a detailed design of the static and dynamic data
Data Migration elements of the solution components including data integrations,
Plan transfers and exchanges. Section 4.8 on page 321 contains more
details on data aspects of solution architecture and design.
Technical/Build Document This is created by those involved in creating the application
Specification components of the overall solution. They will translate the solution
design into technical build documents for both developed
components and packaged or hosted components that are being
configured and customised. It will also contain the technical build
details for data integration, either their implementation using existing
data integration capability or custom data integrations.
Functional Test Document This will define the test cases for those solution components that are
Design and Plan providing functionality and will define the approach to the tests. The
scope of the testing will include:

• The functionality being validated during testing

• The data to be used during tests
• The specification of the expected outputs from the tests
• The execution of the tests and the recording of the functionality
experienced and the outputs generated
• Comparison of the expected and actual functionality and outputs
Non-Functional Document This will define the set of tests to be performed to validate the
Test Design and operational characteristics of the solution and its components to
Plan ensure it meets business expectations. It can include testing across all
the solution’s quality attributes (see section 4.6.4.7 on page 251).
Some of the most important characteristics to be validated are:

Page 118 of 540

 Introduction to Solution Architecture

Stage Artefact Type Description

• Performance and load including stress

• Response time and throughput
• Capacity and growth
• Security
• Recoverability
Integration Test Document This will define how individual functional components are tested
Design and Plan together. The scope of the integration test and the components to be
tested must be defined. Integration testing can be complex if there are
many components to be tested together. The number of combinations
can be large. Risk-based testing can be used to identify the most
commonly used integrations and sequences that should be tested to a
greater degree than others.
System Test Design Document This describes the testing approach that will be used to validate that
and Plan the application meets the defined business requirements. This should
define a comprehensive set of overall application testing scenarios.
Change Impact Document This will contain an assessment of the impact of standards,
Assessment organisation – structure, reporting, training, process and
measurement changes the solution will give rise to. Measurement
changes may arise because of possible changes in the way
performance and processes.
Detailed Document This will define how communications are handled throughout the
Communications solution delivery project across all affected functions and levels of the
Plan organisation. It will define the messages to be articulated, the method
and frequency by which they are communication and how feedback is
to be handled.
Training Needs Document This will define the solution training required across all functions
Analysis affected by the solution including business users, system managers
and administrators, support and service management.
Service Level Document This will specify the solution service levels across the area of
Requirements availability, performance, throughput, support including incident and
problem management, release management and backup, recovery and
business continuity.
Access and Security Document This will define who has what access to the various components of the
Definition solution and how application and data security including encryption
in transit and at rest and authentication is to be handled,
Infrastructure Document This will define the solution infrastructure across all technology areas:
Design processing, storage, communications including infrastructural
applications such as authentication, backup, recovery and business
continuity.
Infrastructure Document This will contain the detailed infrastructural build documentation.
Technical
Specification
Build Development Technology The solution development environment is built according to the
Environment Infrastructure Technical Specification.

Where the development environment is hosted externally this will

involve its configuration.
Build User Acceptance Document This will document the approach to user testing and the support to be
Test Design and provided. It will define the test cases, the data to be used and the
Plan expected results.
Standard Operating Document This will detail the operating procedures associated with the support,
Procedures operation and use of the solution.
Solution Design Document This will contain a log of any solution design changes raised, their

Page 119 of 540

 Introduction to Solution Architecture

Stage Artefact Type Description

Changes and Issue results and details on the resolution of issues that arose during
Resolution solution delivery. This occurs throughout the Build, Test and Deploy
solution delivery phases. The solution architect needs to be involved
throughout delivery.
Data Data The data to be loaded or migrated will be copied to the development
Migration/Load environment. This step will be repeated for the various environments
as they are built and for the various sets of data to be migrated or
loaded. This occurs throughout the Build, Test and Deploy solution
delivery phases.
Data Migration Test Document This will document the results of the various data migration and load
trial runs.
Build Document This will document the work done on the development environment.
Documentation This artefact will be repeated for the other environments being built.

Where the infrastructure is being hosted externally, this will describe

its provisioning and configuration.
Unit Test Results Document This will contain the results of the unit tests.
Integration Test Document This will contain the results of the unit tests and identifies any issues
Results to be resolved. The tests may be repeated after the issues uncovered
have been fixed.
Functional Test Document This will contain the results of the functional tests and identifies any
Results issues to be resolved. The tests may be repeated after the issues
uncovered have been fixed.
Non-Functional Document This will contain the results of the non-functional tests and identifies
Test Results any issues to be resolved. The tests may be repeated after the issues
uncovered have been fixed.
Change Action Plan Document This will describe how organisation changes are to be implemented.
Organisation Document This will specify the design of the new and changed organisation
Design structures being implemented as part of the overall solution design.
Develop Training Training This will consist of training material that will be used to train all those
Material Material involved in the solution: business users, support and service
management.
Operations Document This will document the approach to validating that the new services
Acceptance Testing associated with the solution are capable of being introduced,
(OAT) Design and operated, supported and maintained. The scope will include:
Plan
• Infrastructure has capacity to accommodate the new services
• Services can be monitored and event and alert management
policies and procedures are in place
• Services comply with business continuity standards
• There is no single point of failure within the infrastructure to
deliver the availability requirements
• Services can be backed-up and recovered to meet the solution
requirements
• Any batch or scheduled processes can be run automatically
without the need for manual intervention
• Services comply with security standards
• The solution can be handed-over to support
• Procedures for handling and recovering from errors have been
defined
• Required data archival procedures are in place
• Any new roles and responsibilities have been defined, agreed and
staffed
• User access management policies and procedures have been

Page 120 of 540

 Introduction to Solution Architecture

Stage Artefact Type Description

defined
• The services have been benchmarked for performance and
throughput
• Service level and operating level agreements are in place
• Any required enduring test environments are in place
Build Test Technology The test environment will be built according to the build standards.
Environment
Build UAT Technology The UAT environment will be built according to the build standards.
Environment
Build OAT Technology The OAT environment will be built according to the build standards.
Environment
Test User Acceptance Document This documents the results of the user acceptance tests and identifies
Test Results any issues to be resolved. The tests may be repeated after the issues
uncovered have been fixed.
Data Migration Document This will document the results of the data load and migration
Results including any issues that arose and how they were resolved and any
changes made to the data migration and load processes.
System Test Plan Document This will contain the results of the system tests and identifies any
Results issues to be resolved. The tests may be repeated after the issues
uncovered have been fixed.
UAT Changes and Technology Changes identified during user testing and approved will be
Rework implemented.
End-to-End Testing Document This documents the results of end-to-end solution testing across the
solution landscape.
Performance and Document This documents the results of performance and loading testing.
Load Testing
Role Definition Document The details of the new roles and any changes to existing roles in the
business functions impacted by the solution will be defined.
Training Schedule Document This will define the training to be provided to all users impacted by
the solution.
Operations Document This documents the results of operations acceptance testing.
Acceptance Testing
Results
Service Definition Document This will define the new services being introduced by the solution.
Build Training Technology If needed, a training environment will be built.
Environment
Deploy New/Changed Document The new and changed existing business processes will be
Business Process implemented in their production environments.
Deployment
Data Migration to Document The results of the data migration and load into the production
Live Results environment will be documented
Deploy to Document This will document the results of the solution components being
Production Results deployed to the production environment.
Support and Document This will contain the information needed to support the solution in its
Operations production environment.
Documentation
Operational Document This will contain an assessment of the organisation to accept the
Readiness Review solution.
Organisation and Document The documents the results of the implementation of the organisation
Staffing and personnel changes required to put the solution into production.
Implementation
Training Delivery Document The records the delivery of the training and any feedback received.
Service and Document The Operational Level Agreement (SLA) is the foundation
Operational Level governance and formal operating document for the services being

Page 121 of 540

 Introduction to Solution Architecture

Stage Artefact Type Description

Agreement(s) provided. It defined the end-to-end service performance principles,
activities, objectives and measurements.

The Service Level Agreement (SLA) is the formal agreement relating

to the management and operation of the services. It defines the
meaning of all aspects of the service and the roles and responsibilities
of all stakeholders, how service delivery is measured and what actions
are to be taken in the event of service delivery failures.

In the case of externally hosted applications or services the OLA and

SLA are very important documents.
Transfer to Document This documents the procedures for putting the solution into
Production and production and for any initial period of intensive support.
Hypercare Plan
Build Production Document This documents the results of the building of the production
Environment environment
Operate Benefits Realisation Document This documents the results of a review of the status of the benefits
Review that were meant to have been achieved by the project. This should
include an assessment of the actual amount spent of the delivery of
the solution and a comparison against the original budget.
Lessons Learned Document This documents the lessons learned during solution delivery.
Business Analysis Document This collects the various artefacts created by the business analysis
Documentation function during solution delivery, indexes them and stores them in a
Library defined location
Solution Design Document This collects the various artefacts created by the solution architecture
Documentation function during solution delivery, indexes them and stores them in a
Library defined location
Go Live Support Service This is the set of support services provided during and after the
solution goes live.
Hypercare Service This is the set of intensive support services provided during the
interval after the solution first goes live.
Operational Service Document These are the support processes across the range of service
Management management activities,
Processes
Decommission Technology After the solution is fully operational, any unneeded environments
Unused will be decommissioned.
Environments

Table 21 – Set of Solution Delivery Artefacts

The solution delivery process starts in the top left of this view and moves out through the project phases and down through
the delivery roles as the project proceeds. Section 4.6.3 on page 234 locates different solution design engagement types within
this overall solution delivery process framework.

Page 122 of 540

 Introduction to Solution Architecture

Figure 76 – Progress of Solution Delivery Through Phases and Roles

The solution architecture function needs to be involved at the earliest stage of solution design when the concept of the
solution is being explored. At this early exploration and investigation point, the solution architecture function needs to have
the tools, techniques and experience to offer consulting services to the business function. The solution idea needs to be
examined and validated quickly and to just a sufficient level of detail as to allow an educated decision to be made to continue
or not

However, for this approach to solution engagement to be effective the solution architecture must be enabled to operate in this
way. The business must accept and trust that the solution architecture function has the necessary capabilities. The governance
of the overall solution delivery process must support this mode of operation.

The foundational activities that lead to successful solution delivery project occur in the top left quadrant of the solution
delivery domain.

Page 123 of 540

 Introduction to Solution Architecture

Figure 77 – Foundational Solution Delivery Activi

Activi ties

Focussing on these solution delivery stages and activities will ensure that the solution delivery foundations are sound.

4.4 Solution Architecture Interface with the Business Analysis Function,

Function, Requirements
Gathering and Process Analysis

In the traditional solution design and delivery journey, requirements are gathered by the business analysis function during
requirements gathering workshops organised with business representatives. Analysis is used to gather information and
requirements. Analysis does not solve problems or deliver solutions. It is an important step in solution design. The analysis
function interfaces between the business and the solution architecture function.

In many cases the requirements gathered by business analysts are handed-off to the solution architecture function as
described in section 2.6 on page 50. This frequent lack of continuity in the solution design journey can contribute to solution
failure.

A detailed discussion of requirements gathering and management and the role of business analysis are not within the scope of
this book.

The ideal set of solution requirements should have three essential characteristics:

1. They should be well-formed – SMART (Specific, Measurable, Achievable, Realistic, Traceable). They should have the
following features

• Complete
• Correct
• Feasible
• Implementation Independent
• Necessary
• Singular
• Traceable

Page 124 of 540

 Introduction to Solution Architecture

• Unambiguous
• Verifiable

2. The needs and constraints of stakeholders should be complete and consistent.

• Complete

o Embodies a complete set of needs and constraints from stakeholders, external interfacing systems and
enabling and supporting systems
o Contains a complete set of business processes

• Consistent

o Requirements do not contradict one another

o Requirements are not repeated
o The same terms are used for the same meaning across all requirements

3. The solution design should be complete and consistent with respect to stakeholders’ expectations and should describe a
realistic and feasible solution that meets the stakeholders expectations and constraints

• Complete

o Addresses the complete set of expectations and constraints

• Consistent

o Requirements do not contradict one another

o Requirements are not repeated
o The same terms are used for the same meaning across all requirements
o Aligned and consistent with solution components

• Realistic and Feasible

o The requirements can be fulfilled by a solution that can be acquired or developed within implementation
constraints such as cost, schedule, technical, legal and regulatory

• Bounded

o The solution does not go beyond what is necessary to satisfy solution consumer needs

Because business stakeholder requirements both flow directly into solution design and frequently represent only a subset of
the actual solution requirements, the requirements gathering activities need to be fully integrated within the solution design
process and not be a parallel or external activity.

As discussed in section 2.3 on page 30 the business analyst role evolved (or more correctly devolved) from the earlier systems
analyst role.

There are a number of myths about requirements and the requirements gathering process:

• Requirements gathered from business users and business stakeholders through requirements gathering meetings and
workshops define the scope and functionality of the solution

• In order to define the solution, all that is needed is business requirements

• Requirements change

Page 125 of 540

 Introduction to Solution Architecture

It is unreasonable to expect that business stakeholders in a potential solution can articulate a set of complete, fully-developed
and consistent requirements through part-time involvement in a few requirements gathering exercises.

The wider view of requirements includes the following different classifications:

• Overall Business and Solution Requirements – these are underpinning requirements that describe the need for and
drivers of the requirements, the objectives that must be achieved, the key stakeholders that must be and the benefits that
must be realised

• Functional Requirements – these describe what the solution must do, what processing it will perform, what results it
will generate

• Operational and Quality Requirements – these describe properties and attributes the solution and its operation must
have. They can include areas such as:

o Look, Feel and Navigation

o Usability
o Capacity, Performance, Throughput and Response Times
o Operational and Environmental
o Maintenance and Support
o Security
o Regulatory, Legal and Compliance

• Design Constraint Requirements – the solution may be constrained to operate in a specific environment or use certain
tools or products

• Implementation Requirements – these relate to constraints how the solution must be delivered in terms of time, cost,
resources, available personnel and levels of skills and experience and facilities needed during solution implementation

• Delivery Requirements – these relate to how the solution must be implemented and how it must operate in the current
existing solution landscape – what integrations must be implemented, what data must be reused

It is not requirements that change during solution delivery. It is that latent requirements that were not identified or were
ignored become apparent or unavoidable during implementation. Undiscovered and unarticulated requirements then impact
solution components leading to additional downstream changes which affect the implementation project

Even with an effective elicitation approach, requirements elicited from business stakeholders tend to be:

• Sparse and disconnected

• Isolated and disintegrated statements
• Inconsistent
• Incomplete
• Disjointed
• Conflicting
• Uncosted
• Unprioritised
• At different levels of detail

The requirements are representations of specific points of functionality that rarely aggregate into a defined solution. The
reality is that what is gathered during requirements workshops, meetings, interviews, questionnaires and other activities are
not solution requirements but business stakeholder requirements. These must be translated into solution requirements which
is turn must be translated into a realistic and implementation solution design. These business stakeholder requirements are
one source of solution requirements.

Page 126 of 540

 Introduction to Solution Architecture

Figure 78 – Sparse Business Stakeholder Requirements and the Complete Set of Solution Requirements

This diagram shows the three types of requirements that arise during the process:

1. Business stakeholder requirements and the associated functionality required to deliver them that were identified during
requirements gathering that are included in the solution design.

2. Business stakeholder requirements that were identified during requirements gathering that are omitted from the solution
design after review and evaluation of solution implementation options.

3. Additional solution requirements identified during the Solution Requirements Collection and Specification (see section
4.6.2 on page 226) stage of the solution design process where all the solution components are identified. These
requirements are not expressed by business stakeholders during any requirements gathering process.

Business stakeholder requirements can be excluded from the complete solution design because they cannot be implemented
or are too expensive or time consuming to deliver for the benefits they provide. This needs to be done after discussions with
and the agreement of the business stakeholders.

Requirements gathering should not be part of any solution delivery project but be the subject of an analysis and solution
architecture and design exercise prior to any delivery project. The project to deliver the solution cannot be estimated until the
solution design is complete, unless a more agile approach is being followed where uncertainty is tolerated and resolved during
delivery.

The solution design is always much greater than the sum of the functionality implied by the elicited business stakeholder
requirements. Business stakeholder requirements are just one input into a fully developed solution design. The generalised
solution design process described in section 4.6.2 on page 226 has business requirements being gather in the context of a
Conceptual Solution Architecture (CSA). This can be created using elements of the rapid solution design process outlined in
section 4.6.5 on page 257. The CSA is essentially a solution hypothesis that can be validated, refined, modified, expanded on
or even rejected during consultations with the business.

Page 127 of 540

 Introduction to Solution Architecture

The CSA focusses on the core functional and system components of the solution. The CSA provides a framework for
identifying solution requirements across the solution landscape. It also assists with compiling business stakeholder
requirements as requirements can be elicited within the context of the complete end-to-end solution concept.

This structured approach to gathering requirements in the context of indicative solution architecture yields greater results
than standalone requirements gathering. The analysis and architecture functions need to work together to transform business
stakeholder requirements into solution requirements. Architecture synthesises and actualises overall solution design and
options from business stakeholder requirements and other constraints.

Taking this approach means the solution implementability, operability, usability, maintainability and supportability can be
quantified in advance. It is only after the solution design is defined and agreed that the implementation project can be started.

Rather than operating separately, the business analysis and solution architecture functions need to work together during the
solution design process. The interface between the two functions must become a collaboration.

The solution does not deliver requirements. The solution encompasses multiple interoperating elements that provide
functionality that enable business processes that allow requirements to be complied with.

The solution has functional (and other) requirements that must be delivered in order to be deemed to be complete. As stated
above, the requirements identified during any business requirements elicitation process will only ever be a sparse and
fragmented representation of what the full set of solution requirements that constitute a complete solution

One of the objectives of the solution design process is to minimise the Solution Space – the size and complexity of the
solution and therefore its cost, time, resources and risk to implement - while maximising the size of Requirements Spaces
encompassed by that solution. There will be two Requirements Spaces – that contained in the business stakeholder
requirements and that contained in the wider solution requirements not explicitly defined as requirements by the business
stakeholders.

Page 128 of 540

 Introduction to Solution Architecture

Figure 79 – Mapping the Requirements Space to the Solution Space

Decisions must be made on what can be included and what cannot be included in the solution. The delivery can be phased
and prioritised to maintain solution implementation momentum. Solution design is concerned with finding an optimal
Solution Space. There may be many Solution Space options. The solution architect needs to focus on finding the most viable
ones quickly and the deciding on the one(s) to pursue.

This relates to the Bounded attribute of a requirement described at the start of this section.

4.4.1 Requirements Engineering

It is outside the scope of this book to describe in detail the area of requirements engineering. It is mentioned briefly here to
provide background information on the topic, given the traditional importance of requirements elicitation in the solution
design process.

There is a large amount of material available on the subject of requirements engineering. For example, there have been several
revisions of ISO/IEEE standards that have evolved and developed overtime:

• IEEE Standard 830-1998 IEEE Recommended Practice for Software Requirements Specifications23

23
see:

Page 129 of 540

 Introduction to Solution Architecture

• ISO/IEC/IEEE 29148:2011 Systems and Software Engineering – Life Cycle Processes – Requirements Engineering24

• IEEE 29148-2018 - ISO/IEC/IEEE Approved Draft International Standard - Systems and Software Engineering -- Life
Cycle Processes --Requirements Engineering25

The ISO/IEC/IEEE 29148 standard is intended to describe the processes and artefacts for the engineering of requirements for
systems, software products and services throughout their life cycles. It defines what a good requirement should look like and
lists their attributes and characteristics of requirements.

The wider requirements engineering standards landscape consists of an array of complex interrelated standards:

Figure 80 – Wider Requirements Engineering Landscape

The wider requirements engineering landscape consists of the following standards:

• ISO/IEC TR 24766:2009 Information Technology — Systems And Software Engineering — Guide For Requirements
Engineering Tool Capabilities26

https://standards.ieee.org/standard/830-1998.html . This was replaced by ISO/IEC/IEEE 29148:2011.

24
See:
https://standards.ieee.org/standard/29148-2011.html
25
See:
https://standards.ieee.org/standard/29148-2018.html
26
See:
https://www.iso.org/standard/51041.html

Page 130 of 540

 Introduction to Solution Architecture

• IEEE 1220 (ISO/IEC 26702) Systems Engineering — Application And Management Of The Systems Engineering
Process27

• ISO/IEC 25010:2011 Systems And Software Engineering — Systems And Software Quality Requirements And Evaluation
(SQuaRE) — System And Software Quality Models28

• ISO/IEC 25030:2007 Software Engineering — Software Product Quality Requirements And Evaluation (SQuaRE) —
Quality Requirements29

• ISO/IEC/IEEE 24765:2017 Systems And Software Engineering — Vocabulary30

• ISO/IEC/IEEE 15288:2015 Systems And Software Engineering — System Life Cycle Processes31

• ISO/IEC/IEEE 12207:2017 Systems And Software Engineering — Software Life Cycle Processes32

The ISO/IEC/IEEE 29148:2011 standard includes five deliverables:

1. Stakeholder Requirements Specification (StRS) document

2. System Requirements Specification (SyRS) document
3. Software Requirements Specification (SRS) document
4. System Operational Concept (OpsCon) document
5. Concept of Operations (ConOps) document

The contents of these documents are listed below.

The scope of the Stakeholder Requirements Specification (StRS) document is:

• Business Purpose
• Business Scope
• Business Overview
• Stakeholders
• Business Environment
• Goal And Objective
• Business Model
• Information Environment
• Business Processes
• Business Operational Policies And Rules
• Business Operational Constraints
• Business Operation Modes
• Business Operational Quality
• Business Structure
• User Requirements
• Operational Concept

27
See:
https://www.iso.org/standard/43693.html
28
See:
https://www.iso.org/standard/35733.html
29
See:
https://www.iso.org/standard/35755.html
30
See:
https://www.iso.org/standard/71952.html
31
See:
https://www.iso.org/standard/63711.html
32
See:
https://www.iso.org/standard/63712.html

Page 131 of 540

 Introduction to Solution Architecture

o Operational Policies And Constraints

o Description Of The Proposed System
o Modes Of System Operation
o User Classes And Other Involved Personnel
o Support Environment
• Operational Scenarios
• Project Constraints
The scope of the System Requirements Specification (SyRS) document is:

• System Purpose
• System Scope
• System Overview
o System Context
o System Functions
o User Characteristics
• Functional Requirements
• Usability Requirements
• Performance Requirements
• System Interfaces
• System Operations
o Human System Integration Requirements
o Maintainability
o Reliability
• System Modes And States
• Physical Characteristics
o Physical Requirements
o Adaptability Requirements
• Environmental Conditions
• System Security
• Information Management
• Policies And Regulations
• System Life Cycle Sustainment
• Packaging, Handling, Shipping And Transportation
• Verification
• Assumptions And Dependencies

The scope of the Software Requirements Specification (SRS) document is:

• Purpose
• Scope
• Product Perspective
o System Interfaces
o User Interfaces
o Hardware Interfaces
o Software Interfaces
o Communications Interfaces
o Memory Constraints
o Operations
o Site Adaptation Requirements
• Product Functions
• Product Functions
• Product Functions
• Assumptions And Dependencies
• Apportioning Of Requirements
• Specific Requirements

Page 132 of 540

 Introduction to Solution Architecture

• External Interfaces
• Functions
• Usability Requirements
• Performance Requirements
• Logical Database Requirements
• Design Constraints
• Standards Compliance
• Software System Attributes
• Verification
• Supporting Information

The scope of the System Operational Concept (OpsCon) document is:

• Scope
o Scope
o Document Overview
o System Overview
• Referenced Documents
• Current System Or Situation
o Background, Objectives, And Scope
o Operational Policies And Constraints
o Description Of The Current System Or Situation
o Modes Of Operation For The Current System Or Situation
o User Classes And Other Involved Personnel
 Organisational Structure
 Profiles Of User Classes
 Interactions Among User Classes
 Other Involved Personnel
o Support Environment
• Justification For And Nature Of Changes
o Justification For Changes
o Description Of Desired Changes
o Priorities Among Changes
o Changes Considered But Not Included
o Assumptions And Constraints
• Concepts For The Proposed System
o Background, Objectives, And Scope
o Operational Policies And Constraints
o Description Of The Proposed System
o Modes Of Operation
o User Classes And Other Involved Personnel
 Organisational Structure
 Profiles Of User Classes
 Interactions Among User Classes
 Other Involved Personnel
o Support Environment
• Operational Scenarios
• Summary Of Impacts
o Operational Impacts
o Organisational Impacts
o Impacts During Development
• Analysis Of The Proposed System
o Benefits
o Disadvantages And Limitations
o Alternatives Considered

Page 133 of 540

 Introduction to Solution Architecture

The scope of the Concept of Operations (ConOps) document is:

• Purpose
• Scope
• Strategic Plan
• Effectiveness
• Overall Operation
o Context
o Systems
o Organisational Unit
• Governance
o Governance Policies
o Organisation
o Investment Plan
o Information Asset Management
o Security
o Business Continuity Plan
o Compliance

These deliverables are very detailed, comprehensive and time-consuming to produce. The extent and level of detail is
appropriate only to large and complex software product solutions. It is also not always possible to create these deliverables at
the requirements gathering phase. Most organisations simply do not have the resources to adopt and put into practise these
standards.

Elements of them could be incorporated into standard requirements artefacts produced during most solution delivery
projects,

These represent a highly complex set of standards that have a limited applicability to the business world. They may have some
relevance to organisations developing very complicated automation and process control systems and software products for
certain (highly regulated) industries and applications such as airlines and aerospace, petro-chemical, pharmaceutical, power
stations, medical devices and military. Outside these particular areas, they are of limited if any value and use. Understanding,
applying and keeping current with these standards represents a substantial overhead for any organisation whose effort would
have to be justified.

Finally, these standards focus largely on the software development process. A business or any other information technology
solution consists of much more than just software.

In common with many other information technology practice areas, there has been an initiative to create a Body of
Knowledge, in this case the REBOK (Requirements Engineering Body Of Knowledge). This has been led by JISA (Japan
Information Technology Services Association)33. Some time ago, JISA initiated a RE WG (Requirements Engineering
Working Group) that has evolved to create the REBOK. Unfortunately, the REBOK is currently only available in Japanese34.

4.4.2 Business
Busin ess Processes

As discussed in section 4.1 on page 91, solutions exist to allow business processes to operate. The business organisation
develops, implements and operates business processes. Solutions enable these business processes. So, solutions should be
designed with respect to the processes they will implement. Similarly, the business must take account of the capabilities of
software components, especially acquired products, either on-premises or hosted, when designing processes. While products

33
See:
https://www.jisa.or.jp/
34
See:
http://www.re-bok.org/ and https://www.jisa.or.jp/publication/tabid/272/pdid/Rebok2014/Default.aspx

Page 134 of 540

 Introduction to Solution Architecture

can be customised to suits the needs of the business such customisation is risky (see section 3.2 on page 71), it is almost
always better to adapt processes to the capability of the product.

Processes impact solution design and solution operation is several ways:

• New business processes may need to be defined that describe how the business function should use the solution
• Existing business processes may need to be changed
• Both the new and existing processes should be optimised in a way that the number of activities and the number of roles
involved (and their associated handoffs) are kept to a minimum
• Decisions may be made about the scope of solution, the components to be implemented and the functionality provided
by those components that necessitate work being done outside the scope of the solution, such as manual workarounds

You cannot ignore the process dimension when defining the full set of components that comprise the solution.

There is a hierarchy from information technology infrastructure, platforms, the solutions implemented on those platforms,
the functionality those solutions deliver, business processes that use those functions and the results, outcomes achieved and
value generated for the organisation.

Figure 81 – Hierarchy of
of Information Technology, Business Processes and Value Achieved

The solutions enable business processes to operate. So, the solution design must be aware of the business processes whose
execution it has to enable.

Business process analysis and design is typically performed by business analysts or business process analysts within the
business analysis function. It is common for the business process analysis function to be separate from the business analysis
function. This splitting of functions that are important to the complete design of the overall solution leads to further loss of
information and detail.

Page 135 of 540

 Introduction to Solution Architecture

The business function looking for the solution must define or be guided and directed through and assisted with the definition
of the new business processes and the changes to existing business processes that the solution and its components will
operate. This is one of the reasons why the rapid solution design process described in section 4.6.5 on page 257 has as one of
its core elements the identification of the inventory of business processes enabled and impacted by the solution. This provides
a context for subsequent detailed process design work. It means the solution design work does not get bogged down in
process details before the overall background is understood and before identifying what the affected processes are and how
they relate to one another

As with business analysis and requirements engineering, a full description of business process analysis approaches and
techniques is outside the scope of this book. However, given the importance of business processes to the solution design
process, I have included some relevant details on the topic here.

Neither the solution architecture nor the business analysis functions should develop business processes. They can help with
their design or redesign. But the business must originate and own the business processes.

The topic of business processes and that of organisational change are linked. Business change, especially when associated with
new solutions, can be inevitable. An organisational change process addresses an essential element of business change
associated with the implementation of new solution - the people working in the organisation. Effective deployment of
solutions and realisation of business results requires active management of the people issues. The organisational change
process starts with understanding the objective of and reason for the business changes and the role that other causes of and
enablers of change in the technology and process areas play.

The failure to manage the business change and human side of solution delivery is a major contributor to the reasons solutions
and initiatives fail. Organisation managers can be all too commonly focussed on tactical and operational issues and do not
have the time to consider organisational changes in the necessary detail.

In an unpublished survey conducted by ARIS, now part of Software AG35 on what lessons were learned from the
implementation of large information technology solutions, the following results were obtained:

35
See:
https://www.softwareag.com/nl/products/aris_alfabet/bpa/default.html

Page 136 of 540

 Introduction to Solution Architecture

Figure 82 – Lessons Learned from Large Solutions Implementations

The importance of these various factors was:

Lesson Importance
Pay More Attention To Process Optimisation 80%
Align Systematically To Organisation Goals 65%
Pay More Attention To Understanding The Subject Area Spanned 60%
Implementation Of A Management Information System As Part Of Scope 55%
Outsource Project Management Of The Project To A Third Party 50%
Increase Investment In Training 45%
Greater Employees Involvement 35%
Enforce Changes More Courageously 35%
Identify And Capture Proof Of Benefits And Saving As Part Of Scope 30%
Avoid Big-Bang Implementations 20%

Table 22 – Lessons Learned from Large Solutions Implementations

The need for business process optimisation was assigned the highest importance. The principles for process optimisation
include:

• Design around Customer Interactions

• Design around Value-Adding Activities
• Introduce Parallel Processing Where Possible
• Identify and Handle Exceptions Separately
• Minimise Handoffs
• Perform Work Where it Makes the Most Sense
• Provide a Single Point of Contact
• Create a Separate Process for Each Cluster
• Ensure a Continuous Flow
• Reduce Batch Size
• Bring Downstream Information Needs Upstream
• Capture Information Once at the Source and Share It
• Involve as Few as Possible
• Redesign, then Automate
• Ensure Quality at the Beginning
• Standardise Processes
• Use Co-located or Networked Teams for Complex Issues

Page 137 of 540

 Introduction to Solution Architecture

Figure 83 – Process Optimisation Through Compression of Steps and Collapse of Handoffs

Processes should be optimised through:

• Compression – reduce unnecessary/non-value-adding steps and combine and automate steps

• Collapse – eliminate unnecessary handoffs and involvement by unnecessary roles

Process optimisation is similar to identifying and eliminating unnecessary complexity in solution design that is discussed in
section 4.2 on page 95.

One dimension of optimisation is the elimination of waste within processes. The original concept of process waste came from
the Lean Manufacturing.

The original Lean Manufacturing listed seven causes of waste:

1. Overproduction - manufacturing an item before it is actually required

2. Waiting - whenever goods are not moving or being processed
3. Transport - moving products between processes is a cost which adds no value to the product
4. Inventory – excess work in progress (WIP) cases by overproduction and waiting
5. Unnecessary / Excess Motion - people or equipment moving or walking more than is required to perform the
processing
6. Over/Inappropriate Processing - using expensive resources where simpler ones would be sufficient
7. Defects - resulting in rework or scrap or the need for excessive quality control

Over time additional causes of waste were added:

8. Wrong Product
Product - manufacturing goods or services that do not meet customer demand or specifications
9. 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
10. Inadequate Performance Measurement - working to the wrong performance metrics or to no metrics
11. Uninvolved Personnel - not using staff fully by not allowing them to contribute ideas and suggestions and be part of
participative management

Page 138 of 540

 Introduction to Solution Architecture

12. Inadequate Technology

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

The identification of waste in business processes can be applied as listed in the following table.

Cause Of Waste Business Process Approach to Eliminating Waste

1. Overproduction • Process work as it arises
2. Waiting • Reduce delays as work waits to be processed
• Reduce linear processing and include as much parallelism as possible
3. Transport • Reduce number of steps and movement and delays
• Ensure work in performed in the optimum location
• Reorganise work processing to optimise locations
4. Inventory • Eliminate batching of work rather and move individual cases through the process
5. Unnecessary / Excess • Reduce unnecessary handoffs
Motion • Reduce fragmentation of work
• Reduce the need to search for information
6. Over/Inappropriate • Reduce unnecessary variation in work types
Processing • Reduce the application of unnecessary steps to work
• Do not delay simple work with steps that only need to be applied to complex work
• Reduce non-value adding steps
• Eliminate unnecessary checks and controls
7. Defects • Reduce the need for inspection by automating quality checks and identifying errors as
early in the process as possible
• Do not allow work to start until necessary pre-requisites are available
8. Wrong Product • Organise work around processes rather than processes around work and focus
9. People Unmatched to • Ensure people are adequately and continuously trained
Role • Structure work around required functional competencies
10. Inadequate • Design process metrics to allow process efficiency to be measured
Performance • Implement process data collection, reporting and analysis
Measurement • Take decisions on process metrics
11. Uninvolved • Delegate decision-making and empower people to complete work
Personnel • Encourage, support and reward new ideas
• Encourage feedback from those performing the work
12. Inadequate • Ensure people has access to the necessary technology to allow work to be done
Technology efficiently
• Use technology to automate business processes
• Optimise technology
• Build knowledge-base and documentation into technology

Table 23 – Applying Waste Elimination Principles to Process Optimisation

A business process can be defined as the set of activities that is triggered by one or more events or statuses, requiring one or
more inputs and performed in structured outcome-dependent order or sequence to generate one or more outputs or results
and influence one or more outcomes.

Page 139 of 540

 Introduction to Solution Architecture

Figure 84 – Generic Representation of a Process

The individual activities within the process concerned with making decisions and generating outputs. The process is the self-
contained unit that completes a given task. The process can consist of sub-processes and/or activities. The process and its
constituent activities, stages and steps can be decomposed into a number of levels of detail, down to the individual atomic
level.

Process analysis and design is concerned with optimising an existing or new process and focussing on efficiency and adding
value. The process is primarily concerned with its results and outputs.

A process activity and sequence view is useful for identifying opportunities for efficiencies, resource optimisation, monitoring
progress, collecting volumetric information and detecting problems, duplicated effort, bottlenecks, resource constraints and
non value-adding activities such as waste and the opportunity for process compression/collapse described earlier.

An organisation can be viewed as an assembly of processes that co-ordinate activities to design, develop, produce, market, sell
and deliver products and services to its consumers and provide subsequent support and other services. These are the core
value-adding activities. There are many supporting processes and activities. Core value-adding processes and their activities
are grouped into primary process groups. Each primary process group contains one or more value-adding process activity
sets as well as management and supporting processes.

The process activity set is the set of activities performed to respond to a business event. These can be sub-divided until the
Fundamental Business Process Activity Set level is reached.

Processes can be analysed and decomposed to varying levels of detail and granularity.

Page 140 of 540

 Introduction to Solution Architecture

Figure 85 – Process Decomposition

The decomposition of the sample customer process for buying a product or service described section 4.6.5.11 on page 272
could be represented as follows:

Figure 86 – Process Decomposition Example

The Fundamental Business Process Activity Set can be viewed as the lowest level of business activity that is performed by a
single person within the organisation either entirely manually or with system support and Is generally performed by that
person within a single session. These Fundamental Business Process Activity Sets are at the core of business analysis and
design in the context of solution architecture and design. You should identify the minimum set of Fundamental Business
Process Activity Sets that comprise the business process. The Fundamental Business Process Activity Sets for this buying a
product or service example can be viewed as:

Page 141 of 540

 Introduction to Solution Architecture

Figure 87 – Identification of Fundamental Business Process Activity Sets

There are two Fundamental Business Process Activity Sets here:

1. Handle Customer Call and Generate Order

2. Product/Service Order Fulfilment

Each of these process activity sets will consist of multiple tasks and steps. Handle Customer Call and Generate Order could
include the following steps

• Respond to Customer
• Identify Product/Service Bundle
• Check Availability
• Take and Validate Customer Details
• Agree Price
• Process Payment/Agree Credit
• Handle Exceptions
• Agree Delivery/Provision Schedule

This decomposition and level of detail may not be required at this stage. We just need to know that it has to be and can be
done later.

Activities within processes can be linked by routers that direct flow and maintain order based on the values of output(s) and
the status of outcome(s).

Page 142 of 540

 Introduction to Solution Architecture

Figure 88 – Activity Linkage within Processes

Decisions are the results of (activities and tasks within) business processes. Business processes define the paths to these
results. A business rule defines how inputs are processed to perform actions and make decisions. Business rules (should)
describe and contain the intelligence and decision making of the organisation. The linkage between process inputs, business
rules, actions, decisions and results is shown below.

Figure 89 – Process Inputs, Rules, Actions, Decisions and Results

Processes generate results by applying business rules. These results can be actions performed or decisions made.

Processes do not achieve outcomes. An outcome is the desired consequence of a successfully executed process. Examples of
outcomes include:

• Increased sales
• Higher sales conversion rate
• Increased revenue
• Increased profit
• Improved cashflow
• Improved customer satisfaction

The process can influence the achievement of these outcomes through characteristics such as stream-lined operation, speed
and accuracy of response, better process consumer experience and flexibility.

When recognising the processes impacted by a solution, these will occur in three groups:

Page 143 of 540

 Introduction to Solution Architecture

1. Primary
2. Support
3. Management

Figure 90 – Process Groups

Primary processes are end-to-end, cross-functional processes which directly deliver value. They represent the essential
activities an organisation performs to fulfil its business objectives. These primary processes make up the value chain where
each step adds value to the preceding step as measured by its contribution to the creation or delivery of a product or service,
ultimately delivering value to the organisation. Primary processes can move across business functions, across departments or
even between organisations (such as business partners) and provide a complete end-to-end view of value creation.

All too commonly, the organisation sees its structure vertically and in a compartmentalised view and does not take a cross-
functional view of the end-to-end process that cross these vertical functions. This absence of a cross-functional view leads to
inefficient processes with additional non-value adding steps, unnecessary handoffs and delays while work move between
vertical functions. This is very similar to the issue of silos within solution delivery described in section 2.6 on page 50.

Changing business process operations to take a cross-functional view eliminates waste and inefficiencies associated with work
moving through these organisational silos.

Support processes assist primary processes by performing activities such as managing resources and/or infrastructure
required by primary processes. The differentiator between primary and support processes is that support processes do not
directly deliver value. This does not mean that they are unimportant to an organisation. Support processes include
information technology management, facilities or capacity management and human resource management. Support
processes are generally associated with functional areas but can and often do cross functional boundaries.

Management processes are used to measure, monitor and control business activities and the performance of primary and
support processes. They ensure that a primary or supporting process meets operational, financial, regulatory and legal targets.
Again, they do not directly add value. They are necessary in order to ensure the organisation operates effectively and
efficiently. They can identify process bottlenecks and constraints and the need or opportunity for process improvement.
Many organisations do not have well defined management processes. Effective process management requires measurement
and the ability to analyse the process measures collected. Business process measurement and monitoring provides critical
feedback on process design, performance and compliance. It is necessary to measure process performance in terms of a
variety of possible metrics related to how well the process meets its stated goals.

The following table lists the sample primary and support processes for buying a product or service described on page 273:

Page 144 of 540

 Introduction to Solution Architecture

Phase Step Primary Processes Secondary Processes

Research/ Consider Look For Information/ • Manage Contact • Record, Track, Analyse
Awareness and Interest and Report on Customer
Generated Contacts
• Manage Information
Content and Access
Inquire/ Evaluate Look For Details on • Respond to Customer and • Track Leads
Specific Product/ Service/ Issue and Distribute • Manage Prospect
Offer Marketing Collateral
• Qualify Customer
Receive, Evaluate Offer, • Negotiate Sales/Contract • Manage Sales Accounts
Negotiate and Compare • Acquire Customer Data
• Cross/Up Selling
• Develop Sales Proposal
Decide/ Negotiate Decide To Buy Product/
Service
Buy/Subscribe Buy/ Subscribe and Receive • Determine Customer • Track and Manage
Product/ Service Order Feasibility Customer Order
• Authorise Credit Handling
• Complete Customer • Report Customer Order
Order Handling
• Issue Customer Orders • Manage Inventory
• Fulfil Order • Manage Deliveries
Use/ Bill and Pay/ Receive and Pay Usage • Apply Pricing, • Collect Billing
Change/ Upgrade/ Statements and Bills, Pay Discounting, Adjustments Information
Complain/ Report Fault/
Fault/ Bill and Rebates • Manage Customer Billing
Leave • Create Customer Bill • Manage Customer
• Produce and Distribute Payments
Bill • Manage Customer Debt
Collection
Query Usage Statement • Receive and Handle • Record, Track, Analyse
and Bill Inquiry and Report on Customer
• Track Inquiry to Contacts
Completion
• Respond to Query
Report Fault/ Complain • Receive and Handle Fault • Record, Track, Analyse
Report/Complaint and Report on Customer
• Track Fault Contacts
Report/Complaint to
Completion
• Respond to Fault
Report/Complaint
Upgrade/ Buy Additional • Manage Contact • Build Customer Insight
Product/ Service/ Respond • Negotiate Sales/Contract • Analyse and Manage
to Offer • Cross/Up Selling Customer Risk
• Develop Sales Proposal • Personalise Customer
Profile for Retention and
Loyalty
• Validate Customer
Satisfaction
• Manage Information
Content and Access
Renew, Evaluate • Negotiate Sales/Contract
Alternatives and Negotiate • Cross/Up Selling
Decide to Leave/ Cancel • Manage Termination

Page 145 of 540

 Introduction to Solution Architecture

Phase Step Primary Processes Secondary Processes

Service
Accept Counteroffer

Table 24 – Primary and Support Processes Example

The design of the solution may need to encompass the design of the processes that the solution will impact or enable or
require. Very frequently, the process design work associated with the design of a new solution is the first time the entire end-
to-end business process will have been documented or attempted to be documented. The business analysis function will assist
the business function in doing this work as part of the inclusive solution design work.

Focus on the design of how end-to-end work occurs in order to deliver value. Document the sequence of activities, including
the design of what work is performed, at what time, in what location, by what process actors using what rules.

The high-level process analysis steps are shown below

Figure 91 – Business Process Analysis High-

High-Level Steps

Step Description
Describe Current Process Describe the current process landscape in enough detail to allow business rules to be
Landscape understood and for issues, problems and improvements to be identified.
Describe Current Process Where appropriate (when current processes are being redesigned), describe the
Performance and Value effort, resources, cost, duration, errors, rework and value generated for the current
Generated processes.
Identify and Design the Core Identify and (re)design the theoretical minimum set of core processes required to
Process Landscape achieve the required outcomes and results assuming there are no constraints.
Define Throughput Requirements Define the performance and through required for the process operation – effort,
and Performance Measurement resources, costs, error, quality, rework – and define the measurement framework to
Framework create the data to assess this.
Verify Core Process Landscape Verify that the (re)designed set of core processes will achieve the defined set of
performance and throughput requirements.

Page 146 of 540

 Introduction to Solution Architecture

Table 25 – Business Process Analysis

Analysis High-
High-Level Steps

The structure of the information to be gathered during process analysis is:

Figure 92 – Process Analysis Information Structure

This shows information being collected for current and new processes. If existing processes are not being analysed them this
side of the analysis can be omitted. The details of this information structure are listed in the table below.

Analysis Group Analysis Item Description

Business Process Process Structure and List List the process hierarchy: major process groups and key processes
Model within each group. There will be two types of processes:

1.Delivery processes
2.Management and support processes that are concerned with the
internal management and operation of the business function
Process Definitions Create high-level descriptions for the major process groups and key
processes within each group.
Pre-Conditions Detail what must have happened before the process can start.
Pre-Requisites What must be in place before the process can start.
Inputs What the process needs to operate.
Dependencies What the process is dependent on.
Process Triggers Detail what causes each of the key processes to be initiated.
Processing What the process does.
Process Outcomes/ Results Detail the outcomes, deliverables and results of the key processes.
Process Conceptual Conceptual representations are actor/entity-based pictures that
Representation communicate at a high level how a business process works.
Process Flow These are standard business process flows, typically represented as
Representation cross-functional diagrams.
Timelines What are the expected process times.
Roles and Responsibilities Who is involved in the process.

Page 147 of 540

 Introduction to Solution Architecture

Analysis Group Analysis Item Description

Skills and Capabilities What skills are required of the process participants.
Process Process Beneficiary What are the requirements of each of the main beneficiaries (such as
Performance Requirements customers) want from the process, both in terms of performance
Structure (time to compete) and results.
Comparative Performance What do other organisations achieve for similar processes to similar
Summary beneficiaries illustrating what is possible.
Process Performance What are the metrics for the processes: time to complete, cost,
Metrics resources, steps, number of process executions, errors, rework.
Process Performance What is the measurement framework used to assess process
Measurement Structure performance and throughput and how is the data collected, analysed
and presented.
Other Issues Any issues not clarified.
Identified/Outstanding
Assumptions Any assumptions made in the process design.

Table 26 – Process Analysis Information Structure

The factors that increase the success of business process design and redesign are:

Figure 93 – Business Process Design Success Factors

These success factors are:

Factor Description
Focus On The Process Make the beneficiaries of the process the centre of process change and process
Beneficiaries value.
Emphasise The Process And Not The process drives value achieved. Technology and organisation are enablers of
Its Constraints process operations. Value is derived from process improvement and optimisation.
Do not embed constraints into the process from the start.
Examine Process Delivery First Get the process activities needed to achieve the process goals first. Then examine
and Then Process Performance and optimise process performance.

Page 148 of 540

 Introduction to Solution Architecture

Factor Description
Extend Process Examination To Your processes may interact with other external processes. Consider extending your
External Processes analysis to these to understand the complete process.
Examine The Entire Process The process consists of the activities, the organisation functions that operate the
Landscape processes, the source of the process initiation and technology. Look at all these
elements.
Create A Top-Down Process Create a vision for process excellence based on service, performance, delivery and
Vision achievement of goals unconstrained by limitations.
Do Not Accept Current Beliefs Document the existing rules, assumptions, principles and constraints that underpin
the current process operation. Do not accept these when redesigning processes.
Look At What Others Have Learn from the experiences and achievements of other organisations in achieving
Achieved process change to benefit from them.

Table 27 – Business Process Design Success Factors

The objective of this work is to define what the organisation wants the process to be and answers the what, when, where, who
and how questions of how end-to-end work is executed. This contributes to the solution design.

The process design work should ensure that the proper management controls and metrics are in place for compliance and
performance measurement of process operation.

Understanding the process typically involves process modelling and an assessment of the environmental factors which enable
and constrain the process. A model is rarely a complete and full representation of the actual process. The objective is to create
a representation of the process that describes it accurately and sufficiently for the task at hand to assist with:

• Understanding the business process through the creation of the model

• Creating a visible representation and establishing a commonly shared perspective
• Analysing process performance and defining and validating changes

The To-Be model is an expression of the desired target process state and specifies the requirements for the supporting
resources that enable effective business operations. There is a range of process design, modelling and notational standards
and techniques – see section 8.3.5.1.2 on page 518 for information on the Archimate language and section 4.4.2.1 on page 151
for an outline of the BPMN standard. These process modelling approaches provide a language for describing and
communicating as-is and to-be process information. Like all new languages they must be learned and understood.

There are a number of benefits to using a standards-based approach including:

• A common symbology, language and technique which facilitate communication and understanding
• Standards-based models provide common and consistently defined processes definitions which eases the process of
design, analysis and measurement and facilitates model reuse
• An ability to leverage modelling tools based on common standards and notations
• An ability to import and export models created in various tools for reuse in other tools
• Some tool vendors are leveraging standards and notations for developing the ability to be exported from a modelling
notation to an execution language (for example BPMN to BPEL – WS-BPEL)

The principles of business process analysis and design are:

Page 149 of 540

 Introduction to Solution Architecture

Figure 94 – Business Process Design Standards and Approaches – Part 1

Figure 95 – Business Process Design Standards and Approaches – Part 2

Process Design Standard and Process Design Standard and Approach Area
Approach Group
Process Simplification Ensure Work Is Process Focussed
Reduce Or Eliminate Handoffs
Reduce Work Fragmentation
Reduce Complexity Where Possible
Reduce The Requirement For Reconciliation
Reduce The Need For Controls
Reduce The Requirement For Co-ordination
Process Efficiency And Reduce Or Eliminate Non-Value Adding Activity
Effectiveness Reduce Movement of Work
Reduce Searching For Information
Match Process Costs With Value Generated
Process Quality Reduce Or Eliminate Variability
Focus On Getting The Right Result
Reduce Or Eliminate Rework

Page 150 of 540

 Introduction to Solution Architecture

Process Design Standard and Process Design Standard and Approach Area
Approach Group
Reduce Or Eliminate The Requirement For Review
Process People And Organisation Devolve Decision Making Authority
Structure Teams By Process and Required Skills
Process Workflow Introduce Parallel Processing Where Possible
Reduce Or Eliminate Breaks In Workflow
Have A Workflow Status Dashboard
Separate Simple Cases From Complex Cases
Reduce The Requirement For Reconciliation
Allow Multiple Workflow Versions In Parallel
Process Improvement Enable Process Improvement
Provide Analysis Of Process Performance
Encourage Process Feedback From Users
Process Technology Link Systems To Organisation And Work Structures
Collect Process Information And Build Knowledge Database
Reduce Or Eliminate Manual Data Entry
Reduce Or Eliminate Variation
Automate Work As Much As Possible
Automate Controls As Much As Possible
Process Location Locate Work Appropriately
Centralise Or Decentralise As Appropriate

Table 28 – Business Process Design Standards and Approaches

4.4.2.1 Business Process Modelling Notation (BPMN)

This section contains a brief introduction to BPMN.

BPMN36 is a reasonably widely used and supported standard for business process modelling. One advantage of using BPMN
is that you can output BPMN to Business Process Execution Language (BPEL – WS-BPEL37). This is a standard executable
language for specifying interactions with Web Services.

Like Archimate (see section 8.3.5.1.2 on page 518), BPMN is an inflected language where a basis set of code symbols are
modified by the addition of extra codes to indicate a specific purpose or meaning.

BPMN is not an:

• Organisation structure design language

• Data model and data flow design language but it does contain some data modelling elements
• System functional flow design language

BPMN can be used to show cross-functional process flow. The Pool represents major participants in a process with separate
pools for different organisations or major business units. The Lane is contained within pools. You organise and categorise
process activities within a pool according to function or role. All BPMN diagram elements are placed within swim lanes and
pools.

36
See https://www.omg.org/bpmn/ and https://www.omg.org/spec/BPMN/2.0/About-BPMN/ for more details on BPMN.
37
See https://www.oasis-open.org/committees/download.php/23964/wsbpel-v2.0-primer.htm and http://docs.oasis-
open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html for more details on BPEL

Page 151 of 540

 Introduction to Solution Architecture

Figure 96 – BPMN Pools and Lanes

Schematically, the basic structure of BPMN is

Figure 97 – BPMN Structure

Flow Objects are grouped as follows:

Page 152 of 540

 Introduction to Solution Architecture

Figure 98 – BPMN Flow Objects

Flow Objects define the flow of the process.

Flow Object Symbol Description

Task Unit of work

Sub-Process A set of self-contained activities collapsed within process representation for ease of
understanding

Transaction A sub-process that must be completed or undone if not completed

Start Acts as a trigger for a process/sub-process and takes an input only

End Represents the result of a process/sub-process and generates an output only

Intermediate Represents something that happens between the start and end events

Exclusive Where the sequence slow can take only one of two or more alternative paths

Inclusive Where the sequence slow can take one, more than one or all of two or more
alternative paths and results from paths must be subsequently merged

Parallel Multiple parallel paths are defined

Page 153 of 540

 Introduction to Solution Architecture

Flow Object Symbol Description

Complex Complex behaviours can be defined

Table 29 – BPMN Flow Objects

The following shows how the task symbol is modified to change its behaviour

Figure 99 – Modifying BPMN

The following table shows the BPMN graphic symbols for combinations of task type and loop type.

No Loop Simple Loop Multiple in Multiple in

Parallel Sequence
Simple/Not Specified

Service

Send

Receive

User

Script

Page 154 of 540

 Introduction to Solution Architecture

No Loop Simple Loop Multiple in Multiple in

Parallel Sequence
Manual

Business Rule

Table 30 – BPMN Graphics for Combinations of Task Type and Loop Type

The following table shows the BPMN graphics for sub-processes.

Embedded Sub-
Sub- Embedded Embedded Sub-
Sub- Embedded Called
Process Transaction Sub-
Sub- Process Triggered Sub-
Sub-Process
Process by Event
No Event Specified

Message

Error

Escalation

Compensation (Backout
of Transaction)

Conditional

Signal

Page 155 of 540

 Introduction to Solution Architecture

Embedded Sub-
Sub- Embedded Embedded Sub-
Sub- Embedded Called
Process Transaction Sub-
Sub- Process Triggered Sub-
Sub-Process
Process by Event
Multiple

Timer

Multiple in Parallel

Table 31 – BPMN Graphics for Sub-

Sub-Processes

BPMN events can be modified using a variety of symbols.

Figure 100 – BPMN Event Modification

The following table shows event modifications available:

Start Intermediate Intermediate End

(Inward Direction (Outward
“Catching”) Direction
“Throwing”)
No Trigger

Message

Timer

Conditional

Page 156 of 540

 Introduction to Solution Architecture

Start Intermediate Intermediate End

(Inward Direction (Outward
“Catching”) Direction
“Throwing”)
Signal

Multiple

Multiple in Parallel

Error

Escalation

Compensation (Backout
of Transaction)
Link

Cancel

Terminate

Table 32 – BPMN Event Modifications

Gateways in BPMN control the execution of the process. They represent decisions/branching (exclusive, inclusive, and
complex), merging, forking and joining. Parallel gateways synchronise/combine and create parallel flows. Event-based
gateways represent a branching point in the process where the alternative paths that follow the gateway are based on events
that occur.

Inclusive (AND)

Exclusive (OR)

or
Complex

Parallel

Exclusive Event

Start Exclusive Event

Start Parallel Event

Table 33 – BPMN Gateway Symbols

Page 157 of 540

 Introduction to Solution Architecture

BPMN allows the modelling of items (physical or information items) that are created, manipulated and used during the
execution of a process such as data inputs, data outputs, persistent data stores and collections of data.

Data

Data Collection

Data Input

Data Collection Input

Data Output

Data Collection Output

Data Store

Table 34 – BPMN Data Symbols

As a process representation language BPMN offers the opportunity for great rigour and exactness. However, that level of
detailed information has to be captured about the process. This can be time-consuming and complex. Also, the language has
to be understood by all those participating in the process design activity. This includes business participants whose
involvement is most likely temporary and part time. It is not reasonable to expect them to learn full BPMN language.

The rigour of BPMN is necessary when you are publishing process to a BPEL where it will be executed. For simple process
analysis, definition and description, the full BPMN language is perhaps less useful.

4.5 Solution Architecture Engagement Process

The solution architecture function needs to have a number of engagement models and approaches available in its toolbox to
assist the business with designing solutions to meet its needs. The purposes of having defined engagement models are:

• They provide certainty about the purpose, scope, duration and outputs for the business

• Having separate engagement models provides the flexibility to allow the needs of the business to be met at any stage of
the solution journey

• They maximise reuse and repeatability

• They ensure that quality deliverables are produced

• They ensure the work done is comprehensive

• They increase the confidence of the business that the solution architecture function will provide a quality service

These engagements can occur at different stages in the solution design journey, from the business looking for a concept to be
explored or the business looking for a consulting exercise on the solution needs of a business function or for a solution to be
designed to different levels of detail to understand its likely delivery cost, time and resources.

The following sections describe in detail a number of different engagement types. These can occur in the context of a solution
delivery project or can occur separately from or prior to any decision to implement the solution design.

Page 158 of 540

 Introduction to Solution Architecture

Figure 101 – Solution Architecture Engagement Models

These engagement types are:

• Business Engagement – this is a formal business consulting assignment designed to take place before the idea of
implementing one or more new solutions has been formalised. It aims to take a broad business concern, opportunity or
problem and define new business structures and associated information technology and business processes to realise a
potential resolution. This engagement is designed to take place before any formal solution delivery project is initiated.
Such a project cannot be defined until the objectives of the project can be defined to a sufficient extent and in sufficient
detail that it can be termed a project. This is a non-traditional solution architecture engagement but one which
potentially offers real value to the organisation. This is described in section 4.6.1 on page 161.

• Solution Design Process – this is a formal process for iteratively creating a solution design that can use elements and
techniques of the following engagement types to progress the design process:

• Early Engagement – this is a consulting-type engagement where the problem to be resolved or the opportunity to
be addressed is uncertain. There is some overlap in this type of engagement and that of the business engagement.
The latter is broader in that it is looking to design the structure of the business function (including any information
technology and solution landscape). The former is more focussed on addressing a specific but currently undefined
potential solution area. This is described in section 4.6.4 on page 235.

• Rapid Solution Design – this is concerned with providing a quick solution scoping result for a reasonably well-
defined solution requirement. This allows for an informed decision to be made quickly to proceed or not to proceed
to a more detailed solution design stage. This is described in section 4.6.5 on page 257.

• Detailed Design – this describes a formal structured approach for defining the detail of a solution. This is described
in section 4.6.6 on page 276.

These different engagements are designed to handle different business requests in terms of how specific and known the
problem or opportunity is and how detailed the response required is.

Page 159 of 540

 Introduction to Solution Architecture

Figure 102 – Mapping Business Need to Engagement Types

In terms of the specificity of the business request, the level of detail of the output required and the duration, the engagement
mapping is listed in the table below.

Business Request Level of Level of Likely Engagement

Specificity Solution Duration Type
of Business Detail
Request Required
I have a good idea of the solution I want and I am High Low to Short Rapid Solution
looking for a quick view of the solution options and Medium Design
their indicative costs, resources and timescales to
implement.
I want a full detailed design created from an initial not Low High Medium Solution Design
necessarily well-defined problem or requirement that I Process
can pass to solution delivery
I have a specific solution requirement for which I need High High Short to Detailed Design
a formal detailed specification that I can pass to Medium
solution delivery
I want generalised solution options identified to Low Low to Medium Early
address a problematic situation. Medium Engagement
I want a consulting exercise to define new business Very Low Medium to Medium to Business
structures and associated with solutions to address a High Long Engagement
problem or an opportunity.

Table 35 – Mapping Business Need to Engagement Types

Page 160 of 540

 Introduction to Solution Architecture

4.6 Solution Architecture Engagements

Engagements

4.6.1 Business Engagement

4.6.1.1 Introduction

The business engagement is concerned with analysing the structure and operations of a business function and creating a
target business architecture that includes identifying business solutions.

This is a potentially complex engagement as it may involve the solution architecture function operating outside its traditional
comfort zone.

The objective is to create a realistic, achievable, implementable and operable target business solution architecture to achieve
the desired business solution targets, supported by information gathered and analysed.

This is not an exact engagement with an easily defined and understood extent and duration. It has an essential investigative
and exploratory aspect that means it has to have a necessary latitude. This is not an excuse for excessive analysis without
reaching a conclusion. The goal of this and the other engagements described here is to produce results and answers within a
reasonable time to allow decisions to be made based on evidence.

This engagement is an example of the solution architect offering true business consulting services and being able to offer
value to the business. The engagement can be performed entirely by solution architecture or the solution architecture
function can be part of a wider engagement team. It is intended to describe a structured and focussed engagement. It is suited
to situations where detail and implementation structure and framework are required.

This engagement contains a comprehensive and generalised set of components from which the details and scope of a specific
engagement can be defined. This can be used to create a customised engagement from this menu of options to suit the
specific needs of the business request.

Figure 103 – Generalised Business Engagement Structure

The engagement menu consists of the following groups of items:

Page 161 of 540

 Introduction to Solution Architecture

• Generalised Engagement Activities And Their Sequence –complete set of possible activities and their groups and
sequence and flow through the engagement from which the specific engagement can be created

• Generalised Deliverables From Activities – complete set of possible deliverables from the possible set of activities

• Generalised Engagement Roles And Their Involvement In The Creation Of Deliverables During Activities –
identification of possible roles and their involvement in the possible set of activities and the generation of the possible set
of deliverables

These are used to create a customised path through the architecture engagement process involves agreeing activities to be
performed, deliverables from the engagement and participating roles.

Figure
Figu re 104 – Creating Customised Set of Activities, Roles and Deliverables

The engagement is a structured approach to analysing the operation of an existing business function with a view to improving
its operations or developing a new business function, with a strong focus on solution, processes and technology.

Business architecture is not specifically concerned with a set of business requirements. It is about a taking a wider, broader
and higher view of the collection of business solutions and organisational changes that are needed deliver business objectives.

The business reasons and circumstances for a business engagement can include one or more of the following factors.

Page 162 of 540

 Introduction to Solution Architecture

Figure 105 – Possible

Possi ble Factors Driving the Need for a Business Engagement

These possible factors are:

• Globalisation
• Need for Transparency
• Service Focus and Customer Expectations
• Challenging Economic Circumstances
• Acquisition, Consolidation or Divestment of Operations
• Increased Regulation
• Business and Technology Changes and New Opportunities
• Mobile and Social Computing Changes and Opportunities
• Competition
• New Business Models
• Increased Pace of Change
• Problems with Existing Operations
• Inability to Scale Current Operations
• Change to Outsourcing Operations
• Move to Different Jurisdictions

The engagement is about identifying the changes required to the core domains described in section 2.4.3 to respond to the
business changes. It defines a target architecture and a path to transition to or transformation into it across the core business
domains.

Page 163 of 540

 Introduction to Solution Architecture

Figure 106 – Business Engagement Change Domains

The change domains can be divided into two groups:

1. Above The Line - Concerned with the organisation or the business function

2. Below The Line - Concerned with the technology and infrastructure that underpins and enables the operation of the
organisation or the business function

These domains are internal to the organisation and the business function that is the subject of the engagement and, as such,
are within the direct control of the business function.

There are two extended domain areas that also need to be considered:

1. Organisation Operating Environment and Business Landscape – this is external to the organisation. It consists of the
organisation’s customers, partners, suppliers and other external parties. The organisation has limited control over these
external parties. If the organisation is deploying solutions that are to be used by these parties, the organisation will have
limited control over how those solutions are used. This adds to the complexity of the design of such solutions.

2. Overall Organisation Business Strategy – this defines how the organisation as a whole operates and constrains the
options available within the architecture engagement.

The business strategy will be underpinned by a number of factors such as those listed below. These factors will both constrain
and direct the architecture engagement.

Page 164 of 540

 Introduction to Solution Architecture

Figure 107 – Architecture Engagement Extended Factors

These factors are listed in the table below.

Extended Factor Description

Objectives These are what the organisation wants to or needs to achieve. Individual business
function objectives must contribute to achieving the overall organisation objectives.
Approach and Methods This is what the organisation will do to achieve its objectives. The individual
business function approach and methods must contribute to those of the
organisation.
Success Factors These are the core reasons of and contributors to success and achievement of the
objectives. The organisation must focus its attention on these for it to achieve its
objectives and fulfil its mission. Individual business function success factors must
conform to those of the organisation.
Critical Concerns Identify challenges, opportunities, questions, problems, trends, threats, risks or
circumstances that must be addressed and resolved.
Measurement Framework Set of measurement and indicators that show the degree to which the objectives are
been met and the success factors achieved
Engagement Justification Why are we proposing to do this, why it is needed, what is driving the requirement
and what are the timescales by which it must be complete.
Future State This is a brief description of the ideal or desired target future state in terms of
business operations and changes to key business domains.
Essential Policies and Approaches How the business function or organisation currently achieves what it does.
Business Rules What underlies the way the business operates and how it organises its work and
make decisions.

Table 36 – Architecture Engagement Extended Factors

The expected scope and goals of the engagement needs to be agreed and understood before commencement. The scope can
change during the engagement.

Page 165 of 540

 Introduction to Solution Architecture

Figure 108 – Core and Extended Engagement Teams

There will be core and extended teams involved in and participating in the engagement.

• Leader – this role will both manage the engagement and take a lead role in its delivery. This is not a project management
role. It is a consulting position. This person needs to have the skills and experience to represent the work of the team to
the wider set of participants and stakeholders as well as the ability to manage the team that performs the work, provide
leadership and mentoring and to validate the work done, the results generated, the conclusions reached and the
recommendations made. The leader must become a temporary expert in the subject area. The leader must be able to
bridge the business and information technology areas of knowledge and work.

• Core Engagement Team – this consists of both information technology and business participants. Business experts who
understand the operation of the current function, if relevant, and the business problem, challenge or opportunity being
analysed. The team will need to have the required experience in analysis, research and design and in the various
techniques to be used in the engagement.

• Extended Team – Direct Business Participants and Stakeholders – the members of the extended team will be
involved in meetings, workshops, interviews and other information gathering, assessment and validation activities.

• Wider Organisation – Aware Of, Communicated About And Affected By Engagement – the wider organisation will
be aware of the engagement and may have concerns about its scope and impact. This will be especially true if the
engagement is controversial. The work will not take place in isolation. The purpose and scope of the engagement should
be communicated as necessary to the affected or concerned elements of the wider organisation to stop unfounded reports
and stories spreading.

There may be other temporary participants such as developers if prototypes are being developed or specialists for the
provision of specific services or knowledge.

4.6.1.2 Workshops

Page 166 of 540

 Introduction to Solution Architecture

The engagement will involve a number of workshops. These can an effective and necessary information gathering tool as part
of the architecture engagement. The effectiveness of workshops needs to be optimised with careful preparation, planning and
delivery and post-workshop communications.

Workshops involve the core engagement team presenting to and learning from the extended business team and the wider
organisation. They have two sets of purposes:

1. Primary – achieve the stated objective, gather and confirm information

2. Secondary – build team, get acceptance and buy-in from extended team and wider organisation, identify potential
organisation and personnel problems and hidden agendas, assist with communication and control the message, assist
with making decisions, uncover conflicts

The following is a list of common workshop activities:

• Define and communicate objectives

• Identify and profile extended and wider team participants
• Allocate roles to core team participants
• Define schedule, timescale and duration
• Deal with issues such as facilities and equipment
• Prepare, review, agree and distribute inputs
• Create tables of contents of target deliverables
• Prepare, review, agree set of topics to be covered and presentation material
• Document results and circulate for review and feedback

4.6.1.3 High Level Activities and Their Logical Sequence

The menu of activities for the business engagement and their logical sequence is illustrated below.

Figure 109 – Business Engagement High Level Activities and Their Logical Sequence

These high level activities are:

0. Define And Agree Engagement Scope

1. Information Collection And Assessment
2. Define Vision, Business Principles And System Principles
3. Document Business Processes, Entity Model, Capacity Planning And Solution Approach
4. Document Solutions, Applications And Functions
5. Define Organisation, Infrastructure And Data

Page 167 of 540

 Introduction to Solution Architecture

6. Conduct Solution And Product Evaluation And Selection

7. Design Model Architecture
8. Consolidate, Finalise And Review Design

These activities do not have to be performed sequentially and linearly. The order can be agreed at the start of the engagement
to suit the available resources and time, the scope of the engagement and the level of detail required.

Figure 110 – Business Engagement Activity Sequencing

Some of the steps can be iterated and repeated to increasing levels of detail but there should not be too many iterations.

The information gathering and analysis activities need to be time-limited. Activities can occur in parallel by different sub-
teams to optimise elapsed time and the work schedule.

Always check for previously collected information and inventories of material to avoid duplication of effort. Analysis
paralysis needs to be avoided. The purpose is to move to a conclusion and set of solution and architecture options quickly.
The reason for documenting the current state is to provide a basis for, a context and a justification of the definition of the
desired target state and set of solution and architecture options.

Section 4.2.1 on page 95 contains some notes on the decision leadership that the solution architect needs to demonstrate
during the design process.

The next sections describe these activities and their logical steps in more detail. These steps can be combined or expanded as
required depending on the complexity of the engagement and the amount of information and analysis required. In many
cases, these are logical steps. They can be mapped to a different set of physical steps.

4.6.1.4 Business Engagement Activity 0. Define And Agree Engagement Scope

The possible steps for activity Define And Agree Engagement Scope are:

Page 168 of 540

 Introduction to Solution Architecture

Figure 111 – Steps Within Business Engagement Activity 0. Define And Agree Engagement Scope

These steps are documented in more detail below:

0.1 Preparation and Planning

0.2 Mobilise and Present Approach to Sponsorship and Stakeholder Team
0.3 Review Any Previous Work, if Any
0.4 Perform Initial Informal Information Gathering
0.5 Review Information and Define Scope of Introductory Workshop(s)
0.6 Define Team and Facilities Required
0.7 Create Table of Contents (Scope) of Engagement Deliverable
0.8 Conduct Introductory Workshop(s)
0.9 Update Scope of Deliverables

4.6.1.4.1 Step 0.1 Preparation and Planning

This step involves preparing for the engagement scoping activity. One-to-one meetings will be held with the engagement
sponsors and the business experts on the problem or issue being investigated. Background research on the topic can be
conducted.

The key business participants can be identified and their time can be formally allocated to the engagement.

The purpose of this step is to create material to present at the initial mobilisation sessions. This material can then be refined
and updated during the remaining steps in this activity.

Page 169 of 540

 Introduction to Solution Architecture

The generic approach and its activities and steps should be described. The proposed customisation of the general approach to
suit the specific requirements should be documented.

It is important to be prepared for such meetings. Such preparation demonstrates interest in the topic and generates the
confidence of the business participants. The meetings are more productive. The approach should be reviewed with the
sponsors in advance of the initial mobilisation.

Create an initial schedule for the workshops and information gathering sessions based on the initial understanding of the
central requirements and information required.

You should decide on the approach to capturing and representing visually the information collected at this early stage of the
engagement. A standard approach or approaches means all the information is represented in the same way. You could an
enterprise modelling approach such as Archimate (see section 8.3.5.1.2 on page 518). This would require all parties involved
in the engagement to understand the Archimate symbol vocabulary.

4.6.1.4.2 S tep 0.2

0. 2 Mobilise and Present Approach to Sponsorship, Stakeholder and Core
Project Team

This step is the start of the continuous communication process during the engagement and so it sets the tone for the
remainder of the engagement.

Ensure that the individuals in the business who sponsoring the engagement and the stakeholders involved in the business area
covered by the engagement are known and agreed and that their participation has been confirmed.

Gather information about the expected scope of, the reason for, the expected schedule of and the required deliverables from
the engagement from the sponsor.

Prepare and review the material to present to the team created in the previous step. This includes:

• The reason why the engagement is taking place

• The scope and objectives
• The generic set of steps presented in this section
• The proposed adaptation of the generic approach to suit the engagement
• Indicative work plan and schedule
• Indicative team roles and responsibilities
• Indicative engagement outputs and deliverables such as the table of contents of the report to be produced
• Allocation of resources and facilities
• Approach to communications within the team and between the team and the business participants
• Approach to quality assurance and the review of material before it is presented externally
• Workshop and meeting approach and indicative schedule

This is a mobilisation session. It should present a plan for a plan rather than a fully articulated plan.

The engagement is a consulting, exploratory and learning activity. Not everything can or will be known initially.

4.6.1.4.3 Step 0.3

0. 3 Review Any Previous Work, if Any

The business function may have conduced previous similar engagements relating to the problem or issue under
consideration. If it exists, this material should be identified and reviewed. It may inform how the current engagement should
proceed and how problems that previously arose can be addressed. For example, the business may have engaged the services
of an external consultancy to review operations, perform an audit or identify gaps between what is being done and the best
practises implemented by other organisations.

Page 170 of 540

 Introduction to Solution Architecture

Determine if any of this material is useful and relevant and can be reused or incorporated into the current engagement.

Understand the issues identified during these previous exercises. Review how their recommendations were implemented or
attempted to be implemented, if at all. Identify the reasons, if any, for the partial or incomplete realisation.

4.6.1.4.4 Step 0.4

0. 4 Perform Initial Informal Information Gathering

Before the formal introductory workshops described later in this activity, conduct informal and preparatory individual
meetings with key business experts and the engagement sponsors and stakeholders.

Understand their vision and objectives for both the engagement that the target architecture that will be produced from it.
Ascertain the key underlying issues they are looking to resolve or the opportunity they are looking to address. Confirm their
level of commitment – how much effort are they and their teams able and willing to devote to the engagement.

Where possible, relevant and useful, walk the floor of the current operation or business function and observe the work being
performed. Understand how work currently gets done if the engagement relates to changing an existing business function or
operation.

Document the organisation structure, the key people, their roles, reporting structure, experience, levels of skills.

Understand the state of the current business processes and review any existing process documentation. If there is no
inventory of business processes or the processes are not documented, omit this from the initial information gathering as the
effort could be too substantial at this stage.

Present the previously created draft workshop schedule. Agree the workshop participants. Understand the personalities
involved and any likely objections and resistance to the engagement process and to any recommendations for change that
may come from it as a result of creating a target architecture.

4.6.1.4.5 Step 0.5

0. 5 Review Information and Define Scope of Introductory Workshop(s)

Review the results of the informal meetings and information gathered in the business area and previous engagement. Define
the scope of the introductory workshop(s) for the project team.

The purpose of the introductory workshop is intended to present the engagement to those participants who will be
contributing to information gathering and analysis, issue analysis, research and identification of resolution options.

These introductory workshop(s) need to be prepared carefully to demonstrate professionalism and seriousness of the
engagement.

The following table contains a list of possible topics to cover in the workshop.

Area Topics
Scope • Business functions involved in the engagement
• Locations and jurisdictions involved in the work delivery
• Sets of products and services being provided
• Business processes, business rules
• Facilities, systems and applications used or that support service delivery
Why The • Why the engagement is taking place, what issues, challenges, needs are driving the
Engagement engagement – poor performance, service, loss of business, new regulations?
• What is likely to happen if no action is taken?
• What benefits are likely to accrue?

Page 171 of 540

 Introduction to Solution Architecture

Area Topics
Indication Of • What are the likely changes across the core business areas?
Changes
Aims • Business aims
• Success factors
Stakeholders • Who needs to be involved?
Measurement • Key performance indicators across dimensions of:
Framework
• Service and product delivery – cost, time, quality, volume
• Financial – input costs, cost of product and service delivery, return
• Customer (external party) view – satisfaction, retention
• Organisation – ability to adopt changes and apply new ways of operating
• How will we know if we have been successful?
Future Vision • What does the future look like?
Limitations • What will constrain the range of solution options:

• Cost
• Time
• Resources
• Extent of changes required
• Availability of technology
Obstacles • What are the challenges, problems and issues we need to overcome in order to complete our
methods and achieve the future vision?
The Team And • Who will be involved in doing the work?
Schedule • Who will contribute to the work?
• Who will review the work?
• How will the core and extended teams operate?
• How long will it take?
• What are we going to produce?
Ground Rules • What are the ground rules for the work:

• Communications – what is the message? How do we communicate? How will we be

communicated with? Who communicates outside the team?
• Reporting - who reports to whom?
• Review and quality – what is the process for checking and validating analyses and results?

Table 37 – Introductory Workshop Topics

4.6.1.4.6 Step 0.6

0. 6 Define Team and Facilities Required

This step involves the following activities:

• Determine the required competencies/skills/experience of core team

• Create engagement delivery standards and templates.

• Agree and document communication process

• Agree and document work delivery process including artefact creation and review

• Acquire facilities

• Conduct team building and introductory round table session

Page 172 of 540

 Introduction to Solution Architecture

This team building and introductory round table session will include:

• Describe engagement, its objectives and deliverables

• Describe the known work programme and schedule
• Describe the planned work delivery process
• Describe the participants, stakeholders, organisation structure
• Define team roles, relationships and structures
• Understand team members’ experience and knowledge
• Define internal and external communication processes
• Define principles of operation such as:
o Document all interactions with extended team to avoid confusion and doubt later
o Information gathering needs to be timeboxed
• Define work delivery standards, performance, accountability and processes
• Detail internal and external meeting schedule including daily stand-ups
• Detail the team decision-making process
• Describe the boundaries:
o Between groups within the engagement team
o Between external stakeholders and participants
• Document team charter

4.6.1.4.7 Step 0.7

0. 7 Create Table of Contents (Scope) of Engagement Deliverable

This step involves creating an initial draft table of contents of the analysis and report that will be generated from the business
architecture engagement.

The table of contents is effectively a high-level work breakdown structure for the set of activities needed to create the
deliverable.

The engagement should aim to generate a comprehensive deliverable that describes where the business function or
organisation wants to be and how this can be achieved. It does not have to be lengthy. It can be supported and supplemented
by the other artefacts created during the engagement.

The table of contents could consist of:

Page 173 of 540

 Introduction to Solution Architecture

Figure 112 – Sample Table of Contents for Architecture Engagement Main Deliverable

The possible chapters and sections are:

Chapter Section
Summary
Current State • Terms of Reference
• Issues Driving Need for Change
• Current Organisation Area Future State And Structure
• Volumetrics
• Processes, Business Rules, Performance and Service Levels
• Business Case
Future State • Justification for Action
• Target Organisation Area Future State And Structure
• Volumetrics
• Processes, Business Rules, Performance and Service Levels
• Impact of Change
• Assumptions
• Constraints
Supporting Information • Benchmarks and Best Practices
• External and Internal Drivers for Change
• Possible Software Products and Vendors
• Cost and Benefit Analysis
Supporting Information • Implementation Options and Plans
• Pilot, Phases and Releases
• Schedule and Dependencies
• Resources and People Required

Table 38 – Sample Table of Contents for Architecture Engagement Main Deliverable

4.6.1.4.8 Step 0.8

0. 8 Conduct Introductory Workshop(s)

The introductory workshops with the business participants are aimed at initiating the project and setting expectations. These
are designed to introduce the engagement based on the scope agreed with the sponsor. There are not detailed information
collection sessions.

The aim is to present an overview of the envisaged end-to-end process and to describe the proposed set of topics to be
covered in subsequent information gathering sessions.

It gives participants the opportunity to comment and contribute. It is important to emphasise that the approach and
workplan may change during the engagement and that the focus needs to be on producing quality deliverables within a
reasonable timescale and not analysing to a minute level of detail.

The intention of the architecture engagement is to produce sufficient information to allow business management to make an
informed decision based on the likely achievable and realistic options.

4.6.1.4.9 Step 0.9

0. 9 Update Scope of Deliverables

Based on the feedback from the various team and business introductory workshops, update the expected scope of the
deliverables to be produced.

Page 174 of 540

 Introduction to Solution Architecture

4.6.1.5 Business Engagement Activity 1. Information Collection And Assessment

The possible steps for activity Information Collection And Assessment are:

Figure 113 – Steps Within Business Engagement Activity 1. Information Collection

Collection And Assessment

These steps are documented in more detail below:

1.1 Current Business Review

1.2 Assess Customer (Or External Party) Perceptions
1.3 Review Current Industry Best Practices And Technology Changes
1.4 Analyse Current Business Systems
1.5 Analyse Available Solutions And Products

4.6.1.5.1 Step 1.1 Current Business Review

This step involves gathering information on the structure and operation of existing organisation or function operations
including locations, if this is relevant.

The objective is to have sufficient information on current operations and business processes to understand any performance
and operational issues. The existing business processes should be identified and documented at a high-level, if process
documentation does not already exist. The purpose here is not to create process documentation but to understand the
operation of the processes.

The organisation or function structure, locations and its interactions with internal and external parties should be defined.

Create a model for the existing structure of the function. For each unit within the structure of the function, if relevant, and for
the function itself, identify the following:

Page 175 of 540

 Introduction to Solution Architecture

• Roles, positions, levels/grades, functions, responsibilities, key personnel

• Decision making processes
• Work groups, work organisation, work types, work allocation and distribution, work volumes
• Business processes operated, level and currency of documentation
• Performance, throughput, service levels, monitoring and reporting
• Technology used and staff opinion of technology
• Relationships between work groups and functions
• Interactions with other business functions
• Interactions with external product or service delivery partners
• Staff engagement, staff awareness of issues
• Issues and problems
• Any existing planned changes, their reason and status

Examine the support processes and the associated solutions:

• Work allocation and planning systems - How is work allocated, recorded and workload planned for
• Learning management - Examine staff training processes and approaches and how are business processes linked to
training and skills and experience
• Time recording and management
• Performance recognition and reward - How are good staff performance identified, recognised and rewarded and how is
poor performance handled
• Personnel development and talent management - What is the approach to staff development and progression
• Staff communications - Evaluate how staff are communicated with and how information is disseminated

If relevant, document each business or function location that comes under the scope of the engagement. Define the location
type: office, distribution, storage, service, sales. Describe details about the location including size, number of staff, facilities.

Look at the business processes that govern how work is performed and their business rules. This involves documenting
existing business processes and associated rules at a high-level. The detail may (or may not) come later but only if it is
relevant and useful to the engagement. It is also not concerned with redesigning existing processes. This may also come later.

Identify core business processes categories or groups of processes that contribute to the performance of the same types of
work. Document the major processes within each process category or group. This should include:

• What causes the process to be initiated?

• What information is required and where does it come from?
• What are the outcomes of the process?
• What are the key metrics about each process: time to complete, errors and rework, cost, resources and skills required,
systems used?
• How is process performance recorded and reported on?
• What rules and decision-making are applied to process operations?
• What restrictions, limitations and implied assumptions are applied to each process?
• Where are the manual steps and handoffs?
• What process documentation exists and how does it differ from the actual process as performed?

For each process category, answer the following questions:

• What work areas do not map to existing defined business processes?

• What processes are shared between or performed at multiple locations?

• What processes rely on external involvement and what is that involvement?

• Where are processes and rules automated?

Page 176 of 540

 Introduction to Solution Architecture

Review and create an inventory of all systems and applications that are used to perform or support the performance of work
including:

• Core business applications

• Office support systems
• Reporting applications
• Analysis applications
• Data structures
• Level of automation
• Manual workarounds used with business applications
• Documentation and its currency for each application
• Staff satisfaction with each application

4.6.1.5.2 Step 1.2 Assess Customer (Or External Party) Perceptions

If the business function that is the subject of the architecture engagement is involved in the provision of products and services
to customers or external parties (such as partners, suppliers or regulators), identify some representative customers (or
external parties) that interact with the business function and that agree to be contacted to discuss their interactions and
experiences. For each of these look to gather details on the following:

• Products or services used or acquired

• How much, how frequently
• Alternatives evaluated – both supplier and products or services
• Experiences of interactions and level of satisfaction
• Experiences of products or services and level of satisfaction
• Overall perception of organisation or business function
• Overall satisfaction
• Importance of organisation to customer
• Desired performance
• Views of how the organisation or business function should change or can improve
• Views of how the products or services should change or can improve

The purpose here is to understand how the organisation and its products and services are perceived:

• What products and services are used by the customer?

• How are the products and services are used in customers’ businesses?
• What business issues do these customer face in using the products and services?
• How do the products and services enable customers’ businesses succeed?
• What do customers like?
• What do customers not like?

The goal is to understand what your customers (external parties) want, how they perceive you and what you are capable of.
Customers (external parties) generally want the organisation to demonstrate a mix of one, two or three core values:

1. Understanding and Closeness (Enhancement) – demonstrate and act on customer knowledge and offer customised
products and services to meet those exact needs

2. Product and Service Operational Excellence

Excellence (Efficiency/Utility) – provide reliable, convenient, easy-to-use, cost-
effective, value for money products and services

3. Product and Service Innovation and Leadership (Transformational) – offer products and services that are better,
more innovative, technologically advanced than others

Page 177 of 540

 Introduction to Solution Architecture

Figure 114 – What Customers Want

Identify the issues customers (external parties) encounter during business interactions:

• Access to information
• Quality of information
• Access to person
• Speed and quality of response
• Provision of response
• Ease of ordering products and services
• Order status
• Product and service delivery
• Product and service utility
• Price, billing
• Accuracy and rework
• Query and error handling and resolution

Use the previously identified process groups to identify the points where these issues and problems arise.

4.6.1.5.3 Step 1.3 Review Current Industry Best Practices And Technology Changes

The objective of this step is to understand how comparable organisations achieve better performance.

Review best practices within the industry area in which the organisation or business function operates and identify other
organisations that excel in similar areas.

Review what other competing organisations use and how their performance compares.

Review business trends.

Review solutions and technologies that are available to support operation and their providers.

Review technology trends affecting these solutions and technologies and the business trends.

Page 178 of 540

 Introduction to Solution Architecture

This should involve:

• Reviewing organisations offering similar products and services

• Review organisations that excel in specific areas and that do not necessarily offer similar products and services

These areas can include some or all of:

• Customer service
• Brand development
• Innovation
• Cost reduction
• Sales
• Similar complexity of operation, products or services
• Supply chain management
• Efficiency, performance, throughput for numbers of staff
• Quality control, errors
• Use of technology
• Use of resources
• Organisation structure

Look for excellence in the previously identified core process categories. Identify how that excellence is achieved and what the
previous state was, if possible. Examine the what – results and outcomes achieved – and the how. Use the information to
identify possible new approaches and options to operate the core processes.

There are many possible source of best practice information such as:

• Search of publications and articles

• Industry experts
• Consulting organisations
• Direct contacts
• Industry groups
• Supplier experience
• Relevant industry associations
• Employees’ previous experience
• Customers’ (external party) experience with other organisations

You could consider using services of professional survey organisation if time and budget allow and if the scope of the work
justifies it.

Classify the results of the best practice analysis using the previously identified process categories and other analysis factors:

• Customer service
• Brand development
• Innovation
• Cost reduction
• Sales
• Similar complexity of operation, products or services
• Supply chain management
• Efficiency, performance, throughput for numbers of staff
• Quality control, errors
• Use of technology including externally hosted solutions
• Use of resources
• Organisation structure

Page 179 of 540

 Introduction to Solution Architecture

Identify those organisations that achieve more and determine the gaps between the two organisations.

Quantify the differences and describe the reasons for the difference.

For the technology trends review, determine what new technologies are available and how commercially available these new
technologies are.

How can these new technologies be applied within the organisation?

How are other organisations using new technologies?

Who are the vendors offering these new technologies?

4.6.1.5.4 Step 1.4 Analyse

An alyse Current Business Systems

Examine the business system and technology landscape, data and communications infrastructure of the organisation,
including externally used solutions.

Determine the major data stores:

• Subject area(s)
• Underlying applications
• Data source(s)
• Data types and formats
• Size, amount of data, number of transactions
• Technology and its currency
• Data quality issues
• Value and utility to the business
• Year of implementation, year of last major upgrade/update

Create logical entity diagram(s) that identify key data topics or classes. Data topics are logical groups of data that relate to the
same subject. Document the high-level contents of each data topic. Identify relationships and linkages between data topics.
This is useful in understanding the data topic landscape and connections.

Figure 115 – Data Relationship Diagram

Create an inventory of solutions and applications that are in use. Describe their technology basis – product/custom-
developed, software used, technical infrastructure.

Page 180 of 540

 Introduction to Solution Architecture

Detail the core functions provided by the systems and applications. Link the solutions and applications and their functions to
the core process categories and their constituent processes.

Describe the state of these systems and applications in terms of:

• Fitness for purpose and suitability for current business operations

• Value to the business
• Manual workarounds and manual handoffs to other systems
• Ease of use and usefulness
• Goodness of fit for planned and known future business changes
• Efficiency of operations
• User experiences of the system
• Level and currency of documentation and training material
• Volume of work, number of users, number of transactions
• Year of implementation, year of last major upgrade/update
• Internal or hosted

Evaluate the technical state of the solutions and applications in terms of:

• Reliability
• Availability
• Compliance with technical standards
• Compliance with data regulations
• Flexibility and ease of modification
• Vendor plans for packaged applications
• Version in use and current versions supported by vendor
• Issues with technical infrastructures - for example, operating system and database versions
• Cost of operations, support and maintenance
• Fitness and appropriateness as a platform for future developments
• Compliance with organisation IT architecture standards

Create a diagram showing the communications infrastructural components, including any network, and their relationships.
Identify major elements of the infrastructure including:

• External hosting and communications links

• Internal infrastructure – server operating systems, databases
• Security
• Application access
• User access devices

Based on the review of business solutions and applications, create a four-state classification based on two factors:

1. Value to the business

2. State of application and underlying technology and vendor

Page 181 of 540

 Introduction to Solution Architecture

Figure 116 – Business Solution Classification

The extremes of the combinations of the two classifications are:

1. Application Technical State Poor Value to the Business Low = Replace Now - These applications need to be replaced or
retired and their data converted to new platforms.

2. Application Technical State Good Value to the Business Low = Retain or Replace Later - These applications may be
considered for replacement in the future or may be retained depending on the target business architecture, the associated
technology architecture and the systems needs to support its operation.

3. Application Technical State Poor Value to the Business High = Replace Later - These applications should be flagged for
replacement in the future.

4. Application Technical State Good Value to the Business High = Retain - These applications should be retained unless
there are better options readily available that can be implemented easily and quickly with minimum disruption.

In reality, business solutions will not fit neatly into the extreme ends of the two classification ranges and so some judgement
will be required regarding the positioning those applications.

4.6.1.5.5 Step 1.5 Analyse Available Solutions And Products

The objective of this step is to evaluate possible options for those business solutions and applications - packaged, in-house or
hosted or custom development – that were flagged for replacement, now or in the future.

This is a high-level evaluation and sense-check that possible solution options including both products and custom
development are likely to meet key requirements. The focus should be on products where possible.

The scope of this step is to not conduct a full procurement process. It is concerned with identifying sources of possible sets of
product information and preparing vendor contact approaches including technical and business questionnaires to
understand the suitability of their products. For public sector organisations, a different and more limited approach to vendor
contacts may apply.

Define the high-level functional requirements based on functionality provided by current solutions targeted for replacement
and likely future business requirements not currently provided.

Define the high-level operational and solution delivery requirements such as capacity, throughput, number of users, volume
of data, availability, resilience and other quality characteristics – see 4.6.4.7 on page 251 for more information on this.

Page 182 of 540

 Introduction to Solution Architecture

The vendor contact questionnaire should include at least the following points:

• Vendor details – company size, duration in business, product details, numbers of installations of product, maturity of
product
• Compliance with functional requirements
• Compliance with operational requirements
• Security model
• Product delivery options
• Customer satisfaction scores
• Implementation project resources and timescale
• Service management and support
• Outline financial analysis – initial cost, maintenance, cost of ownership

At the end of this, summarise the information gathered from vendors, comparing solutions across key requirement and
evaluation factors.

4.6.1.6 Business Engagement Activity 2. Define Vision, Business Principles And System
Principles

The possible steps for activity Define

Define Vision, Business Principles And System Principles are:

Figure 117 – Steps Within Business Engagement Activity 2. Define Vision, Business Principles And System Principles

These steps are documented in more detail below:

2.1 Define Vision For Functional Business Area

2.2 Describe Functional Business Area Principles, Assumptions and Limitations
2.3 Describe System Principles, Assumptions and Limitations

4.6.1.6.1 Step 2.1 Define Vision For Functional Business Area

Page 183 of 540

 Introduction to Solution Architecture

The vision is a high-level description of the desired future architecture and operating structure of the organisation or business
function. It is concerned with the desired future state and not, at this stage, how that state can be achieved. It represents an
ideal view of what the future should be. There can be more than one vision or alternative versions of the same vision.

The vision is defined, refined and enhanced iterate using various activities:

• Create initial vision based on information known so far – this forms the basis for discussions
• Tools such as the Business Model Canvas
• Key stakeholder interviews
• Vision workshop
• Rich pictures

It is then communicated to participants.

The vision is the means for articulating the target of the architecture engagement. It can be used externally (outside the
engagement team) to communicate what the engagement is concerned with and internally (within the team) it can be used to
organise and focus work effort and to define the boundaries of the work.

Create a starting vision based on consolidated information collected and analysed. Separate the What of the vision from the
How of its realisation.

The vision should contain the following elements.

• The expected environment in which the organisation or business function operates

o Products and services provided

o Customer segments supplied
o Physical distribution
o Competitors
o Economy

• The business function operating model in terms of its future core business process groups and constituent business
processes

o Structure of the business function core operating domains

o Organisation structure and operation
o Supporting and enabling technology

Use scenarios and process journeys to walk through the internal and external operations for key business activities and detail
their flow. Develop inventory of key scenarios and process journeys. The approach breathes life into the operating model and
can be used to determine its validity and to identify potential inconsistencies. Describe alternatives and options where
relevant. Identify differences and divergences in the information collected. Define the choices and decisions to be made to
clarify the vision.

The following table lists some factors to be considered when developing the initial vision:

Factor Questions
Products and Services • What products and services do we supply
• How many types do we supply?
• How are they different from those of other organisations?
• How do we deliver the products and services?
• How do we develop and enhance them?
Customers • Who do we provide products and services to?
• How broad is the range of customers?
• Why do customers acquire our products and services?

Page 184 of 540

 Introduction to Solution Architecture

Suppliers and Partners • Who are our suppliers and partners?

• How do we work with them?
• How many are there?
Competition • Who do we compete with?
• How do we compete?
• How well do we compete?
• How are we different from our competitors?
• How is competition changing?
Regulatory Landscape • What is the regulatory landscape?
• How compliant are we with regulations?
• How is it changing?
Business Processes • How well defined are our business processes?
• How optimised, integrated, efficient and automated are they?
• How well do they work in terms of cost and time to operate?
• How do we measure performance?
Organisation • What is our organisation structure?
• Who does what?
• What does it cost to operate?
• How is the organisation operated and managed?
• How do we recognise and reward talent and performance?
Locations and Facilities • Where do we operate from?
• How many types of locations do we have?
Solutions, Systems, Data • What are the key business systems?
and Technology • How well do they meet the needs of the organisation?
• How well integrated are they?
• What is the state of the organisation’s technology infrastructure?
• Can customers and suppliers interact with the organisations using technology?
• How well do we manage data?

Table 39 – Vision Development Factors

Consider using the Business Model Canvass38 approach to describe the vision for the functional business area. This consists of
a structure that expresses the core principles and value proposition of a business in nine elements that are contained in four
groups:

1. Infrastructure
o Key Partners - the key partners and suppliers needed to achieve the business model
o Key Activities - the most important activities the business must perform to ensure the business model works
o Key Resources - the most important assets to make the business model work
2. Offering
o Value Propositions - the value, products and services provided to the customer
3. Customers
o Customer Relationships - the customer relationships that need to be created
o Channels - the channels through which the business reaches its customers
o Customer Segments - the types of customers being targeted by the business model
4. Finances
o Cost Structure - the most important costs incurred by the business model
o Revenue Streams - the sources through which the business model gets revenue from customers

38
The Business Model Canvas was developed by Alexander Osterwalder. The concept was originally published at
https://nonlinearthinking.typepad.com/nonlinear_thinking/2008/07/the-business-model-canvas.html. It followed on from his earlier work
The Business Model Ontology - A Proposition In A Design Science Approach
http://www.hec.unil.ch/aosterwa/PhD/Osterwalder_PhD_BM_Ontology.pdf.

Page 185 of 540

 Introduction to Solution Architecture

Figure 118 – Business Model Canvass

Identify the key stakeholders who are important to the achievement of the target from the architecture engagement or who
know about the business environment. These can be:

• Business executives and heads of business functions

• Those involved in developing business strategy
• Those involved in analysing business and market trends

Prepare structured interview notes using previously documented vision factors and tools such as the business model canvas.
Gather information from key stakeholders using structured one-to-one interviews. These will provide hard and soft
information:

• Hard – facts, numbers, detail

• Soft – stakeholder level of interest, engagement, commitment and enthusiasm, possible resistance, amount and quality of
information provided

Collect information from multiple stakeholders to get different perspectives. Document the information collected and
circulate to the stakeholders for review and comments.

Conduct one or more vision workshops. Their purpose is to present the initial consolidated vision, alternatives, differences
and decisions for review and elaboration.

Again, separate the What of the vision from the How of its actualisation. The How is a constraint that can be addressed later.

At this stage, a detailed analysis and discussion can be counter-productive. The goal is to achieve (some) consensus on the
vision and to create a netted list of disagreements and differences.

Present the information collected using the previous structures and frameworks:

Page 186 of 540

 Introduction to Solution Architecture

• Scenarios and process journeys

• Vision factors and business model canvas
• Use pictures and diagrams

The topic of rich pictures is discussed in section 4.6.4.6 on page 249. They are (more or less) detailed visualisations that
represent information more effectively than lengthy narrative text. Pictures are more easily understood and engaged with and
are better tools to elicit information from people. They assist informed discussions. The show relationships and interactions
between key entities. They provide a more concise illustration of operations.

Evolve and refine rich picture representations of as-in and to-be situations throughout the engagement exercise.

Rich pictures are not systematic views (yet). They do not contain solution and system-related components such as IT
applications, infrastructure and data flows at this stage. These are resolution and implementation-related elements. Resist the
temptation to include systematic parts at the investigation stage and pre-judge options for resolution and transformation. We
are looking at transformation with a small “t” here. Jumping to conclusions at this stage will limit the scope of information
gathered and prejudge resolution options.

Recall that one of the solution component types that comprise the complete solution picture described in section 2.4 on page
33 is Organisational Changes. Any solution will involve some changes to the organisation such as new personnel required to
operate the solution and the associated new or changed business processes, deployed existing personnel, changes in business
function structure and new skills and experience required.

The exploratory and consulting nature of the architecture engagement means that organisational changes will have a greater
part in the target architecture than a pure solution design engagement where a solution is being specified. Achieving the
ultimate target architecture is likely to involve some form of organisation change. The required changes may be resisted by
some affected stakeholders and other individuals or the organisation itself may be unable to accommodate change. It is
important to identify potential blockers early in the business architecture engagement and to continue this throughout the
engagement. The recommended actions to address these blockers in order to enable the required change to occur need to be
defined. This may be outside the normal skills and experience of the solution architecture function. The solution architect
should define the options for these changes. Their achievement can be left to others.

The solution architect can assist with these actions:

• Supporting those that in favour of change

• Identifying and addressing the objections of those who resist change
• Articulating the new culture that will facilitate change
• Defining the change message and communicating the need for change
• Assembling suitable business representatives into a change forum to whom the progress of the engagement and the
benefits of change
• Collecting, co-ordinating and responding to feedback
• Creating a communications portal with information that affirms the need for change

The performance of these actions should be led by the engagement sponsor.

4.6.1.6.2 Step 2.2 Describe Functional Business Area Principles, Assumptions and
Limitations

This step is concerned with defining the principles, assumptions and limitations for the overall business function and for each
of the core business domains. The use of the words P rinciples, A ssumptions and Limitations is interchangeable. Their
definitive categorisation is not important at this stage. Just capture them for now.

Principles are values, core beliefs, standards, guidelines, rules, regulations, laws and directions that underpin and govern the
overall organisation or business function. Assumptions are used as the basis for decisions. Assumptions need to be validated

Page 187 of 540

 Introduction to Solution Architecture

because they can be incorrect. Limitations are constraints that narrow the range of resolution options and the scope of actions
that can be taken.

Figure 119 – Principles, Limitations and Assumptions Across Core Business Domains.

There will also be principles, assumptions and limitations for the extended business domains described in section 4.6.1.1 on
page 161 that should be captured.

Principles, assumptions and limitations affect the target vision. Understanding them is important to creating a realistic and
achievable vision that meets the needs of the organisation. Information on principles, assumptions and limitations can be
initially gathered through a focussed and dedicated workshop. They should be refined and expanded on throughout the
engagement.

4.6.1.6.3 Step 2.3 Describe System Principles, Assumptions and Limitations

The step is concerned with describing the usage of solution, applications and systems, technology and data and not the detail
of their construction and underlying technologies. It is about describing an external rather than internal view.

• Applications and Systems

o Current application and system selection, design, operation principles – rules that define usage and actions
o User interfaces and interaction
o Integration
o Constraints that limit operation and use
o Assumptions on the applications and systems – extendibility, growth, deployment and usage in different
ways
o Who manages and supports

Page 188 of 540

 Introduction to Solution Architecture

• Information and Data

o Who and how acquires, owns, uses, manages

o Limitations
o Assumptions on data – quality, integration, redundancy

• Technology and Infrastructure

o Current technology and infrastructure organisation, selection, design, operation principles – rules that
define usage and actions
o Security
o Standards and compliance
o Limitations
o Assumptions on technology and infrastructure – suitability, capacity, growth, adaptability
o Who manages and supports

Describe the current and target business process principles, assumptions and limitations using a structure along the following
lines:

• Principles

o Process optimisation through compression of work and collapse of roles

o Include parallel processing
o Automation as much as possible
o Decision by exception rather included in the normal processing path than in all cases
o Cross-functional teams
o Process information gathering, reporting, analysis and optimisation

• Assumptions

o Number of people available to process work

o Number of work items

• Limitations

o Volumes and levels of process workload

o Temporal variation in workload
o Skills required

Describe the current and target organisation and structure principles, assumptions and limitations using a structure along the
following lines:

• Principles

o Organisation structure, hierarchy, reporting

o Allocation and handling of work
o How do we want to interact with partners, suppliers, customers

• Assumptions

o Number of people in each function and role

o Skills and experience required

• Limitations

o Numbers of new staff, retraining

Page 189 of 540

 Introduction to Solution Architecture

o What limitations apply to organisation change

o What is the regulatory environment

Describe the current and target locations and offices principles, assumptions and limitations using a structure along the
following lines:

• Principles

o Number and type of locations and offices

o Consolidation of locations and offices as required
o Location of work processing

• Assumptions

o Size and quality of locations and offices

o Costs of locations and offices

• Limitations

o Restrictions on options to consolidate locations and offices

o Restrictions on options to relocate staff
o Restrictions on availability of suitable locations and offices

Present the previously defined vision and information collected during business review across the core six business domains:

• Location and Offices

• Business Processes
• Organisation and Structure
• Technology, Infrastructure and Communications
• Applications and Systems
• Information and Data

Use these structures to validate and refine these principles, assumptions and limitations.

Refer also to the extended business domains if necessary.

4.6.1.7 Business Engagement Activity 3. Document Business Processes, Entity Model,

Capacity Planning And Solution Approach

The possible steps for activity Document Business Processes, Entity Model, Capacity Planning And Solution Approach
are:

Page 190 of 540

 Introduction to Solution Architecture

Figure 120 – Steps Within Business Engagement Activity 3. Document Business Processes, Entity Model, Capacity Planning And
Solution Approach

These steps are documented in more detail below:

3.1 Define And Document Business Processes

3.2 Create Conceptual Entity Model
3.3 Gather Capacity Planning Information
3.4 Define Solution And System Approach
3.5 Develop And Validate Feasibility Prototype(s)

4.6.1.7.1 Step 3.1 Define And Document Business Processes

The objective of this step is the design of the target business processes. Processes are important because they reflect and
represent what the organisation does and how it does it. This can be based on the redesign of existing processes to make them
more efficient and effective or it can involve the definition of entirely new business processes that replace existing ones.

The importance of business processes to solution design is discussed in section 4.4.2 on page 134. The information contained
in that section and the approach to business process analysis can be used here.

This step can be quite lengthy, depending on the extent of the engagement and the number and complexity of existing and
new business processes involved. It covers the following work:

• Create business process change/design inventory

• Define process attributes
• Identify existing process enhancements and improvements
• Define the core set of business processes required to operate the target architecture
• Define the target architecture process model
• Create extended process definition
• Define and validate the projected performance characteristics

Page 191 of 540

 Introduction to Solution Architecture

• Identify and describe the management and support processes

Redesign of existing processes is usually termed Business Process Improvement (BPI). This is concerned with designing a
new process to achieve the desired outputs. The focus is on specifying new processes to replace existing ones so less detail on
existing processes needs to be collected.

Design of new business processes is usually termed Business Process Redesign (BPR) . This is concerned with modifying
existing process to identify, reduce or eliminate problems and to improve performance. The focus is on collecting detailed
information on existing processes so they can be improved.

The two approaches can be used in tandem for different processes.

Figure 121 – Right-

Right- to-
to-Left BPI and Left-
Left -to-
to-Right BPR

BPI can be viewed as left-to-right business process changes. You are working through the operation of existing processes,
identifying opportunities and options for changes and improvements.

BPR can be viewed as right-to-left process changes. You are starting with a set of outputs, results and deliverables and are
defining the optimum new business process to achieve them.

This section will not cover business process design in detail. The importance of business processes to the design of a complete
solution and the approach to business process analysis are discussed in section 4.4.2 on page 134. That section should be read
in conjunction with this section.

This step in the architecture engagement is not concerned with detailed process analysis and the design of new processes. It is
concerned with documenting processes in sufficient detail to allow problems and resolution to be identified.

Processes can be described to ever more levels of detail.

Page 192 of 540

 Introduction to Solution Architecture

Figure 122 – Process Decomposition

Processes should be decomposed to an appropriate level of detail to gather the required information, and no more.

The focus here is to create and agree an inventory of triggers and events to which the business function reacts and responds
and the identification of any new triggers and events required by new/changed processes.

Create and agree an inventory of outputs and results generated in response to triggers and events by process activities.
Identify any new outputs and results required by new/changed processes

Create and agree an inventory of outcomes influenced, achieved or desired in response to triggers and events by process
activities. Identify any new outcomes desired by new/changed processes.

Create and agree an inventory of key process activities. Identify any new activities required by new/changed processes
Decompose large monolithic activities into smaller more granular representations of key process activities

In any organisation and business function, there will be two sets of processes:

1. The processes that do the value-adding work

2. The processes that relate to management and administration of the doing processes and of the business function
operations

Page 193 of 540

 Introduction to Solution Architecture

Figure 123 – Doing and Managing Processes

The analysis should focus on the doing processes. The management and support processes can be left to one side for now.

For each of the current key processes, create a process flow description/map at enough detail to ensure it can be understood.
Describe the existing process at sufficient level to allow problems, issues and opportunities for improvement to be identified.
Existing process analysis is more important for BPI than for BPR exercises. Create an inventory of key processes and the
associated issues and opportunities for improvement.

Describe the current and future target process activity performance attributes. Not all process activities will share all
performance attributes. For example, some processes that result in the supply of products may require an inventory level to
be available and some form of re-ordering trigger when the inventory falls below a threshold. Performance attribute is one
that has a cost, direct or indirect. Detail the current and future targeted/desired/expected performance characteristics.

Figure 124 – Process Attributes

The types of process attributes to be defined include:

• Cost – how much does the process cost to operate

• Resources
Reso urces – what resources/operators are required to operate the process and its steps? What resources are involved in
the process?
• Skills/Roles – what skills and experience are required to operate the process and its steps? What roles are associated with
the process?

Page 194 of 540

 Introduction to Solution Architecture

• Exceptions – what exceptions occur to normal, straight-through processing? How are exceptions identified and
handled?
• Error Rate – how many errors occur during processing? What are the error types and causes?
• Elapsed Time – what is the elapsed time from process start to end?
• Effort(s) – how much work of what types is required to operate the process?
• Inventory Levels – does the process require any product inventory and, if so, what?
• Service Levels – what service levels, if any, apply to the operation of the process?
• Rules – what rules does the process implement?
• Facilities – what facilities does the process require?

Some of these process attributes may not be known or easily discovered. For example, many organisations do not know the
cost of their processes. Where this information is not available, it should be estimated quickly rather than effort and time
being expended to extract it.

Identify the roles required for the target processes and the associated skills, experience, education, training and competencies
needed to perform them. Include hard and soft skills. This information will be used to design the target organisation
structure.

Define the business function location types required to operate the new target processes, if relevant.

Analyse the performance of the existing processes and determine the value they create. Extend the previous business process
flow analysis by adding performance and value dimensions.

Provides a target list for enhancements:

• Longest process and process step elapsed time

• Longest process and process step elapsed time relative to processing time
• Greatest number of handoffs
• Processes and process steps with largest number of steps
• Processes and process steps crossing organisation functional boundaries
• Processes and process steps with data quality issues
• Processes and process steps with errors and rework
• Processes and process steps that do not add value
• Processes and process steps experiencing delays in getting responses to requests, internal or external

Use the list of types of wastes (see section 4.4.2 on page 134) to identify most wasteful processes and process steps and thus
the top opportunities for improvement.

Define the core set of business processes required to achieve the desired results and outputs for the target architecture. At this
stage assume there are no constraints in skills, resources, technology, external interactions or locations. These can be added
later. Create an inventory of these core business processes.

Define the target architecture process model. Define the new/redesigned target processes and process steps. There can be
many options when defining the new/changed processes. These options can involve organisation change such as:

• Case management approach with assigned case workers

• Team-based processing
• Upskilling teams
• Elimination of cross-functional handoffs
• Automation and technology changes
• Personnel relocation
• Outsourcing
• Integration with external parties

Other changes can include:

Page 195 of 540

 Introduction to Solution Architecture

• Introduction of parallel processing

• Work prioritisation
• Automated decision making
• Compression of steps
• Collapsing of roles
• Eliminating unnecessary inspections
• Removal of unnecessary steps added for historical reasons to address exceptions and complexity

The focus here is on ensuring that processes add value and on reducing unnecessary process cost.

Then extend the definition of the new/redesigned target processes and process steps with details on:

• The roles that perform them

• When the work is performed
• What supporting solutions and technology are used or required to perform the work

Create a matrix of this extended process definition.

Figure 125 – Extended Process Definition

Define the projected performance characteristics of the future process state. Validate the performance by walking through the
processes.

There may be more than one set of future state process options. If so, each needs to be considered with respect to
characteristics such as:

• Time to implement
• Likely cost
• Resources required
• Probability of success and risk of failure
• Degree of organisation change and expected amount of disruption caused
• Degree to which the improvement objectives will be achieved

Use these factors to determine the most suitable option or subset of options.

Identify the management processes required to administer, manage and assess the performance of the target future state
processes using the steps:

• Collect, analyse and take action on process performance information.

• Measure the satisfaction of the process beneficiary
• Assess process quality, rework and error rate
• Review process cost

Page 196 of 540

 Introduction to Solution Architecture

There will be general management processes across all operational processes and specific management processes for specific
operational processes.

4.6.1.7.2 Step 3.2 Create Conceptual Entity Model

Create an inventory of entities involved the operation of the business function covered by the engagement and how it can
deliver its products and services.

Entities are objects about which data is stored and processed. They are people, functions, events, products and can include:

• Business roles and organisation functions involved in the work

• External parties contributing to the products and services
• Products and services
• Beneficiaries of the work done by the business function
• Offices and locations

The conceptual entity model is effectively an Entity Relationship Diagram (ERD). This results in a picture of data flows and
interactions within the business function.

Figure 126 – Sample Entity Relationship Diagram for Conceptual Model

The tasks involved in creating the ERD are:

• Identify the types and groups of entities and the individual entities of each type
• Describe each entity briefly and identify its main characteristic
• Define the interactions and relationships between the entities
• Define the direction and number of interactions and relationships
• Quantify the volumes of interactions
• Identify the major business rules associated with the interactions and relationships

4.6.1.7.3 Step 3.3 Gather Capacity Planning Information

Page 197 of 540

 Introduction to Solution Architecture

The capacity requirements of a solution affect the design options. Solutions that must handle large volumes of work have very
different design characteristics than those of solutions with much smaller throughput.

Capacity planning covers all aspects of business volumetric information such as:

• Technology
• Personnel
• Location
• Physical product production capacity
• Physical product storage capacity
• Physical product transportation capacity

Capacity and resource requirements can also vary according to various cycles and patterns of usage: daily, weekly, monthly
and seasonally. Solutions should be sized to handle peak workloads. The required elasticity of the solution resources needs to
be identified. This can be an influencing factor when considering a hosted solution or service where resource elasticity is
much less expensive.

Capacity and resource usage information will affect overall system(s) performance and the choice of technology and
ultimately the solution options. It is important that capacity planning information is reasonably accurate and that the
underlying assumptions are understood and documented. The business may not understand technical aspects of capacity
planning and so must be guided to an understanding and must approve the estimates produced.

Technology capacity planning involves understanding the resource requirements of technical infrastructure. Ultimately, this
can be provided internally, by an outsourcing partner, by an Infrastructure as a Service (IaaS platform, by a hosted service
provider some other form of XaaS delivery method. Whatever the method, technical resource usage costs and will be charged
for.

Capacity planning metrics depend on the type of work being performed:

• Number of transactions or events of each type

• Number of data entities of each type
• Average and peak numbers
• Past and expected future growth rates
• Resource types to perform work types

Understand or make realistic assumptions about the technology resource requirements of transactions and entity data so the
cost model can be understood.

Operation requirements will affect capacity requirements:

• Availability
• Response times
• Service levels
• Acceptable failure rate
• Recovery time

High operational requirements – highly available systems with very good and consistent response times – will affect resource
requirements and cost. Therefore, you must understand the resource requirement impact of operational requirements.

Different elements of the overall operation of the business function will have different operational requirements. Externally
facing applications will need to be more highly available than internal systems.

The business may not understand technical aspects of operational requirements and so must be guided to an understanding
of the consequence of their requirements and must approve the estimates produced.

The business function will operate across different locations and location types, such as:

Page 198 of 540

 Introduction to Solution Architecture

• Call centre
• Service centre
• Front office processing
• Middle office processing
• Back office processing
• Physical product storage and delivery

Each of these will also have different resource requirements and operational characteristics. You should look to create a
resource entity model to understand the structure and volumes of resource consuming entities.

Figure 127 – Sample Resource Entity Model

Create a structured capacity planning model that captures inputs in terms of resource types and volumes and defines the rules
used to translate inputs into system resources. Explicitly define assumptions in terms of:

• Growth in volumes of resource utilisation

• Operational requirements and their resource implications

Figure 128 – Sample Capacity Planning Model View

The capacity planning model can be created as a spreadsheet.

Finally, review and agree the capacity plan with the business stakeholders.

4.6.1.7.4 Step 3.4 Define Solution And System Approach

Consider and decide on whether to include a solution product evaluation and determination activity at this stage. You may
want to determine the characteristics of the software and system components of the overall solution in more detail before
seeking to identify possible suitable products or there may be an overriding requirement to identify likely solutions to meet
urgent requirements now.

Page 199 of 540

 Introduction to Solution Architecture

Agree the approach to solution selection. Decide on whether to perform a parallel product and solution selection exercise.

Figure 129 – Spectrum of Solution Component Acquisition Options

There is a spectrum of (not necessarily mutually exclusive) options available for acquiring the product and system
components of the overall solution. Separate options can be considered for different components of the overall business
function solution, subject to the integration issues and requirements being understood. These types of options include:

• Change Existing Processes – the way in which the systems are used can be changed
• Change Processes and Update Existing Systems – the business processes can be changed and the existing systems can
be modified to provide new functions
• Acquire Software Product(s) or Services – a product can be acquired and installed on the organisation’s technology
infrastructure to replace or extend the existing systems
• Acquire Hosted/Cloud Solution – a hosted system can be acquired to replace or extend the existing systems
• Develop Customised Solution(s) – the organisation can develop new customised systems
• Outsource Solution – the provision of the solution can be outsourced to a service provider
• Outsource Operations – the entire set of business operations supported by the systems can be outsourced to a service
provider who can use their own systems to deliver the service

Within these option types, there can be several realistic options:

Figure 130 – Combinations of Options

You need to keep the number of options to a small number.

One of the objectives of the architecture engagement is to reduce the set of options to a small number that are:

• Practical

Page 200 of 540

 Introduction to Solution Architecture

• Realistic
• Achievable
• Affordable
• Usable
• Compliant with organisation strategy and principles
• Compliant with organisation’s enterprise architecture
• Compliant with organisation’s appetite for risk

The buy rather than build option affects financial estimates. Remember that the product or service acquisition, either product
installed on premises or provided by a hosted service, cost is just one (small) component of the overall solution acquisition
and implementation cost. The sources for cost estimates for product or service buy include:

• Issuing formal or informal RFP/RFS (request for proposal/request for solution)

• Previous experiences, either within the organisation or elsewhere
• Vendor contacts

Use indicative estimates if available. Do not spend too much time getting detailed costs at this stage. The issue of cost
estimates is described in section 2.4.6 on page 44. There are lots of reasons for poor and inaccurate cost estimates. The topic
of organisation biases and how they affect solution estimates including costs is detailed in section 3.1 on page 57.

There are techniques such as Reference Class Forecasting that can be used to improve accuracy in plans and projections by
basing them on actual performance in a reference class of comparable solutions. Compare the proposed solution with the
reference class distribution to establish the most likely outcome.

Cost estimation can be a painful process. There can be a tendency not to include all cost items. This does not make the costs
go away. Accurate cost analysis and estimation are very important as they affect decision-making. You need to avoid
problems with inaccurate cost forecasting such as:

• Strategic Misrepresentation – Deliberate misrepresentation in budgeting caused by distorted incentives

• Planning Fallacy – Systematic tendency to underestimate how long it will take to complete a task even when there is past
experience of similar tasks over-running
• Optimism Bias – Systematic tendency to be overly optimistic about the outcome of actions

The key sets of factors in any decision include:

• Overall lifetime cost

• Risks associated with solution option
• Resources and time to implement
• Compliance with organisation’s business strategy, IT strategy and enterprise architecture

Create a cost model that can be reviewed and updated during the engagement. The structure and detail of the cost model is as
important as the cost values themselves. A good cost model reflects the source and structure of costs. It allows the costs to be
known and understood. The amounts of each element within the cost model can be changed as more accurate information
becomes known. Completely accurate information may not be available at this stage but the model can be created and
partially populated. Identify the gaps and repeat the analysis when more certain information is available.

The following outlines the phases and steps of a generalised cost estimation process that can be used to create structured and
evidence-based estimates for the system components of the solution.

Page 201 of 540

 Introduction to Solution Architecture

Figure 131 – Cost Estimation Process

This generalised process can be used as a structure to create good quality estimates. The steps in this process are:

Initiation and Research Phase

• Step 1: Define the Purpose of the Estimate

o Determine the estimate’s purpose

o Determine the level of detail required
o Determine who will receive the estimate
o Determine the overall scope of the estimate

• Step 2: Develop the Estimating Plan

o Determine the cost estimating team

o Outline the cost estimating approach
o Develop the estimate timeline
o Determine who will do the independent cost estimate
o Develop the schedule

Assessment Phase

• Step 3: Define the Solution

o Identify in a technical baseline description document

o The purpose of the project
o Its system and performance characteristics
o Any technology implications
o Solution acquisition schedule
o Acquisition approach
o Relationship to other existing system components
o Support (resources, training, etc.) and security needs

Page 202 of 540

 Introduction to Solution Architecture

o Risks
o Assumptions
o System quantities for development, test, and production
o Deployment and maintenance plans
o Predecessor or similar legacy systems

• Step 4: Determine the Estimating Approach

o Define work breakdown structure (WBS) and describe each element

o Choose the estimating method best suited for each WBS element
o Identify potential cross-checks for likely cost and schedule drivers
o Develop a cost estimating checklist

• Step 5: Identify Ground Rules and Assumptions

o Clearly define what is included and excluded from the estimate

o Identify global and program specific assumptions such as:
 The estimate’s timescale, including time-phasing and life cycle
 Program schedule information by phase
 Program acquisition strategy
 Any schedule or budget constraints
 Inflation assumptions
 Costs such as travel and other expenses
 Equipment the organisation is to furnish
 Prime contractor and major subcontractors
 Use of existing facilities or new modifications or developments
 Technology refresh cycles
 Technology assumptions and new technology to be developed
 Commonality with legacy systems and assumed heritage savings
 Effects of new ways of doing business

• Step 6: Obtain Data

o Create a data collection plan with emphasis on collecting current and relevant technical, programmatic,
cost, and risk data.
o Investigate possible data sources
o Collect data and normalise them for cost accounting, inflation, learning, and quantity adjustments
o Analyse the data to look for cost drivers, trends, and outliers compare results against rules of thumb and
standard factors derived from historical data
o Interview data sources and document all relevant information including an assessment of data reliability
and accuracy

• Step 7: Develop Point Estimate

o Develop the cost model by estimating each WBS element, using the best methodology from the data
collected
o Include all estimating assumptions in the cost model
o Express costs in constant year currency
o Sum the WBS elements to develop the overall point estimate
o Validate the estimate by looking for errors like double counting and omitting costs
o Compare estimate against the independent cost estimate and examine w here and why there are differences
o Perform cross-checks on cost drivers to see if results are similar
o Update the model as more data become available or as changes occur and compare results against previous
estimates

Analysis Phase

Page 203 of 540

 Introduction to Solution Architecture

• Step 8: Conduct Sensitivity Analysis

o Test the sensitivity of cost elements to changes in estimating input values and key assumptions
o Identify effects of changing the program schedule or quantities on the overall estimate
o Determine which assumptions are key cost drivers and which cost elements are affected most by changes

• Step 9: Conduct Risk and Uncertainty Analysis

o Determine the level of cost, schedule, and technical risk associated with each WBS element and discuss with
technical experts
o Analyse each risk for its severity and probability of occurrence
o Develop minimum, most likely, and maximum ranges for each element of risk
o Use an acceptable statistical analysis methodology to develop a confidence interval around the point
estimate
o Determine type of risk distributions and reason for their use
o Identify the confidence level of the point estimate
o Identify the amount of contingency funding and add this to the point estimate to determine the risk-
adjusted cost estimate

• Step 10: Document the Estimate

o Document all steps used to develop the estimate so that it can be recreated quickly by a cost analyst
unfamiliar with the program and produce the same result
o Document the purpose of the estimate, the team that prepared it, and who approved the estimate and on
what date
o Describe the program, including the schedule and technical baseline used to create the estimate
o Present the time-phased life-cycle cost of the program
o Discuss all ground rules and assumptions
o Include auditable and traceable data sources for each cost element
o Document for all data sources how the data were normalised
o Describe the results of the risk, uncertainty, and sensitivity analyses and whether any contingency funds
were identified
o Document how the estimate compares to the funding profile
o Track how this estimate compares to previous estimates, if applicable

Presentation Phase

• Step 11: Present Estimate for Approval

o Develop a briefing that presents the documented life-cycle cost estimate for management approval,
including
 An explanation of the technical and programmatic baseline and any uncertainties
 A comparison to an independent cost estimate (ICE) with explanations of any differences
 A comparison of the estimate (life-cycle cost estimate (LCCE) or independent cost estimate to the
budget
 Enough detail so the presenter can easily defend the estimate by showing how it is accurate,
complete, and high in quality
o Focus the briefing, in a logical manner, on the largest cost elements and drivers of cost
o Make the content concise and complete so that those who are unfamiliar with it can easily comprehend the
competence that underlies the estimate results
o Have more detailed available to respond to more searching questions
o Act on and document feedback from management
o The cost estimating team should request acceptance of the estimate

• Step 12: Update Estimate to Reflect Actual Costs and Changes

Page 204 of 540

 Introduction to Solution Architecture

o Update the estimate to

 Reflect any changes in technical or program assumptions
 Keep it current as the program passes through new phases

4.6.1.7.5 Step 3.5 Develop And Validate Feasibility Prototype(s)

Developing a prototype may useful in demonstrating and presenting options or concepts for components of the solution.
They can be of use to validate approaches, demonstrate behaviours or algorithms or prove that a solution component can
handle the required workload or illustrate the potential solution to the business. Prototypes are not intended to be complete
solutions. They are intended to be throwaway developments. They may evolve into production components but where this
happens care needs to be taken.

Prototyping is concerned with producing a working model of elements of the solution more quickly than standard
approaches. Prototypes bypass functionality such as detailed error checking.

Prototyping is most suitable where the requirements or the design of the solution component is not well defined or
understood or when some form of exploratory effort is justified to draw out aspects of the solution.

Prototypes have a cost in terms of resources to implement as well as affecting the engagement schedule.

4.6.1.8 Business Engagement Activity 4. Document Solutions, Applications

Applications And Functions

The possible steps for activity Document Systems, Applications And Functions are:

Figure 132 – Steps Within Business Engagement Activity 4. Document Systems, Applications And Functions

These steps are documented in more detail below:

4.1 Document Systems, Applications And Functions

4.6.1.8.1 Step 4.1 Document Systems, Applications And Functions

The objective of this activity is to define the set of solutions and applications that comprise the overall solution required as
part of the target business architecture. It may not be possible at this stage to identify the precise set of applications and their
boundaries. The purpose of the applications is to operate the required business processes and support business activities.
Applications can perform multiple functions or a single function. The set of applications can include existing legacy
applications that will be retained.

The possible set of tasks in this step is:

Page 205 of 540

 Introduction to Solution Architecture

• Analyse industry-specific applications

• Analyse existing application landscape
• Determine application integration, linkages and interfaces
• Determine business processing applications
• Determine data access approach and applications
• Determine management approach and applications
• Validate applications and previously-defined processes

There may be standard products available for the industry in which the organisation operates that are relevant to the
requirements of the business function within the scope of the business architecture engagement. Review such products and
applications. Review industry-specific standards to determine applicability to the organisation’s requirements. Analyse and
classify the suitability of products and the applicability of the standards as:

• Definitely suitable
• Potentially suitable
• Definitely unsuitable

Create an inventory of standard products and industry-specific standards and their classification.

Review the entire existing suite of applications in use to determine which should be retained and which are candidates for
replacement:

• Include customisations
• Include reporting and analytics tools

Classify the type of application:

• User productivity
• Reporting and analysis
• Package
• Custom developed
• Information sharing
• Transaction processing

Analyse and classify the suitability of these existing applications:

• Definitely retain
• Potentially retain
• Definitely replace

Create an inventory of such applications and their classification.

Determine application integration, linkages and interfaces. Identify the external applications that interface with the previously
identified existing suite of applications and the interfaces between the existing applications. Describe the nature of the
interface: frequency, direction, protocol, security, volume, method of interface and exchange. Describe the data that is
exchanged in sufficient detail so the effort to implement with new systems can be accurately estimated. The topic of data
integration is covered in more detail in section 4.8.5 on page 339.

Figure 133 – Inventory of Interfaces, Exchanges and Transfers

Transfers

Page 206 of 540

 Introduction to Solution Architecture

Create inventory of integrations, interfaces and exchanges, completing a set of information along the following lines:

Transfer Protocol Direction Data Data Encryption Batch/ Source Target Frequency
Mechanism Format Content Realtime
File HTTP In CSV Yes Hourly
transfer
Mail HTTPS Out XML No Daily
Web FTP Bidirectional JSON Weekly
service
Message XBRL On
Queueing demand
Manual SFTP XLSX
transfer
Replication TLS Proprietary
Proprietary SSH
API

Table 40 – Inventory of Interfaces, Exchanges and Transfers

Analyse business processing applications. Business applications are those that process business transactions. These are central
to the successful operation of the business function and need to be analysed in more detail. For each application, list the key
transactions. List the data entities created or updated by these transactions. List the business processes that use the
transactions within the applications.

Describe the architecture of the business transaction processing systems:

• Modular, componentised applications that are loosely integrated

• Monolithic applications with tightly coupled components

The architecture of these systems determines the usefulness of the applications in the future architecture.
Monolithic applications may not be part of the future architecture. The options for their replacement include

• Some functions may be outsourced

• Some functions may be provided by hosted applications
• Separate applications may be implemented for some sets of functions

Determine data access approach and applications. Analyse these approaches and applications used to provide access to data.
List the data sources. List the data access, extraction and staging approaches.

Determine management approach and applications. List the service management and administration processes and
applications that support the operation and use of the business systems.

Consolidate and validate the previously collected and analysed information:

• Inventory of industry-specific standards and the applicability

• Application landscape inventory and their potential future suitability
• Inventory of application integrations, interfaces and exchanges
• Transaction processing applications and their transaction types
• Inventory of data entities created or updated by these transactions
• Inventory of business processes that use the transactions within the applications
• Description of the architecture of the business transaction processing systems
• Inventory of approaches and applications used to provide access to data
• Inventory of service management and administration processes and applications

Page 207 of 540

 Introduction to Solution Architecture

4.6.1.9 Business Engagement Activity 5. Define Organisation, Infrastructure And Data

The possible steps for activity Define Organisation, Infrastructure And Data are:

Figure 134 – Steps Within Business Engagement Activity 5. Define Organisation, Infrastructure And Data

These steps are documented in more detail below:

5.1 Define Organisation And Resource Requirements And Structure

5.2 Define Application And Data Organisation
5.3 Define Infrastructure Requirements

4.6.1.9.1 Step 5.1 Define Organisation And Resource Requirements And Structure

Create a high-level future state organisation structure options with details on the roles, staffing levels and locations. Define
the high-level structures for allocation and performing work and making decisions. Define the work groups structure and
their interactions. Define the management, administration and escalation processes. Create a target organisation chart. Define
the differences between the current and future state organisation structures.

Define the target state staffing structures. Map existing roles and structures to the proposed new staffing structure. Create a
high-level plan to transition from the existing to the proposed new staffing structure. Staff transitions and organisation
changes can be problematic – such change can be resisted or its achievement ineffective. Prepare for and address such
resistance to change or reasons why change is not achieved to reduce potential problems.

Review possible resistance to staffing structures and organisation changes. Resistance to change or reasons why change fails
can be explicit or concealed. Explicit resistance or reasons can take forms such as:

• Insufficient numbers of appropriate staff to handle workload

• Lack of personnel skill, experience, knowledge
• Lack of effective communication
• Inadequate organisation structures
• Ineffective management structures

Identify hidden resistance factors to change. There are many causes and ways in which organisations and personnel
demonstrate resistance to change:

Page 20