Enterprise architecture concepts

Semyon’s Enterprise Change & Transformation Toolbox ©Semyon Axelrod, 2015 Page 1
Enterprise Change &
Transformation Toolbox
“If you think good architecture is expensive, try bad architecture.”
Big Ball of Mud,
Brian Footeand Joseph Yoder
©Semyon Axelrod, 2015

Contents
Executive Summary............................................................................................................ 3
Introduction......................................................................................................................... 5
The Main Tool – Three-Layered Enterprise Architecture Model................................... 5
TLEAM’s Main Sources and Major Tenants...................................................................... 7
TLEAM’s Main Sources................................................................................................. 7
Brief TLEAM Tenants Overview ................................................................................... 7
Operating Model Architecture .................................................................................... 7
Business Capabilities Model....................................................................................... 8
Unified Modeling Language ....................................................................................... 9
Other important techniques that are not directly included as TLEAM submodels........... 10
Zachman framework ..................................................................................................... 11
TOGAF ......................................................................................................................... 11
Federal Enterprise Architecture .................................................................................... 12
The Four Domains of Enterprise Architecture Knowledge .......................................... 12
Corporate Information Factory ..................................................................................... 13
Concepts of Operations (ConOps) ................................................................................ 14
TLEAM Fundamentals ..................................................................................................... 15
The Power of Layering ................................................................................................. 15
Horizontal Traceability within the Layers .................................................................... 15
Business-Centric Layer................................................................................................. 16
Specification-Centric Layer .......................................................................................... 19
Implementation-Centric Layer...................................................................................... 20

Executive Summary
There are many excellent definitions of System Architecture that have been
proposed and used in the information technology field. Some of these are quite
long1, but one that I prefer was likely developed by a CPA rather than by a
software engineer or an architect: “Important decisions about expensive things”.
This succinct definition resonates even at a single-system level, but is even more
appropriate at the Enterprise level.
In this day and age of rapid technological and business changes impacting the
very core fabric of our lives in an infinite number of often unpredictable ways,
Enterprise Architecture (EA) provides an invaluable knowledge base for any
enterprise that aspires to keep up with these changes and proactively use then for
competitive advantage. Skillful application of the EA principles and concepts not
only enables, but also drives an improved quality of analysis and decision making,
in turn leading to better business outcomes.
One popular view of EA sees it as “the process of translating business vision and
strategy into effective enterprise change by creating, communicating, and
improving the key requirements, principles, and models that describe the
enterprise’s future state and enable its evolution and transformation.”2
A pragmatic approach described below called Three Layered Enterprise
Architecture Model (TLEAM) can provide great value for business and IT efforts
aimed at translating business vision and strategy into effective business
improvement supported by innovative and efficient technology. Such an
approach has been developed incrementally over the last 10 years by integrating
and extending various concepts and techniques from popular enterprise
architecture, as well as information system development methodologies, standards
and practices. The goal was to create a robust, rigorous, and, above all else,
affordable approach. While the benefits of this approach are accessible to IT
professionals, their business counterparts are the ultimate beneficiaries.
The approach, in a nutshell, can be described by the two main tenets:
 Emphasis on using well-aligned business-centric and technology-centric
models;
 Validation of the business information models by analyzing them within
contextually specific business process (a.k.a. behavioral) models.
1 The one that is most commonly used is defined in ISO/IEC 42010:2007, Systems and Software
Engineering -- Recommended practice for architectural description ofsoftware-intensive systems standard.
“The fundamental organization of a systemembodied in its components,their relationships to each other,
and to the environment, and the principles guiding its design and evolution.”
2 Master of Professional Studies in Enterprise Architecture, Penn State online. Retrieved from website 02-
17-2015

Below are some challenges where the application of the methodology has been of
tremendous benefit:
 Identification of an IT investment strategy with the highest return
potential;
 Establishment and maintenance of effective Business- IT priorities
alignment;
 Identification of financial and other compliance reports reconciliation
errors’ root causes;
 Resolving co-ownership issues of business data by multiple divisions and
departments, and the transition of ownership between departments within
business process stages;
 Improvement in overall system and data quality through reduction of
duplicate information, and better alignment/integration between various
business processes;
 Improvements in business outcomes due to ability to get necessary
decision-supporting information in a timely fashion and in a customer-
friendly way.
Applying TLEAM's main tenets and focusing initially on the Business-Centric
Layer of the model can drive savings in strategic business and IT alignment,
overall business information and data quality improvements, M&A activities and
other key strategic Business and IT initiatives.

Introduction
The MainTool – Three-LayeredEnterprise Architecture
Model
Any successful EA initiative should include a high-level description of the
architecture in the form of graphical models and a pertinent narrative. These are
very important as they provide the foundation for the design work to develop
additional details and make the concepts used in EA models a practical reality at
the system implementation level.
Not surprisingly, the most important technique in my toolbox is a graphical model
which serves as a nexus for all the other leveraged techniques and concepts.
This modeling approach was inspired mainly by combining two core concepts.
The first is a partitioning concept developed by S. Cook and J. Daniels3, who
found it very useful to separate all the models into three interrelated domains: the
essential, specification, and implementation domains.
The second concept is a similar yet distinct approach which belongs to the area of
system development known as Model Driven Architecture (MDA). It also
partitions models into three layers, but these MDA layers have a different purpose
as compared to the Cook and Daniels’ approach, and naturally have different
names: the Computationally Independent Model, the Platform Independent
Model, and the Platform Specific Model.
I have developed and successfully used a modeling approach that is inspired by a
synthesis of these two aforementioned approaches as well as some other concepts
and methodologies. In my practice, I also found it extremely useful to segregate
all models and artifacts into three universal layers that are relevant to all
companies regardless of their industry, size, culture, etcetera:
 The Business-Centric Layer;
 The Specification-Centric Layer;
 The Implementation-Centric Layer.
I called this graphical representation of my EA approach the Three Layered
Enterprise Architecture Model (TLEAM) diagram (fig. 1 below).
The multiple [sub]models that are hosted by the TLEAM layers in turn can be
grouped into three main categories: the behavioral (a.k.a. How/Function column
in Zachman framework), the information/data (a.k.a. What /Data column in
Zachman framework), and the auxiliary. The auxiliary group, in turn, can be
broken down into more specific “elementary” areas according to the Zachman
framework approach.
3 “Designing Object Systems: Object-Oriented Modelling with Syntropy”,1994, Prentice Hall; ISBN:
0132038609

Once the dependencies between the different models in the TLEAM layers have
been established, documented, and internalized into corporate knowledge and
culture, the common understanding can and should be used by the Enterprise
leadership in their decision-making process.
The richness of information expressed by all models that TLEAM hosts, and the
rigorous correlations between them, allow a more robust analysis, safety checks,
and enabling necessary controls at the Enterprise level.
Business
Capabilities
Model
Principles
and
Policies
Business-Centric Layer
Enterprise Business Information Model/Ontology
Business Strategy
ConOps
Implementation-Centric Layer
Technology
Standards
and Guidelines
Enterprise
Design
Patterns
Enterprise System
A
Specification
Enterprise
Technical Integration
Architecture Model
Specification-Centric Layer
XML SchemasComponentsServices
System Specification Information Model / Fact Model
Physical System Information (a.k.a. Data) Model
© Semyon Axelrod
Three Layered Enterprise Architecture Model
Business Use
Case Model
Database
Rules&
Workflows
Rules Engine Workflow Engine
Operating
Model
Business
Patterns
V 8.3.
Business Use Case
Realization Model
Enterprise IT
Governance
Core Enterprise
IT Assets
LOB Information Model
Figure 1. Three Layered Enterprise Architecture Model4
4 For more information about the model please see: “Quality Data Through Enterprise Information
Architecture”, The Architecture Journal, January 2007.

The approach outlined by the TLEAM is the main tool in the toolbox: all other
models, techniques, mechanisms, concepts, and building blocks are correlated
with it. It is further explained in the “TLEAM Fundamentals” section below.
TLEAM’s Main Sources and Major Tenants
TLEAM’s Main Sources
The main techniques of the approach were inspired by5:
 Guidelines for object-oriented analysis and design developed by Steve
Cook and John Daniels in their book “Designing Object Systems: Object-
Oriented Modelling with Syntropy”;
 Enterprise Operating Model and the corresponding Conceptual Enterprise
Architecture model as described by Peter Weill, Jeanne Ross and David
Robertson’ in their book “Enterprise Architecture as Strategy”;
 OMG’s Model Driven Architecture (MDA)6;
 Business Capabilities Modeling;
 OMG’s Unified Modeling Language (UML).
Brief TLEAM Tenants Overview
As outlined in Figure 1 above, TLEAM’s three layers host a wealth of
[sub]models partitioned into: behavioral, information/data, and auxiliary. In the
Business-Centric layer, this separation is quite clear. Color-coding indicates this
distinction: models that are behavioral in nature have red frames; information/data
models have green; and the auxiliary group, which has composite (hybrid) nature,
has blue frames.
While all [sub]models are important, some of them need more introduction than
the others, either because they are less known, as in case of the Operating and
Business Capabilities Models; or because, as in the case of UML, they play such a
central role.
A brief description of the tenants that meet these unique stipulations follows.
Operating Model Architecture
One of the most powerful tools in the EA toolbox is the concept of the Operating
Model.
Arguably, the best book that proves the importance of EA for the modern
Enterprise is “Enterprise Architecture as Strategy”7. Drawing on a wealth of case
studies from a variety of industries and sectors, the authors demonstrate that the
5 The described EA TLEAM approach reflects only my own ideas and experience. It has neither been
reviewed nor endorsed by the organizations and/or authors of the other referenced methodologies.
6 http://www.omg.org/mda/
7 “Enterprise Architecture As Strategy: Creating a Foundation for Business Execution” by Jeanne W. Ross,
Peter Weill and David Robertson. Harvard Business Press, 2006, ISBN: 9781591398394,

ability to transform an organization into a top performer is predicated on
developing a robust foundation for execution in the form of Enterprise
Architecture. For the purpose of this document, I will use the term “Operating
Model Architecture” to describe the Operating Model-based approach to the
development of EA, as introduced in the aforementioned book.
While the book offers many insights and useful techniques, its main value is
rooted in the in-depth research of the Operating Model – the desired level of
business process integration and standardization and related EA imprint on
business performance. That research proves that business strategies, commonly
expressed in the form of PowerPoint presentations and financial models, are not
sufficiently rigorous and robust to define a well-built foundation for development
and execution at the Enterprise level. The Operating Model Architecture (OMA)
built around common customers and products on one side, and the balance of
Enterprise versus local business units’ and divisions’ interests on the other, is
needed to provide sufficient guidance for the development of a robust foundation
for execution at the Enterprise level. This technique can be used to establish
consensus about:
a) business capabilities and processes that are common and therefore good
candidates to be standardized and used by multiple business units
b) shared core business (i.e., information, business services) and IT (i.e.,
applications, infrastructure, etc.) assets that are needed to support these
common business capabilities and processes.
Business Capabilities Model
The second technique of the EA toolbox is inspired by a concept of business
capability researched, developed, and refined by Michael Porter, Ric Merrifield,
Ulrich Homann, Michael Rosen, William Ulrich, Roger Sessions and others. This
concept is used to build a business value network model, which resides in the
Business-Centric Layer of the TLEAM.
According to Ulrich Homann, “business capability is a particular ability or
capacity that a business may possess or exchange to achieve a specific purpose or
outcome. A capability describes what the business does (outcomes and service
levels) to add value for customers. A business capability abstracts and
encapsulates the people, process/procedures, technology, and information into the
essential building blocks needed to facilitate performance improvement and
redesign analysis.”8
In my experience, the business capability concept works very well for creating a
robust view of the business, whereas albeit commonly used, the organizational
chart views and/or detailed business processes views are too brittle and thus do
not provide the required stable foundation.
8 “A Business-Oriented Foundation for Service Orientation” Ulrich Homann, MSDN, 2006.

It is also possible and very beneficial to apply the Business Capabilities Model in
conjunction with, and as an elaboration of, the Operating Model Architecture
(OMA) described above. The Business Capabilities Model provides an additional
level of detail that connects the OMA, which deals mainly with the level of details
that exist in the realm of C-level executives, with the more detail system and
services specification dominion of software engineering, e.g., Service Oriented
Architecture (SOA). At this more detailed level, the Business Capabilities Model
fortified by the OMA can be used to guide validation of the IT Asset Portfolio and
IT Programs priorities, and the creation of system specifications (SOA or
otherwise). The synergy between the two models produces a much more robust
outcome than if each was applied independently.
For a more detailed explanation regarding how this synergy works please see the
“Business-Centric Layer” part of the “TLEAM Fundamentals” section below.
Unified Modeling Language
Another important ingredient of the TLEAM approach is the Unified Modeling
Language (UML). UML is a modeling language widely used by software
developers and architects. The UML standard is managed by the Object
Management Group (OMG)9.
Martin Fowler has established a notion of three different ways that UML is
currently used by system development practitioners: programming language,
blueprint, and sketch modes. It is important to note that according to this
classification, I currently use UML in the blueprint and the sketch modes.
In TLEAM, UML is the "glue" that is used to align the techniques of the approach
as well as to fill in the gaps between them. I use a number of UML models and
diagrams to capture both behavioral and information/data - oriented models: Class
and Object diagrams, State Transition diagrams, and Business and System Use
Case models just to name a few.
UML’s support for meticulous validation of business information structures and
elements within the context of the relevant business process models, i.e., Use
Cases Realizations or Activity diagrams and other similar techniques, enables
both main approaches’ tenets stated above in the Executive Summary section.
Since UML contains both information (a.k.a. data) and behavioral models (e.g.,
Business Use Case Realizations), it enables the validation for correctness and
completeness of information as well as business process models in the Business-
Centric Layer by requiring cross-referencing of the entities against each other.
This is achieved by requiring specially designated staff members, e.g., data
stewards to validate the common meaning of business attributes and information
structures that contain these attributes within the context of business processes
9 http://www.uml.org/

that use them. See more information on this process in the Appendix A “A
Process for Information and Data Management”.
The behavioral models that are not originated through UML can also be validated,
as long as they can be detailed down to the individual business attribute (a.k.a.
data element) level.
This support for correlation of the different behavioral [sub]models within the
Business-Centric layer enables robust business models analysis and early
identification of the gaps and inconsistencies. Also, as it is well-known from
numerous research reports, reducing the number of defects in the business
analysis and requirements phase allows for massive savings in the overall cost of
system development10 and assists business leadership in clarifying their vision and
mission.
Since UML is consistently used in all three TLEAM layers, including the
Business-Centric layer, it is possible to not only correlate information models
with the process models within the same layer, but also to relate models from
different layers and thus analyze the impact of changes regardless of where these
changes were initiated, on the business or technology side of the organization.
Changes originated in the Business-Centric layer would require traversing
TLEAM layers top-down, while changes discovered in the Implementation-
Centric Layer would naturally require TLEAM navigation in the opposite
direction: bottom-up.
The publication of the Ontology Definition MetaModel (ODM) specification by
OMG connects UML with OWL and RDF that were initially defined to provide
an XML-based machine to machine interchange of metadata and semantics.
ODM now integrates these foundational WWW technologies with UML-based
visual modeling. The connection between Model-Driven Architecture and
ontologies engineering concepts that ODM specification provides makes it easier
to use UML in TLEAM as a specification programming language in addition to
the current usage for blueprint and sketch.
Other important techniques that are not directly
included as TLEAM submodels
A number of other techniques also deserve attention as they provide a valuable
addition to the basic TLEAM palette. While it is not possible to cover all the
deserving methodologies and approaches within this paper, it is necessary to
mention at least a few that have the most significant value and can be used to
augment the TLEAM and its [sub]models.
10 “Understanding and Controlling Software Costs.” Boehm, Barry W., and Philip N. Papaccio. IEEE
Transactions on Software Engineering. 1988

Zachmanframework
No EA discussion is possible without mentioning the Zachman framework. The
framework launched EA as a discipline more than 20 years ago11 and is still
widely used today by EA practitioners.
John Zachman introduced the notion of Enterprise-wide classification, which can
be used for both “management of the Enterprise, as well as to the development of
the Enterprise's systems”12. This classification still serves as a foundation for most
of the EA approaches that are currently being used and developed. The Zachman
framework can be used as a great tool for a completeness check.
TOGAF
TOGAF is a close second to the Zachman framework with regards to frequency of
reference during any EA-related conversation. According to the TOGAF
website13, “TOGAF is a framework - a detailed method and a set of supporting
tools - for developing an Enterprise Architecture”.
While TOGAF is extensive and highly-detailed, it should be noted that it operates
within the same architectural domains as do most of the other EA frameworks:
 Business architecture
 Applications architecture
 Data architecture
 Technical architecture.
Arguably, the most important part of TOGAF is the Architecture Development
Method. “The ADM describes how to derive an organization-specific enterprise
architecture that addresses business requirements.”14 ADM documentation
includes a set of detailed guidelines and techniques.
Other important components of TOGAF include:
 Architecture Content Framework;
 TOGAF Reference Models, including the Foundation Architecture and the
Integrated Information Infrastructure Reference Model (III-RM);
 Architecture Capability Framework.
There is a lot of synergy between TLEAM and TOGAF as both use many
techniques that have served experienced software developers quite well.
However, the power of TLEAM is in that it provides unambiguous locations for
11 Zachman, J.A. "A Framework for Information Systems Architecture." IBM Systems Journal,Volume 26,
Number 3, 1987.
12 Zachman, John A. "The Framework for Enterprise Architecture: Background, Des cription and Utility."
Zachman Institute for Framework Advancement (ZIFA). Document ID: 810-231-0531
13 TOGAF® Version 9.1, retrieved from the Opengroup.org website 02-20-15
14 TOGAF® Version 9.1 Enterprise Edition, An Introduction.

almost any artifact that TOGAF can host, while at the same time the learning
curve for it is arguably much shorter (at least for the experienced software
developers and architects who have a basic command of UML).
Recent developments in TOGAF and ArchiMate allow for a very collaborative
and synergetic relationship between them and UML15.
Federal Enterprise Architecture
The Federal Enterprise Architecture (FEA), which was originally created as
Federal Enterprise Architecture Framework (FEAF), is a methodology for
creating EA. FEAF was established in 1999 by the Chief Information Officers
Council of the major Federal Agencies in response to the Clinger-Cohen Act of
1996. FEAF became FEA in 2002 and addresses a broad spectrum of issues
mostly relevant to Federal Agencies and other public sector organizations. The
purpose of the FEA is to facilitate the development of common processes and
information sharing among Federal Agencies. FEA is one of the most complete of
all the EA methodologies as it includes EA taxonomy, as well as an
organizational change management program with an architectural process to build
the taxonomy and other EA artifacts. While there is a wealth of very useful
information in the FEA compendium of documents, one of the best starting points
is: “A Practical Guide to Federal Enterprise Architecture.”16
The Four Domains of Enterprise Architecture Knowledge
This tool is more a concept than a technique. It has been originated by Forrester
Research – the partitioning of the Enterprise into four main Architectural
domains: Business, Application, Information, and Infrastructure. An extension of
this model includes seven subdomains (a.k.a. segments). The model (fig. 2)
provides an auxiliary view to the main model of the approach (The Three Layered
Enterprise Architecture Model mentioned above).
15 “The ArchiMate® visual modeling language standard is a natural choice for Enterprise
Architectures while, for Solution Architectures,the Unified Modeling Language® (UML®)
provides a wide range of views, concepts,and relationships. When architects make these
common and workable choices,understanding howto use the ArchiMate language and UML
togetheris necessary for efficient and precise alignment between the Enterprise and Solution
Architectures. The Open Group, “Using the ArchiMate® Language with UML®”
16 Chief Information Officer Council, Version 1.0, February 2001

Figure 2. Forrester Research Model of Core EA knowledge areas
As was the case for the Business Capabilities Model and OMA, the Three
Layered Enterprise Architecture Model and the Four Domains EA model are quite
synergetic. The value of the two techniques used together is greater than the value
of the two used independently due to their propensity to validate each other and
thus improve their efficacy. It is important to note that the Four Domains EA
Model represents the minimalist coarse-grained foundational view17 of EA, thus
providing the means for validation of the long-term completeness and
effectiveness of the EA program at a very fundamental level. However, this
model does not guide the EA practitioners towards specific deliverables that are
needed for implementation. At the same time, while the Three Layered Enterprise
Architecture Model provides a set of core deliverables, it may rely on the Four
Domains EA Model for validation of its completeness.
CorporateInformationFactory
The concept of Corporate Information Factory (CIF) was initially introduced by
W. H. Inmon, C. Imhoff and R. Sousa in 1998 in their book bearing the same
17 Any EA effort that does not account for the four domains and 11 segments will probably run into
significant problems relatively soon after the beginning of the EA program.

name18. Technically speaking, the CIF is not an Enterprise Architecture
methodology as it represents only a data-centric architectural view of the
enterprise. As such, it introduces a number of specific concepts that are important
in this view: data warehouse, data mart, and operational data store. It does leave
out all the other domains almost entirely.
Most of the companies benefit from incorporating CIF into their playbook. CIF
can be used for validation purposes to ensure that the specifications and
implementation models in the data-related segments of the Enterprise
Architecture are aligned with the CIF methodology. The data and data-warehouse
architects that use the CIF approach benefit from the scalable enterprise level
approach that CIF represents and typically find that, because they use CIF, their
deliverables can be aligned with the rest of the EA models with greater ease. At
the same time, the CIO and other IT and Business leadership of the organizations
following the CIF approach, will find it rewarding that the artifacts produced by
the different enterprise IT teams are consistent and complementary.
Concepts of Operations (ConOps)
The ConOps model is widely used in the private, public, military, and other
sectors where complex ecosystems require common understanding by multiple
stakeholders. According to “A Practical Guide to Federal Enterprise
Architecture:”19
“The high-level Concept of Operations (CONOPS) Graphic is the most general of
the architecture products and the most flexible in format. It is intended to portray
the operational activities of the agency (the enterprise) in a single graphic. This
work product graphic provides a concise illustration of the business of the
enterprise.” See more about this technique in the next section.
18 Corporate Information Factory, W. H. Inmon, C. Imhoff and R. Sousa. Wiley; 2000, ISBN-10:
0471399612
19 “A Practical Guide to Federal Enterprise Architecture”. Chief Information Officer Council, 2001
http://www.gao.gov/bestpractices/bpeaguide.pdf

TLEAM Fundamentals
The Power of Layering
As outlined earlier (fig. 1), the TLEAM consists of three layers:
 Business-Centric Layer;
 Specification-Centric Layer;
 Implementation-Centric Layer.
It is impossible to overestimate the power of partitioning an enterprise into these
three distinct yet interconnected layers. For example, it is not uncommon for IT
departments to be asked to solve problems that manifest themselves primarily in
the technology-driven Implementation-Centric Layer. Problems with data quality
are probably among the most common scenarios. Most of the time though, the
root cause of these problems will reside in the Business-Centric Layer or
Specification-Centric Layer. As such, no technology changes, e.g. switching
from .Net to Java (or the other way around), or replacing one ETL platform with
another, can address the problem that should be resolved in the Business-Centric
Layer. By using a technique that can guide Enterprise leadership to the root
causes of the problems, and by demonstrating that the system issues (observed in
the Implementation-Centric Layer) are only symptoms, the TLEAM can provide
enormous savings to an enterprise, both in time and in money.
This vertical interconnectedness between the model layers provides a foundation
for robust traceability and thus troubleshooting between the business-centric and
the system implementation-centric layers artifacts. Again, let’s look at one of the
most common scenarios: data output produced as a result of the systems (a.k.a.
data) integration project, does not align well with the expectations of the business
clients. According to these business clients some important results are plainly
wrong. It is pretty common to discover after painful and costly trouble shooting
efforts that the root cause is in the semantic mismatch between the two business
areas: the understanding of the data by two business teams differs even sometimes
so slightly that these business teams are not aware of the differences until they
start receiving the erroneous end-results produced by the new integrated
ecosystem. This example is a good segue to the second important TLEAM
feature: horizontal traceability within the same model layer.
Horizontal Traceabilitywithin the Layers
Horizontal traceability provides a foundation for a rich contextual connection
between different organizational units as well as the systems implemented within

the same single organizational unit, including those integrated as an afterthought.
It can be used as a foundation for all the integration efforts within a company20.
This robust horizontal traceability mechanism is complimentary to the vertical
traceability and is absolutely necessary for high-quality integration of business
processes and systems to become a reality. TLEAM provides a foundation for the
information traceability and thus improvement to decision making quality,
without which it is impossible to address a cluster of issues introduced by the
modern business environment in general, and more specifically by the legal and
regulatory compliance concerns. For example, absence of the federated business-
centric information model spanning multiple business units should raise concern
about the quality of information produced by the integration of the systems that
belong to various departments.
Business-Centric Layer
The top Business-Centric Layer is used to host behavioral models that describe in
a variety of formats the business functions and activities, as well as related issues
and business solutions. The construction of this layer usually starts with
development of the Concepts of Operations model21.
For a majority of Enterprise Architects, at least for those with a software
development background, the CONOPS models will look like a drawing
developed by a sales or marketing organization, rather than as an engineering
diagram. It captures only the highest level concepts, and usually lacks any level
of detail that is near and dear to engineers. But the simplistic appearance of the
diagram is deceiving. Even at this high level, it helps to clearly present
information to the target audience – C-level executives -- by developing a
common view of the Enterprise at a level of detail that is appropriate for C-level
executives in order to forge common understanding.
It is also common for most of companies to have documents capturing business
strategy, usually as PowerPoint presentations along with the financial models
produced by the leadership of the main business divisions. Unfortunately,
commonly both of these artifacts -- CONOPS and business strategy documents,
don’t support the level of rigor that is required in a well-engineered EA model22.
However, any EA effort can benefit from the information captured in the
aforementioned artifacts. To emphasize this point – though not rigorous enough
but nevertheless useful, both entities in Figure 1 (i.e. CONOPS and business
20 For more information please see “MDM is Not Enough - Semantic Enterprise is Needed”
21 Alternatively, some organizations may choose an information-centric approach where Business
Information Model plays the primary role from the very beginning. See more about what would be
required from an organization to implement this approach in the Appendix C, “Information 1st
organizations.docx”
22 The artifacts from Balanced Scorecards (BSC) and similar methodologies can also play important role
as inputs into EA model.

strategy documents) are placed in a separate box that overlaps with the Business-
Centric Layer, albeit only partially.
The next necessary artifact of the Business-Centric Layer is the Operating Model.
The model should guide Enterprise Architects and enterprise leaders in making
decisions regarding IT assets that should (or should not) be shared at the
Enterprise level, thus delineate their importance to the Enterprise. The first step in
this direction should be the selection of one of the four possible Operating model
types shown on Figure 3 below: Diversification, Coordination, Replication, and
Unification. The short list of enterprise characteristics that correspond to each of
the models, shown in Figure 3, can be used as a starting point by enterprise
leadership. The Operating Model choices involve non-trivial processes with vital
consequences for any company, and should not be taken lightly. The "Enterprise
Architecture as Strategy" is an excellent guide for any company that is ready to
embark on this endeavor.
Figure 3. Operating Model Types and their characteristics23.
After the enterprise leaders reach agreement about the Operating Model type, they
should determine what should be treated as the core shared Enterprise IT assets.
At the risk of oversimplification, the following rule is very helpful in practice: the
23 From “Enterprise Architecture as Strategy by P. Weill, J. Ross and D. Robertson

higher the degree of standardization, the more an IT asset can be reused by
multiple departments. The Integration dimension of the Operating Model affects
the intensity of the Enterprise integration activities, and thus the importance of the
integration infrastructure that is needed to support it. The correlation here is also
straightforward: the higher the degree of inter-departmental integration, the higher
the investment in Enterprise integration models and infrastructure.
Regardless of the specific type of Operating model being selected, the approach
above leads to the following questions:
 What core enterprise assets categories should be analyzed by using the
Operating Model Architecture approach?
 Should it be just core technology platforms, such as RDBMS, e.g., Oracle,
SQL Server, DB2, and application servers, rules and workflow
technologies?
 Can the list be extended to a more granular level to include shared
subsystems, services and components?
 Should SOA be used?
As it is well known by now, after 20 years of still-to-be-fulfilled promises of the
coming era of massive software reuse, the list of important architectural issues
related to asset sharing and re-use may become quite long.
While "Enterprise Architecture as Strategy" provides some guidelines in
answering the questions in this area, it leaves room for a more technically-
oriented methodology to provide more details. The Enterprise Business
Capabilities Model, one of the models shown in Figure 1, responds well to this
demand. It is the result of the Operating Model Architecture principles – "the
organizing logic for core business processes and IT infrastructure reflecting the
standardization and integration of a company's operating model" – being applied
to the Business Capabilities model. The outcome is the capabilities hierarchy
with an importance grade that was validated against the Operating model.
Complementary to Business Capabilities, the Business Use Cases (BUC)
modeling approach can also be utilized. I recommend implementing the
technique that incorporates not only BUCs but also the corresponding Business
Use Cases Realizations (BUCR). In this case, a very strong synergy between
BUCRs and Capabilities views enables the identification and potential
remediation of gaps between the business goals of the customers as they are
perceived by the business decision makers (BUCs and BUCRs), and the way the
same the business decision makers view their own business value chain. From
the data vs. behavior (a.k.a. process) dichotomy point of view, both (Capabilities
and BUCs/BUCRs) represent the process-oriented side of Business Architecture.
Business Patterns, as well as Business Policies and Principles, complement the set
of artifacts that exist in the Business-Centric Layer. All the aforementioned
artifacts would also reside in the Business Architecture domain of the Four

Domains EA model (fig. 2). This is not, however, the case with the Business
Enterprise Information Model/Ontology and Line Of Business Information
Models, which also reside in the Business-Centric Layer of TLEAM. These
artifacts are information-oriented in nature, and capture main information
structures and elements that support the process-oriented view of business. The
approach recommends UML Class diagram techniques to be used for these
artifacts. As an alternative, an Ontology-based approach can also be used.
Whichever technique is chosen, the most important tenet of the TLEAM approach
is to correlate the process-oriented (a.k.a. behavior) business models with the
information-oriented (a.k.a. data) business models. The UML Class diagram that
constitutes the Business Enterprise Information Model should capture all the
business entities and their relations at a level of individual Business Attributes24.
Specification-Centric Layer
The middle Specification-Centric Layer of the TLEAM is the place to host
specifications for the systems that are visible at the very top Enterprise level. It
is important to point out that in the models created for a specific business unit, as
opposed to the whole Enterprise, this layer would host all the system
specifications regardless of whether there is Enterprise or only local visibility.
I strongly recommend keeping the information in this layer in a platform-
independent form and move all platform-specific information to the
Implementation-Centric layer, which is naturally platform specific.
By defining and maintaining system priorities in terms of the validated and
approved business use cases and business capabilities, the enterprise leaders
assure alignment between business and IT goals. While the initial planning
process is clearly top-down, at the same time, bottom–up revisions and change
requests are quite common. As the company progresses towards the new state of
the enterprise, changes and adjustments are inevitable and sometimes more
acutely pronounced at the implementation level of a particular division and its IT
systems, rather than at the global enterprise level. Regardless of where the change
request would come from, the most important thing is to make sure that all the
related artifacts in all three layers are updated and are kept in sync. Most of the
time, updates initiated at the system specification layer should have very limited
effect on the core Enterprise capabilities.
On the information/data side of the specifications, a transition from Business
Information Attributes defined in the Business-Centric layer to data elements that
populate system specifications is usually quite straight forward as long as
24 For additional details regarding the importance of correlation between the information (data)--
oriented view of business on the one side and the process-oriented view of business on the other,
please see “Quality Data Through Enterprise Information Architecture”, The Architecture
Journal, January, 2007

business and IT teams are willing to collaborate and learn from each other. For
example, it is common for more than one system in multiple business units to
operate on a Business Attribute defined at the business layer level. In this case,
each system’s specification will define its own unique data element, but all data
elements would be mapped to the same one single Business Attribute from the
business layer in case of a singular business information model or multiple
business attributes from different LOB models. In the latter case, (federated LOBs
information models) the connection between the federation member models at the
Business-Centric Layer level would have been already established. This bi-
directional traceability approach helps alleviate a problem known as
“departmental information silos”. In the silos case, no unifying enterprise
integration logic exists in the business-centric level, so the data elements
mappings between the different business departments is usually done at the
system-driven Implementation-Centric Layer, commonly without the benefit of
the business SME’s first establishing the connection at the Business-Centric Layer
level.
Similar to the top layer, in the spirit of correlating information/data models with
the functional/ behavioral contextual information, System Use Cases and System
Use Cases Realizations that are introduced at this level should provide enough
grounding for the data elements and structures validations and vice versa.
Implementation-Centric Layer
The bottom Implementation-Centric Layer is the hosting location for system
implementation level and related artifacts that are managed at a single system
level of knowledge management, which are naturally technology platform-
specific. While each system is designed and implemented individually, the
federation of all the systems for each LOB constitute the complete set of all the
systems at the enterprise level. This view is consistent with the ITIL
recommended approach (a.k.a. CMDB) that presently guides most of the IT
operations teams.
The detailed description of the artifacts that exist in this layer is out of scope for
this paper. However, it is worth pointing out that multiple platform-specific data
element implementations may be mapped to the same data element defined in the
specification layer, which is platform neutral. This unambiguous, contextually-
based mapping from possibly multiple technology-specific implementations to a
single data element defined at the technology-independent specification level is
the foundation for the robust system integration approach, mostly because it
allows for robust validation of the business context for any system-level data
element regardless of the implementation platform on either side of the system
interface.

Conclusion
While skillful application of the EA principles and practices can provide huge business
value, unlocking the full potential of the EA-based knowledge is not trivial.
Most popular EA methodologies require significant investment of enterprise business and
technology resources, unavoidably turning EA development programs into a multi-year,
potentially “never catching up to its promises” endeavor.
The proposed TLEAM-based approach is robust, rigorous, and, yet, affordable. It builds
on common well accepted industry models and lets the practitioners to pick and choose
methodologies that are the most suitable and appropriate for theirs specific organizational
environment, corporate culture and political circumstances.
While all the [sub]models would benefit from cross-referencing against each other, they
can be implemented a la carte based on resources’ availability and time agendas.
“Iterative and incremental” works for Enterprise Architecture at least as well if not better
than it does for a single system architecture.
Regardless of the specifics TLEAM will help business and IT teams to develop a
common vision and create a strong enterprise foundation for execution. This foundation
can make all the difference between struggling and thriving in the new fast-paced world
of ever accelerating change.

Enterprise architecture concepts

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (18)

Similar to Enterprise architecture concepts

Similar to Enterprise architecture concepts (20)

Enterprise architecture concepts