Alan McSweeney, profile picture
Uploaded byAlan McSweeney
PDF, PPTX145,675 views

Structured Approach to Solution Architecture

The document outlines a structured approach to solution architecture, emphasizing the need for consistency in design options to address business requirements effectively. It details key elements such as compliance with enterprise architecture standards, the importance of defining various solution components, and the iterative nature of solution design and implementation. Additionally, it highlights the TOGAF framework as a guiding methodology for developing and analyzing solution architecture across multiple dimensions.

Embed presentation

Download as PDF, PPTX
1 / 108
2 / 108
Most read
3 / 108
4 / 108
5 / 108
6 / 108
7 / 108
8 / 108
9 / 108
10 / 108
11 / 108
12 / 108
13 / 108
Most read
14 / 108
15 / 108
16 / 108
17 / 108
18 / 108
19 / 108
20 / 108
21 / 108
22 / 108
23 / 108
24 / 108
25 / 108
26 / 108
27 / 108
28 / 108
29 / 108
30 / 108
31 / 108
32 / 108
33 / 108
34 / 108
35 / 108
36 / 108
37 / 108
38 / 108
39 / 108
Most read
40 / 108
41 / 108
42 / 108
43 / 108
44 / 108
45 / 108
46 / 108
47 / 108
48 / 108
49 / 108
50 / 108
51 / 108
52 / 108
53 / 108
54 / 108
55 / 108
56 / 108
57 / 108
58 / 108
59 / 108
60 / 108
61 / 108
62 / 108
63 / 108
64 / 108
65 / 108
66 / 108
67 / 108
68 / 108
69 / 108
70 / 108
71 / 108
72 / 108
73 / 108
74 / 108
75 / 108
76 / 108
77 / 108
78 / 108
79 / 108
80 / 108
81 / 108
82 / 108
83 / 108
84 / 108
85 / 108
86 / 108
87 / 108
88 / 108
89 / 108
90 / 108
91 / 108
92 / 108
93 / 108
94 / 108
95 / 108
96 / 108
97 / 108
98 / 108
99 / 108
100 / 108
101 / 108
102 / 108
103 / 108
104 / 108
105 / 108
106 / 108
107 / 108
108 / 108
Structured Approach to Solution Architecture Alan McSweeney
June 12, 2014 2 Solution Architecture Is … − Description of the structure, characteristics and behaviour of a solution − The means by which the solution is defined, delivered, managed and operated • A solution is an answer to a business problem that may or may not include a technology component • Solution architecture is concerned with identifying that solution or set of solution options and their components • Generally there are many potential solutions to a problem with varying suitability • All solutions are subject to constraints
Structured Approach to Solution Architecture • Objective is to ensure consistency in solution architecture design options • Ensure solution addresses all business requirements • Provide checklist to validate solution design options • Design realistic and achievable solutions that meet the business needs • Adapt elements of TOGAF to assist with structured solution design June 12, 2014 3
June 12, 2014 4 Solution Architecture In Context Business Objectives Business Operational Model Enterprise Architecture Solution Delivery Management And Operations Business Processes Business Systems Business Strategy Solution Architecture
Solution Architecture June 12, 2014 5 Enterprise Architecture Solution Delivery Business Systems Solution Architecture Takes the requirements for solutions to business needs Ensures compliance with overall systems architecture standards Designs solution options based on requirements subject to standards and other solution constraints that are then implemented
Solution Architecture June 12, 2014 6 Enterprise Architecture Solution Delivery Business Systems Solution Architecture Takes the requirements for solutions to business needs Ensures compliance with overall systems architecture standards Designs solution options based on requirements subject to standards and other solution constraints that are then implemented Goal is to ensures solutions implemented deliver business requirements accurately, efficiently and in a timely manner with no surprises
June 12, 2014 7 Solution Architecture In Context Business Strategy Business Objectives Business Operational Model Enterprise Architecture Business Processes Business Systems Solution Architecture Solution Delivery Management And Operations Processes operationalise business objectives Operational model defined to achieve objectives Architecture defines technology framework to run operational model Objectives derived from strategy Systems assist with the operation of processes Solution architecture defines business systems design within enterprise architecture principles Solutions are implemented according to the solution architecture
June 12, 2014 8 Solution Does Not Always Consist Solely Of A New Application External Manual Interaction External Manual Interaction External Manual Interaction External Manual Interaction Extended Application (Other Systems) System Component System Component System Component External Component External Component External Component Core Application
June 12, 2014 9 Complete View of Solution System Component System Component System Component External Component External Component External Component Automated Process Automated Process Automated Process External Manual Interaction External Manual Interaction Manual Process Manual Process External Manual Interaction External Manual Interaction Manual Process Manual Process
June 12, 2014 10 Overall Solution Can Be A Combination of Automated and Manual Processes Automated Process Automated Process Automated Process Manual Process Manual Process Manual Process Manual Process Extended Application Core Application
June 12, 2014 11 Solution Design and Implementation Sequence Business Plan Business Need Business Benefits Requirements Definition Process Design Solution Architecture and Design Technical and Detailed Design Implementation You Can Iterate Through These Steps Multiple Times, Refining Detail Each Stage
June 12, 2014 12 TOGAF Enterprise Architecture Development and Implementation Process Architecture Change Management Implementation Governance Migration Planning Opportunities and Solutions Technology Architecture Information Systems Architecture Business Architecture Architecture Vision Requirements Management Data Architecture Solutions and Application Architecture Business solutions fit into these areas of the TOGAF framework
Extended Solution ViewsCore Solution Views June 12, 2014 13 Solution Architecture Dimensions/Views Solution Architecture Dimensions Business View Functional View Data View Technical View Implementation View Management And Operation
Core Views and Extended Views • Core Solution Architecture Views – concerned with the kernel of the solution − Business − Functional − Data • Extended Solution Architecture Views – concerned with solution implementation and operation − Technical − Implementation − Management and Operation June 12, 2014 14
Solution Architecture Dimensions/Views • Dimensions/views are structured sets of requirements, conditions, specifications, provisions, concerns and fundamentals for each dimension of the overall solution • Core dimensions/views define what the solution must do and the results expected • Extended dimensions/views define how the solution must be implemented, managed and operated June 12, 2014 15
Generalised Solution Architecture Sub-System 1 Primary Processor Sub-System 2 Monitor, Audit, Manage Sub-System 3 Control Data Storage and Flow June 12, 2014 16
Generalised Solution Architecture • Sub-System 1 - performs primary activities, functions that accepts and process inputs, performs transformations and creates and presents outputs, divided into multiple components, implements and actualises processes and activities • Sub-System 2 - monitors, audits, measures, manages performance and activities of the components of sub-system 1 • Sub-System 3 - controls operation and communication and storage of data of an between the components of sub-system 1 and between sub-system 1 and sub-system 2 June 12, 2014 17
Generalised Solution Architecture • Useful in defining the components of the solution June 12, 2014 18
Solution Core Views Business and Process View Processes Enabled and Actualised by Solution and its Functions Data View Range of Data Being Processed/Handled Functionaland ResultsView W hatisGenerated/ Created/ Achieved/ Output June 12, 2014 19
Solution Core Views And Their Interrelationships Data View Range of Data Being Processed/ Handled Business and Process View Processes Enabled and Actualised by Solution and its Functions Functions and Results View What is Generated/ Created/Achieved Functions Generate Results Consist of Created or Transformed Data Business Processes Read and Generate Data Processes Are Implemented by Functions that Generate ResultsJune 12, 2014 20
Business and Process View And Decomposition Process 1 Activity 1.1 Activity 1.N Task 1.1.1 Step 1.1.1.1 Step 1.1.1.N Task 1.1.N Task 1.N.1 Task 1.N.N Step 1.N.N.1 Step 1.N.N.N Process N… … … … … … June 12, 2014 21
Data View And Decomposition Data Type 1 Data Element 1.1 Data Element 1.N Data Attribute 1.1.1 Data Attribute Value 1.1.1.1 Data Attribute Value 1.1.1.N Data Attribute 1.1.N Data Attribute 1.N.1 Data Attribute 1.N.N Data Attribute Value 1.N.N.1 Data Attribute Value 1.N.N.N Data Type N… … … … … … June 12, 2014 22
Functions/Results/Outputs View And Decomposition Output 1 Output Element 1.1 Output Element 1.N Output Attribute 1.1.1 Output Attribute Value 1.1.1.1 Output Attribute Value 1.1.1.N Output Attribute 1.1.N Output Attribute 1.N.1 Output Attribute 1.N.N Output Attribute Value 1.N.N.1 Output Attribute Value 1.N.N.N Output N… … … … … … June 12, 2014 23
Solution Core Views Business and Process View Data View Functionaland ResultsView June 12, 2014 24
June 12, 2014 25 Dimensions/Views Of Solution Architecture Solution Architecture Dimensions Business View Functional View Technical View Implementation View Data View Context Purpose Characteristics Context Stakeholders Characteristics Context Structure Operation Development Characteristics Context Artefacts/ Products Execution Characteristics Context Entities Roles Interfaces Characteristics Management and Operations View Context Operational Processes Support Operation Characteristics
June 12, 2014 26 Business And Process View Topics Business Requirements View Business Context Purpose Characteristics Business Environment Resources, Skills and Experience Products, Services and Value Propositions Value Chain Stakeholders Business Processes Availability, Continuity and Resilience Cost and Affordability Flexibility and Ability to Evolve Ease of Implementation Suitability and Efficiency Performance Reliability Manageability and Ease of Operation Linkage to Other Systems Stability Security Usability
June 12, 2014 27 Functional And Results View Topics Functional View Functional Context Purpose Characteristics Related Systems Operational Processes Products, Services and Value Propositions Value Chain Stakeholders Business Processes Availability, Continuity and Resilience Cost and Affordability Flexibility and Ability to Evolve Ease of Implementation Suitability and Efficiency Performance Reliability Manageability and Ease of Operation Linkage to Other Systems Scalability Security Usability
June 12, 2014 28 Technical View Topics Technical View Technical Context Technical Configuration Operation Implementation Environment and Tools Development Approach Language Framework/Systems Availability, Continuity and Resilience Cost and Affordability Flexibility and Ability to Evolve Ease of Implementation Suitability and Efficiency Performance Reliability Manageability and Ease of Operation Linkage to Other Systems Scalability Security Usability Innovation and Growth Characteristics System Structure Hardware Infrastructure Software Infrastructure System Operation System Management and Administration System Lifecycle System Change and Growth Data Infrastructure Integration Infrastructure
June 12, 2014 29 Implementation View Topics Technical View Implementation Context Implementation Artefacts/Products Execution Implementation Environment Development Approach Language Framework/Systems Availability, Continuity and Resilience Cost and Affordability Flexibility and Ability to Evolve Ease of Implementation Suitability and Efficiency Performance Reliability Manageability and Ease of Operation Linkage to Other Systems Scalability Security Usability Characteristics Solution Elements Delivered Components Collateral Governance Implementation Organisation Supporting Material Implementation Process Delivery Plan Configuration Financial Management Solution Validation
Data View Topics June 12, 2014 30 Data View Data Context Entitles Interfaces Data Model Reference and Master Data Availability, Continuity and Resilience Cost and Affordability Flexibility and Ability to Evolve Ease of Implementation Suitability and Efficiency Performance Reliability Manageability and Ease of Operation Storage and Capacity Scalability Security Usability Analysis and Reporting Characteristics Data Entities Relationships Access Rights and Permissions Sources and Targets Transformations Reporting Analysis Data Types Data Types Conversion/Migration Data Volumes Data Velocity Data Variety
Management and Operation View Topics June 12, 2014 31 Management and Operation View Management and Operation Context Operational Processes Support Service Management Framework Operational Framework Transition Business Readiness Availability, Continuity and Resilience Cost and Affordability Flexibility and Ability to Evolve Ease of Implementation Suitability and Efficiency Performance Reliability Manageability and Ease of Operation Linkage to Other Systems Scalability Security Usability Operation Characteristics Capacity Availability, Continuity and Resilience Change Support Model Support Processes Deployment/ Maintenance Structure Deployment/ Maintenance Process Service Level Service Desk Service Management Processes Configuration Release and Deployment Incident Problem Organisational Change Steady State Alerting and Monitoring Backup and Recovery Service Level Management
June 12, 2014 32 Mapping TOGAF Enterprise Architecture Process To Solution Architecture Definition TOGAF Phase D: Technology Architecture TOGAF Phase C: Information Systems Architecture TOGAF Phase B: Business Architecture TOGAF Phase C1: Data Architecture TOGAF Phase C2: Solutions and Application Architecture Business View Data View Technical View Functional View Implementation View Management and Operation View SolutionArchitecture Views/Dimensions
Extended Solution Dimensions Core Solution Dimensions TOGAF Solution Dimensions Solution Dimensions Business View Data View Technical View Functional View Implementation View Management and Operation View June 12, 2014 33
Solution Architecture Design Boundaries June 12, 2014 34 Enterprise Architecture Defines the Solution Technical Boundary Business View Data View Technical View Functional View Implementation View Management and Operation View Solution Architecture Solution Architecture Defines the Solution Scope Boundary
Designing The Solution • Overall solution design is constrained both by enterprise architecture and solution architecture views • There are many possible solution options to a business requirement or problem − Solution can be manual or automated to a lesser or greater extent − Solution can involve enhancing existing system and/or process or developing new system and/or process − These constraints form boundaries to the solution design June 12, 2014 35
Solution Design Factors, Limitations And Boundaries • Core Constraints – concerned with essential solution attributes − Enterprise Architecture − Solution Architecture Views/Dimensions − Existing or New System − Degree of Automation • Extended Constraints – concerned with solution implementation and operation − Resources − Finance − Timescale − Expected Life June 12, 2014 36
Core Solution Design Factors, Limitations And Boundaries Degree of Automation of Solution Solution Architecture View Design Constraints Enterprise Architecture Constraints Use Existing System or Create New System Range of Solution Options June 12, 2014 37
Extended Solution Design Factors, Limitations And Boundaries • Other implementation and operation-related constraints that will affect the solution options: − Resources and their availability − Timescale and urgency of solution − Cost and available finance − Likely duration of solution June 12, 2014 38
Different Solution Designs And Options Can Comply With Constraints Differently June 12, 2014 39
Comparison Of Possible Options For One Solution June 12, 2014 40
Solution Architecture Dimensions/Views And Solution Design Factors, Limitations And Boundaries Extended Views Core Views June 12, 2014 41 Solution Design Factors, Limitations And Boundaries Solution Architecture Dimensions/Views
Solution Architecture Dimensions/Views And Solution Design Factors, Limitations And Boundaries Enterprise Architecture Technical View Implementation View Management and Operation View Business View Data View Functional View Degree of Automation Finance Timescale Existing or New System Resources Expected Life June 12, 2014 42
June 12, 2014 43 Mapping TOGAF Enterprise Architecture Process To Solution Architecture Definition TOGAF Phase D: Technology Architecture TOGAF Phase C: Information Systems Architecture TOGAF Phase B: Business Architecture TOGAF Phase C1: Data Architecture TOGAF Phase C2: Solutions and Application Architecture Business View Data View Technical View Functional View Implementation View Management and Operation View SolutionArchitecture Views/Dimensions
Steps For TOGAF View/Dimension Analysis And Development • Common set of steps across four solution architecture views/dimensions common to TOGAF 1. Select reference models, viewpoints, and tools 2. Develop baseline view/dimension architecture description 3. Develop target view/dimension architecture description 4. Perform gap analysis 5. Define roadmap components 6. Resolve impacts across the architecture landscape 7. Conduct formal stakeholder review 8. Finalise the view/dimension architecture 9. Create view/dimension architecture definition document June 12, 2014 44
Steps For TOGAF View/Dimension Analysis And Development • Use TOGAF framework to give a rigour to the solution architecture analysis and design • Modify as required to suit the depth of the analysis • Can iterate through the steps with varying levels of analysis as solution is articulated June 12, 2014 45
TOGAF Steps For Business Dimension/View Analysis And Design June 12, 2014 46
Step 1 - Select Reference Models, Viewpoints, and Tools (1) • Select relevant Business Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, and the stakeholders and concerns • Select relevant Business Architecture viewpoints (e.g., operations, management, financial); i.e. those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Business Architecture • Identify appropriate tools and techniques to be used for capture, modeling, and analysis • Determine Overall Modelling Process − For each viewpoint, select the models needed to support the specific view required, using the selected tool or method − Ensure that all stakeholder concerns are covered − Identify the key business functions within the scope of the architecture, and maps those functions onto the business units within the organisation − Breakdown business-level functions across actors and business units to allow the actors in a function to be identified and permits a breakdown into services supporting/delivering that functional capability − Breakdown a function or business service through process modeling to allow the elements of the process to be identified and permit the identification of lower-level business services or functions June 12, 2014 47
Step 1 - Select Reference Models, Viewpoints, and Tools (2) • Identify Required Service Granularity Level, Boundaries, and Contracts − Business Architecture phase therefore needs to identify which components of the architecture are functions and which are services • Business services are specific functions that have explicit, defined boundaries that are explicitly governed • Services are distinguished from functions through the explicit definition of a service contract • A service contract covers the business/functional interface and also the technology/data interface − Business Architecture will define the service contract at the business/functional level, which will be expanded on in the Application and Technology Architecture phases − Granularity of business services should be determined according to the business drivers, goals, objectives, and measures for this area of the business June 12, 2014 48
Step 1 - Select Reference Models, Viewpoints, and Tools (3) • Identify Required Catalogs of Business Building Blocks − Catalogs capture inventories of the core assets of the business − Catalogs form the raw material for development of matrices and views and also act as a key resource for portfolio managing business and IT capability − Develop some or all of the following catalogs: • Organisation/Actor catalog • Driver/Goal/Objective catalog • Role catalog • Business Service/Function catalog • Location catalog • Process/Event/Control/Product catalog • Contract/Measure catalog June 12, 2014 49
Step 1 - Select Reference Models, Viewpoints, and Tools (4) • Identify Required Matrices − Matrices show the core relationships between related model entities − Matrices form the raw material for development of views and also act as a key resource for impact assessment, carried out as a part of gap analysis • Business interaction matrix - showing dependency and communication between business units and actors • Actor/role matrix - showing the roles undertaken by each actor June 12, 2014 50
Step 1 - Select Reference Models, Viewpoints, and Tools (5) • Identify Required Diagrams − Diagrams present the Business Architecture information from a set of different perspectives according to the requirements of the stakeholders • Business Footprint diagram • Business Service/Information diagram • Functional Decomposition diagram • Goal/Objective/Service diagram • Use-case diagram • Organisation Decomposition diagram • Process Flow diagram • Events diagram June 12, 2014 51
Step 1 - Select Reference Models, Viewpoints, and Tools (6) • Identify Types of Requirement to be Collected − Once the Business Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalising the business- focused requirements for implementing the Target Architecture − Requirements may relate to the business domain, or may provide requirements input into the Data, Application, and Technology Architectures − Types of requirement • Functional requirements • Non-functional requirements • Assumptions • Constraints • Domain-specific Business Architecture principles • Policies • Standards • Guidelines • Specifications June 12, 2014 52
Step 2 - Develop Baseline Business Architecture Description • Develop a Baseline Description of the existing Business Architecture, to the extent necessary to support the Target Business Architecture • Scope and level of detail to be defined will depend on the extent to which existing business elements are likely to be carried over into the Target Business Architecture June 12, 2014 53
Step 3 - Develop Target Business Architecture Description • Develop a Target Description for the Business Architecture, to the extent necessary to support the Architecture Vision • Scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision June 12, 2014 54
Step 4 - Perform Gap Analysis • Verify the architecture models for internal consistency and accuracy • Perform trade-off analysis to resolve conflicts (if any) among the different views • Validate that the models support the principles, objectives, and constraints • Test architecture models for completeness against requirements • Identify gaps between the baseline and target June 12, 2014 55
Step 5 - Define Roadmap Components • Create a business roadmap to prioritise activities over the coming phases • Initial Business Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities and Solutions phase June 12, 2014 56
Step 6 - Resolve Impacts Across the Architecture Landscape • Understand any wider impacts or implications of proposed Business Architecture − Does this Business Architecture create an impact on any pre- existing architectures? − Have recent changes been made that impact on the Business Architecture? − Are there any opportunities to leverage work from this Business Architecture in other areas of the organisation? − Does this Business Architecture impact other projects (including those planned as well as those currently in progress)? − Will this Business Architecture be impacted by other projects (including those planned as well as those currently in progress)? June 12, 2014 57
Step 7 - Conduct Formal Stakeholder Review • Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Business Architecture • Is fit for the purpose of supporting subsequent work in the other architecture domains? • Refine the proposed Business Architecture but only if necessary June 12, 2014 58
Step 8 - Finalise the Business Architecture • Select standards for each of the building blocks re-using as much as possible from the reference models selected from the Architecture Repository • Document each building block • Conduct final cross-check of overall architecture against business goals • Document reason for building block decisions in the architecture document • Document final requirements traceability report • Document final mapping of the architecture within the Architecture Repository and publish via the Architecture Repository • Finalise all the work products, such as gap analysis results June 12, 2014 59
Step 9 - Create Architecture Definition Document • Document reasons for building block decisions in the Architecture Definition Document • Prepare the business sections of the Architecture Definition Document − A business footprint (a high-level description of the people and locations involved with key business functions) − A detailed description of business functions and their information needs − A management footprint (showing span of control and accountability) − Standards, rules, and guidelines showing working practices, legislation, financial measures, etc. − A skills matrix and set of job descriptions June 12, 2014 60
TOGAF Steps For Data Dimension/View Analysis And Design June 12, 2014 61
Step 1 - Select Reference Models, Viewpoints, and Tools (1) • Select relevant Data Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, and the stakeholders and concerns • Select relevant Data Architecture viewpoints (e.g., operations, management, financial); i.e. those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Data Architecture • Identify appropriate tools and techniques to be used for data capture, modeling, and analysis • Determine Overall Modelling Process − For each viewpoint, select the models needed to support the specific view required, using the selected tool or method − Ensure that all stakeholder concerns are covered − Collect data-related models from existing Business Architecture and Application Architecture materials − Rationalise data requirements and align with any existing organisation data catalogs and models - this allows the development of a data inventor y and entity relationship − Update and develop matrices across the architecture by relating data to business service, business function, access rights, and application − Elaborate Data Architecture views by examining how data is created, distributed, migrated, secured, and archived June 12, 2014 62
Step 1 - Select Reference Models, Viewpoints, and Tools (2) • Identify Required Catalogs of Data Building Blocks − Capture organisation’s data inventory as a catalog within the Architecture Repository − Create an inventory of the data needed to be in place to support the Architecture Vision − Refer to the Business Service/Information diagram created during the Business Architecture phase, showing the key data entities required by the main business services − Consolidate the data requirements in a single location − Refine the data inventory to achieve semantic consistency and to remove gaps and overlaps June 12, 2014 63
Step 1 - Select Reference Models, Viewpoints, and Tools (3) • Identify Required Matrices − Matrices show the core relationships between related model entities − Form the raw material for development of diagrams and also act as a key resource for impact assessment − Understand how data is created, maintained, transformed, and passed to other applications, or used by other applications − Note gaps such as entities that never seem to be created by an application or data created but never used − Update and refine the architectural diagrams of how data relates to other aspects of the architecture − Suggested matrices • Data Entity/Business Function (showing which data supports which functions and which business function owns which data) • Business Service/Information (developed during the Business Architecture phase) • System/Data (developed across the Application Architecture and Data Architecture phases) June 12, 2014 64
Step 1 - Select Reference Models, Viewpoints, and Tools (4) • Identify Required Diagrams − Diagrams present the Data Architecture information from a set of different perspectives according to the requirements of the stakeholders − Once the data entities have been refined, a diagram of the relationships between entities and their attributes can be produced • Class diagram • Data Dissemination diagram • Data Lifecycle diagram • Data Security diagram • Data Migration diagram • Class Hierarchy diagram June 12, 2014 65
Step 1 - Select Reference Models, Viewpoints, and Tools (5) • Identify Types of Requirement to be Collected − Once the Data Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalising the business-focused requirements for implementing the Target Architecture − Types of requirement • Functional requirements • Non-functional requirements • Assumptions • Constraints • Domain-specific Data Architecture principles • Policies • Standards • Guidelines • Specifications June 12, 2014 66
Step 2 - Develop Data Business Architecture Description • Develop a Baseline Description of the existing Data Architecture, to the extent necessary to support the Target Business Architecture • Scope and level of detail to be defined will depend on the extent to which existing data elements are likely to be carried over into the Target Data Architecture June 12, 2014 67
Step 3 - Develop Target Business Architecture Description • Develop a Target Description for the Data Architecture, to the extent necessary to support the Architecture Vision • Scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision June 12, 2014 68
Step 4 - Perform Gap Analysis • Verify the architecture models for internal consistency and accuracy • Perform trade-off analysis to resolve conflicts (if any) among the different views • Validate that the models support the principles, objectives, and constraints • Test architecture models for completeness against requirements • Identify gaps between the baseline and target − Create gap matrix − Identify building blocks to be carried over, classifying as either changed or unchanged − Identify eliminated building blocks − Identify new building blocks − Identify gaps and classify as those that should be developed and those that should be procured June 12, 2014 69
Step 5 - Define Roadmap Components • Create a data business roadmap to prioritise activities over the coming phases • Initial Data Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities and Solutions phase June 12, 2014 70
Step 6 - Resolve Impacts Across the Architecture Landscape • Understand any wider impacts or implications of proposed Data Architecture − Does this Data Architecture create an impact on any pre-existing architectures? − Have recent changes been made that impact on the Data Architecture? − Are there any opportunities to leverage work from this Data Architecture in other areas of the organisation? − Does this Data Architecture impact other projects (including those planned as well as those currently in progress)? − Will this Data Architecture be impacted by other projects (including those planned as well as those currently in progress)? June 12, 2014 71
Step 7 - Conduct Formal Stakeholder Review • Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Data Architecture • Is fit for the purpose of supporting subsequent work in the other architecture domains? • Identify any areas where the Solution and Application Architecture may need to change to cater for changes in the Data Architecture (or to identify constraints on the Solution and Application Architecture about to be designed) • Refine the proposed Data Architecture but only if necessary June 12, 2014 72
Step 8 - Finalise the Data Architecture • Select standards for each of the building blocks re-using as much as possible from the reference models selected from the Architecture Repository • Document each building block • Conduct final cross-check of overall architecture against business goals • Document reason for building block decisions in the architecture document • Document final requirements traceability report • Document final mapping of the architecture within the Architecture Repository and publish via the Architecture Repository • Finalise all the work products, such as gap analysis results June 12, 2014 73
Step 9 - Create Architecture Definition Document • Document reasons for building block decisions in the Architecture Definition Document • Prepare Data Architecture sections of the Architecture Definition Document − Business data model − Logical data model − Data management process model − Data Entity/Business Function matrix − Data interoperability requirements June 12, 2014 74
TOGAF Steps For Functional Dimension/View Analysis And Design June 12, 2014 75
Step 1 - Select Reference Models, Viewpoints, and Tools (1) • Review and validate (or generate, if necessary) the set of application principles − Form part of an overarching set of architecture principles • Select relevant Application Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, and the stakeholders and concerns • Select relevant Application Architecture viewpoints (for example, stakeholders of the applications, viewpoints relevant to functional and individual users of applications, etc.); i.e. those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Application Architecture • Identify appropriate tools and techniques to be used for data capture, modeling, and analysis • Consider using platform-independent descriptions of business logic − Isolate the business logic from changes to the underlying platform and implementation technology June 12, 2014 76
Step 1 - Select Reference Models, Viewpoints, and Tools (2) • Determine Overall Modeling Process − For each viewpoint, select the models needed to support the specific view required, using the selected tool or method − Ensure that all stakeholder concerns are covered − Process steps • Understand the list of applications or application components that are required, based on the baseline Application Portfolio, what the requirements are, and the business architecture scope • Identify logical applications and the most appropriate physical applications • Develop matrices across the architecture by relating applications to business service, business function, data, process, etc. • Elaborate a set of Application Architecture views by examining how the application will function, capturing integration, migration, development, and operational concerns − The level of granularity should be sufficient to enable identification of gaps and the scope of candidate work packages June 12, 2014 77
Step 1 - Select Reference Models, Viewpoints, and Tools (3) • Identify Required Catalogs of Application Building Blocks − Capture organisation’s Application Portfolio as a catalog within the Architecture Repository • Application Portfolio catalog • Interface catalog June 12, 2014 78
Step 1 - Select Reference Models, Viewpoints, and Tools (4) • Identify Required Matrices − Matrices show the core relationships between related model entities − Form the raw material for development of diagrams and also act as a key resource for impact assessment − Once the baseline Application Portfolio has been assembled, it is necessary to map the applications to their purpose in supporting the business • Initial mapping should focus on business services within the Business Architecture − Once applications are mapped to business services, it will also be possible to make associations from applications to data • Refer to Phase C1: Information Systems Architectures - Data Architecture − Identify user and organisational dependencies on applications − Specifically consider the operational support business unit − Update and refine the architectural diagrams of how data relates to other aspects of the architecture − Examine application dependencies on shared operations capabilities and produce a diagram on how each application is effectively operated and managed − Suggested matrices • System/Business Unit matrix • Role/System matrix • Application Interaction matrix • System/Function matrix June 12, 2014 79
Step 1 - Select Reference Models, Viewpoints, and Tools (5) • Identify Required Diagrams − Diagrams present the Application Architecture information from a set of different perspectives according to the requirements of the stakeholders − Once the desired functionality of an application is known, it is necessary to perform an internal assessment of how the application should be best structured to meet its requirements • Packaged applications − Numbers of configuration options, add-on modules • Custom developed applications − Identify the high-level structure of the application in terms of modules or sub- systems as a foundation to organise design activity − Once the application entities have been refined, a diagram of the relationships between entities and their attributes can be produced • Application Communication diagram • Application and User Location diagram • Enterprise Manageability diagram • Process/System Realisation diagram • Application Migration diagram • Software Distribution diagram • Software Engineering diagram June 12, 2014 80
Step 1 - Select Reference Models, Viewpoints, and Tools (6) • Identify Types of Requirement to be Collected − Once the Application Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalising the application-focused requirements for implementing the Target Architecture − Types of requirement • Functional requirements • Non-functional requirements • Assumptions • Constraints • Domain-specific Application Architecture principles • Policies • Standards • Guidelines • Specifications June 12, 2014 81
Step 2 - Develop Application Business Architecture Description • Develop a Baseline Description of the existing Application Architecture, to the extent necessary to support the Target Business Architecture • Scope and level of detail to be defined will depend on the extent to which existing data elements are likely to be carried over into the Target Application Architecture June 12, 2014 82
Step 3 - Develop Target Application Architecture Description • Develop a Target Description for the Application Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Data Architecture • Scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision June 12, 2014 83
Step 4 - Perform Gap Analysis • Verify the architecture models for internal consistency and accuracy • Test architecture models for completeness against requirements • Identify gaps between the baseline and target − Create gap matrix − Identify building blocks to be carried over, classifying as either changed or unchanged − Identify eliminated building blocks − Identify new building blocks − Identify gaps and classify as those that should be developed and those that should be procured June 12, 2014 84
Step 5 - Define Roadmap Components • Create an application business roadmap to prioritise activities over the coming phases • Initial Application Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities and Solutions phase June 12, 2014 85
Step 6 - Resolve Impacts Across the Architecture Landscape • Understand any wider impacts or implications of proposed Application Architecture − Does this Application Architecture create an impact on any pre- existing architectures? − Have recent changes been made that impact on the Application Architecture? − Are there any opportunities to leverage work from this Application Architecture in other areas of the organisation? − Does this Application Architecture impact other projects (including those planned as well as those currently in progress)? − Will this Application Architecture be impacted by other projects (including those planned as well as those currently in progress)? June 12, 2014 86
Step 7 - Conduct Formal Stakeholder Review • Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Application Architecture • Identify any areas where the where the Business and Data Architectures (e.g., business practices) may need to change to cater for changes in the Application Architecture (for example, changes to for ms or procedures, application systems, or database systems) • Identify any constraints on the Technology Architecture (especially the infrastructure) about to be designed June 12, 2014 87
Step 8 - Finalise the Application Architecture • Select standards for each of the building blocks re-using as much as possible from the reference models selected from the Architecture Repository • Document each building block • Conduct final cross-check of overall architecture against business goals • Document reason for building block decisions in the architecture document • Document final requirements traceability report • Document final mapping of the architecture within the Architecture Repository and publish via the Architecture Repository • Finalise all the work products, such as gap analysis results June 12, 2014 88
Step 9 - Create Architecture Definition Document • Document reasons for building block decisions in the Architecture Definition Document • Prepare Application Architecture sections of the Architecture Definition Document June 12, 2014 89
TOGAF Steps For Technical Dimension/View Analysis And Design June 12, 2014 90
Step 1 - Select Reference Models, Viewpoints, and Tools (1) • Review and validate the set of technology principles • Select relevant Technology Architecture resources (reference models, patterns, etc.) from the Architecture Repository • Select relevant Technology Architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Technology Architecture • Identify appropriate tools and techniques to be used for capture, modeling, and analysis, in association with the selected viewpoints June 12, 2014 91
Step 1 - Select Reference Models, Viewpoints, and Tools (2) • Determine Overall Modelling Process − For each viewpoint, select the models needed to support the specific view required, using the selected tool or method − Develop a Technology Architecture • Define a classification of platform services and logical technology components (including standards) • Identify relevant locations where technology is deployed • Carr y out a physical inventor y of deployed technology and abstract up to fit into the classification • Look at application and business requirements for technology • Is the technology in place fit-for-purpose to meet new requirements • Deter mine configuration of the selected technology • Determine impact − Sizing and costing − Capacity planning − Installation/governance/migration impacts June 12, 2014 92
Step 1 - Select Reference Models, Viewpoints, and Tools (3) • Determine Overall Modelling Process − Technology Architecture may be impacted by earlier decisions made around service granularity/level of detail and service boundaries • Performance - Coarse-grained services contain several units of functionality with potentially varying nonfunctional requirements, so platform performance should be considered • Maintainability - If service granularity is too coarse, then introducing changes to that ser vice becomes difficult and impacts the maintenance of the service and the platform on which it is delivered • Location and Latency - Services might interact with each other over remote links and inter-service communication will have in-built latency • Availability - Service invocation is subject to network and/or service failure so high communication availability is an important consideration during service decomposition and defining service granularity − Product selection processes may occur within the Technology Architecture phase where existing products are re-used, incremental capacity is being added, or product selection decisions are a constraint during project initiation − Where product selection deviates from existing standards, involves significant effort, or has wide-ranging impact, this activity should be flagged as an opportunity and addressed through the Opportunities and Solutions phase June 12, 2014 93
Step 1 - Select Reference Models, Viewpoints, and Tools (4) • Identify Required Catalogs of Technology Building Blocks − Catalogs are inventories of the core assets of the business − Catalogs for m the raw material for development of matrices and diagrams and also act as a key resource for portfolio managing business and IT capability − Based on existing technology catalogs and analysis of applications carried out in the Application Architecture phase, collect a list of products in use − If the requirements identified in the Application Architecture are not met by existing products, extend the product list by examining products available on the market that provide the functionality and meet the required standards − If technology standards are currently in place, apply these to the technology component catalog to gain a baseline view of compliance with technology standards − Create catalogs • Technology standards • Technology portfolio June 12, 2014 94
Step 1 - Select Reference Models, Viewpoints, and Tools (5) • Identify Required Matrices − Matrices show the core relationships between related model entities − Create System/Technology matrix June 12, 2014 95
Step 1 - Select Reference Models, Viewpoints, and Tools (6) • Identify Required Diagrams − Diagrams present the Technology Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders • Provide a link between platform requirements and hosting requirements − For major baseline applications or application platforms (where multiple applications are hosted on the same infrastructure stack), produce a stack diagram showing how hardware, operating system, software infrastructure, and packaged applications combine − For each environment, produce a logical diagram of hardware and software infrastructure showing the contents of the environment and logical communications between components • Where available, collect capacity information on the deployed infrastructure − For each environment, produce a physical diagram of communications infrastructure, such as routers, switches, firewalls, and network links • Where available, collect capacity information on the communications infrastructure − Create diagrams • Environments and Locations diagram • Platform Decomposition diagram • Processing diagram • Networked Computing/Hardware diagram • Communications Engineering diagram June 12, 2014 96
Step 1 - Select Reference Models, Viewpoints, and Tools (7) • Identify Types of Requirement to be Collected − Once the Technology Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalising the data- focused requirements for implementing the Target Architecture − Identify types of requirement that must be met by the architecture implementation • Functional requirements • Non-functional requirements • Assumptions • Constraints • Domain-specific Technology Architecture principles • Policies • Standards • Guidelines • Specifications June 12, 2014 97
Step 1 - Select Reference Models, Viewpoints, and Tools (8) • Select Services − Services portfolios are combinations of basic services from the service categories in the Technical Reference Model that do not conflict • Requirements for organisation-specific elements or pre-existing decisions • Pre-existing and unchanging organisational elements • Inherited external environment constraints − For each building block, build up a service description portfolio as a set of non-conflicting ser vices − Set of services must be tested to ensure that the functionality provided meets application requirements June 12, 2014 98
Step 2 - Develop Baseline Business Architecture Description • Develop a Baseline Description of the existing Technology Architecture to the extent necessary to support the Target Technology Architecture • Scope and level of detail to be defined will depend on the extent to which existing business elements are likely to be carried over into the Target Business Architecture • Identify the relevant Technology Architecture building blocks, drawing on any artifacts held in the Architecture Repository • Convert the description of the existing environment into the terms of the organisation’s Foundation Architecture • Set down a list of key questions which can be used later in the development process to measure the effectiveness of the new architecture • Use the models identified within Step 1 of Phase D as a guideline for creating new architecture content to describe the Baseline Architecture June 12, 2014 99
Step 3 - Develop Target Technology Architecture Description • Develop a Target Description for the Technology Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Information Systems Architecture • Scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision • Process in the creation of a broad architectural model of the target system is the conceptualisation of building blocks • Architecture Building Blocks (ABBs) describe the functionality and how they may be implemented without the detail introduced by configuration or detailed design • Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 of Phase D as a guideline for creating new architecture content to describe the Target Architecture June 12, 2014 100
Step 4 - Perform Gap Analysis • Verify the architecture models for internal consistency and accuracy • Note changes to the viewpoint represented in the selected models from the Architecture Repository • Test architecture models for completeness against requirements • Identify gaps between the baseline and target − Create gap matrix − Identify building blocks to be carried over, classifying as either changed or unchanged − Identify eliminated building blocks − Identify new building blocks − Identify gaps and classify as those that should be developed and those that should be procured June 12, 2014 101
Step 5 - Define Roadmap Components • Create a business roadmap to prioritise activities over the coming phases • Initial Technology Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities and Solutions phase June 12, 2014 102
Step 6 - Resolve Impacts Across the Architecture Landscape • Understand any wider impacts or implications of proposed Technology Architecture − Does this Technology Architecture create an impact on any pre- existing architectures? − Have recent changes been made that impact on the Technology Architecture? − Are there any opportunities to leverage work from this Technology Architecture in other areas of the organisation? − Does this Technology Architecture impact other projects (including those planned as well as those currently in progress)? − Will this Technology Architecture be impacted by other projects (including those planned as well as those currently in progress)? June 12, 2014 103
Step 7 - Conduct Formal Stakeholder Review • Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Technology Architecture • Is fit for the purpose of supporting subsequent work in the other architecture domains? • Refine the proposed Technology Architecture but only if necessary June 12, 2014 104
Phase Step 8 - Finalise the Business Architecture • Select standards for each of the building blocks re-using as much as possible from the reference models selected from the Architecture Repository • Document each building block • Conduct final cross-check of overall architecture against business goals • Document reason for building block decisions in the architecture document • Document final requirements traceability report • Document final mapping of the architecture within the Architecture Repository and publish via the Architecture Repository − From the selected building blocks, identify those that might be re-used (working practices, roles, business relationships, job descriptions, etc.), • Finalise all the work products, such as gap analysis results June 12, 2014 105
Step 9 - Create Architecture Definition Document • Document reasons for building block decisions in the Architecture Definition Document • Prepare the business sections of the Architecture Definition Document − Fundamental functionality and attributes - semantic, unambiguous including security capability and manageability − Dependent building blocks with required functionality and named interfaces − Interfaces - chosen set, supplied (APIs, data for mats, protocols, hardware interfaces, standards) − Map to business/organisational entities and policies • Use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture • Route the document for review by relevant stakeholders and incorporate feedback June 12, 2014 106
Summary • The role of solution architecture is to identify answer to a business problem and set of solution options and their components • There will be many potential solutions to a problem with varying suitability • Solution options are derived from a combination of Solution Architecture Dimensions/Views which describe characteristics, features, qualities, requirements and Solution Design Factors, Limitations And Boundaries which delineate limitations • Use structured approach to assist with solution design to create consistency • TOGAF approach to enterprise architecture can be adapted to perform analysis and design for elements of Solution Architecture Dimensions/Views • Solution architecture is part of the continuum from business problem to operable solution
June 12, 2014 108 More Information Alan McSweeney http://ie.linkedin.com/in/alanmcsweeney

More Related Content

PPTX
Solution architecture
byiasaglobal
 
PDF
Solution Architecture – Approach to Rapidly Scoping The Initial Solution Options
byAlan McSweeney
 
PDF
Agile Solution Architecture and Design
byAlan McSweeney
 
PPTX
Solution Architecture and Solution Acquisition
byAlan McSweeney
 
PDF
Solution Architecture Centre Of Excellence
byAlan McSweeney
 
PDF
Digital Transformation And Solution Architecture
byAlan McSweeney
 
PDF
Design Science and Solution Architecture
byAlan McSweeney
 
PDF
Solution Architecture And Solution Security
byAlan McSweeney
 
Solution architecture
byiasaglobal
 
Solution Architecture – Approach to Rapidly Scoping The Initial Solution Options
byAlan McSweeney
 
Agile Solution Architecture and Design
byAlan McSweeney
 
Solution Architecture and Solution Acquisition
byAlan McSweeney
 
Solution Architecture Centre Of Excellence
byAlan McSweeney
 
Digital Transformation And Solution Architecture
byAlan McSweeney
 
Design Science and Solution Architecture
byAlan McSweeney
 
Solution Architecture And Solution Security
byAlan McSweeney
 

What's hot

PDF
Enterprise Architecture
byVikas Grover
 
PDF
Enterprise Architecture Implementation And The Open Group Architecture Framew...
byAlan McSweeney
 
PPTX
A Summary of TOGAF's Architecture Capability Framework
byPaul Sullivan
 
PPT
Solution Architecture Concept Workshop
byAlan McSweeney
 
PDF
Maximising The Value and Benefits of Enterprise Architecture
byAlan McSweeney
 
PPT
Solution Architecture
byFirmansyahIrma1
 
PPTX
Solution Architecture Framework
byFirmansyahIrma1
 
PPTX
Enterprise Architecture, Project Management & Digital Transformation
byRiaz A. Khan, OpenCA, TOGAF
 
PDF
Enterprise Architecture - TOGAF Overview
byMohamed Sami El-Tahawy
 
PDF
Shadow IT And The Failure Of IT Architecture
byAlan McSweeney
 
PPTX
Practical Enterprise Architecture - Introducing CSVLOD EA Model
byAshraf Fouad
 
PDF
Business capability mapping and business architecture
bySatyaIluri
 
PPTX
A new IT Operating Model Emerges
byDavid Favelle
 
PPT
What is the Value of Mature Enterprise Architecture TOGAF
byxavblai
 
PPTX
Togaf 9.2 Introduction
byMohamed Zakarya Abdelgawad
 
PPT
Enterprise Architecture Frameworks
byStephen Lahanas
 
PPTX
Business Architecture Explained
byaaronwilliamson
 
PPTX
Enterprise Architecture for Dummies
bySebastien Juras
 
PDF
IT4IT - Manage the Digital Enterprise.pdf
byitSMF Belgium
 
PPTX
On business capabilities, functions and application features
byJörgen Dahlberg
 
Enterprise Architecture
byVikas Grover
 
Enterprise Architecture Implementation And The Open Group Architecture Framew...
byAlan McSweeney
 
A Summary of TOGAF's Architecture Capability Framework
byPaul Sullivan
 
Solution Architecture Concept Workshop
byAlan McSweeney
 
Maximising The Value and Benefits of Enterprise Architecture
byAlan McSweeney
 
Solution Architecture
byFirmansyahIrma1
 
Solution Architecture Framework
byFirmansyahIrma1
 
Enterprise Architecture, Project Management & Digital Transformation
byRiaz A. Khan, OpenCA, TOGAF
 
Enterprise Architecture - TOGAF Overview
byMohamed Sami El-Tahawy
 
Shadow IT And The Failure Of IT Architecture
byAlan McSweeney
 
Practical Enterprise Architecture - Introducing CSVLOD EA Model
byAshraf Fouad
 
Business capability mapping and business architecture
bySatyaIluri
 
A new IT Operating Model Emerges
byDavid Favelle
 
What is the Value of Mature Enterprise Architecture TOGAF
byxavblai
 
Togaf 9.2 Introduction
byMohamed Zakarya Abdelgawad
 
Enterprise Architecture Frameworks
byStephen Lahanas
 
Business Architecture Explained
byaaronwilliamson
 
Enterprise Architecture for Dummies
bySebastien Juras
 
IT4IT - Manage the Digital Enterprise.pdf
byitSMF Belgium
 
On business capabilities, functions and application features
byJörgen Dahlberg
 

Viewers also liked

PPT
Enterprise Architecture for Dummies - TOGAF 9 enterprise architecture overview
byWinton Winton
 
PPTX
Baseline activities and data management for the African Chicken Genetic Gains...
byILRI
 
PPTX
IT strategy
byKate Koltunova
 
PDF
Integrated Project and Solution Delivery And Business Engagement Model
byAlan McSweeney
 
PPTX
Solution design & procurement approach v1
byDoug Walters
 
PPTX
Integrating IBM Internet of Things Platform and IBM Blockchain
byRahul Gupta
 
PDF
Workshop de Value Proposition Design v1
byDTStartups
 
PPT
Approach To It Strategy And Architecture
byAlan McSweeney
 
PPTX
Enterprise Architecture Overview
byTim Murphy
 
PPTX
Delivering enterprise architecture
byBas van Gils
 
PDF
What Can We Do With The ArchiMate Language?
byIver Band
 
PDF
EAPJ Vol IV July 2017
byDarryl_Carr
 
PPTX
Togaf introduction and core concepts
byPaul Sullivan
 
PDF
14.1 features
byCurtis Tsang
 
PDF
Enterprise Architecture - An Introduction from the Real World
byDaljit Banger
 
PDF
European Interoperability Framework For European Public Services Draft 2.0
byFriso de Jong
 
PPT
Albertin Hp - Unified communication
byeGgov Regione Veneto Veneto
 
PPTX
Integrating architecture and itil
bywweinmeyer79
 
PDF
ArchiMate 3.0: A New Standard for Architecture
byIver Band
 
PPTX
Agile, TOGAF and Enterprise Architecture: Will They Blend?
byDanny Greefhorst
 
Enterprise Architecture for Dummies - TOGAF 9 enterprise architecture overview
byWinton Winton
 
Baseline activities and data management for the African Chicken Genetic Gains...
byILRI
 
IT strategy
byKate Koltunova
 
Integrated Project and Solution Delivery And Business Engagement Model
byAlan McSweeney
 
Solution design & procurement approach v1
byDoug Walters
 
Integrating IBM Internet of Things Platform and IBM Blockchain
byRahul Gupta
 
Workshop de Value Proposition Design v1
byDTStartups
 
Approach To It Strategy And Architecture
byAlan McSweeney
 
Enterprise Architecture Overview
byTim Murphy
 
Delivering enterprise architecture
byBas van Gils
 
What Can We Do With The ArchiMate Language?
byIver Band
 
EAPJ Vol IV July 2017
byDarryl_Carr
 
Togaf introduction and core concepts
byPaul Sullivan
 
14.1 features
byCurtis Tsang
 
Enterprise Architecture - An Introduction from the Real World
byDaljit Banger
 
European Interoperability Framework For European Public Services Draft 2.0
byFriso de Jong
 
Albertin Hp - Unified communication
byeGgov Regione Veneto Veneto
 
Integrating architecture and itil
bywweinmeyer79
 
ArchiMate 3.0: A New Standard for Architecture
byIver Band
 
Agile, TOGAF and Enterprise Architecture: Will They Blend?
byDanny Greefhorst
 

Similar to Structured Approach to Solution Architecture

PPTX
Enterprise Architecture Approach Togaf 9
byPrashant Patade
 
PPT
Unpacking TOGAF's 'Phase B': Business Transformation, Business Architecture a...
byTetradian Consulting
 
PDF
Incorporating A DesignOps Approach Into Solution Architecture
byAlan McSweeney
 
PDF
Data Architecture for Solutions.pdf
byAlan McSweeney
 
PDF
Introduction to Enterprise Architecture and TOGAF 9.1
byiasaglobal
 
PPT
How to Build TOGAF Architectures With System Architect (2).ppt
byStevenShing
 
PDF
An Enterprise Architecture Design Build Approach - Innovate Vancouver.pdf
byInnovate Vancouver
 
PPTX
Solution Design Services An Overview
byBoston Technology Corporation
 
PPT
Stepping-stones of enterprise-architecture: Process and practice in the real...
byTetradian Consulting
 
PPS
Understanding and Applying The Open Group Architecture Framework (TOGAF)
byNathaniel Palmer
 
PPS
Understanding and Applying The Open Group Architecture Framework (TOGAF)
byNathaniel Palmer
 
PDF
SAP Enterprise Architecture Framework.pdf
byLiuLeonardo
 
PPTX
Togaf cc
bycrabypatty
 
PDF
Architecture Series 5-4 Solution Architecture Draft
byFrankie Hsiang
 
PDF
Solution Architecture And User And Customer Experience
byAlan McSweeney
 
PPT
Agile Application Modernization Project
byLawrence Wilkes
 
PDF
Togaf 9.1 architecture
byNarayan Sau
 
PDF
Adam boczek 2015 agile architecture in 10 steps v1.0
byiasaglobal
 
PDF
Adam boczek 2015 agile architecture in 10 steps v1.0
byiasaglobal
 
PPT
TOGAF Complete Slide Deck
bySandeep Sharma IIMK Smart City,IoT,Bigdata,Cloud,BI,DW
 
Enterprise Architecture Approach Togaf 9
byPrashant Patade
 
Unpacking TOGAF's 'Phase B': Business Transformation, Business Architecture a...
byTetradian Consulting
 
Incorporating A DesignOps Approach Into Solution Architecture
byAlan McSweeney
 
Data Architecture for Solutions.pdf
byAlan McSweeney
 
Introduction to Enterprise Architecture and TOGAF 9.1
byiasaglobal
 
How to Build TOGAF Architectures With System Architect (2).ppt
byStevenShing
 
An Enterprise Architecture Design Build Approach - Innovate Vancouver.pdf
byInnovate Vancouver
 
Solution Design Services An Overview
byBoston Technology Corporation
 
Stepping-stones of enterprise-architecture: Process and practice in the real...
byTetradian Consulting
 
Understanding and Applying The Open Group Architecture Framework (TOGAF)
byNathaniel Palmer
 
Understanding and Applying The Open Group Architecture Framework (TOGAF)
byNathaniel Palmer
 
SAP Enterprise Architecture Framework.pdf
byLiuLeonardo
 
Togaf cc
bycrabypatty
 
Architecture Series 5-4 Solution Architecture Draft
byFrankie Hsiang
 
Solution Architecture And User And Customer Experience
byAlan McSweeney
 
Agile Application Modernization Project
byLawrence Wilkes
 
Togaf 9.1 architecture
byNarayan Sau
 
Adam boczek 2015 agile architecture in 10 steps v1.0
byiasaglobal
 
Adam boczek 2015 agile architecture in 10 steps v1.0
byiasaglobal
 
TOGAF Complete Slide Deck
bySandeep Sharma IIMK Smart City,IoT,Bigdata,Cloud,BI,DW
 

More from Alan McSweeney

PDF
The Solution Architect As Product Manager.pdf
byAlan McSweeney
 
PDF
Solution Architecture and Solution Estimation.pdf
byAlan McSweeney
 
PDF
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
byAlan McSweeney
 
PDF
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
byAlan McSweeney
 
PDF
IT Architecture’s Role In Solving Technical Debt.pdf
byAlan McSweeney
 
PDF
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
byAlan McSweeney
 
PDF
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
byAlan McSweeney
 
PDF
Solution Security Architecture
byAlan McSweeney
 
PDF
Solution Architecture And (Robotic) Process Automation Solutions
byAlan McSweeney
 
PDF
Data Profiling, Data Catalogs and Metadata Harmonisation
byAlan McSweeney
 
PDF
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
byAlan McSweeney
 
PDF
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
byAlan McSweeney
 
PPTX
Operational Risk Management Data Validation Architecture
byAlan McSweeney
 
PDF
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
byAlan McSweeney
 
PDF
Ireland 2019 and 2020 Compared - Individual Charts
byAlan McSweeney
 
PDF
Analysis of Irish Mortality Using Public Data Sources 2014-2020
byAlan McSweeney
 
PDF
Ireland – 2019 And 2020 Compared In Data
byAlan McSweeney
 
PDF
Review of Information Technology Function Critical Capability Models
byAlan McSweeney
 
PDF
Critical Review of Open Group IT4IT Reference Architecture
byAlan McSweeney
 
PDF
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
byAlan McSweeney
 
The Solution Architect As Product Manager.pdf
byAlan McSweeney
 
Solution Architecture and Solution Estimation.pdf
byAlan McSweeney
 
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
byAlan McSweeney
 
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
byAlan McSweeney
 
IT Architecture’s Role In Solving Technical Debt.pdf
byAlan McSweeney
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
byAlan McSweeney
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
byAlan McSweeney
 
Solution Security Architecture
byAlan McSweeney
 
Solution Architecture And (Robotic) Process Automation Solutions
byAlan McSweeney
 
Data Profiling, Data Catalogs and Metadata Harmonisation
byAlan McSweeney
 
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
byAlan McSweeney
 
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
byAlan McSweeney
 
Operational Risk Management Data Validation Architecture
byAlan McSweeney
 
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
byAlan McSweeney
 
Ireland 2019 and 2020 Compared - Individual Charts
byAlan McSweeney
 
Analysis of Irish Mortality Using Public Data Sources 2014-2020
byAlan McSweeney
 
Ireland – 2019 And 2020 Compared In Data
byAlan McSweeney
 
Review of Information Technology Function Critical Capability Models
byAlan McSweeney
 
Critical Review of Open Group IT4IT Reference Architecture
byAlan McSweeney
 
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
byAlan McSweeney
 

Recently uploaded

PDF
"When every team does things "right", but together it turns into chaos", Yozh...
byFwdays
 
PDF
Parental Control App for Phones_ The Complete 2026 Guide for Safer, Smarter P...
byRyan Cooper
 
PDF
"Painless Major Upgrade: A Strategy for Updating Large Codebases", Andrii Yat...
byFwdays
 
PPTX
Introduction to Artificial Intelligence (AI).pptx
byammar414783
 
PPTX
TechSprint Inauguration at SJB Institute of Technology held on 18 December 2025
bysuhasspgdg
 
PDF
Transcript: EU regulations for the North American book supply chain - Tech Fo...
byBookNet Canada
 
PDF
Transcript: What Thema can do: Leveraging metadata to support the discoverabi...
byBookNet Canada
 
PDF
When Drones Decide for Themselves_ Inside the Rise of Machine-Led Flight.pdf
byLyra Anderson
 
PPTX
2026 SCORM Troubleshooting Rustici + dominKnow.pptx
byRustici Software
 
PDF
Quick Learn Laravel for Beginner from Zero to Survive
byiDev Semarang
 
PPTX
TechSprint (SJBIT) 2025-26 Hackathon Winners & Awards Ceremony
bysuhasspgdg
 
PDF
EU regulations for the North American book supply chain - Tech Forum 2026
byBookNet Canada
 
PDF
Real-Time AI at Scale Masterclass: Feature Store at Scale
byScyllaDB
 
PDF
Real-Time AI at Scale Masterclass - Challenges of AI at Scale
byScyllaDB
 
PDF
Title Installing Windows, Linux, MacOS.pdf
byGeraldAbadajos
 
PDF
Build Next-Gen Spatial & Sensor Workflows: Secure, Scalable Processing in Sno...
bySafe Software
 
PDF
What Thema can do: Leveraging metadata to support the discoverability of Firs...
byBookNet Canada
 
PDF
How to Design Premium Health (Public Health) PPT Using AI? Top Strategies
byPublic Health Concern Nepal
 
PDF
January 2026 OpenMetadata Community Spotlight - OpenMetadata @ Wix.pdf
byOpenMetadata
 
PDF
Taxonomy Alignment for SDG Tagging - ASHA Case Study
byEnterprise Knowledge
 
"When every team does things "right", but together it turns into chaos", Yozh...
byFwdays
 
Parental Control App for Phones_ The Complete 2026 Guide for Safer, Smarter P...
byRyan Cooper
 
"Painless Major Upgrade: A Strategy for Updating Large Codebases", Andrii Yat...
byFwdays
 
Introduction to Artificial Intelligence (AI).pptx
byammar414783
 
TechSprint Inauguration at SJB Institute of Technology held on 18 December 2025
bysuhasspgdg
 
Transcript: EU regulations for the North American book supply chain - Tech Fo...
byBookNet Canada
 
Transcript: What Thema can do: Leveraging metadata to support the discoverabi...
byBookNet Canada
 
When Drones Decide for Themselves_ Inside the Rise of Machine-Led Flight.pdf
byLyra Anderson
 
2026 SCORM Troubleshooting Rustici + dominKnow.pptx
byRustici Software
 
Quick Learn Laravel for Beginner from Zero to Survive
byiDev Semarang
 
TechSprint (SJBIT) 2025-26 Hackathon Winners & Awards Ceremony
bysuhasspgdg
 
EU regulations for the North American book supply chain - Tech Forum 2026
byBookNet Canada
 
Real-Time AI at Scale Masterclass: Feature Store at Scale
byScyllaDB
 
Real-Time AI at Scale Masterclass - Challenges of AI at Scale
byScyllaDB
 
Title Installing Windows, Linux, MacOS.pdf
byGeraldAbadajos
 
Build Next-Gen Spatial & Sensor Workflows: Secure, Scalable Processing in Sno...
bySafe Software
 
What Thema can do: Leveraging metadata to support the discoverability of Firs...
byBookNet Canada
 
How to Design Premium Health (Public Health) PPT Using AI? Top Strategies
byPublic Health Concern Nepal
 
January 2026 OpenMetadata Community Spotlight - OpenMetadata @ Wix.pdf
byOpenMetadata
 
Taxonomy Alignment for SDG Tagging - ASHA Case Study
byEnterprise Knowledge
 

Structured Approach to Solution Architecture

  • 1.
    Structured Approach to SolutionArchitecture Alan McSweeney
  • 2.
    June 12, 20142 Solution Architecture Is … − Description of the structure, characteristics and behaviour of a solution − The means by which the solution is defined, delivered, managed and operated • A solution is an answer to a business problem that may or may not include a technology component • Solution architecture is concerned with identifying that solution or set of solution options and their components • Generally there are many potential solutions to a problem with varying suitability • All solutions are subject to constraints
  • 3.
    Structured Approach toSolution Architecture • Objective is to ensure consistency in solution architecture design options • Ensure solution addresses all business requirements • Provide checklist to validate solution design options • Design realistic and achievable solutions that meet the business needs • Adapt elements of TOGAF to assist with structured solution design June 12, 2014 3
  • 4.
    June 12, 20144 Solution Architecture In Context Business Objectives Business Operational Model Enterprise Architecture Solution Delivery Management And Operations Business Processes Business Systems Business Strategy Solution Architecture
  • 5.
    Solution Architecture June 12,2014 5 Enterprise Architecture Solution Delivery Business Systems Solution Architecture Takes the requirements for solutions to business needs Ensures compliance with overall systems architecture standards Designs solution options based on requirements subject to standards and other solution constraints that are then implemented
  • 6.
    Solution Architecture June 12,2014 6 Enterprise Architecture Solution Delivery Business Systems Solution Architecture Takes the requirements for solutions to business needs Ensures compliance with overall systems architecture standards Designs solution options based on requirements subject to standards and other solution constraints that are then implemented Goal is to ensures solutions implemented deliver business requirements accurately, efficiently and in a timely manner with no surprises
  • 7.
    June 12, 20147 Solution Architecture In Context Business Strategy Business Objectives Business Operational Model Enterprise Architecture Business Processes Business Systems Solution Architecture Solution Delivery Management And Operations Processes operationalise business objectives Operational model defined to achieve objectives Architecture defines technology framework to run operational model Objectives derived from strategy Systems assist with the operation of processes Solution architecture defines business systems design within enterprise architecture principles Solutions are implemented according to the solution architecture
  • 8.
    June 12, 20148 Solution Does Not Always Consist Solely Of A New Application External Manual Interaction External Manual Interaction External Manual Interaction External Manual Interaction Extended Application (Other Systems) System Component System Component System Component External Component External Component External Component Core Application
  • 9.
    June 12, 20149 Complete View of Solution System Component System Component System Component External Component External Component External Component Automated Process Automated Process Automated Process External Manual Interaction External Manual Interaction Manual Process Manual Process External Manual Interaction External Manual Interaction Manual Process Manual Process
  • 10.
    June 12, 201410 Overall Solution Can Be A Combination of Automated and Manual Processes Automated Process Automated Process Automated Process Manual Process Manual Process Manual Process Manual Process Extended Application Core Application
  • 11.
    June 12, 201411 Solution Design and Implementation Sequence Business Plan Business Need Business Benefits Requirements Definition Process Design Solution Architecture and Design Technical and Detailed Design Implementation You Can Iterate Through These Steps Multiple Times, Refining Detail Each Stage
  • 12.
    June 12, 201412 TOGAF Enterprise Architecture Development and Implementation Process Architecture Change Management Implementation Governance Migration Planning Opportunities and Solutions Technology Architecture Information Systems Architecture Business Architecture Architecture Vision Requirements Management Data Architecture Solutions and Application Architecture Business solutions fit into these areas of the TOGAF framework
  • 13.
    Extended Solution ViewsCoreSolution Views June 12, 2014 13 Solution Architecture Dimensions/Views Solution Architecture Dimensions Business View Functional View Data View Technical View Implementation View Management And Operation
  • 14.
    Core Views andExtended Views • Core Solution Architecture Views – concerned with the kernel of the solution − Business − Functional − Data • Extended Solution Architecture Views – concerned with solution implementation and operation − Technical − Implementation − Management and Operation June 12, 2014 14
  • 15.
    Solution Architecture Dimensions/Views •Dimensions/views are structured sets of requirements, conditions, specifications, provisions, concerns and fundamentals for each dimension of the overall solution • Core dimensions/views define what the solution must do and the results expected • Extended dimensions/views define how the solution must be implemented, managed and operated June 12, 2014 15
  • 16.
    Generalised Solution Architecture Sub-System1 Primary Processor Sub-System 2 Monitor, Audit, Manage Sub-System 3 Control Data Storage and Flow June 12, 2014 16
  • 17.
    Generalised Solution Architecture •Sub-System 1 - performs primary activities, functions that accepts and process inputs, performs transformations and creates and presents outputs, divided into multiple components, implements and actualises processes and activities • Sub-System 2 - monitors, audits, measures, manages performance and activities of the components of sub-system 1 • Sub-System 3 - controls operation and communication and storage of data of an between the components of sub-system 1 and between sub-system 1 and sub-system 2 June 12, 2014 17
  • 18.
    Generalised Solution Architecture •Useful in defining the components of the solution June 12, 2014 18
  • 19.
    Solution Core Views Businessand Process View Processes Enabled and Actualised by Solution and its Functions Data View Range of Data Being Processed/Handled Functionaland ResultsView W hatisGenerated/ Created/ Achieved/ Output June 12, 2014 19
  • 20.
    Solution Core ViewsAnd Their Interrelationships Data View Range of Data Being Processed/ Handled Business and Process View Processes Enabled and Actualised by Solution and its Functions Functions and Results View What is Generated/ Created/Achieved Functions Generate Results Consist of Created or Transformed Data Business Processes Read and Generate Data Processes Are Implemented by Functions that Generate ResultsJune 12, 2014 20
  • 21.
    Business and ProcessView And Decomposition Process 1 Activity 1.1 Activity 1.N Task 1.1.1 Step 1.1.1.1 Step 1.1.1.N Task 1.1.N Task 1.N.1 Task 1.N.N Step 1.N.N.1 Step 1.N.N.N Process N… … … … … … June 12, 2014 21
  • 22.
    Data View AndDecomposition Data Type 1 Data Element 1.1 Data Element 1.N Data Attribute 1.1.1 Data Attribute Value 1.1.1.1 Data Attribute Value 1.1.1.N Data Attribute 1.1.N Data Attribute 1.N.1 Data Attribute 1.N.N Data Attribute Value 1.N.N.1 Data Attribute Value 1.N.N.N Data Type N… … … … … … June 12, 2014 22
  • 23.
    Functions/Results/Outputs View AndDecomposition Output 1 Output Element 1.1 Output Element 1.N Output Attribute 1.1.1 Output Attribute Value 1.1.1.1 Output Attribute Value 1.1.1.N Output Attribute 1.1.N Output Attribute 1.N.1 Output Attribute 1.N.N Output Attribute Value 1.N.N.1 Output Attribute Value 1.N.N.N Output N… … … … … … June 12, 2014 23
  • 24.
    Solution Core Views Businessand Process View Data View Functionaland ResultsView June 12, 2014 24
  • 25.
    June 12, 201425 Dimensions/Views Of Solution Architecture Solution Architecture Dimensions Business View Functional View Technical View Implementation View Data View Context Purpose Characteristics Context Stakeholders Characteristics Context Structure Operation Development Characteristics Context Artefacts/ Products Execution Characteristics Context Entities Roles Interfaces Characteristics Management and Operations View Context Operational Processes Support Operation Characteristics
  • 26.
    June 12, 201426 Business And Process View Topics Business Requirements View Business Context Purpose Characteristics Business Environment Resources, Skills and Experience Products, Services and Value Propositions Value Chain Stakeholders Business Processes Availability, Continuity and Resilience Cost and Affordability Flexibility and Ability to Evolve Ease of Implementation Suitability and Efficiency Performance Reliability Manageability and Ease of Operation Linkage to Other Systems Stability Security Usability
  • 27.
    June 12, 201427 Functional And Results View Topics Functional View Functional Context Purpose Characteristics Related Systems Operational Processes Products, Services and Value Propositions Value Chain Stakeholders Business Processes Availability, Continuity and Resilience Cost and Affordability Flexibility and Ability to Evolve Ease of Implementation Suitability and Efficiency Performance Reliability Manageability and Ease of Operation Linkage to Other Systems Scalability Security Usability
  • 28.
    June 12, 201428 Technical View Topics Technical View Technical Context Technical Configuration Operation Implementation Environment and Tools Development Approach Language Framework/Systems Availability, Continuity and Resilience Cost and Affordability Flexibility and Ability to Evolve Ease of Implementation Suitability and Efficiency Performance Reliability Manageability and Ease of Operation Linkage to Other Systems Scalability Security Usability Innovation and Growth Characteristics System Structure Hardware Infrastructure Software Infrastructure System Operation System Management and Administration System Lifecycle System Change and Growth Data Infrastructure Integration Infrastructure
  • 29.
    June 12, 201429 Implementation View Topics Technical View Implementation Context Implementation Artefacts/Products Execution Implementation Environment Development Approach Language Framework/Systems Availability, Continuity and Resilience Cost and Affordability Flexibility and Ability to Evolve Ease of Implementation Suitability and Efficiency Performance Reliability Manageability and Ease of Operation Linkage to Other Systems Scalability Security Usability Characteristics Solution Elements Delivered Components Collateral Governance Implementation Organisation Supporting Material Implementation Process Delivery Plan Configuration Financial Management Solution Validation
  • 30.
    Data View Topics June12, 2014 30 Data View Data Context Entitles Interfaces Data Model Reference and Master Data Availability, Continuity and Resilience Cost and Affordability Flexibility and Ability to Evolve Ease of Implementation Suitability and Efficiency Performance Reliability Manageability and Ease of Operation Storage and Capacity Scalability Security Usability Analysis and Reporting Characteristics Data Entities Relationships Access Rights and Permissions Sources and Targets Transformations Reporting Analysis Data Types Data Types Conversion/Migration Data Volumes Data Velocity Data Variety
  • 31.
    Management and OperationView Topics June 12, 2014 31 Management and Operation View Management and Operation Context Operational Processes Support Service Management Framework Operational Framework Transition Business Readiness Availability, Continuity and Resilience Cost and Affordability Flexibility and Ability to Evolve Ease of Implementation Suitability and Efficiency Performance Reliability Manageability and Ease of Operation Linkage to Other Systems Scalability Security Usability Operation Characteristics Capacity Availability, Continuity and Resilience Change Support Model Support Processes Deployment/ Maintenance Structure Deployment/ Maintenance Process Service Level Service Desk Service Management Processes Configuration Release and Deployment Incident Problem Organisational Change Steady State Alerting and Monitoring Backup and Recovery Service Level Management
  • 32.
    June 12, 201432 Mapping TOGAF Enterprise Architecture Process To Solution Architecture Definition TOGAF Phase D: Technology Architecture TOGAF Phase C: Information Systems Architecture TOGAF Phase B: Business Architecture TOGAF Phase C1: Data Architecture TOGAF Phase C2: Solutions and Application Architecture Business View Data View Technical View Functional View Implementation View Management and Operation View SolutionArchitecture Views/Dimensions
  • 33.
    Extended Solution Dimensions Core Solution Dimensions TOGAF Solution Dimensions Solution Dimensions Business View DataView Technical View Functional View Implementation View Management and Operation View June 12, 2014 33
  • 34.
    Solution Architecture DesignBoundaries June 12, 2014 34 Enterprise Architecture Defines the Solution Technical Boundary Business View Data View Technical View Functional View Implementation View Management and Operation View Solution Architecture Solution Architecture Defines the Solution Scope Boundary
  • 35.
    Designing The Solution •Overall solution design is constrained both by enterprise architecture and solution architecture views • There are many possible solution options to a business requirement or problem − Solution can be manual or automated to a lesser or greater extent − Solution can involve enhancing existing system and/or process or developing new system and/or process − These constraints form boundaries to the solution design June 12, 2014 35
  • 36.
    Solution Design Factors,Limitations And Boundaries • Core Constraints – concerned with essential solution attributes − Enterprise Architecture − Solution Architecture Views/Dimensions − Existing or New System − Degree of Automation • Extended Constraints – concerned with solution implementation and operation − Resources − Finance − Timescale − Expected Life June 12, 2014 36
  • 37.
    Core Solution DesignFactors, Limitations And Boundaries Degree of Automation of Solution Solution Architecture View Design Constraints Enterprise Architecture Constraints Use Existing System or Create New System Range of Solution Options June 12, 2014 37
  • 38.
    Extended Solution DesignFactors, Limitations And Boundaries • Other implementation and operation-related constraints that will affect the solution options: − Resources and their availability − Timescale and urgency of solution − Cost and available finance − Likely duration of solution June 12, 2014 38
  • 39.
    Different Solution DesignsAnd Options Can Comply With Constraints Differently June 12, 2014 39
  • 40.
    Comparison Of PossibleOptions For One Solution June 12, 2014 40
  • 41.
    Solution Architecture Dimensions/ViewsAnd Solution Design Factors, Limitations And Boundaries Extended Views Core Views June 12, 2014 41 Solution Design Factors, Limitations And Boundaries Solution Architecture Dimensions/Views
  • 42.
    Solution Architecture Dimensions/ViewsAnd Solution Design Factors, Limitations And Boundaries Enterprise Architecture Technical View Implementation View Management and Operation View Business View Data View Functional View Degree of Automation Finance Timescale Existing or New System Resources Expected Life June 12, 2014 42
  • 43.
    June 12, 201443 Mapping TOGAF Enterprise Architecture Process To Solution Architecture Definition TOGAF Phase D: Technology Architecture TOGAF Phase C: Information Systems Architecture TOGAF Phase B: Business Architecture TOGAF Phase C1: Data Architecture TOGAF Phase C2: Solutions and Application Architecture Business View Data View Technical View Functional View Implementation View Management and Operation View SolutionArchitecture Views/Dimensions
  • 44.
    Steps For TOGAFView/Dimension Analysis And Development • Common set of steps across four solution architecture views/dimensions common to TOGAF 1. Select reference models, viewpoints, and tools 2. Develop baseline view/dimension architecture description 3. Develop target view/dimension architecture description 4. Perform gap analysis 5. Define roadmap components 6. Resolve impacts across the architecture landscape 7. Conduct formal stakeholder review 8. Finalise the view/dimension architecture 9. Create view/dimension architecture definition document June 12, 2014 44
  • 45.
    Steps For TOGAFView/Dimension Analysis And Development • Use TOGAF framework to give a rigour to the solution architecture analysis and design • Modify as required to suit the depth of the analysis • Can iterate through the steps with varying levels of analysis as solution is articulated June 12, 2014 45
  • 46.
    TOGAF Steps ForBusiness Dimension/View Analysis And Design June 12, 2014 46
  • 47.
    Step 1 -Select Reference Models, Viewpoints, and Tools (1) • Select relevant Business Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, and the stakeholders and concerns • Select relevant Business Architecture viewpoints (e.g., operations, management, financial); i.e. those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Business Architecture • Identify appropriate tools and techniques to be used for capture, modeling, and analysis • Determine Overall Modelling Process − For each viewpoint, select the models needed to support the specific view required, using the selected tool or method − Ensure that all stakeholder concerns are covered − Identify the key business functions within the scope of the architecture, and maps those functions onto the business units within the organisation − Breakdown business-level functions across actors and business units to allow the actors in a function to be identified and permits a breakdown into services supporting/delivering that functional capability − Breakdown a function or business service through process modeling to allow the elements of the process to be identified and permit the identification of lower-level business services or functions June 12, 2014 47
  • 48.
    Step 1 -Select Reference Models, Viewpoints, and Tools (2) • Identify Required Service Granularity Level, Boundaries, and Contracts − Business Architecture phase therefore needs to identify which components of the architecture are functions and which are services • Business services are specific functions that have explicit, defined boundaries that are explicitly governed • Services are distinguished from functions through the explicit definition of a service contract • A service contract covers the business/functional interface and also the technology/data interface − Business Architecture will define the service contract at the business/functional level, which will be expanded on in the Application and Technology Architecture phases − Granularity of business services should be determined according to the business drivers, goals, objectives, and measures for this area of the business June 12, 2014 48
  • 49.
    Step 1 -Select Reference Models, Viewpoints, and Tools (3) • Identify Required Catalogs of Business Building Blocks − Catalogs capture inventories of the core assets of the business − Catalogs form the raw material for development of matrices and views and also act as a key resource for portfolio managing business and IT capability − Develop some or all of the following catalogs: • Organisation/Actor catalog • Driver/Goal/Objective catalog • Role catalog • Business Service/Function catalog • Location catalog • Process/Event/Control/Product catalog • Contract/Measure catalog June 12, 2014 49
  • 50.
    Step 1 -Select Reference Models, Viewpoints, and Tools (4) • Identify Required Matrices − Matrices show the core relationships between related model entities − Matrices form the raw material for development of views and also act as a key resource for impact assessment, carried out as a part of gap analysis • Business interaction matrix - showing dependency and communication between business units and actors • Actor/role matrix - showing the roles undertaken by each actor June 12, 2014 50
  • 51.
    Step 1 -Select Reference Models, Viewpoints, and Tools (5) • Identify Required Diagrams − Diagrams present the Business Architecture information from a set of different perspectives according to the requirements of the stakeholders • Business Footprint diagram • Business Service/Information diagram • Functional Decomposition diagram • Goal/Objective/Service diagram • Use-case diagram • Organisation Decomposition diagram • Process Flow diagram • Events diagram June 12, 2014 51
  • 52.
    Step 1 -Select Reference Models, Viewpoints, and Tools (6) • Identify Types of Requirement to be Collected − Once the Business Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalising the business- focused requirements for implementing the Target Architecture − Requirements may relate to the business domain, or may provide requirements input into the Data, Application, and Technology Architectures − Types of requirement • Functional requirements • Non-functional requirements • Assumptions • Constraints • Domain-specific Business Architecture principles • Policies • Standards • Guidelines • Specifications June 12, 2014 52
  • 53.
    Step 2 -Develop Baseline Business Architecture Description • Develop a Baseline Description of the existing Business Architecture, to the extent necessary to support the Target Business Architecture • Scope and level of detail to be defined will depend on the extent to which existing business elements are likely to be carried over into the Target Business Architecture June 12, 2014 53
  • 54.
    Step 3 -Develop Target Business Architecture Description • Develop a Target Description for the Business Architecture, to the extent necessary to support the Architecture Vision • Scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision June 12, 2014 54
  • 55.
    Step 4 -Perform Gap Analysis • Verify the architecture models for internal consistency and accuracy • Perform trade-off analysis to resolve conflicts (if any) among the different views • Validate that the models support the principles, objectives, and constraints • Test architecture models for completeness against requirements • Identify gaps between the baseline and target June 12, 2014 55
  • 56.
    Step 5 -Define Roadmap Components • Create a business roadmap to prioritise activities over the coming phases • Initial Business Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities and Solutions phase June 12, 2014 56
  • 57.
    Step 6 -Resolve Impacts Across the Architecture Landscape • Understand any wider impacts or implications of proposed Business Architecture − Does this Business Architecture create an impact on any pre- existing architectures? − Have recent changes been made that impact on the Business Architecture? − Are there any opportunities to leverage work from this Business Architecture in other areas of the organisation? − Does this Business Architecture impact other projects (including those planned as well as those currently in progress)? − Will this Business Architecture be impacted by other projects (including those planned as well as those currently in progress)? June 12, 2014 57
  • 58.
    Step 7 -Conduct Formal Stakeholder Review • Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Business Architecture • Is fit for the purpose of supporting subsequent work in the other architecture domains? • Refine the proposed Business Architecture but only if necessary June 12, 2014 58
  • 59.
    Step 8 -Finalise the Business Architecture • Select standards for each of the building blocks re-using as much as possible from the reference models selected from the Architecture Repository • Document each building block • Conduct final cross-check of overall architecture against business goals • Document reason for building block decisions in the architecture document • Document final requirements traceability report • Document final mapping of the architecture within the Architecture Repository and publish via the Architecture Repository • Finalise all the work products, such as gap analysis results June 12, 2014 59
  • 60.
    Step 9 -Create Architecture Definition Document • Document reasons for building block decisions in the Architecture Definition Document • Prepare the business sections of the Architecture Definition Document − A business footprint (a high-level description of the people and locations involved with key business functions) − A detailed description of business functions and their information needs − A management footprint (showing span of control and accountability) − Standards, rules, and guidelines showing working practices, legislation, financial measures, etc. − A skills matrix and set of job descriptions June 12, 2014 60
  • 61.
    TOGAF Steps ForData Dimension/View Analysis And Design June 12, 2014 61
  • 62.
    Step 1 -Select Reference Models, Viewpoints, and Tools (1) • Select relevant Data Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, and the stakeholders and concerns • Select relevant Data Architecture viewpoints (e.g., operations, management, financial); i.e. those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Data Architecture • Identify appropriate tools and techniques to be used for data capture, modeling, and analysis • Determine Overall Modelling Process − For each viewpoint, select the models needed to support the specific view required, using the selected tool or method − Ensure that all stakeholder concerns are covered − Collect data-related models from existing Business Architecture and Application Architecture materials − Rationalise data requirements and align with any existing organisation data catalogs and models - this allows the development of a data inventor y and entity relationship − Update and develop matrices across the architecture by relating data to business service, business function, access rights, and application − Elaborate Data Architecture views by examining how data is created, distributed, migrated, secured, and archived June 12, 2014 62
  • 63.
    Step 1 -Select Reference Models, Viewpoints, and Tools (2) • Identify Required Catalogs of Data Building Blocks − Capture organisation’s data inventory as a catalog within the Architecture Repository − Create an inventory of the data needed to be in place to support the Architecture Vision − Refer to the Business Service/Information diagram created during the Business Architecture phase, showing the key data entities required by the main business services − Consolidate the data requirements in a single location − Refine the data inventory to achieve semantic consistency and to remove gaps and overlaps June 12, 2014 63
  • 64.
    Step 1 -Select Reference Models, Viewpoints, and Tools (3) • Identify Required Matrices − Matrices show the core relationships between related model entities − Form the raw material for development of diagrams and also act as a key resource for impact assessment − Understand how data is created, maintained, transformed, and passed to other applications, or used by other applications − Note gaps such as entities that never seem to be created by an application or data created but never used − Update and refine the architectural diagrams of how data relates to other aspects of the architecture − Suggested matrices • Data Entity/Business Function (showing which data supports which functions and which business function owns which data) • Business Service/Information (developed during the Business Architecture phase) • System/Data (developed across the Application Architecture and Data Architecture phases) June 12, 2014 64
  • 65.
    Step 1 -Select Reference Models, Viewpoints, and Tools (4) • Identify Required Diagrams − Diagrams present the Data Architecture information from a set of different perspectives according to the requirements of the stakeholders − Once the data entities have been refined, a diagram of the relationships between entities and their attributes can be produced • Class diagram • Data Dissemination diagram • Data Lifecycle diagram • Data Security diagram • Data Migration diagram • Class Hierarchy diagram June 12, 2014 65
  • 66.
    Step 1 -Select Reference Models, Viewpoints, and Tools (5) • Identify Types of Requirement to be Collected − Once the Data Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalising the business-focused requirements for implementing the Target Architecture − Types of requirement • Functional requirements • Non-functional requirements • Assumptions • Constraints • Domain-specific Data Architecture principles • Policies • Standards • Guidelines • Specifications June 12, 2014 66
  • 67.
    Step 2 -Develop Data Business Architecture Description • Develop a Baseline Description of the existing Data Architecture, to the extent necessary to support the Target Business Architecture • Scope and level of detail to be defined will depend on the extent to which existing data elements are likely to be carried over into the Target Data Architecture June 12, 2014 67
  • 68.
    Step 3 -Develop Target Business Architecture Description • Develop a Target Description for the Data Architecture, to the extent necessary to support the Architecture Vision • Scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision June 12, 2014 68
  • 69.
    Step 4 -Perform Gap Analysis • Verify the architecture models for internal consistency and accuracy • Perform trade-off analysis to resolve conflicts (if any) among the different views • Validate that the models support the principles, objectives, and constraints • Test architecture models for completeness against requirements • Identify gaps between the baseline and target − Create gap matrix − Identify building blocks to be carried over, classifying as either changed or unchanged − Identify eliminated building blocks − Identify new building blocks − Identify gaps and classify as those that should be developed and those that should be procured June 12, 2014 69
  • 70.
    Step 5 -Define Roadmap Components • Create a data business roadmap to prioritise activities over the coming phases • Initial Data Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities and Solutions phase June 12, 2014 70
  • 71.
    Step 6 -Resolve Impacts Across the Architecture Landscape • Understand any wider impacts or implications of proposed Data Architecture − Does this Data Architecture create an impact on any pre-existing architectures? − Have recent changes been made that impact on the Data Architecture? − Are there any opportunities to leverage work from this Data Architecture in other areas of the organisation? − Does this Data Architecture impact other projects (including those planned as well as those currently in progress)? − Will this Data Architecture be impacted by other projects (including those planned as well as those currently in progress)? June 12, 2014 71
  • 72.
    Step 7 -Conduct Formal Stakeholder Review • Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Data Architecture • Is fit for the purpose of supporting subsequent work in the other architecture domains? • Identify any areas where the Solution and Application Architecture may need to change to cater for changes in the Data Architecture (or to identify constraints on the Solution and Application Architecture about to be designed) • Refine the proposed Data Architecture but only if necessary June 12, 2014 72
  • 73.
    Step 8 -Finalise the Data Architecture • Select standards for each of the building blocks re-using as much as possible from the reference models selected from the Architecture Repository • Document each building block • Conduct final cross-check of overall architecture against business goals • Document reason for building block decisions in the architecture document • Document final requirements traceability report • Document final mapping of the architecture within the Architecture Repository and publish via the Architecture Repository • Finalise all the work products, such as gap analysis results June 12, 2014 73
  • 74.
    Step 9 -Create Architecture Definition Document • Document reasons for building block decisions in the Architecture Definition Document • Prepare Data Architecture sections of the Architecture Definition Document − Business data model − Logical data model − Data management process model − Data Entity/Business Function matrix − Data interoperability requirements June 12, 2014 74
  • 75.
    TOGAF Steps ForFunctional Dimension/View Analysis And Design June 12, 2014 75
  • 76.
    Step 1 -Select Reference Models, Viewpoints, and Tools (1) • Review and validate (or generate, if necessary) the set of application principles − Form part of an overarching set of architecture principles • Select relevant Application Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, and the stakeholders and concerns • Select relevant Application Architecture viewpoints (for example, stakeholders of the applications, viewpoints relevant to functional and individual users of applications, etc.); i.e. those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Application Architecture • Identify appropriate tools and techniques to be used for data capture, modeling, and analysis • Consider using platform-independent descriptions of business logic − Isolate the business logic from changes to the underlying platform and implementation technology June 12, 2014 76
  • 77.
    Step 1 -Select Reference Models, Viewpoints, and Tools (2) • Determine Overall Modeling Process − For each viewpoint, select the models needed to support the specific view required, using the selected tool or method − Ensure that all stakeholder concerns are covered − Process steps • Understand the list of applications or application components that are required, based on the baseline Application Portfolio, what the requirements are, and the business architecture scope • Identify logical applications and the most appropriate physical applications • Develop matrices across the architecture by relating applications to business service, business function, data, process, etc. • Elaborate a set of Application Architecture views by examining how the application will function, capturing integration, migration, development, and operational concerns − The level of granularity should be sufficient to enable identification of gaps and the scope of candidate work packages June 12, 2014 77
  • 78.
    Step 1 -Select Reference Models, Viewpoints, and Tools (3) • Identify Required Catalogs of Application Building Blocks − Capture organisation’s Application Portfolio as a catalog within the Architecture Repository • Application Portfolio catalog • Interface catalog June 12, 2014 78
  • 79.
    Step 1 -Select Reference Models, Viewpoints, and Tools (4) • Identify Required Matrices − Matrices show the core relationships between related model entities − Form the raw material for development of diagrams and also act as a key resource for impact assessment − Once the baseline Application Portfolio has been assembled, it is necessary to map the applications to their purpose in supporting the business • Initial mapping should focus on business services within the Business Architecture − Once applications are mapped to business services, it will also be possible to make associations from applications to data • Refer to Phase C1: Information Systems Architectures - Data Architecture − Identify user and organisational dependencies on applications − Specifically consider the operational support business unit − Update and refine the architectural diagrams of how data relates to other aspects of the architecture − Examine application dependencies on shared operations capabilities and produce a diagram on how each application is effectively operated and managed − Suggested matrices • System/Business Unit matrix • Role/System matrix • Application Interaction matrix • System/Function matrix June 12, 2014 79
  • 80.
    Step 1 -Select Reference Models, Viewpoints, and Tools (5) • Identify Required Diagrams − Diagrams present the Application Architecture information from a set of different perspectives according to the requirements of the stakeholders − Once the desired functionality of an application is known, it is necessary to perform an internal assessment of how the application should be best structured to meet its requirements • Packaged applications − Numbers of configuration options, add-on modules • Custom developed applications − Identify the high-level structure of the application in terms of modules or sub- systems as a foundation to organise design activity − Once the application entities have been refined, a diagram of the relationships between entities and their attributes can be produced • Application Communication diagram • Application and User Location diagram • Enterprise Manageability diagram • Process/System Realisation diagram • Application Migration diagram • Software Distribution diagram • Software Engineering diagram June 12, 2014 80
  • 81.
    Step 1 -Select Reference Models, Viewpoints, and Tools (6) • Identify Types of Requirement to be Collected − Once the Application Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalising the application-focused requirements for implementing the Target Architecture − Types of requirement • Functional requirements • Non-functional requirements • Assumptions • Constraints • Domain-specific Application Architecture principles • Policies • Standards • Guidelines • Specifications June 12, 2014 81
  • 82.
    Step 2 -Develop Application Business Architecture Description • Develop a Baseline Description of the existing Application Architecture, to the extent necessary to support the Target Business Architecture • Scope and level of detail to be defined will depend on the extent to which existing data elements are likely to be carried over into the Target Application Architecture June 12, 2014 82
  • 83.
    Step 3 -Develop Target Application Architecture Description • Develop a Target Description for the Application Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Data Architecture • Scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision June 12, 2014 83
  • 84.
    Step 4 -Perform Gap Analysis • Verify the architecture models for internal consistency and accuracy • Test architecture models for completeness against requirements • Identify gaps between the baseline and target − Create gap matrix − Identify building blocks to be carried over, classifying as either changed or unchanged − Identify eliminated building blocks − Identify new building blocks − Identify gaps and classify as those that should be developed and those that should be procured June 12, 2014 84
  • 85.
    Step 5 -Define Roadmap Components • Create an application business roadmap to prioritise activities over the coming phases • Initial Application Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities and Solutions phase June 12, 2014 85
  • 86.
    Step 6 -Resolve Impacts Across the Architecture Landscape • Understand any wider impacts or implications of proposed Application Architecture − Does this Application Architecture create an impact on any pre- existing architectures? − Have recent changes been made that impact on the Application Architecture? − Are there any opportunities to leverage work from this Application Architecture in other areas of the organisation? − Does this Application Architecture impact other projects (including those planned as well as those currently in progress)? − Will this Application Architecture be impacted by other projects (including those planned as well as those currently in progress)? June 12, 2014 86
  • 87.
    Step 7 -Conduct Formal Stakeholder Review • Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Application Architecture • Identify any areas where the where the Business and Data Architectures (e.g., business practices) may need to change to cater for changes in the Application Architecture (for example, changes to for ms or procedures, application systems, or database systems) • Identify any constraints on the Technology Architecture (especially the infrastructure) about to be designed June 12, 2014 87
  • 88.
    Step 8 -Finalise the Application Architecture • Select standards for each of the building blocks re-using as much as possible from the reference models selected from the Architecture Repository • Document each building block • Conduct final cross-check of overall architecture against business goals • Document reason for building block decisions in the architecture document • Document final requirements traceability report • Document final mapping of the architecture within the Architecture Repository and publish via the Architecture Repository • Finalise all the work products, such as gap analysis results June 12, 2014 88
  • 89.
    Step 9 -Create Architecture Definition Document • Document reasons for building block decisions in the Architecture Definition Document • Prepare Application Architecture sections of the Architecture Definition Document June 12, 2014 89
  • 90.
    TOGAF Steps ForTechnical Dimension/View Analysis And Design June 12, 2014 90
  • 91.
    Step 1 -Select Reference Models, Viewpoints, and Tools (1) • Review and validate the set of technology principles • Select relevant Technology Architecture resources (reference models, patterns, etc.) from the Architecture Repository • Select relevant Technology Architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Technology Architecture • Identify appropriate tools and techniques to be used for capture, modeling, and analysis, in association with the selected viewpoints June 12, 2014 91
  • 92.
    Step 1 -Select Reference Models, Viewpoints, and Tools (2) • Determine Overall Modelling Process − For each viewpoint, select the models needed to support the specific view required, using the selected tool or method − Develop a Technology Architecture • Define a classification of platform services and logical technology components (including standards) • Identify relevant locations where technology is deployed • Carr y out a physical inventor y of deployed technology and abstract up to fit into the classification • Look at application and business requirements for technology • Is the technology in place fit-for-purpose to meet new requirements • Deter mine configuration of the selected technology • Determine impact − Sizing and costing − Capacity planning − Installation/governance/migration impacts June 12, 2014 92
  • 93.
    Step 1 -Select Reference Models, Viewpoints, and Tools (3) • Determine Overall Modelling Process − Technology Architecture may be impacted by earlier decisions made around service granularity/level of detail and service boundaries • Performance - Coarse-grained services contain several units of functionality with potentially varying nonfunctional requirements, so platform performance should be considered • Maintainability - If service granularity is too coarse, then introducing changes to that ser vice becomes difficult and impacts the maintenance of the service and the platform on which it is delivered • Location and Latency - Services might interact with each other over remote links and inter-service communication will have in-built latency • Availability - Service invocation is subject to network and/or service failure so high communication availability is an important consideration during service decomposition and defining service granularity − Product selection processes may occur within the Technology Architecture phase where existing products are re-used, incremental capacity is being added, or product selection decisions are a constraint during project initiation − Where product selection deviates from existing standards, involves significant effort, or has wide-ranging impact, this activity should be flagged as an opportunity and addressed through the Opportunities and Solutions phase June 12, 2014 93
  • 94.
    Step 1 -Select Reference Models, Viewpoints, and Tools (4) • Identify Required Catalogs of Technology Building Blocks − Catalogs are inventories of the core assets of the business − Catalogs for m the raw material for development of matrices and diagrams and also act as a key resource for portfolio managing business and IT capability − Based on existing technology catalogs and analysis of applications carried out in the Application Architecture phase, collect a list of products in use − If the requirements identified in the Application Architecture are not met by existing products, extend the product list by examining products available on the market that provide the functionality and meet the required standards − If technology standards are currently in place, apply these to the technology component catalog to gain a baseline view of compliance with technology standards − Create catalogs • Technology standards • Technology portfolio June 12, 2014 94
  • 95.
    Step 1 -Select Reference Models, Viewpoints, and Tools (5) • Identify Required Matrices − Matrices show the core relationships between related model entities − Create System/Technology matrix June 12, 2014 95
  • 96.
    Step 1 -Select Reference Models, Viewpoints, and Tools (6) • Identify Required Diagrams − Diagrams present the Technology Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders • Provide a link between platform requirements and hosting requirements − For major baseline applications or application platforms (where multiple applications are hosted on the same infrastructure stack), produce a stack diagram showing how hardware, operating system, software infrastructure, and packaged applications combine − For each environment, produce a logical diagram of hardware and software infrastructure showing the contents of the environment and logical communications between components • Where available, collect capacity information on the deployed infrastructure − For each environment, produce a physical diagram of communications infrastructure, such as routers, switches, firewalls, and network links • Where available, collect capacity information on the communications infrastructure − Create diagrams • Environments and Locations diagram • Platform Decomposition diagram • Processing diagram • Networked Computing/Hardware diagram • Communications Engineering diagram June 12, 2014 96
  • 97.
    Step 1 -Select Reference Models, Viewpoints, and Tools (7) • Identify Types of Requirement to be Collected − Once the Technology Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalising the data- focused requirements for implementing the Target Architecture − Identify types of requirement that must be met by the architecture implementation • Functional requirements • Non-functional requirements • Assumptions • Constraints • Domain-specific Technology Architecture principles • Policies • Standards • Guidelines • Specifications June 12, 2014 97
  • 98.
    Step 1 -Select Reference Models, Viewpoints, and Tools (8) • Select Services − Services portfolios are combinations of basic services from the service categories in the Technical Reference Model that do not conflict • Requirements for organisation-specific elements or pre-existing decisions • Pre-existing and unchanging organisational elements • Inherited external environment constraints − For each building block, build up a service description portfolio as a set of non-conflicting ser vices − Set of services must be tested to ensure that the functionality provided meets application requirements June 12, 2014 98
  • 99.
    Step 2 -Develop Baseline Business Architecture Description • Develop a Baseline Description of the existing Technology Architecture to the extent necessary to support the Target Technology Architecture • Scope and level of detail to be defined will depend on the extent to which existing business elements are likely to be carried over into the Target Business Architecture • Identify the relevant Technology Architecture building blocks, drawing on any artifacts held in the Architecture Repository • Convert the description of the existing environment into the terms of the organisation’s Foundation Architecture • Set down a list of key questions which can be used later in the development process to measure the effectiveness of the new architecture • Use the models identified within Step 1 of Phase D as a guideline for creating new architecture content to describe the Baseline Architecture June 12, 2014 99
  • 100.
    Step 3 -Develop Target Technology Architecture Description • Develop a Target Description for the Technology Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Information Systems Architecture • Scope and level of detail to be defined will depend on the relevance of the business elements to attaining the Target Architecture Vision • Process in the creation of a broad architectural model of the target system is the conceptualisation of building blocks • Architecture Building Blocks (ABBs) describe the functionality and how they may be implemented without the detail introduced by configuration or detailed design • Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 of Phase D as a guideline for creating new architecture content to describe the Target Architecture June 12, 2014 100
  • 101.
    Step 4 -Perform Gap Analysis • Verify the architecture models for internal consistency and accuracy • Note changes to the viewpoint represented in the selected models from the Architecture Repository • Test architecture models for completeness against requirements • Identify gaps between the baseline and target − Create gap matrix − Identify building blocks to be carried over, classifying as either changed or unchanged − Identify eliminated building blocks − Identify new building blocks − Identify gaps and classify as those that should be developed and those that should be procured June 12, 2014 101
  • 102.
    Step 5 -Define Roadmap Components • Create a business roadmap to prioritise activities over the coming phases • Initial Technology Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities and Solutions phase June 12, 2014 102
  • 103.
    Step 6 -Resolve Impacts Across the Architecture Landscape • Understand any wider impacts or implications of proposed Technology Architecture − Does this Technology Architecture create an impact on any pre- existing architectures? − Have recent changes been made that impact on the Technology Architecture? − Are there any opportunities to leverage work from this Technology Architecture in other areas of the organisation? − Does this Technology Architecture impact other projects (including those planned as well as those currently in progress)? − Will this Technology Architecture be impacted by other projects (including those planned as well as those currently in progress)? June 12, 2014 103
  • 104.
    Step 7 -Conduct Formal Stakeholder Review • Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Technology Architecture • Is fit for the purpose of supporting subsequent work in the other architecture domains? • Refine the proposed Technology Architecture but only if necessary June 12, 2014 104
  • 105.
    Phase Step 8- Finalise the Business Architecture • Select standards for each of the building blocks re-using as much as possible from the reference models selected from the Architecture Repository • Document each building block • Conduct final cross-check of overall architecture against business goals • Document reason for building block decisions in the architecture document • Document final requirements traceability report • Document final mapping of the architecture within the Architecture Repository and publish via the Architecture Repository − From the selected building blocks, identify those that might be re-used (working practices, roles, business relationships, job descriptions, etc.), • Finalise all the work products, such as gap analysis results June 12, 2014 105
  • 106.
    Step 9 -Create Architecture Definition Document • Document reasons for building block decisions in the Architecture Definition Document • Prepare the business sections of the Architecture Definition Document − Fundamental functionality and attributes - semantic, unambiguous including security capability and manageability − Dependent building blocks with required functionality and named interfaces − Interfaces - chosen set, supplied (APIs, data for mats, protocols, hardware interfaces, standards) − Map to business/organisational entities and policies • Use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture • Route the document for review by relevant stakeholders and incorporate feedback June 12, 2014 106
  • 107.
    Summary • The roleof solution architecture is to identify answer to a business problem and set of solution options and their components • There will be many potential solutions to a problem with varying suitability • Solution options are derived from a combination of Solution Architecture Dimensions/Views which describe characteristics, features, qualities, requirements and Solution Design Factors, Limitations And Boundaries which delineate limitations • Use structured approach to assist with solution design to create consistency • TOGAF approach to enterprise architecture can be adapted to perform analysis and design for elements of Solution Architecture Dimensions/Views • Solution architecture is part of the continuum from business problem to operable solution
  • 108.
    June 12, 2014108 More Information Alan McSweeney http://ie.linkedin.com/in/alanmcsweeney