Enterprise Change & Transformation Toolbox
“If
you think good architecture is expensive, try bad architecture.”
Brian
Foote and Joseph Yoder
©Semyon Axelrod, 2015
Work In
Progress
Contents
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 long[1],
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.
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 Main Tool – Three-Layered
Enterprise 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. Daniels[3],
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.
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.
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 by[5]:
·
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”;
·
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 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.
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 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 development[10]
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.
Zachman framework
No EA
discussion is possible without mentioning the Zachman framework. The framework launched EA as a discipline
more than 20 years ago[11]
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 website[13],
“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 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 UML[15].
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).
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 view[17]
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.
Corporate Information
Factory
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 name[18]. 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.
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 Traceability
within 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 company[20].
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 model[21].
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 model[22]. 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 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 characteristics[23].
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 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 Attributes[24].
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 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.
[1] The one
that is most commonly used is defined in ISO/IEC
42010:2007, Systems
and Software Engineering -- Recommended practice for architectural description
of software-intensive systems standard. “The
fundamental organization of a system embodied 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
[3] “Designing
Object Systems: Object-Oriented Modelling with Syntropy”, 1994, Prentice Hall;
ISBN: 0132038609
[4] For more
information about the model please see: “Quality Data
Through Enterprise Information Architecture”, The Architecture Journal, January 2007.
[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,
[9] http://www.uml.org/
[10] “Understanding
and Controlling Software Costs.” Boehm, Barry W., and Philip N. Papaccio. IEEE
Transactions on Software Engineering. 1988
[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,
Description and Utility." Zachman Institute for Framework Advancement
(ZIFA). Document ID: 810-231-0531
[14] TOGAF® Version
9.1 Enterprise Edition, An Introduction.
[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 how to use
the ArchiMate language and UML
together is necessary for efficient and precise
alignment between the Enterprise and Solution
[16] Chief
Information Officer Council, Version
1.0, February 2001
[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.
[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
[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.
[23] From
“Enterprise Architecture as Strategy by P. Weill, J. Ross and D. Robertson
[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
posted by semyon axelrod | 8:42 AM
0 Comments:
Post a Comment
<< Home