See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/333247901
Structured Approach to Solution Architecture
Presentation · May 2019
DOI: 10.13140/RG.2.2.31068.85122
CITATIONS READS
0 1,933
1 author:
Alan McSweeney
Eirgrid
96 PUBLICATIONS 25 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
IT Management View project
Information Technology Solution Sourcing and Supplier Governance View project
All content following this page was uploaded by Alan McSweeney on 21 May 2019.
The user has requested enhancement of the downloaded file.
Structured Approach to
Solution Architecture

Alan McSweeney
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
June 12, 2014 2
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

Solution Architecture In Context

Business Business
Processes Systems

Solution
Architecture

Business Management
Business Business Enterprise Solution
Operational And
Strategy Objectives Architecture Delivery
Model Operations

June 12, 2014 4

Solution Architecture
Takes the
requirements for
solutions to
Business business needs
Systems

Solution
Architecture

Ensures compliance Designs solution options

with overall systems based on requirements
architecture subject to standards and
standards other solution constraints
that are then implemented

Enterprise Solution
Architecture Delivery

June 12, 2014 5

Solution Architecture
Takes the
requirements for
solutions to
Business business needs
Systems

Solution
Goal is to ensures Architecture
solutions implemented
deliver business
requirements Designs solution options
Ensures compliance
accurately, efficiently based on requirements
with overall systems
and in a timely manner subject to standards and
architecture
with no surprises other solution constraints
standards
that are then implemented

Enterprise Solution
Architecture Delivery

June 12, 2014 6

Solution Architecture In Context
Business
Strategy

Business Objectives derived

Objectives from strategy
Business
Operational Operational model defined to
Model achieve objectives
Enterprise Architecture defines technology
Architecture framework to run operational model
Business Processes operationalise
Processes business objectives
Business Systems assist with the
Systems operation of processes

Solution Solution architecture defines business systems

Architecture design within enterprise architecture principles

Solution Solutions are implemented according

Delivery to the solution architecture

Management
And Operations

June 12, 2014 7

Solution Does Not Always Consist Solely Of A New
Application

External
Extended Application External
Manual (Other Systems) Manual
Interaction
Interaction

External Core External

Component Application Component

System System
Component Component

System
Component

External External External

Manual Component Manual
Interaction Interaction

June 12, 2014 8

Complete View of Solution

External External
Manual Manual
Interaction Interaction

External Automated External

Component Process Component
Manual Manual
Process Process
System System
Component Component

Automated Automated
Process System Process
Manual Manual
Process Component Process

External External External

Manual Component Manual
Interaction Interaction

June 12, 2014 9

Overall Solution Can Be A Combination of
Automated and Manual Processes

Extended Application
Automated
Process
Manual Manual
Process Process
Core
Application
Automated Automated
Process Process
Manual Manual
Process Process

June 12, 2014 10

Solution Design and Implementation Sequence

Business Plan

Business Need Y
Thr ou Ca
Mu oug n It
l ti p h T e r a
h
Business Benefits Det le Tim ese S te
ail e t
Eac s, Re eps
h S fini
tag ng
Requirements e
Definition

Process Design

Solution Architecture
and Design

Technical and
Detailed Design

Implementation

June 12, 2014 11

TOGAF Enterprise Architecture Development and
Implementation Process Business solutions fit into these
areas of the TOGAF framework

Architecture
Vision
Architecture
Business
Change
Architecture
Management
Data
Architecture

Information
Implementation Requirements
Systems
Governance Management
Architecture

Solutions and
Application
Architecture
Migration Technology
Planning Architecture
Opportunities
and Solutions

June 12, 2014 12

Solution Architecture Dimensions/Views

Solution
Architecture
Dimensions

Management
Business Functional Data Technical Implementation
And
View View View View View
Operation

Core Solution Views Extended Solution Views

June 12, 2014 13

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 Sub-System 3

Control Data
Monitor, Audit,
Storage
Manage
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
Data View
Range of Data Being

ew d
Vi an
Processed/Handled

l ts a l
su ion
t

/
nc

O e d t ed
Fu

hi te era
R e

Ac rea en
ut ve /
pu d/
C G
Business and Process

s
ti

t
ha
View

W
Processes Enabled and
Actualised by Solution and its
Functions

June 12, 2014 19

Solution Core Views And Their Interrelationships

Data View

Range of Data
Being Processed/
Handled
Functions
Business Generate
Processes Results
Read and Consist of
Generate Data Created or
Transformed
Data

Business and
Process View Functions and
Results View
Processes Enabled
and Actualised by Processes Are What is Generated/
Solution and Implemented by Created/Achieved
its Functions Functions that
June 12, 2014 Generate Results 20
Business and Process View And Decomposition

Process 1 … Process N

Activity 1.1 … Activity 1.N

Task 1.1.1 … Task 1.1.N Task 1.N.1 … Task 1.N.N

Step 1.1.1.1 … Step 1.1.1.N Step 1.N.N.1 … Step 1.N.N.N

June 12, 2014 21
Data View And Decomposition

Data Type 1 … Data Type N

Data Element 1.1 … Data Element 1.N

Data Attribute
1.1.1
… Data Attribute
1.1.N
Data Attribute
1.N.1
… Data Attribute
1.N.N

Data Attribute
Value 1.1.1.1
… Data Attribute
Value 1.1.1.N
Data Attribute
Value 1.N.N.1
… Data Attribute
Value 1.N.N.N

June 12, 2014 22

 Functions/Results/Outputs View And Decomposition

Output 1 … Output N

Output Element
1.1 … Output Element
1.N

Output Attribute
1.1.1
… Output Attribute
1.1.N
Output Attribute
1.N.1
… Output Attribute
1.N.N

Output Attribute
Value 1.1.1.1
… Output Attribute
Value 1.1.1.N
Output Attribute
Value 1.N.N.1
… Output Attribute
Value 1.N.N.N

June 12, 2014 23

Solution Core Views Data View

ew d
Vi an
lts al
su on
Re ncti
Fu
Business and Process
View

June 12, 2014 24

Dimensions/Views Of Solution Architecture
Solution
Architecture
Dimensions

Management
Implementation
Business View Functional View Data View Technical View and Operations
View
View

Context Context Context Context Context Context

Artefacts/ Operational
Purpose Stakeholders Entities Structure
Products Processes

Characteristics Characteristics Roles Operation Execution Support

Interfaces Development Characteristics Operation

Characteristics Characteristics Characteristics

June 12, 2014 25

Business And Process View Topics
Business Requirements View

Business Context Purpose Characteristics

Business Environment Availability, Continuity and Resilience

Resources, Skills and Experience Cost and Affordability

Products, Services and Value

Flexibility and Ability to Evolve
Propositions

Value Chain Ease of Implementation

Stakeholders Suitability and Efficiency

Business Processes Performance

Reliability

Manageability and Ease of Operation

Linkage to Other Systems

Stability

Security

Usability

June 12, 2014 26

Functional And Results View Topics
Functional View

Functional Context Purpose Characteristics

Related Systems Availability, Continuity and Resilience

Operational Processes Cost and Affordability

Products, Services and Value

Flexibility and Ability to Evolve
Propositions

Value Chain Ease of Implementation

Stakeholders Suitability and Efficiency

Business Processes Performance

Reliability

Manageability and Ease of Operation

Linkage to Other Systems

Scalability

Security

Usability

June 12, 2014 27

 Technical View Topics
Technical View

Technical Context Technical Configuration Operation Innovation and Growth Characteristics

Implementation Availability, Continuity

System Structure System Operation System Lifecycle
Environment and Tools and Resilience
System Management System Change and
Development Approach Hardware Infrastructure Cost and Affordability
and Administration Growth
Flexibility and Ability to
Language Software Infrastructure
Evolve

Framework/Systems Data Infrastructure Ease of Implementation

Integration Suitability and

Infrastructure Efficiency

Performance

Reliability

Manageability and Ease

of Operation
Linkage to Other
Systems

Scalability

Security

Usability

June 12, 2014 28

Implementation View Topics
Technical View

Implementation
Implementation Context Execution Characteristics
Artefacts/Products
Availability, Continuity and
Implementation Environment Solution Elements Governance
Resilience

Development Approach Delivered Components Implementation Organisation Cost and Affordability

Flexibility and Ability to

Language Collateral Implementation Process
Evolve

Framework/Systems Supporting Material Delivery Plan Ease of Implementation

Configuration Suitability and Efficiency

Financial Management Performance

Solution Validation Reliability

Manageability and Ease of

Operation

Linkage to Other Systems

Scalability

Security

Usability

June 12, 2014 29

Data View Topics
Data View

Data Context Entitles Interfaces Analysis and Reporting Characteristics

Availability, Continuity
Data Model Data Entities Sources and Targets Reporting
and Resilience
Reference and Master
Relationships Transformations Analysis Cost and Affordability
Data
Access Rights and Flexibility and Ability to
Conversion/Migration Data Types
Permissions Evolve

Data Volumes Data Types Ease of Implementation

Data Velocity Suitability and Efficiency

Data Variety Performance

Reliability

Manageability and Ease

of Operation

Storage and Capacity

Scalability

Security

Usability

June 12, 2014 30

 Management and Operation View Topics
Management and
Operation View
Management and
Operational Processes Support Operation Characteristics
Operation Context
Service Management Deployment/ Availability, Continuity
Capacity Support Model
Framework Maintenance Structure and Resilience
Availability, Continuity Deployment/
Operational Framework Support Processes Cost and Affordability
and Resilience Maintenance Process
Service Management Flexibility and Ability to
Transition Change Service Desk
Processes Evolve

Business Readiness Service Level Alerting and Monitoring Ease of Implementation

Organisational Change Configuration Backup and Recovery Suitability and Efficiency

Service Level
Steady State Release and Deployment Performance
Management

Incident Reliability

Manageability and Ease

Problem
of Operation

Linkage to Other Systems

Scalability

Security

Usability

June 12, 2014 31

Mapping TOGAF Enterprise Architecture Process To
Solution Architecture Definition
TOGAF Phase
B: Business Business View
Architecture

Solution Architecture
TOGAF Phase
C1: Data

Views/Dimensions
Architecture Data View
TOGAF Phase
C: Information
Systems
Architecture TOGAF Phase Functional View
C2: Solutions
and
Application
TOGAF Phase
Architecture
D: Technology Technical View
Architecture

Implementation
View

Management and
Operation View
June 12, 2014 32
Solution Dimensions

Business View

Core
Solution Data View TOGAF
Dimensions Solution
Dimensions
Functional View

Technical View

Implementation Extended
View Solution
Dimensions
Management and
Operation View
June 12, 2014 33
Solution Architecture Design Boundaries
Enterprise Architecture Defines the
Solution Technical Boundary

Business View Technical View

Solution
Architecture
Solution Implementation
Defines the Data View Architecture View
Solution
Scope
Boundary Management
Functional View and Operation
View

June 12, 2014 34

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
Enterprise Architecture Constraints

Use
Solution Range of Existing
Architecture
View Design Solution System or
Create New
Constraints Options System

Degree of Automation of Solution

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

Solution Architecture
Dimensions/Views

Solution Design Factors,

Core Views Limitations And
Boundaries

Extended Views

June 12, 2014 41

Solution Architecture Dimensions/Views And
Solution Design Factors, Limitations And Boundaries

Enterprise
Architecture

Business View
Existing or
Data View New System Degree of
Automation
Functional View

Expected Life
Technical View
Finance
Implementation View
Resources
Management and
Operation View

Timescale

June 12, 2014 42

Mapping TOGAF Enterprise Architecture Process To
Solution Architecture Definition
TOGAF Phase
B: Business Business View
Architecture

Solution Architecture
TOGAF Phase
C1: Data

Views/Dimensions
Architecture Data View
TOGAF Phase
C: Information
Systems
Architecture TOGAF Phase Functional View
C2: Solutions
and
Application
TOGAF Phase
Architecture
D: Technology Technical View
Architecture

Implementation
View

Management and
Operation View
June 12, 2014 43
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
View publication stats

More Information

Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney

June 12, 2014 108