Solution Architecture and Solution Complexity
0 likes2,463 views
The document discusses solution architecture and the complexity involved in designing and implementing solutions, emphasizing the importance of understanding both problem states and potential complexities. It outlines the factors that contribute to solution complexity, including the nature of the problem, the number of components, and their interactions, as well as external factors influencing the solution delivery process. The document also notes the necessity of managing complexity to avoid risks associated with operational and functional inefficiencies while ensuring that solutions are appropriately designed to meet user needs.
Solution Architecture and Solution Complexity
- 1. Solution Architecture and Solution ComplexitySolution Architecture and Solution ComplexitySolution Architecture and Solution ComplexitySolution Architecture and Solution Complexity Extract from Introduction to Solution ArchitectureIntroduction to Solution ArchitectureIntroduction to Solution ArchitectureIntroduction to Solution Architecture Paperback - https://www.amazon.com/dp/1797567616 Kindle - https://www.amazon.com/dp/B07P2NCFDQ
- 2. Introduction to Solution Architecture Page 101 of 538 • 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.24.2.24.2.24.2.2 Solution ComplexitySolution ComplexitySolution ComplexitySolution 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. FigureFigureFigureFigure 63636363 –––– Solution Design Complexity HeatmapSolution Design Complexity HeatmapSolution Design Complexity HeatmapSolution 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 ReaSYSTEMANTICS: How Systems ReaSYSTEMANTICS: How Systems ReaSYSTEMANTICS: How Systems Really Work and How They Faillly Work and How They Faillly Work and How They Faillly 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.
- 3. Introduction to Solution Architecture Page 102 of 538 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 IntroductioAn IntroductioAn IntroductioAn Introduction to Cyberneticsn to Cyberneticsn to Cyberneticsn to Cybernetics http://pespmc1.vub.ac.be/books/IntroCyb.pdf, W Ross Ahsby introduced his Law Of Requisite VarietyLaw Of Requisite VarietyLaw Of Requisite VarietyLaw 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 RegulatorGood RegulatorGood RegulatorGood 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 systemevery good regulator of a system must be a model of that systemevery good regulator of a system must be a model of that systemevery 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 yourROI: It's yourROI: It's yourROI: It's your job. Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineeringjob. Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineeringjob. Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineeringjob. Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP 2002(XP 2002(XP 2002(XP 2002), Alghero, Sardinia, Italy. He claimed that 46% of product features implemented were never used. FeaturesFeaturesFeaturesFeatures UsedUsedUsedUsed NeverNeverNeverNever 45% RarelyRarelyRarelyRarely 19% SometimesSometimesSometimesSometimes 16% OftenOftenOftenOften 13% AlwaysAlwaysAlwaysAlways 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.
- 4. Introduction to Solution Architecture Page 103 of 538 necessary complexity in one area of the solution will cause additional compensating complexity to occur or be needed elsewhere. FigureFigureFigureFigure 64646464 –––– TheTheTheThe Waterbed Analogy of Necessary Solution ComplexityWaterbed Analogy of Necessary Solution ComplexityWaterbed Analogy of Necessary Solution ComplexityWaterbed 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.
- 5. Introduction to Solution Architecture Page 104 of 538 FigureFigureFigureFigure 65656565 –––– AccumulatingAccumulatingAccumulatingAccumulating Solution ComplexitySolution ComplexitySolution ComplexitySolution 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. FigureFigureFigureFigure 66666666 –––– SimpleSimpleSimpleSimple and Complex Problems and Solutionsand Complex Problems and Solutionsand Complex Problems and Solutionsand 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.
- 6. Introduction to Solution Architecture Page 105 of 538 FigureFigureFigureFigure 67676767 –––– Solution Complexity and Time to DeliverSolution Complexity and Time to DeliverSolution Complexity and Time to DeliverSolution 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: ComplexityComplexityComplexityComplexity FactorFactorFactorFactor GroupGroupGroupGroup Complexity FactorComplexity FactorComplexity FactorComplexity Factor ReverseReverseReverseReverse WeightingWeightingWeightingWeighting Weighting/Weighting/Weighting/Weighting/ ImportanceImportanceImportanceImportance Simple/Few/Low/Yes/NotSimple/Few/Low/Yes/NotSimple/Few/Low/Yes/NotSimple/Few/Low/Yes/Not ApplicableApplicableApplicableApplicable ToToToTo Complex/Large/High/NoComplex/Large/High/NoComplex/Large/High/NoComplex/Large/High/No Operational Factors Operational Security Requirements Privacy and Confidentiality Of Data Being Processed Operational Performance And Throughput Requirements Operational Reliability And Availability Requirements Amount Of On-Premises Infrastructure Required
- 7. Introduction to Solution Architecture Page 106 of 538 ComplexityComplexityComplexityComplexity FactorFactorFactorFactor GroupGroupGroupGroup Complexity FactorComplexity FactorComplexity FactorComplexity Factor ReverseReverseReverseReverse WeightingWeightingWeightingWeighting Weighting/Weighting/Weighting/Weighting/ ImportanceImportanceImportanceImportance Simple/Few/Low/Yes/NotSimple/Few/Low/Yes/NotSimple/Few/Low/Yes/NotSimple/Few/Low/Yes/Not ApplicableApplicableApplicableApplicable ToToToTo Complex/Large/High/NoComplex/Large/High/NoComplex/Large/High/NoComplex/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 Factors Number Of Technologies Included In The 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 Technologies Y Amount Of Custom Development Development Platform Productivity Amount And Complexity Of Data To Be Loaded Or Migrated Reuse Of Existing Custom Components Business Factors Overall Business Project Size 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 Business Functions Or Areas Y Availability Of Business Resources To Work On The Solution Y Number Of Locations Of Business Functions Number Of Existing Solution Components Being Replaced Organisation Change Requirements Product Factors Number Of Products and Services Required To 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 Implementing Products and Services Y Products and Services Are Being Provided By Existing Suppliers To The Organisation Y 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)
- 8. Introduction to Solution Architecture Page 107 of 538 ComplexityComplexityComplexityComplexity FactorFactorFactorFactor GroupGroupGroupGroup Complexity FactorComplexity FactorComplexity FactorComplexity Factor ReverseReverseReverseReverse WeightingWeightingWeightingWeighting Weighting/Weighting/Weighting/Weighting/ ImportanceImportanceImportanceImportance Simple/Few/Low/Yes/NotSimple/Few/Low/Yes/NotSimple/Few/Low/Yes/NotSimple/Few/Low/Yes/Not ApplicableApplicableApplicableApplicable ToToToTo Complex/Large/High/NoComplex/Large/High/NoComplex/Large/High/NoComplex/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 Factors Fixed Project Implementation Deadline 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 Experience Factors Project Manager Skills And Experience Y Implementation Team Skills And Experience Y TableTableTableTable 17171717 –––– Solution Complexity FactorsSolution Complexity FactorsSolution Complexity FactorsSolution Complexity Factors Individual factor scores are assigned in a range of 1 to 10 on the scale where 1 represents Simple/Few/Low/Yes/NotSimple/Few/Low/Yes/NotSimple/Few/Low/Yes/NotSimple/Few/Low/Yes/Not ApplicableApplicableApplicableApplicable to 10 representing Complex/Large/High/NoComplex/Large/High/NoComplex/Large/High/NoComplex/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 suppliersNumber of separate suppliersNumber of separate suppliersNumber of separate suppliers involved in the delivery of the product(s)involved in the delivery of the product(s)involved in the delivery of the product(s)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)Maturity of the product(s)Maturity of the product(s)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.
- 9. Introduction to Solution Architecture Page 108 of 538 FigureFigureFigureFigure 68686868 –––– NonNonNonNon----Linear Nature of Solution Delivery ComplexityLinear Nature of Solution Delivery ComplexityLinear Nature of Solution Delivery ComplexityLinear Nature of Solution Delivery Complexity However, the exact nature of the non-linearity is not obvious. In reality the complexity curve will be like: FigureFigureFigureFigure 69696969 –––– Adjusted Complexity CurveAdjusted Complexity CurveAdjusted Complexity CurveAdjusted 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 58. The following table contains an example of the application of this complexity model.
- 10. Introduction to Solution Architecture Page 109 of 538 ComplexityComplexityComplexityComplexity FactorFactorFactorFactor GroupGroupGroupGroup Complexity FactorComplexity FactorComplexity FactorComplexity Factor ReverseReverseReverseReverse WeightingWeightingWeightingWeighting Weighting/Weighting/Weighting/Weighting/ ImportanceImportanceImportanceImportance UnweightedUnweightedUnweightedUnweighted ScoreScoreScoreScore WeightedWeightedWeightedWeighted ScoreScoreScoreScore Operational Factors Operational Security Requirements VH 6 9 Privacy and Confidentiality Of Data Being Processed VH 7 10.5 Operational Performance And Throughput Requirements H 4 5 Operational Reliability And Availability Requirements H 6 7.5 Amount Of On-Premises Infrastructure Required M 3 3 Volume Of Data Being Processed H 5 6.25 Volume and Variability of Workload To Be Processed H 4 5 Number Of Different Types Of Transactions To Be Processed M 6 6 Number Of Internal Solution Consumers M 5 5 Number Of External Solution Consumers VH 6 9 Technical Factors Number Of Technologies Included In The Overall Solution H 7 8.75 Number Of Solution Components H 7 8.75 Number Of Solutions Integrations And Interfaces H 7 8.75 Number Of Application Tiers L 5 3.75 Technologies Already Part Of The Organisation’s Enterprise Architecture M 4 4 Availability Of Skills And Experience In Technologies Y M 8 8 Amount Of Custom Development H 6 7.5 Development Platform Productivity M 5 5 Amount And Complexity Of Data To Be Loaded Or Migrated H 7 8.75 Reuse Of Existing Custom Components M 5 5 Business Factors Overall Business Project Size VH 7 10.5 Number Of Business Functions Or Areas That Will Use The Solution H 2 2.5 Number And Complexity Of Underlying Business Processes H 6 7.5 Familiarity Of The It Function With The Business Functions Or Areas Y M 8 8 Availability Of Business Resources To Work On The Solution Y M 7 7 Number Of Locations Of Business Functions H 4 5 Number Of Existing Solution Components Being Replaced M 6 6 Organisation Change Requirements H 5 6.25 Product Factors Number Of Products and Services Required To Deliver The Solution M 6 6 Number Of Separate Suppliers Involved In The Delivery Of The Product(s) and Service(s) H 4 5 Maturity Of The Product(s) and Service(s) Y H 7 8.75 Supplier Proven Skills And Experience In Implementing Products and Services Y M 9 9
- 11. Introduction to Solution Architecture Page 110 of 538 ComplexityComplexityComplexityComplexity FactorFactorFactorFactor GroupGroupGroupGroup Complexity FactorComplexity FactorComplexity FactorComplexity Factor ReverseReverseReverseReverse WeightingWeightingWeightingWeighting Weighting/Weighting/Weighting/Weighting/ ImportanceImportanceImportanceImportance UnweightedUnweightedUnweightedUnweighted ScoreScoreScoreScore WeightedWeightedWeightedWeighted ScoreScoreScoreScore Products and Services Are Being Provided By Existing Suppliers To The Organisation Y L 8 6 Number Of Supplier Offshore Locations Involved In The Delivery Of The Product(s) and Service(s) H 5 6.25 Degree Of Configuration Of Product(s) and Service(s) M 7 7 Degree Of Customisation Of The Of Product(s) and Service(s) H 7 8.75 Number Of Personnel From Supplier Involved In The Product and Service Delivery H 5 6.25 Complexity Of Outsourcing Relationship, If Applicable, To The Delivery Of The Product(s) and Service(s) M 1 1 Amount Of New Technology Introduced By The Product(s) and Service(s) M 1 1 Project Factors Fixed Project Implementation Deadline VH 1 1.5 Expected Project Duration VH 4 6 Overall Solution Delivery Project Size VH 6 9 Number Of Outsourcing Arrangements Included In The Overall Solution VH 1 1.5 Number Of Externally Hosted Components Included In The Overall Solution H 7 8.75 Size Of Implementation Project Team H 6 7.5 Multiple Language Requirements H 1 1.25 Number Of Jurisdictions In Which The Solution Will Operate H 8 10 Skill and Experience Factors Project Manager Skills And Experience Y H 8 10 Implementation Team Skills And Experience Y H 8 10 ScoreScoreScoreScore 264264264264 313131317777.75.75.75.75 TableTableTableTable 18181818 –––– Sample Solution Complexity ScoresSample Solution Complexity ScoresSample Solution Complexity ScoresSample 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.
- 12. Introduction to Solution Architecture Page 111 of 538 FigureFigureFigureFigure 70707070 –––– Sample Solution Complexity Score on Solution Complexity CurveSample Solution Complexity Score on Solution Complexity CurveSample Solution Complexity Score on Solution Complexity CurveSample Solution Complexity Score on Solution Complexity Curve Using this approach, the following complexity score would lead to the following resource uplifts. ComplexityComplexityComplexityComplexity ScoreScoreScoreScore PossiblePossiblePossiblePossible ResourceResourceResourceResource UpliftUpliftUpliftUplift 300 1.06 350 1.44 400 1.73 450 1.89 500 1.97 TableTableTableTable 19191919 –––– Complexity Scores and Resource UpliftsComplexity Scores and Resource UpliftsComplexity Scores and Resource UpliftsComplexity 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.
- 13. Introduction to Solution Architecture Page 112 of 538 It could be possible to create a solution complexity dashboard along the following lines. This example contains the following numbered sections: FigureFigureFigureFigure 71717171 –––– Sample Solution Complexity DashboardSample Solution Complexity DashboardSample Solution Complexity DashboardSample Solution Complexity Dashboard The numbered elements of this are: NumberNumberNumberNumber DescriptionDescriptionDescriptionDescription 1111 This shows the complexity factor groups. 2222 This shows the individual complexity factors. 3333 This allows individual complexity factors to be included or excluded from the derivation of the overall solution complexity. 4444 This indicates if the score for the factor is reversed. 5555 This is the weighting applied to the factor based on the scale of VL, L, M, H and VH. 6666 This allows the individual complexity factor to be assigned a value. 7777 This is the weighted score of the complexity factor. 8888 The shows the relative value of the group of complexity factors. 9999 This shows the overall complexity score against the available score. 10101010 This shows the estimated uplift that should be applied to the estimated based on the derived complexity of the solution. 11111111 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. 12121212 This shows the overall solution complexity score. 13131313 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.
- 14. Introduction to Solution Architecture Page 113 of 538 14141414 This shows where the overall solution complexity lies on the solution complexity curve. TableTableTableTable 20202020 –––– Sample Solution Complexity Dashboard ElementsSample Solution Complexity Dashboard ElementsSample Solution Complexity Dashboard ElementsSample Solution Complexity Dashboard Elements The following diagram shows this sample complexity dashboard with some of the factors excluded. FigureFigureFigureFigure 72727272 –––– Solution Complexity Dashboard With Not Applicable Complexity FactorsSolution Complexity Dashboard With Not Applicable Complexity FactorsSolution Complexity Dashboard With Not Applicable Complexity FactorsSolution 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.