by Dr. Vsevolod S.

Chernyshenko

 Development of a Business Architecture to support an agreed Architecture Vision Main aspects

o Describe the Baseline Business Architecture o Develop a Target Business Architecture

o Analyze the gaps between Business Architectures

Baseline

and

Target

o Select and develop the relevant architecture viewpoints o Select the relevant tools and techniques

 Target Business Architecture describes o product and/or service strategy o organizational, functional, process, information, geographic aspects of the business environment
based on the strategic drivers business principles, business goals,

and and

Architecture viewpoints o enable the architect to demonstrate how the stakeholder concerns (from Architecture view phase) are addressed in the Business Architecture

 Output of Preliminary phase

Output of Architecture Vision phase o Especially the baseline and high-level Target Business Architecture

Draft Architecture Definition Document

Baseline Business Architecture Target Business Architecture o Organization structure o Business goals and objectives o Business functions o Business services o Business processes o Business roles o Business data model o Correlation of organization and functions

1. Select reference models viewpoints and tools

2. Develop Baseline Business Architecture Description

3. Develop Target Business Architecture Description

6. Resolve impacts across Architecture Landscape 9. Create Architecture Definition Document

4. Perform Gap Analysis

5. Define Roadmap Components

7. Conduct formal stakeholder review

8. Finalize Business Architecture

 Identify appropriate tools and techniques to be used

1. Select reference models viewpoints and tools

2. Develop Baseline Business Architecture Description 5. Define Roadmap Components

3. Develop Target Business Architecture Description 6. Resolve impacts across Architecture Landscape

Modelling notations for different levels of abstraction and for specific aspects Business Process Modelling o ADONIS process landscapes o ADONIS process models

4. Perform Gap Analysis

7. Conduct formal stakeholder review

8. Finalize Business Architecture

9. Create Architecture Definition Document

Viewpoints are based on the data in stakeholder map (Architecture Vision)

 Develop Baseline Description of the existing Business Architecture Target Description for the Business Architecture

1. Select reference models viewpoints and tools

2. Develop Baseline Business Architecture Description 5. Define Roadmap Components

3. Develop Target Business Architecture Description 6. Resolve impacts across Architecture Landscape

4. Perform Gap Analysis

7. Conduct formal stakeholder review

8. Finalize Business Architecture

9. Create Architecture Definition Document

by using modelling techniques and tools chosen For new architecture models use the models and viewpoints identified to satisfy stakeholder concerns

 Identify gaps between the baseline and target Identify gaps and classify as should be developed should be procured by using modelling techniques and tools chosen
4. Perform Gap Analysis 5. Define Roadmap Components 7. Conduct formal stakeholder review 8. Finalize Business Architecture

1. Select reference models viewpoints and tools

2. Develop Baseline Business Architecture Description

3. Develop Target Business Architecture Description 6. Resolve impacts across Architecture Landscape

9. Create Architecture Definition Document

Building a roadmap is required to prioritize activities over coming phases Business Architecture roadmap will be used as raw material to support Opportunities & Solutions phase

1. Select reference models viewpoints and tools

2. Develop Baseline Business Architecture Description 5. Define Roadmap Components

3. Develop Target Business Architecture Description 6. Resolve impacts across Architecture Landscape

4. Perform Gap Analysis

Think about and document: Does this Business Architecture create an impact on 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 organization?

7. Conduct formal stakeholder review

8. Finalize Business Architecture

9. Create Architecture Definition Document

1. Select reference models viewpoints and tools

2. Develop Baseline Business Architecture Description 5. Define Roadmap Components

3. Develop Target Business Architecture Description 6. Resolve impacts across Architecture Landscape

Check original motivation for the architecture project and Statement of Architecture Work against the proposed Business Architecture Does it fit for the purpose of supporting subsequent work in the other architecture domains Refine the proposed Business Architecture only if necessary
7. Conduct formal stakeholder review 8. Finalize Business Architecture 9. Create Architecture Definition Document

4. Perform Gap Analysis

 Select standards for each of the building blocks Fully document each building block Conduct final cross-check of overall architecture against business goals o Document rationale for building block decisions in the architecture document Document final requirements traceability report Document final mapping of the architecture within the Architecture Repository Finalize all the work products, such as gap analysis results
1. Select reference models viewpoints and tools 2. Develop Baseline Business Architecture Description 3. Develop Target Business Architecture Description 4. Perform Gap Analysis 5. Define Roadmap Components 6. Resolve impacts across Architecture Landscape 7. Conduct formal stakeholder review 8. Finalize Business Architecture 9. Create Architecture Definition Document

 Document rationale for building block decisions in Architecture Definition Document Prepare business sections of Architecture Definition Document, comprising some or all of:

1. Select reference models viewpoints and tools

2. Develop Baseline Business Architecture Description 5. Define Roadmap Components

3. Develop Target Business Architecture Description 6. Resolve impacts across Architecture Landscape

4. Perform Gap Analysis

7. Conduct formal stakeholder review

8. Finalize Business Architecture

9. Create Architecture Definition Document

o A business footprint, i.e. high-level description of people and locations involved with key business functions o A detailed description of business functions and their information needs o A management footprint, showing span of control and accountability o Standards, rules, and guidelines showing working practices, legislation, financial measures, etc. o A skills matrix and set of job descriptions

Draft Architecture Definition Document

Business Process Modelling o ADONIS process landscapes o ADONIS process models

 Appropriate mapping of key processes towards meeting the strategic aims of an organisation Appropriate mapping of organisational structures with the functional procedures and workflows Conceptual representations of processes as environment to effectively plan and optimise work processes, thereby speeding up the learning process of transformation Improved qualification and service performance of staff and better motivation

 Create awareness of the respective problems Make organisation sensitive towards a process oriented culture o thinking in whole processes that lead to service production o Imagination and awareness of what happens beyond the own organisational / unit`s borders Check lists, criteria for analysis, options for design Presentation and communication of overall process chains

 Processes as the key elements in business domains A process has a trigger, defined inputs and outputs, as well as a defined sequence of activities / functions to transform the input into a desirable output Activities are being performed either by people or by artifacts (e.g. agents, applications, other ICT) A process has specific goals to be fulfilled The respective activities have conditions within which they can be executed (e.g. predefined rules, ordinances, decisions and process borders) Data and documents (electronic/physical) may be input or results of a process or respective activities

 Appropriate presentation of relevant characteristics Composition / decomposition o Don`t model complex processes in one single chart! Appropriately support analysis and design of processes Integration with information, document and organisational elements o ER diagrams and class diagrams o Organisational models and work environment models o Document resource models

 Overview of business domains of an organisation o Should map with the strategic objectives Supports navigation and entry point for process models Notation o Process object

o Relations
has process has note

o Note
o Aggregation

 Process models represent a sequence of activities which are required in a given chain to produce services or products Control objects o Process start, Process splits (sequential, exclusive, parallel), unification and end and successor relationships enable to depict the sequence of activities as perceived in reality

Process start
Process end

And/Or/Xor-Splits
Parallel split

Activity
Sub-process

Unification
Note Aggregation Successor has resource has note

IT Resources

 Represent responsibilities of organisational units for specific process chains o E.g. work groups, departments etc. Usually, processes span across a number of organisational units, hence per unit a swim lane is depicted to aggregate the process chains within each individual unit Organisational unit can be referred to via the organisational diagram or the work environment diagram Can be modelled horizontally or vertically o Once decision is taken, no alternation possible for a process model

 Complex process models should be developed using decomposition (sub-processes), i.e. developing manageable process models Principles of decomposition o Process modules, which can be reused in other contexts, should be own sub-models o A process model should fit onto one sheet of paper (not spanning across A3 size) o A process model should not contain too many organizational unit -> use sub-models may help

by Dr. Vsevolod S. Chernyshenko

 Information Systems Architecture, including development of Data and Application Architectures Main aspects to develop baseline and target architectures covering either or both: o application systems domains o data domains

Output of Preliminary phase Statement of Architecture Work Tailored framework Application principles Data principles Output of Architecture Vision Phase Architecture repository Output of Business Architecture Phase

Draft Architecture Definition Document including: Baseline and Target Data Architecture

o Which Data are actually used in the clients business. (Format? Paper? Digital?) o When and where will Data be created, edited, needed or deleted o Which Data should application/architecture be covered by the future

Baseline and Target Application Architecture

Data Architecture views stakeholder concerns

and viewpoints addressing key

o Business stakeholder need other views then IT stakeholder

Application Architecture views and viewpoints addressing key stakeholder concerns

o Business stakeholder need other views then IT stakeholder

Draft Architecture Definition Document including: Baseline and Target Data Architecture

o Which Data are actually used in the clients business. (Format? Paper? Digital?) o When and where will Data be created, edited, needed or deleted o Which Data should application/architecture be covered by the future

Baseline and Target Application Architecture

Data Architecture views stakeholder concerns

and viewpoints addressing key

o Business stakeholder need other views then IT stakeholder

Application Architecture views and viewpoints addressing key stakeholder concerns

o Business stakeholder need other views then IT stakeholder

Draft Architecture Requirements Specification, including: Gap analysis results Relevant technical requirements Constraints on the Technology Architecture about to be designed

 Involves combination of Data and Application Architecture o data-driven approach o application-driven approach Possible way of solving o top-down design and bottom-up implementation

 Define the major kinds of application system necessary to: process the data support the business Effort is not concerned with applications systems design from technical point of view Applications are not described as computer systems Applications are logical groups of capabilities
o managing the data objects in the Data Architecture o supporting the business functions in the Business Architecture

Defined without reference to particular technologies

1. Select reference models viewpoints and tools

2. Develop Baseline Application Architecture Description

3. Develop Target Application Architecture Description

6. Resolve impacts across Architecture Landscape 9. Create Architecture Definition Document

4. Perform Gap Analysis

5. Define Roadmap Components

8. Finalize Application Architecture

7. Conduct formal stakeholder review

TOGAF process for developing an Application Architecture: Understand the list of applications and application components required requirements business architecture scope per application 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

 Build up an Application Portfolio List, name and describe all applications available Matrices showing relationships between related model entities TOGAF states the following matrices as important:
o System/Organisation
o Role/System o Application Interaction o System/Function

Group

Description

Example titles

Use by
Everyone

Operating systems OS installed in University.

IDE & SDK

eWorkspace

Document preparation systems Voice recognizers

Windows Server 2008 r2, Ububtu, Windows 7, Mac OS X. Environments for development or update NetBeans IDE, Eclipse eWorkspace, creating interfaces for repository and IDE, JavaScript SDK. etc. Web platform produced by universitys IT staff, featuring repositories, access control systems, systems responsible for secure communications, identity systems, students and lecturers workspace, eLibrary, etc. Main tools for enterprise architects of the team, also Microsoft Office, used for processing recognized documents. OpenOffice, Microsoft Visio, Enterprise Architect. Used for dictation, text-to-speech processing. Dragon Naturally Provide access for different voice profiles in a Speaking, "Say-Now" networked environment. Feature increase Voice Recognition accuracy tools and other analyzing techniques. Software, Sonic Extractor.

IT specialists of Enterprise Architecture team Everyone

Everyone but first of all enterprise architects and academic staff Academic staff, Processing office

 Better visualisation through diagrams requirements of the stakeholders TOGAF recommends:

o Application Communication diagram

according

to

the

o Application and User Location diagram

o Enterprise Manageability diagram

o Process/System Realization diagram o Application Migration diagram

o Software Distribution diagram

o Software Engineering diagram

 After preparing portfolio, matrices and diagrams have been developed, architecture modeling is completed by formalizing requirements Types of requirement that must be met by the architecture implementation, including:
o Functional requirements o Non-functional requirements

o Policies
o Standards o Guidelines

o Assumptions
o Constraints o Domain-specific Application Architecture principles

o Specifications

 Creation of both Baseline and Target Data Model Using ADONIS integrated UML language for e.g. Class models consisting of all data used in the educational\academical process e.g.:
o Describing University o Describing Ministry of Science and Education

Creation of both Baseline and Target Application Architecture Using ADONIS for modelling Baseline and Target Application Architecture
o Covering all aspects of eUniversity applications o Developing harmonized target Application Architecture basis for target eUniversity process as

 Design:
o Business Architecture design

o Data (or Application) Architecture design

o Application (or Data) Architecture design o Technology Architecture design

Implementation:
o Technology Architecture implementation o Application (or Data) Architecture implementation

o Data (or Application) Architecture implementation

o Business Architecture implementation

1. Select reference models viewpoints and tools

2. Develop Baseline Data Architecture Description

3. Develop Target Data Architecture Description

6. Resolve impacts across Architecture Landscape 9. Create Architecture Definition Document

4. Perform Gap Analysis

5. Define Roadmap Components

7. Conduct formal stakeholder review

8. Finalize Data Architecture

Human actor Project manager Social worker Human Resources officer IT Manager Developer or maintainer of software Developer or maintainer of hardware Technology Risk Manager

Role(-s) Manage business processes. Controls budget. Searches for tender. Research people needs. Proposes interfaces, goals. Manages the interaction of employees. Searches for employees. Could be responsible for some identity-related information. Investigates existing information infrastructure of the university. Propose strategy of IT design. Designs and implements applications. Search for best solutions in records processing software. Searches for best solutions in media processing tools, data storages. Installs software. Ensures security.

Computer actor Role(-s) Existed resources and Operating systems, database management systems, web applications services, university applications. Record processors Used to process data by university staff.

Record software
Data storage Security system

Used to record data by university staff.

Holds record and processed data. Includes authorization and access control systems, systems responsible for secure communications (e.g. between academics and Processing office).

Identity management system

Identity stores

Includes registration, identity information access and etc.

Includes stores holding information about directories and permissions.

 Select relevant Data Architecture reference model

o on basis of the business drivers, concerns, and Business Architecture stakeholders,

Select relevant Data Architecture viewpoints Identify appropriate tools and techniques e.g.:
o Entity-relationship diagram o Class diagrams o Object role modeling

Consider using platform-independent descriptions

 Identify required diagrams to model different viewpoints (for stakeholder) and different levels of detail List of possible diagrams: Entity Relationship Model Class diagram Further UML models
o Use Case o Component

 Develop
o Baseline Description Architecture of the existing Business

o Target Description for the Business Architecture

by using modelling techniques and tools chosen

For new architecture models use the models and viewpoints identified to satisfy stakeholder concerns

 Step 1: Identification of goals and purposes Step 2: Identification and analysis of concrete data and information

Step 3: Abstraction in one (or several) conceptual model(s)

 Among creation of Data Architecture models other scenarios for Data modelling can be: Design of systems for data and information storage Design of application systems
o Domain specific application systems o Document management systems o Workflow management systems

Development of querying statements (e.g. in service requests from databases) Development of online forms Development of interfaces among systems

by Dr. Vsevolod S. Chernyshenko

 Map application components defined in the Application Architecture phase into a set of technology components Main aspects:
define baseline (i.e., current) and target views of the technology portfolio detailing the roadmap towards the Target Architecture identify key work packages in the roadmap

Output of Preliminary phase Output of Architecture Vision phase Output of Information System Architecture phase Draft Architecture Requirements Specification o Gap analysis results (from Business, Data and Application Architecture) o Relevant technical requirements from previous phases

Business, Data, and Application Architecture components of an Architecture Roadmap

 Draft Architecture Definition Document, including:

Baseline Technology Architecture Target Technology Architecture, including:
o Technology Components and their relationships to o Technology platforms and their decomposition o Environments and locations - a grouping of technology into computing environments (e.g., production) o Expected processing load and distribution of technology components o Physical (network) communications o Hardware and network specifications IS the required development, load across

Views corresponding to the selected viewpoints addressing key stakeholder concerns

Linking platform requirements and hosting requirements, as a single application may need to be physically located in several environments to support local access, development lifecycles, and hosting requirements.

1. Select reference models viewpoints and tools

2. Develop Baseline Technology Architecture Description

3. Develop Target Technology Architecture Description

6. Resolve impacts across Architecture Landscape 9. Create Architecture Definition Document

4. Perform Gap Analysis

5. Define Roadmap Components

8. Finalize Technology Architecture

7. Conduct formal stakeholder review

 Select relevant Technology Architecture reference model:

on basis of the business drivers, stakeholders, concerns, and Business Architecture

Select relevant Technology Architecture resources from the Architecture Repository Select relevant Technology Architecture viewpoints Identify appropriate tools and techniques e.g. simple documents and spreadsheets more sophisticated modelling tools and techniques

 Define a taxonomy of platform services and logical technology components (including standards) Identify relevant locations where technology is deployed Carry out a physical inventory of deployed technology and abstract up to fit into the taxonomy Look at application and business requirements for technology

 Is the technology in place fit-for-purpose to meet new requirements (i.e. does it meet functional and nonfunctional requirements)?
Refine the taxonomy

Product selection (including dependent products)

Determine configuration of the selected technology Determine impact

Sizing and costing Capacity planning Installation/governance/migration impacts

Data Interchange Services and Standards. Services: Document Conversion Media (Records) Data Interchange Media Management Software Data Interchange User Data, Access Rights Interchange Media Interface support media file formats Voice Recognition Document Processing Publishing

Functions:

Standards:

UN/EDIFACT ANSI X12 TRADACOMS

Data Management Services and Technology Components. Services: University Repository User Management System Database Management System File Management Voice Recognition Document Processing Publishing UN/EDIFACT ANSI X12 TRADACOMS

Functions:

Standards:

Data Management Services and Technology Components. Services: Data Communications Distributed Data Distributed File Remote Access Voice Recognition Document Processing Publishing UN/EDIFACT ANSI X12 TRADACOMS

Functions:

Standards:

 Identify required diagrams to model different viewpoints (for stakeholder) and different levels of detail List of possible diagrams suggested by TOGAF
Environments and Locations diagram

Platform Decomposition diagram

Processing diagram Networked Computing/Hardware diagram

Communications Engineering diagram