Building a Formal Enterprise Architecture Model

7/31/2019 Building a Formal Enterprise Architecture Model

1/13

white PAPeR

Suresh Nair,

Chief Architect Financial Services

Buldng a Formal enrprsArccur Modl

March, 2011


2/13

| 1 |

I MphasiS White PaperBuilding a Formal Enterprise Architecture Model

Table of Contents

Abstract 2

The Problem Statement 2

The Goals of this Framework 2

The Purpose of EA 2

Drivers for Change 3

Business and IT Roadmaps 4

The Models 6

Concept Model 6

Business Processes 7

Function Inventory 8

Organization Structure / Roles and Responsibili ties / Geographic Distribution 8

Application Architecture 9

Infrastructure 9

IT Operations 9

A Realistic Approach to Building the Models 10

The Future 11

Further Reading 11


3/13

MphasiS White Paper I Building a Formal Enterprise Architecture Model

| 2 |

AbstractThis white paper outlines a pragmatic and easy to under-

stand process we have followed in bui lding enterprisearchitecture (EA) documentation that we have sen to be

consistently effective. The document provides an overview

of all the elements in an enterprise architecture, including

the process for building the enterprise architecture from

individual projects within the organization.

The Problem StatementSeveral robust standards exist for Enterprise Architecture

today; each with subtle differences on the governance and

delivery models.Problem 1: Coarse Granularity & FuzzinessEnterprise Architecture standards must encompass a very

broad boundary to be effective. Additionally, the standards

need to be left very broad to accommodate a very wide

range of real world scenarios. First time adopters of

enterprise standards often spend several iterations getti ng

the granularity of their enterprise architecture efforts right.

If the first iteration is too coarse, it may not have enough

detail to be usable. If there is too much detail, the

implementation may get caught in analysis paralysis.

Problem 2: Documentation DetailsWhile some EA standards especially tool driven ones

provide formats for capturing details, the precise format of

the documentation and enterprise models are often left to

the interpretation of the implementation teams. For smaller

organizations or ini tiatives the overhead of defining

documentation standards and managing actual

documentation can be problematic.

Problem 3: Moving TargetsWhile nearly all EA standards are designed to support

continuous evolution of the organization, how this is

realized is crucial to the EA initiative being sustainable.

If the EA initiative is not tightly integrated into the projectcycles for applications, maintaining EA models becomes

and overhead.

The Goals of this FrameworkThis white paper attempts to define a process and a set

of models to capture the enterprise architecture that avoidsthese problems. This includes:

A set of work products that are common to the EA

framework and to projects. That is

- A project could create these, and they can be reused

as is in the enterprise architecture.

- If these are created as part of an EA initiative, they

can be reused in individual projects

A clear level of granularity for all the work products.

This helps avoid some of the back and forth that

organizations go through in the evolution of the EA

framework

Support for very wide range of EA standards; as wellas a wide range of project architecture standards.

For example, an organization could follow TOGAF

(The Open Group Architecture Framework) at the

enterprise level, and ATAM (Architecture Tradeoff Analysis

Method) for a single project. The models described

here could be used to capture the work products for both

governance frameworks in a way that it can trickle down

to individual project teams, or bubble up to the enterprise

level repository

The Purpose of EAThis is a very broad topic, and we could literally define

hundreds of benefits and outcomes from a strong EA

initiative. We would like to focus on a few pragmatic

goals. For the purposes of this document, we assume the

overall Enterprise Architecture initiative suppor ted by the

models described here would achieve the following:

Identify redundancies and duplication of functionality

across the organization

Support the operational model of the organization

Reduce the time to market for any business change.

This includes:- Identify reusable assets to minimize new effort

- Rapidly perform impact analysis to identify elements

that need to change to meet the change business

need

Provide a governance framework for all IT changes,

allowing all stakeholders to understand the health of the

IT assets of the organization, and changes that are

needed to give the organization a competitive edge

through its IT assets


4/13

| 3 |


Drivers for ChangeIn any organization, there would be two parallel paths of

change; business driven change and technology drivenchange.

The elements in the model are:

Enterprise Assets: inventory of enterprise wide assets in

a format that is agnostic to how they are realized in any

IT system- Function inventory: List of use cases as realized

through any system or process in the organization

- Enterprise Information Model: A concept model of

information used by the organization. The model uses

a technology agnostic form such as Object Role

Model (ORM) or Web Ontology Language (OWL) to

capture the ontology

Capability to deliver the assets: This is the realization of

assets as physical implementations across the

organization

- Applications: IT systems deployed across the

enterprise that realize the functionality from the

function inventory. Each application is traced to the

functions and entities in the enterprise inventories.

The relationships are App function,

App function, App Entity and App Entit y

- Infrastructure: Inventory of the Commercial Off the

Shelf (COTS) software or hardware across the

enterprise. Relationships are App hardware/

software. Only di rect usage is traced.

Dependencies between hardware and software is

tracked within the infrastructure model

- IT Operations: The tasks performed by IT to keepapplications and infrastructure working smoothly

are tracked. Functionality and Apps would be tracked

to these tasks through Functionality task and

App Task relationships. If the

enterprise has ITIL repositories to track the

infrastructure to operations mapping (I.e. IT operations

tasks to sustain hardware or COTS software), and

these may not need to be modeled

Utilization Context: This provides the details of the

organization and day to day processes and operations

where IT assets are used

- Business Processes: These are cap tured in BPMNnotation using a process modeling tool. It is critical

to success that these show the Human to Human,

Human to System and System to System interactions

in each process. Each system task corresponds to a

function in the enterprise function inventory. Humans

and systems are shown as separate swimlanes,

clearly showing which system implement functions,

and the utilization context for those functions

- Organization Structure: This is a model of the

organization as a whole, showing the different teams,

legal vehicles and reporting hierarchy of the

organization

Audit findings

New regulations oroperating controls

Changes in themarket place

Mergers /acquisitions/restructuring

Cost reductiondrives

Business Drivers

New functionalityneeds

New data needs

New Products orofferings

New roles

Newaudit/control/regulations

Process changes

Changes due to Business Drivers

Data centeroperational

changes

Security winerabilityidentification

Technologyconsolidation mandates

Mergers / acquisitions /restructuring

Vendor drivenupgrades / platform

changes

Technology Drivers

Major version orvendor changes for

COTS

IT operations orcontrol changes

Integrationchanges

Outsourcing externalhosting

Applicationhosting changes /

virtualizationCapacity increase

Changes due to Technology Drivers

To provide a framework for managing business and

technology changes, we need to have a method to classify

each change, and to have an enterprise level taxonomy

where these changes are tracked. In this way, all the

changes happening at any point in time can be

immediately located. If two different drivers need to make

changes to the same technology component or business

process, we can quickly identify the dependencies and

conflicts.

The key to managing these changes is to maintain models

of the enterprise, showing as is and go to versions,clearly highlighting the changes that need to be made.

Each change in turn needs to be traced to the business

driver or technology driver that requires the change to be

made.

Version1 (As Is)

Enterprise Assets

FunctionalityInventory

EnterpriseInformation

Model

Utilization Contest

BusinessProcesses

OrganizationStructure

GeographicDistribution

Roles andResponsibilities

SupportOperations

Capability to deliver the assets

Applications

IT Operations

Infrastructure

Version2 (Go To)

Enterprise Assets

FunctionalityInventory V2

EnterpriseInformationModel V2

Utilization Contest

BusinessProcesses V2

OrganizationStructure V2

GeographicDistribution v2

Roles andResponsibilities

V2

SupportOperations V2


Applications V2

IT Operations V2

Infrastructure V2

BusinessDriven

Changes

TechnologyDriven

Changes

Fig 1. Examples of business driven change

Fig 2. Examples of technology driven changes

Fig 3. Enterprise model changes


5/13


| 4 |

- Geographic Distribution: This places the organization

structure and roles and responsibilities into a

geographic context

- Roles and responsibilities: An inventory of thedifferent roles across the organization; showing the

hierarchy between roles. (NOTE: The functionality

responsibilities would be derived from the business

processes that the role participates in)

- Support operations: This model is actually outside

of the context, and shows the enterprise governance

that controls the utilization context elements. It would

include, for example activities such as the business

process improvement practice, audit and ser vice

oriented architecture governance. This allows

organizations to capture governance that may need to

be put in place as part of a project.

Business and IT RoadmapsThere is a fundamental over-simplification in the previous

section in the representation of there being a single as isand go to state.

A more accurate representation is to think of the utilization

context as changing through a series of mil estones. The

business processes, organization structure and roles and

responsibilities evolve continuously to respond to internal

and external change d rivers.

New functionality may be required, or it may become

necessary to deliver existing functionality in a different

context, or to a different geography or group of users.

Another way to think of this is to say that the utilization

context is continuously changing; and the enterprise asset

inventory + the capability to deliver these assets needs to

change to support these changes.

Consider the following diagram showing the changes in

utilization context, enterprise inventory and delivery

capability over time.

Business Processes

Geographic Distribution

Organization Structure

Roles and Responsibilities

Support Operations

Utilization Context V1Business Processes




Support Operations

Utilization Context V4Business Processes




Support Operations

Utilization Context V2

Applications

Infrastructure

IT Operations

Capability V1

Applications

Infrastructure

IT Operations

Capability V2

IT Operations

Capability V3

Infrastructure

Applications

IT Operations

Capability V4

Infrastructure

Applications

Enterprise Information Model

Enterprise Assets V1

Functionality Inventory


Enterprise Assets V4


M2M1 M3 M4 M5 M6 M7

Time

Fig 4. Model versions in production


6/13

| 5 |


This shows time along the X axis. The milestones marked

M1 to M7 mark significant milestones:

M1: We start with a base system, and as-i s models for

utilization, capability and enterprise assets M2: Based on the needs for the business to change their

business processes, organization structure or other based

on technology, the IT organization will need to change

its abilit y to deliver. The utilization context changes are

set to start from milestone M3. The capability needs to be

delivered sufficiently before hand

M3: Once the IT delivery capability changes are

completed, the business change bring into effect the

changes in its business processes and operations

M4: Some changes in IT delivery capability may have no

impact on the utilization context. Examples include

upgrade of technology versions, changing in application

hosting infrastructure or optimization of IT operations. In

this case, there is a change to the capability model, with

no change to the utilization context

M5: If the organization undergoes significant shifts in its

business model, the enterprise asset model may need to

be changed. Changes to the enterprise asset model

should be very controlled, as they can break all the

traceability models that are built up to that point

M5 M6 : If there is a change in the enterprise asset

model, there would need to be a short gap before new

Enterprise Assets

Functionality InventoryF1 V1

F2 V1


ApplicationsUC1 V3

UC1 V4

InfrastructureS1 V1

IT Operations


Business ProcessesBP1 V3

BP2 V1




Support Operations

Utilization Context

Version 1 (As Is)Enterprise Assets

Functionality InventoryF1 V1

F2 V1


ApplicationsUC1 V3

UC2 V5

Infrastructure

IT Operations


Business ProcessesBP1 V3

BP2 V2




Support Operations

Utilization Context

Version 2 (Go To)

S1 V2

S2 V1

Project2

Project1

changes are planned so that the inventory can be

reassessed and verified against the new model

M6 / M7: Further extension of the capability and

utilization contexts would continue following the samemodel.

ProjectsAny modern organization needs to change conti nuously.

The changes can range from the minor isolated to a small

group of tasks; to sweeping enterprise level changes.

Changes are achieved through projects, each with its

own finite objectives. Each project is tracked separately to

closure; but work together to achieve the enterprise level

changes.In the model, we can consider that any change in

enterprise assets, delivery capabili ties or utilization context

are brought around by one or more projects.

Each change between one version and the next should be

associated with one and only one project. All the changes

to achieve the next version of the delivery model and

utilization context may require multiple, parallel projects.

Fig 5. How changes are clubbed into projects


7/13


| 6 |

As shown in the diagram above, multiple changes in

business processes can occur during the lifespan of long

running projects. The model based controls help identify the

impact of these on the ongoing projects, and allow for

mid course corrections to be made to projects to ensure

that the desired capability or utilization context changes are

made.

It is critical to remember that changes will never end, and

there will always be multiple projects in progress,

impacting the same set of shared enterprise assets,capability or utilization contexts.

The ModelsConcept Model

The concept model would include a ll business terminology,

and the relationship between different kinds of elements.

An ontology modeling notation such as Object Role Model

(ORM), Web Ontology Language (OWL) or Resource

Description Format (RDF) rather than a class modelingnotation such as UML Class diagrams, Entity diagrams or

Concept modeling notation.

M2M1 M3 M4 M5 M6 M7

Time

Capability V3 Capability V4Capability V1 Capability V2

Utilization Context V1 Utilization Context V2 Utilization Context V4

Enterprise Assets V1 Enterprise Assets V4

Project1

Project2

Project3

f1 The Academic with empNr 715 has EmpName Adams A.f2 The Academic with empNr 715 works for the Dept named Computer Science.f3 The Academic with emp Nr 715 occupies the Room with roomNr 69-301.f4 The Academic with empNr 715 uses the Extension with extNr 2345.f5 The Extension with extNr 2345 provides the Accesslevel with code LOC.f6 The Academic with empNr 715 is contracted till the Date with mdy-code 01/31/95.

Aset of facts...

... is represented as a diagram

AccessLevel(Code)

Extension(extNr)

Academic(empNr)

Room(roomNr)

Date(mdy)

Dept(name)

EmpNamehas

provides

is used by/uses Works for


8/13

| 7 |


Guidelines: Entity names must be generic nouns. Actions and proper

nouns should never be used as object names. Proper

nouns may be added as instances of an object asshown in the diagram above

The model should go down to the attribute level; but with

attributes clearly marked with dotted lines. The correct

way to approach this is to first complete the high level

entities, then keep detailing the entities till all fields are

covered

The Objects are absolute definitions; the role shows

the relationship with another object. The first time modeler

often makes the mistake of using the role as the class

name. For example, Address is a valid object. Home

address, Office address or Branch location are all

valid roles for an address relative to another object.Be very ca reful not to create Home Address as an

object class in its own right. If certain attributes only

make sense to a t ype of role, ORM provides constraint

modeling notations to capture this. Modeling this way

makes it much easier to standardize data across the

enterprise

Do not attempt to capture state changes in the ORM

diagram. For example, there should not be Active

customer and inactive customer as two different

objects. Instead, Is Active would be a unary role

against the Customer object

TaxonomyA top level taxonomy would need to be defined and

maintained centrally. Within each taxonomy heading there

needs to be one overview diagram showing the key

entities within the heading. Each key entity would have its

own diagram that provides the attributes for the entit y.

If there are complex constraints that need to be captured

between entities, then these would be named after the key

entity that is taken as a starting point for the diagram.

Business ProcessesThe intention of the business process model is to capture

the interactions between the different participants in the

process.

Guidelines: Each role and application involved should have its own

pool in the business process diagram

If a user performs a task by interacting with the system,

there needs to be an indication of the dialog between

the human and the system. The system action is to

present data to the user, or react to the users input. The

users actions are to review the data and respond.

The process models should be built iteratively, starting

from a very coarse model. The model should be

continuously detailed till all interactions between systems

are broken down. Actions within a system should not bebroken down unless they are decisions that change the

way the system interacts with other systems

Each task performed by a system would need to be

traced to the function inventory, so should use the same

wording as in the function inventory If the function falls within a specific taxonomy

hierarchy within the appl ication this is represented in the

BPM diagram using swim lanes within the pool

representing the system

The BPM diagram should be annotated with data that is

passed between people or systems during interactions.

The terms used must correspond to terms from the ORM

model

The definition of exceptions, timers and compensating

transactions should be used where appropriate, adhering

to a standard understanding of when each is to be used:

- Exception: An exception is a system or external

event that should not occur, but could happen.

Exceptions should not be used for decisions and

validations. For example, a date of bir th field

having a value >= today is a validation error.

An inability to retrieve the date of birth field from the

database is an exception. The number of records in a

file not matching the record count specified in the

footer of a file is an error. If the reading of a file from

the hard disk is interrupted, and the footer itself

cannot be read, it is an exception.

- Timer: Timers can be used to indicate the scheduled

start of an activity, to capture service level

guarantees for a task, or to show notifications ortriggers that get sent if a task is not completed by a

particular point in time.

- Compensating transactions: If an exception occurs,

and steps need to be taken to bring the system back

to a consistent point of recovery; then we use

compensating transactions. If, for example, child

records are created before the parent, but there is

an error creating the parent, compensating

transactions need to be executed to delete the parent

record. Showing these as compensating transactions

allows for them to be coupled with the functions the

are compensating. Therefore, if the function ischanged in the future, designers and developers will

be aware that the compensating function also needs

to be updated.

TaxonomyBusiness processes are grouped by depar tment. Most

processes will involve more than one depar tment. In such

cases, the department with primary accountability for

timely completion of the processes is considered to own the

process. [NOTE: This may not be the department with the

most tasks].


9/13


| 8 |

Function InventoryThe function inventory is a list of use cases as per the

formal definition: a description of a systems behavior as

it responds to a request that originates from outside of thatsystem. The business process modeling activity shows the

externally visible functionality from the system, and drives

the evolution of the function inventory of the organization.

Guidelines: The nomenclature of functions needs to be formalized and

standardized across the organization.

Some recommendations are:

- Use forms for use cases. Generate

Invoice, Post the journal entry, Send email

- Instead of having separate Add / Modify

/ Delete use cases, use a single

Maintain function

Organization Structure / Roles andResponsibilities / Geographic Distribution

A critical element in the Enterprise Architecture are theselists:


Roles and responsibilities


The framework provides a single ontology for each of these

lists. The ontologies may need to be extended to handle

variations from organization to organization.

Company Legal Entity Tradem arked Company Name

GeographyOrganizational

Unit

Person

Role

Resource

Function

System

... Performs .../... Performed by...

... Belongs to .../... Located in...

... Belongs to .../... Structured as...

... Has a .../... Name of...... Registered as .../... Is an operating arm of ...

... Owns .../... Belongs to......Requiredby

.../...Require

s...

... Performs .../... Performed by...

... Managed by .../... Administers...

... Owned by .../... Accountable for ...


10/13

| 9 |


Application ArchitectureApplication architecture documents are interconnected

with the enterprise architecture through the use of shared

artifacts, using the same notations.

The application architecture format recommended is al igned

to the IEEE 1471-2000 standard for appl ication architecture

documentation. It uses a pragmatic version of the 4+1

views approach to capture the a rchitecture of application.

Guidelines: The Business Process Model section must include

special IT operations that may be needed for the

application. For example, if the system includes aconnection to an external organization, then the process

for setting up a system to system handshake with the

external organization must be included in the BPMN

process diagrams, and the functionality required to meet

these needs included in the technical solution section.

The standard IT development practices to achieve the

functionality would not be included in the architecture

document. If a 3rd party tool is used that requires its own

development practices (including its own configuration

management and release control process), then it must be

covered in the enterprise Infrastructure and IT process list,

and referenced from the architecture document.InfrastructureThe enterprise infrastructure is the consolidation of physical

system views from each application architecture document.

Where the multiple applications are co-hosted on the same

infrastructure, the model shows this hierarchy.

IT OperationsThis is an aggregation of development, configuration

management, system run time operational controls for all the

applications and systems listed in the system.

The IT operations would be captured as BPMN diagrams,

showing the different IT roles, and the da ily processes,as well as handling of exceptions and notifications from

systems.

It provides the application teams and the enterprise with

a holistic view of the tasks to support the applications

currently in use, and the impact of new technologies and

applications on existing IT processes and total cost of

ownership factors.

Context Model:Subset of enterprise ORM model relevant to the application

Business process Model:Subset of enterprise BPMN model relevant to the application

Organization Context:Subset of enterprise Organization charts, roles & responsibilitiesand geographic distribution that are relevant to the application

Function List:Subset of enterprise function list that is implemented in theapplication. IMPORTANT NOTE: multiple applications mayimplement the same function. The enterprise wide function listprovides a mapping to each application that implements thatfunction

Business Architecture

Addresseig Architecturally significant use casesTechnical solution to achieve each architecturally eignificant usecase

Hon Functional eceteenocentreTechnical solution to achieve each non functional requirenent

Solution Section

Logical viewObject model view of the data managed by the systen. In UMLentity model format with custom meta data extensions

Development viewComponent model view of the system. Each component specifedin the solution section needs to be shown here, showing it'sinteraction with other components.

Physical View - SystemsWiring diagran showing the physical realization of the solutionwill also include the inputs from the non-fundional requirements

Physical view- DataA high level view of the data that is outsied of prcgram logic.This includes Databases and database schema / ln-memorydata caches shared between processes /Files

Scenarios -State DiagramsFor key entities that are modified by different functicns, use UMLState diagrams to show the fundions /triggers that cause statechanges, and map these to the physical realization of the states

Scenarios -Activity or Sequence DiagramsFor key functions, use activity or sequence diagrams to showthe diffrent components involved, and the interactions beteeen

them

Application Architecture (4+1 views)

Meta datapoints to

ORM

TaskIn a

Process

Step bystep

playback

How itsachieved

Roles inswirn lanes

Data tags in thediagram

Fig 8. Application architecture document structure


11/13


| 10 |

A Realistic Approach to Buildingthe Models

Given the level of details in each model, it is clear that try-ing to build a complete model for an organization as an

exercise would be near impossible. However, we have seen

that the approach works even if the entire breadth of the

model is not in place. What is critical is the layered and

systematic approach starting from the enterprise inventory;

through utilization context to the capability model.

Since the enterprise structure is an upwards aggregation

from the architecture documents for a single application, it

becomes possible to run projects independently; but to put

their work products into the enterprise framework.

For this bottom up approach to work, governance of the

aggregated enterprise model needs to placed with a small

team that has the bandwidth to ensure that each applica-

tion architect is correctly building the artifacts, and is

correctly integrating these into the enterprise wide model.

With each subsequent application architecture that is

added to the enterprise framework there would be less

effort required, as most of the elements would already be

included in the enterprise model.

Support Operations




Business Processes

Utilization Context

IT Operations

Infrastructure

Applications

Capability to deliverthe assets



Enterprise Assets

Version 1.1

Support Operations




Business Processes

Utilization Context

IT Operations

Infrastructure

Applications




Enterprise Assets

Version 1.3

Support Operations




Business Processes

Utilization Context

IT Operations

Infrastructure

Applications




Enterprise Assets

Version 1.2

Application 1 Application 2 Application 3

Fig 9. Enriching the Enterprise Architecture in Iterations


12/13

| 11 |


The FutureService oriented architecture, Business Process Modeling

and Semantic Web initiatives are significantly changingthe way we look at enterprise architecture. The process

described here is still largely driven by the skill of the

business analysts and architects involved. Today several

standards bodies are working to define industry wide

semantic ontologies and service definitions built on these

semantic standards.

As industry ontologies become more formalized, a large

percentage of the effort needed to build the type of

enterprise architecture framework outlined here will drop

dramatically.

Industry wide initiatives such as SUPER (see the furtherreading section for links) are already looking forward to

the time when this type of ontology driven enterprise

framework is in place.

Further Reading BPMN:

- The Business Process Modeling Notation standard ismaintained by the Object Management Group.

The formal site is: http://www.bpmn.org/

ORM:

- The Object Role Model notation is driven today

largely by the ORM foundation:

http://www.ormfoundation.org/

Formal Standards for Architecture Documentation

- IEEE standard 1471-2000: IEEE Recommended

Practice for Architectural Descriptions of Software

Intensive Systems, Architecture Working Group of the

Software Engineering Standards Committee, 2000 isthe formal standard for building documentation. The

standard does not, however, mandate specific

notations.

- The Software Engineering Institute under Carnegie

Mellon University has a detailed section on capturing

software architecture following the IEEE standard:

http://sei.cmu.edu/architecture/tools/viewsandbe

yond/

4+1 Architecture Views in UML:

- The formal definition of the 4+1 architecture views

can be found here:

http://people.cs.ubc.ca/~gregor/teaching/papers/4%2b1view-architecture.pdf

- However, a more accessible version of the 4+1 views

can be found here:

http://epf.eclipse.org/wikis/openup/core.tech.

common.extend_supp/guidances/examples/four_

plus_one_view_of_arch_9A93ACE5.html

SUPER or Semantics Utilised for Process management

within and between EnteRprises

- http ://www.ip-super.org/


13/13


| 12 |

Abou MpasS

MphasiS is a $1 billion global service provider, delivering technology based solutions toclients across the world. With currently over 41,000 people, MphasiS services clients in

Banking and Capital Markets, Insurance, Manufacturing, Communications, Media &

Entertainment, Healthcare & Life Sciences, Transportation & Logistics, Retail & Consumer

Packaged Goods, Energy & Utilities, and Governments around the world. Our competency

lies in our ability to offer integrated service offerings in Applications, Infrastructure Services,

and Business Process Outsourcing capabilities. We are uniquely positioned to offer our clients

the highest level of expertise and competitive costs. To know more about MphasiS, log on to

www.mphasis.com

Conac us

USAMphasiS460 Park Avenue South

Suite # 1101, New York

NY 10016, U.S.A.

Tel: +1 212 686 6655

Fax: +1 212 686 2422

UK

MphasiS88 Wood Street

London EC2V 7RS, UK

Tel: +44 208 528 1000

Fax: +44 208 528 1001

AUSTRALIAMphasiS

9 Norberry Terrace,177-199 Pacific Hwy,North Sydney, 2060,

AustraliaTel: +61 2 99542224Fax: +61 2 99558112

INDIA

MphasiSBagmane Technology Park

Byrasandra

C.V. Raman Nagar

Bangalore 560 093, India

Tel: +91 80 4042 6000Fax: +91 80 2534 6760

MphasiS and the MphasiS logo are registeredtrademarks of MphasiS Corporation. All other brandor product names are trademarks or registered marks

of their respective owners. MphasiS is an equalopportunity employer and values the diversity of its

people. Copyright MphasiS Corporation. All rightsreserved.

0311

Building a Formal Enterprise Architecture Model

Documents

Transcript of Building a Formal Enterprise Architecture Model