white PAPeR

Building a Formal enterprise Architecture Model

Suresh Nair, Chief Architect Financial Services March, 201 1

Building a Formal Enterprise Architecture Model I MphasiS White Paper

Table of Contents
Abstract The Problem Statement The Goals of this Framework The Purpose of EA Drivers for Change Business and IT Roadmaps The Models Concept Model Business Processes Function Inventory Organization Structure / Roles and Responsibilities / Geographic Distribution Application Architecture Infrastructure IT Operations A Realistic Approach to Building the Models The Future Further Reading 2 2 2 2 3 4 6 6 7 8 8 9 9 9 10 1 1 1 1

| 1 |

MphasiS White Paper I Building a Formal Enterprise Architecture Model

Abstract
This white paper outlines a pragmatic and easy to understand process we have followed in building enterprise architecture (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 Goals of this Framework

This white paper attempts to define a process and a set of models to capture the enterprise architecture that avoids these 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 well as 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 Problem Statement

Several robust standards exist for Enterprise Architecture today; each with subtle differences on the governance and delivery models.

Problem 1: Coarse Granularity & Fuzziness

Enterprise 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 getting 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 Details

While 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 initiatives the overhead of defining documentation standards and managing actual documentation can be problematic.

The Purpose of EA
This 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 supported 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

Problem 3: Moving Targets

While 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 project cycles for applications, maintaining EA models becomes and overhead.

| 2 |

Building a Formal Enterprise Architecture Model I MphasiS White Paper

Drivers for Change

In any organization, there would be two parallel paths of change; business driven change and technology driven change.
Business Drivers Cost reduction drives Audit findings Changes in the market place Mergers / acquisitions/ restructuring New regulations or operating controls
Process changes

Changes due to Business Drivers

New functionality needs Newaudit/control/ regulations

New Products or offerings

New roles

New data needs

Fig 1. Examples of business driven change

Technology Drivers
Data center operational changes

Vendor driven upgrades / platform changes

Changes due to Technology Drivers

Major version or vendor changes for COTS Application Capacity increase hosting changes / virtualization
Integration changes Outsourcing external hosting

Technology consolidation mandates

Security winerability identification Mergers / acquisitions / restructuring

IT operations or control changes

Fig 2. Examples of technology driven changes

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 Functionality Inventory Enterprise Information Model
Business Driven Changes

Version2 (Go To)

Enterprise Assets
Functionality Inventory V2 Enterprise Information Model V2

Capability to deliver the assets Applications Infrastructure

Capability to deliver the assets

Applications V2 Infrastructure V2

IT Operations Utilization Contest

Business Processes Geographic Distribution Organization Structure Roles and Responsibilities

IT Operations V2

Utilization Contest
Technology Driven Changes
Business Processes V2 Geographic Distribution v2 Organization Structure V2 Roles and Responsibilities V2

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 <Implements> function, App <externally accesses> function, App <is system of record for> Entity and App <externally references> Entity - Infrastructure: Inventory of the Commercial Off the Shelf (COTS) software or hardware across the enterprise. Relationships are App <uses> hardware/ software. Only direct usage is traced. Dependencies between hardware and software is tracked within the infrastructure model - IT Operations: The tasks performed by IT to keep applications and infrastructure working smoothly are tracked. Functionality and Apps would be tracked to these tasks through Functionality <uses> task and App <dependent on> 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 captured in BPMN notation 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

Support Operations

Support Operations V2

Fig 3. Enterprise model changes

| 3 |

MphasiS White Paper I Building a Formal Enterprise Architecture Model

- Geographic Distribution: This places the organization structure and roles and responsibilities into a geographic context - Roles and responsibilities: An inventory of the different 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 service 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 Roadmaps

There is a fundamental over-simplification in the previous section in the representation of there being a single as is and go to state. A more accurate representation is to think of the utilization context as changing through a series of milestones. The business processes, organization structure and roles and responsibilities evolve continuously to respond to internal and external change drivers. 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.

M1

M2

M3

M4

M5 Time

M6

M7

Utilization Context V1 Business Processes Geographic Distribution Organization Structure Roles and Responsibilities Support Operations Capability V1 Applications Infrastructure IT Operations Capability V2 Applications Infrastructure IT Operations Enterprise Assets V1 Functionality Inventory Enterprise Information Model
Fig 4. Model versions in production

Utilization Context V2 Business Processes Geographic Distribution Organization Structure Roles and Responsibilities Support Operations Capability V3 Applications Infrastructure IT Operations

Utilization Context V4 Business Processes Geographic Distribution Organization Structure Roles and Responsibilities Support Operations Capability V4 Applications Infrastructure IT Operations Enterprise Assets V4 Functionality Inventory

Enterprise Information Model

| 4 |

Building a Formal Enterprise Architecture Model I MphasiS White Paper

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-is 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 ability 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

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 same model.

Projects
Any modern organization needs to change continuously. 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 capabilities 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.

Version 1 (As Is)

Enterprise Assets Functionality Inventory
F1 V1
F2 V1

Version 2 (Go To)

Enterprise Assets Functionality Inventory
F1 V1
F2 V1

Enterprise Information Model Capability to deliver the assets Applications

UC1 V3
UC1 V4

Project 1

Enterprise Information Model Capability to deliver the assets Applications

UC1 V3
UC2 V5

Infrastructure
S1 V1 S1 V2
S2 V1

Infrastructure

IT Operations Utilization Context Business Processes

BP1 V3 BP2 V1

Project 2

IT Operations Utilization Context Business Processes

BP1 V3 BP2 V2

Organization Structure Roles and Responsibilities Geographic Distribution Support Operations

Fig 5. How changes are clubbed into projects

Organization Structure Roles and Responsibilities Geographic Distribution Support Operations

| 5 |

MphasiS White Paper I Building a Formal Enterprise Architecture Model

Depending on the scope and effort involved in the change, projects can run for quite some time. Projects can only start after all predecessors are completed. In many cases projects should not be completed too early, or the work products cannot be moved into production without disrupting other applications or projects.

M1

M2

M3 M4

M5 Time

M6

M7

Utilization Context V1 Capability V1 Capability V2

Utilization Context V2 Capability V3

Utilization Context V4 Capability V4

Enterprise Assets V1
Project1 Project2 Project3
Fig 6. Aligning projects to milestones

Enterprise Assets V4

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.

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 empNr 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

provides
2345 LOC Extension 1221 INT
(extNr) Access Level (Code) has EmpName

The Models
Concept Model
The concept model would include all 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 modeling notation such as UML Class diagrams, Entity diagrams or Concept modeling notation.
Diagram includes sample data and volumes

715 Adams A 139 Cantor G

is used by/uses
2345 715 1221 139

Academic (empNr)

Works for

Dept (name)

715 Computer Science 139 Mathematics

<< occupies
Room (roomNr)

is contracted till
715 01/31/97

69-301 715 67-301 139

Date (mdy)

is tenured
139

Fig 7. Object role model notation

| 6 |

Building a Formal Enterprise Architecture Model I MphasiS White Paper

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 as shown 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 careful not to create Home Address as an object class in its own right. If certain attributes only make sense to a type 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

Taxonomy
A 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 entity. 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 Processes
The 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 be broken 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 application 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 birth 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 or triggers 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 is changed in the future, designers and developers will be aware that the compensating function also needs to be updated.

Taxonomy
Business processes are grouped by department. Most processes will involve more than one department. 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].

| 7 |

MphasiS White Paper I Building a Formal Enterprise Architecture Model

Function Inventory
The 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 that system. The business process modeling activity shows the externally visible functionality from the system, and drives the evolution of the function inventory of the organization.

Organization Structure / Roles and Responsibilities / Geographic Distribution

A critical element in the Enterprise Architecture are these lists: Organization Structure Roles and responsibilities Geographic Distribution 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.

Guidelines:
The nomenclature of functions needs to be formalized and standardized across the organization. Some recommendations are: - Use <verb> <noun> forms for use cases. Generate Invoice, Post the journal entry, Send email - Instead of having separate Add <entity> / Modify <entity> / Delete <entity> use cases, use a single Maintain <entity> function

Company

Legal Entity ... Has a .../... Name of...

Tradem arked Company Name

... Registered as .../... Is an operating arm of ... Geography

Organizational Unit ... Belongs to .../... Structured as...

Person System

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

Resource
... Owns .../... Belongs to...
... Required by .../... Requires...

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

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

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

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

| 8 |

Building a Formal Enterprise Architecture Model I MphasiS White Paper

Application Architecture
Application architecture documents are interconnected with the enterprise architecture through the use of shared artifacts, using the same notations. The application architecture format recommended is aligned to the IEEE 1471-2000 standard for application architecture documentation. It uses a pragmatic version of the 4+1 views approach to capture the architecture 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 a connection 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.

Business Architecture
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 & responsibilities and geographic distribution that are relevant to the application Function List: Subset of enterprise function list that is implemented in the application. IMPORTANT NOTE: multiple applications may implement the same function. The enterprise wide function list provides a mapping to each application that implements that function

Data tags in the diagram Roles in swirn lanes

Task In a Process Meta data points to ORM

Infrastructure
The 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 Operations
How its achieved

Solution Section
Addresseig Architecturally significant use cases Technical solution to achieve each architecturally eignificant use case Hon Functional eceteenocentre Technical solution to achieve each non functional requirenent

This 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 daily 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.

Application Architecture (4+1 views)

Logical view Object model view of the data managed by the systen. In UML entity model format with custom meta data extensions

Step by step playback

Development view Component model view of the system. Each component specifed in the solution section needs to be shown here, showing it's interaction with other components. Physical View - Systems Wiring diagran showing the physical realization of the solution will also include the inputs from the non-fundional requirements Physical view- Data A high level view of the data that is outsied of prcgram logic. This includes Databases and database schema / ln-memory data caches shared between processes /Files Scenarios -State Diagrams For key entities that are modified by different functicns, use UML State diagrams to show the fundions /triggers that cause state changes, and map these to the physical realization of the states Scenarios -Activity or Sequence Diagrams For key functions, use activity or sequence diagrams to show the diffrent components involved, and the interactions beteeen them

Fig 8. Application architecture document structure

| 9 |

MphasiS White Paper I Building a Formal Enterprise Architecture Model

A Realistic Approach to Building the Models

Given the level of details in each model, it is clear that trying 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 application 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.

Application 1

Application 2

Application 3

Version 1.1
Enterprise Assets Functionality Inventory Enterprise Information Model Capability to deliver the assets Applications Infrastructure IT Operations Utilization Context Business Processes Organization Structure Roles and Responsibilities Geographic Distribution Support Operations

Version 1.2
Enterprise Assets Functionality Inventory Enterprise Information Model Capability to deliver the assets Applications Infrastructure IT Operations Utilization Context Business Processes Organization Structure Roles and Responsibilities Geographic Distribution Support Operations

Version 1.3
Enterprise Assets Functionality Inventory Enterprise Information Model Capability to deliver the assets Applications Infrastructure IT Operations Utilization Context Business Processes Organization Structure Roles and Responsibilities Geographic Distribution Support Operations

Fig 9. Enriching the Enterprise Architecture in Iterations

| 10 |

Building a Formal Enterprise Architecture Model I MphasiS White Paper

The Future
Service oriented architecture, Business Process Modeling and Semantic Web initiatives are significantly changing the 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 further reading 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 is maintained 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 is the 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/

| 1 | 1

MphasiS White Paper I Building a Formal Enterprise Architecture Model

Contact us
MphasiS
460 Park Avenue South Suite # 1 , New York 101 NY 10016, U.S.A. Tel: +1 212 686 6655 Fax: +1 212 686 2422

About MphasiS
MphasiS is a $1 billion global service provider, delivering technology based solutions to clients 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

USA

MphasiS
88 Wood Street London EC2V 7RS, UK Tel: +44 208 528 1000 Fax: +44 208 528 1001

UK

MphasiS 9 Norberry Terrace, 177-199 Pacific Hwy, North Sydney, 2060, Australia Tel: +61 2 99542224 Fax: +61 2 995581 12 MphasiS

AUSTRALIA

INDIA

Bagmane Technology Park Byrasandra C.V. Raman Nagar Bangalore 560 093, India Tel: +91 80 4042 6000 Fax: +91 80 2534 6760

MphasiS and the MphasiS logo are registered trademarks of MphasiS Corporation. All other brand or product names are trademarks or registered marks of their respective owners. MphasiS is an equal opportunity employer and values the diversity of its people. Copyright MphasiS Corporation. All rights reserved.

| 12 |

0311