Enterprise Architecture Professional Training and Certification

(EA Phase-2 Training)

Architecture Development Model Module 5- ADM Phase E- Application Architecture

Mahindra Satyam 2009 1

Phase C: Application Architecture

Mahindra Satyam 2009

Module Objectives
The aim of this module is to understand: The objectives of the Application Architecture part of Phase C What it consists of What inputs are needed for it What the outputs are

Mahindra Satyam 2009

Application Architecture
Objective To define the kinds of application systems necessary to process the data and support the business.

Mahindra Satyam 2009

Application Architecture
The objective is NOT to: Specify technologies Design application systems Because: Applications are stable but technologies change over time, And are chosen/selected according to needs

Mahindra Satyam 2009

Phase C: Inputs: Application Architecture

Request for Architecture Work Capability Assessment

Communications Plan
Organization model for EA Tailored Architecture Framework Application principles Statement of Architecture Work

Mahindra Satyam 2009

Phase C: Inputs: Application Architecture

Architecture Vision
Architecture Repository Draft Architecture Definition Doc.

Draft Architecture Requirements

Specification, including: Gap analysis results

Relevant technical requirements

Business and Data Architecture components of an Architecture Roadmap

Mahindra Satyam 2009

Steps
The order of the steps should be adapted to the situation.
9. Create Architecture Definition Document
8. Finalize the Application Architecture 7. Conduct formal stakeholder review 6. Resolve impacts across the Architecture Landscape 5. Define roadmap components

In particular you should determine whether it is appropriate to do the Baseline Application Architecture or Target Application Architecture development first

4. Perform gap analysis

3. Develop Target Application Architecture Description 2. Develop Baseline Application Architecture Description

1. Select reference models, viewpoints, and tools

Mahindra Satyam 2009

Step 1: Select reference models, viewpoints, and tools

Review/generate and validate application principles see Architecture Principles Select Application Architecture resources (reference models,patterns, ) Select relevant Application Architecture viewpoints Identify appropriate tools and techniques (including forms) to be used for capture, modeling, and analysis, in association with the selected viewpoints. Consider using platform-independent descriptions of business logic (e.g. the OMGs MDA) Continued

Mahindra Satyam 2009

TOGAF 9 Viewpoints
Preliminary Phase Principles catalog Phase B, Business Architecture Organization/Actor catalog Driver/Goal/Objective catalog Role catalog Business Service/Function catalog Location catalog Process/Event/Control/Product catalog Contract/Measure catalog Business Interaction matrix Actor/Role matrix Business Footprint diagram Business Service/Information diagram Functional Decomposition diagram Product Lifecycle diagram Goal/Objective/Service diagram Use-Case diagram Organization Decomposition diagram Process Flow diagram Event diagram Phase C, Data Architecture Data Entity/Data Component catalog Data Entity/Business Function matrix System/Data matrix Class diagram Data Dissemination diagram Data Security diagram Class Hierarchy diagram
Phase C, Application Architecture Application Portfolio catalog Interface catalog System/Organization matrix Role/System matrix System/Function matrix Application Interaction matrix Application Communication diagram Application and User Location diagram System Use-Case diagram Enterprise Manageability Diagram Process/System Realization diagram Software Engineering diagram Application Migration diagram Software Distribution diagram

Phase A, Architecture Vision Stakeholder Map matrix Value Chain diagram Solution Concept diagram

Phase D, Technology Architecture Technology Standards catalog Technology Portfolio catalog System/Technology matrix Environments and Locations diagram Platform Decomposition diagram Processing diagram Networked Computing/Hardware diagram Communications Engineering diagram

Phase E. Opportunities & Solutions Project Context diagram Benefits diagram

Requirements Management Requirements catalog

Mahindra Satyam 2009

Step 1: Select reference models, viewpoints, and tools

Determine Overall Modeling Process
For each viewpoint, select the models needed to support the specific view required, using the selected tool or method. E.g.: The TMF has developed detailed applications models relevant to the Telecommunications industry. The OMG has some vertical Domain Task Forces developing models for specific vertical domains such as Healthcare, Transportation, Finance, etc.

Confirm all stakeholders concerns are addressed. If not, create new models to
address concerns not covered, or augment existing models

Identify Required Catalogs of Application Building Blocks. The organizations Application portfolio is captured as a catalog within the Architecture Repository. Continued

Mahindra Satyam 2009

Step 1: Select reference models, viewpoints, and tools

Identify Required Matrices

Matrices show the core relationships between related model entities.

Identify Required Diagrams

Diagrams present the Application Architecture information from a set of different viewpoints

Identify Types of Requirements to be Collected

e.g. Functional requirements, Non-functional requirements, Assumptions, Constraints, Domain-specific Business Architecture principles, Policies, Standards, Guidelines, Specifications

Mahindra Satyam 2009

Example The Integrated Information Infrastructure Model

An Applications Architecture reference model A model of the application components and application services Software essential for an integrated information infrastructure Based on the TRM Aimed at the helping the design of architectures to enable and Support the vision of Boundaryless Information Flow

Mahindra Satyam 2009

III-RM Business and Technical Drivers

The cause: multiple systems, conceived and developed individually Compounding the problem: cross-functional teams continuously forming, new business partners, stove-piped information

Sell Space
Manufacturing Legal Customer Support Selling

Online Systems

Mahindra Satyam 2009

III-RM Focus

Mahindra Satyam 2009

III-RM High Level View

Mahindra Satyam 2009

Step 2 Develop a Baseline Application Architecture Description

If possible, identify the relevant Application ABBs, drawing on the Architecture Repository.

If not, define each application in line with the Application Portfolio catalog

Mahindra Satyam 2009

Step 3 Develop Target Application Architecture Description

If possible, identify the relevant Application Architecture building blocks, drawing on the Architecture Repository If not, develop a new architecture model: use the models identified within Step 1 as a guideline

Mahindra Satyam 2009

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 and Document Test architecture models for completeness against requirements Identify gaps between the baseline and target: Create the gap matrix Identify building blocks to be carried over, classifying them 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.

Mahindra Satyam 2009

Step 5: Define roadmap components

This initial Application Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase.

Mahindra Satyam 2009

Step 6: Resolve impacts across the Architecture Landscape Architecture artifacts in the Architecture Landscape should be examined to identify
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 organization?

Does this Application Architecture impact other projects ?

Will this Application Architecture be impacted by other projects?

Mahindra Satyam 2009

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. : Conduct an Impact analysis to Identify any areas where the Business and Data Architecture may need to change to cater for changes in the Application Architecture.

If the impact is significant revisit the Business and Data Architectures.

Mahindra Satyam 2009

Step 8 Finalize the Application Architecture

Select standards for each of the ABBs, reusing as much as possible. Fully document each ABB.
Cross check the overall architecture against the business requirements. Document the final requirements traceability report. Document the final mapping of the architecture within the Architecture repository. Identify the ABBs that might be reused and publish them via the architecture repository. Finalize all the work products, such as gap analysis
Mahindra Satyam 2009

Step 9: Create Architecture Definition Document

Document the rationale for all building block decisions in the architecture definition document. Prepare the Application Architecture sections of the architecture definition document report.

If appropriate, 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.

Mahindra Satyam 2009

Phase C: Outputs: Application Architecture

Statement of Architecture Work Validated application principles, or new application principles Draft Architecture Definition Document Draft Architecture Requirements Specification Application Architecture components of an Architecture Roadmap

Mahindra Satyam 2009

Architecture Definition Document Application Architecture Components

Baseline Application Architecture, if appropriate Target Application Architecture, including: Process systems model Place systems model Time systems model People systems model

Application Architecture views corresponding to the selected viewpoints addressing key stakeholder concerns

Mahindra Satyam 2009

Architecture Requirements Specification Application Architecture Components

Gap analysis results Application interoperability requirements Areas where the Business Architecture may need to change in order to comply with changes in the Application Architecture Constraints on the Technology Architecture about to be Designed Updated business/application/data requirements, if appropriate

Mahindra Satyam 2009

Summary

The applications are not described as computer systems but as logical groups of capabilities that manage data and support business functions. The applications and their capabilities should be defined without reference to particular technologies. The applications should best able, whereas the technology used to implement them may not be.

Mahindra Satyam 2009

Test Yourself Question

Q1. How should the application systems best be described? A. As computer systems B. As logical groups of capabilities C. As schemas D. As data-flow diagrams E. As UML diagrams

Mahindra Satyam 2009

Enterprise Architecture Professional Training and Certification

Architecture Development Model Phase 2 Application Architecture-part2

Enterprise Architecture Group

Mahindra Satyam 2009 30

Phase C Application Architecture Catalogs, Matrices and Diagrams

Mahindra Satyam 2009

Module Objectives

The objectives of this module are to understand: The Catalogs, Matrices and Diagrams of Phase C, Application Architecture What they consist of How they are used

Mahindra Satyam 2009

TOGAF 9 Viewpoints
Preliminary Phase Principles catalog Phase B, Business Architecture Organization/Actor catalog Driver/Goal/Objective catalog Role catalog Business Service/Function catalog Location catalog Process/Event/Control/Product catalog Contract/Measure catalog Business Interaction matrix Actor/Role matrix Business Footprint diagram Business Service/Information diagram Functional Decomposition diagram Product Lifecycle diagram Goal/Objective/Service diagram Use-Case diagram Organization Decomposition diagram Process Flow diagram Event diagram Phase C, Data Architecture Data Entity/Data Component catalog Data Entity/Business Function matrix System/Data matrix Class diagram Data Dissemination diagram Data Security diagram Class Hierarchy diagram
Phase C, Application Architecture Application Portfolio catalog Interface catalog System/Organization matrix Role/System matrix System/Function matrix Application Interaction matrix Application Communication diagram Application and User Location diagram System Use-Case diagram Enterprise Manageability Diagram Process/System Realization diagram Software Engineering diagram Application Migration diagram Software Distribution diagram

Phase A, Architecture Vision Stakeholder Map matrix Value Chain diagram Solution Concept diagram

Phase D, Technology Architecture Technology Standards catalog Technology Portfolio catalog System/Technology matrix Environments and Locations diagram Platform Decomposition diagram Processing diagram Networked Computing/Hardware diagram Communications Engineering diagram

Phase E. Opportunities & Solutions Project Context diagram Benefits diagram

Requirements Management Requirements catalog

Mahindra Satyam 2009

Catalogs, Matrices and Diagrams

Catalogs Application Portfolio catalog Interface catalog Diagrams Application Communication diagram Application and User Location diagram System Use-Case diagram Enterprise Manageability diagram Process/System Realization diagram Software Engineering diagram Application Migration diagram Software Distribution diagram

Matrices System/Organization matrix Role/System matrix System/Function matrix Application Interaction matrix

Mahindra Satyam 2009

Catalogs
Catalog
Application Portfolio Catalog

Purpose
To identify and maintain a list of all the applications in the enterprise. This list helps to define the horizontal scope of change initiatives that may impact particular kinds of applications. An agreed Application Portfolio allows a standard set of applications to be defined and governed. It contains the following metamodel entities: Information System Service Logical Application Component Physical Application Component

Interface Catalog

The purpose of the Interface catalog is to scope and document the interfaces between applications to enable the overall dependencies between applications to be scoped as early as possible. It contains the following metamodel entities: Logical Application Component Physical Application Component Application communicates with application relationship

Mahindra Satyam 2009

Matrices

System/Organization matrix Role/System matrix System/Function matrix Application Interaction matrix

Mahindra Satyam 2009

System/Organization Matrix
The purpose of this matrix is to depict the relationship between systems (i.e., application components) and organizational units within the enterprise. The mapping of the Application Component-Organization Unit relationship is an important step as it enables the following to take place: Assign usage of applications to the organization units that perform business functions Understand the application support requirements of the business services and processes carried out by an organization unit Support the gap analysis and determine whether any of the applications are missing and as a result need to be created Define the application set used by a particular organization unit

Mahindra Satyam 2009

Example System/Organization Matrix

APPLICATION (Y-AXIS) AND ORGANISATION UNIT (X-AXIS)

SAP HR SIEBEL SAP FINANCIALS PROCURESOFT

CUSTOMER SERVICES

PROCUREMENT AND WAREHOUSING

HR

CORPORATE FINANCE

X X X X

X X X X

Mahindra Satyam 2009

Role/System Matrix
The purpose of the Role/System matrix is to depict the relationship between systems (i.e., application components) and the business roles that use them within the enterprise. The mapping of the Application Component-Role relationship is an important step as it enables the following to take place: Assign usage of applications to the specific roles in the organization Understand the application security requirements of the business services and processes supporting the function, and check these are in line with current policy Support the gap analysis and determine whether any of the applications are missing and as a result need to be created Define the application set used by a particular business role; essential in any move to role-based computing

Mahindra Satyam 2009

Example Role/System Matrix

APPLICATION (YAXIS) AND FUNCTION (XAXIS)

CALL CENTRE OPERATOR

CALL CENTRE MANAGER

FINANCE ANALYST

CHIEF ACCOUNTANT

SAP HR SIEBEL SAP FINANCIALS

X X X

X X X

PROCURESOFT

Mahindra Satyam 2009

System/Function Matrix
The purpose of the System/Function matrix is to depict the relationship between systems (i.e., application components) and business functions within the enterprise The mapping of the Application Component-Function relationship is an important step as it enables the following to take place: Assign usage of applications to the business functions that are supported by them Understand the application support requirements of the business services and processes carried out Support the gap analysis and determine whether any of the applications are missing and as a result need to be created Define the application set used by a particular business function

Mahindra Satyam 2009

Example System/Function Matrix

APPLICATION (YAXIS) AND FUNCTION (XAXIS)

CALL CENTRE 1ST LINE

WAREHOUS E CONTROL

VACANCY FILLING

GENERAL LEDGER MAINTENANCE

SAP HR SIEBEL SAP FINANCIALS

X X X

X X X

PROCURESOFT

Mahindra Satyam 2009

Diagrams
Application Communication diagram N2 model or Node Connectivity diagram Application and User Location diagram System Use-Case diagram Enterprise Manageability diagram Process/System Realization diagram Software Engineering diagram Application Migration diagram Software Distribution diagram

Mahindra Satyam 2009

Application Communication Diagram

The purpose of the Application Communication diagram is to depict all models and mappings related to communication between applications in the metamodel entity. It shows application components and interfaces between components. Communication should be logical and should only show intermediary technology where it is architecturally relevant.

Mahindra Satyam 2009

Example Application Communication Diagram

Interface a

App 1
Interface b

App 2

App 3

Interface c

App 4

Shows application components and interfaces between components. Interfaces may be associated with Data Entities where appropriate. Applications may be associated with business services where appropriate Communications should be logical and should not show intermediary technology [such as Queuing infrastructure ]
Interface i Interface j

Interface d

App 5

Interface e

App 7

Interface f Interface g Interface k

Interface h

App 6

Mahindra Satyam 2009

N2 Model

Mahindra Satyam 2009

Information Exchange Matrix

LABEL

SOURCE

DESTINATION

DATA ENTITY

EVENT TRIGGERED

1a

ABC

ABM

Sales order (create request)

New sales order from front end

1b

ABM

ABC

Sales order (confirm create)

Order created in the backend ERP system

2a

ABM

CCD

Product catalog

Subscribe/Publish timer

Mahindra Satyam 2009

Application & User Location Diagram

The purpose of this diagram is to clearly depict the business locations from which business users typically interact with the applications, but also the hosting location of the application infrastructure. The diagram enables: Identification of the number of package instances needed Estimation of the number and the type of user licenses Estimation of the level of support needed Selection of system management tools, structure, and management system Appropriate planning for the technological components of the business Performance considerations while implementing solutions

Mahindra Satyam 2009

Example Application & User Location Diagram (Part 1)

APPLIC ATION

USER TYPE

INTERNAL, CUSTOMER OR PARTNER Internal

USER BUSINESS LOCATION NA Western Region EMEA Headquarters, UK

LOCATION ADDRESS

ORG UNIT (USER BELONGS TO)

CRM

Developer Super User Administrator

Chicago Sears tower office Chicago Downtown office Middlesex, London

NA Sales & Marketing EMEA Sales

SAP R/3

Test Engineers Mechanical Engineers Procurement managers

Internal

Beijing Manufacturing Plant

Manufacturing & Logistics

Mahindra Satyam 2009

Example Application & User Location Diagram (Part 2)

Mahindra Satyam 2009

System Use Case Diagram

Mahindra Satyam 2009

Enterprise Manageability Diagram

The Enterprise Manageability diagram shows how one or more applications interact with application and technology components that support operational management of a solution. Analysis can reveal duplication and gaps, and opportunities in the IT service management operation of an organization.

Mahindra Satyam 2009

Example Enterprise Manageability Diagram

System Management Tooling

Application

Problem Management

Logging and Reporting

Error Alerting

Backup and Restore Tooling

The view shows how one or more applications interact with application and technology components that supports operational management of a solution. This view is really a filter on the application-application communication view. This diagram may also show support personnel access to administrative functions of the system.

Mahindra Satyam 2009

Process/System Realization Diagram

The purpose of the Process/System Realization diagram is to clearly depict the sequence of events when multiple applications are involved in executing a business process.
It enhances the Application Communication diagram by augmenting it with any sequencing constraints, and hand-handoff points between batch and real-time processing.

Mahindra Satyam 2009

Example Process/System Realization Diagram

UML Sequence (most detail) and activity diagrams (less detail) can be used, or a less formal swimlaned flowchart (least detail). BPMN is also as option. The decision on diagram form will depend on the level of detail and formality. Generally, the nonformal view is best suited to stake holders, but specific areas of architecture risk need to be addressed in more detail. The diagram can show organizations, actors, application components, data entities and architecturally significant technology components.

Mahindra Satyam 2009

Software Engineering Diagram

The Software Engineering diagram breaks applications into packages, modules, services, and operations from a development perspective.
It enables more detailed impact analysis when planning migration stages, and analyzing opportunities and solutions. It is ideal for application development teams and application management teams when managing complex development environments.

Mahindra Satyam 2009

Example Software Engineering Diagram

Mahindra Satyam 2009

Application/Migration Diagram

The Application Migration diagram identifies application migration from baseline to target application components. It enables a more accurate estimation of migration costs It should be used to identify temporary applications, staging areas, and the infrastructure required to support migrations

Mahindra Satyam 2009

Example Application/Migration Diagram

Mahindra Satyam 2009

Software Distribution Diagram

This diagram is a composite of the Software Engineering diagram and the Application-User Location diagram. Depending on the circumstances, this diagram alone may be sufficient, or may not be needed.

Mahindra Satyam 2009

Thank you

mahindrasatyam.net
Safe Harbor
This document contains forward-looking statements within the meaning of section 27A of Securities Act of 1933, as amended, and section 21E of the Securities Exchange Act of 1934, as amended. The forward-looking statements contained herein are subject to certain risks and uncertainties that could cause actual results to differ materially from those reflected in the forward-looking statements. Satyam undertakes no duty to update any forward-looking statements. For a discussion of the risks associated with our business, please see the discussions under the heading Risk Factors in our report on Form 6-K concerning the quarter ended September 30, 2008, furnished to the Securities and Exchange Commission on 07 November, 2008, and the other reports filed with the Securities and Exchange Commission from time to time. These filings are available at http://www.sec.gov

Mahindra Satyam 2009 61

Thank you

mahindrasatyam.net
Safe Harbor
This document contains forward-looking statements within the meaning of section 27A of Securities Act of 1933, as amended, and section 21E of the Securities Exchange Act of 1934, as amended. The forward-looking statements contained herein are subject to certain risks and uncertainties that could cause actual results to differ materially from those reflected in the forward-looking statements. Satyam undertakes no duty to update any forward-looking statements. For a discussion of the risks associated with our business, please see the discussions under the heading Risk Factors in our report on Form 6-K concerning the quarter ended September 30, 2008, furnished to the Securities and Exchange Commission on 07 November, 2008, and the other reports filed with the Securities and Exchange Commission from time to time. These filings are available at http://www.sec.gov

Mahindra Satyam 2009 62