Building a Formal Enterprise Architecture Model
-
Upload
ramesh-rajagopalan -
Category
Documents
-
view
224 -
download
0
Transcript of 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
-
7/31/2019 Building a Formal Enterprise Architecture Model
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
-
7/31/2019 Building a Formal Enterprise Architecture Model
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
-
7/31/2019 Building a Formal Enterprise Architecture Model
4/13
| 3 |
I MphasiS White PaperBuilding a Formal Enterprise Architecture Model
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
Capability to deliver the assets
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
-
7/31/2019 Building a Formal Enterprise Architecture Model
5/13
MphasiS White Paper I Building a Formal Enterprise Architecture Model
| 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
Geographic Distribution
Organization Structure
Roles and Responsibilities
Support Operations
Utilization Context V4Business Processes
Geographic Distribution
Organization Structure
Roles and Responsibilities
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 Information Model
Enterprise Assets V4
Functionality Inventory
M2M1 M3 M4 M5 M6 M7
Time
Fig 4. Model versions in production
-
7/31/2019 Building a Formal Enterprise Architecture Model
6/13
| 5 |
I MphasiS White PaperBuilding a Formal Enterprise Architecture Model
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
Enterprise Information Model
ApplicationsUC1 V3
UC1 V4
InfrastructureS1 V1
IT Operations
Capability to deliver the assets
Business ProcessesBP1 V3
BP2 V1
Organization Structure
Roles and Responsibilities
Geographic Distribution
Support Operations
Utilization Context
Version 1 (As Is)Enterprise Assets
Functionality InventoryF1 V1
F2 V1
Enterprise Information Model
ApplicationsUC1 V3
UC2 V5
Infrastructure
IT Operations
Capability to deliver the assets
Business ProcessesBP1 V3
BP2 V2
Organization Structure
Roles and Responsibilities
Geographic Distribution
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/31/2019 Building a Formal Enterprise Architecture Model
7/13
MphasiS White Paper I Building a Formal Enterprise Architecture Model
| 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
-
7/31/2019 Building a Formal Enterprise Architecture Model
8/13
| 7 |
I MphasiS White PaperBuilding a Formal Enterprise Architecture Model
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].
-
7/31/2019 Building a Formal Enterprise Architecture Model
9/13
MphasiS White Paper I Building a Formal Enterprise Architecture Model
| 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:
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.
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 ...
-
7/31/2019 Building a Formal Enterprise Architecture Model
10/13
| 9 |
I MphasiS White PaperBuilding a Formal Enterprise Architecture Model
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
-
7/31/2019 Building a Formal Enterprise Architecture Model
11/13
MphasiS White Paper I Building a Formal Enterprise Architecture Model
| 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
Geographic Distribution
Roles and Responsibilities
Organization Structure
Business Processes
Utilization Context
IT Operations
Infrastructure
Applications
Capability to deliverthe assets
Enterprise Information Model
Functionality Inventory
Enterprise Assets
Version 1.1
Support Operations
Geographic Distribution
Roles and Responsibilities
Organization Structure
Business Processes
Utilization Context
IT Operations
Infrastructure
Applications
Capability to deliverthe assets
Enterprise Information Model
Functionality Inventory
Enterprise Assets
Version 1.3
Support Operations
Geographic Distribution
Roles and Responsibilities
Organization Structure
Business Processes
Utilization Context
IT Operations
Infrastructure
Applications
Capability to deliverthe assets
Enterprise Information Model
Functionality Inventory
Enterprise Assets
Version 1.2
Application 1 Application 2 Application 3
Fig 9. Enriching the Enterprise Architecture in Iterations
-
7/31/2019 Building a Formal Enterprise Architecture Model
12/13
| 11 |
I MphasiS White PaperBuilding a Formal Enterprise Architecture Model
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/
-
7/31/2019 Building a Formal Enterprise Architecture Model
13/13
MphasiS White Paper I Building a Formal Enterprise Architecture Model
| 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