Applied Data Resource Management
White Paper
Enterprise
Information Architecture
Every organization looks to it's IT organization for ways to share information, integrate systems, reduce
costs, increase productivity and improve data quality.
It is the role of the Enterprise Information Architecture (EIA) to provide these benefits.
The EIA provides an enterprise blueprint or 'data map' of what information is available, where and it's
precise definition.
A logical Enterprise Information Architecture (EIA) is the foundation for the integration of corporate data.
It is this blueprint that provides the target data structures for the mapping of both legacy and new
applications to a common definition of data for the synchronization of data and associated processes.
Common data and supporting metadata is essential to building reusable data components and
eliminating endless re-architecting of systems to support common views of data, new requirements and
information reporting.
An Enterprise Information Architecture (EIA) that is both comprehensive, extendable and sufficiently
detailed at the attribute level to bring immediate value to software developers is the key to both strategic
and tactical success.
It provides the means to reduce costs via reduced maintenance requirements, accelerate and improved
the quality of analysis for new systems and provides a common framework for eliminating repetitive or
duplicate internal efforts that result in stand-along or 'stovepipe' systems. It is the data blueprint, that is
as essential to building good systems as the architectural blueprint is to constructing a building.
Information that is organized inconsistently internally or across the corporation in conflicting ways makes
interoperable systems and cross-system retrieval of information difficult. It results in information that is
difficult to synchronize and semantically inconsistent. The application of extract, transform and load
(ETL) tools becomes suspect because the data semantics may not match the apparent meaning of the
data. The implementation of a common data architecture across systems makes it possible to apply
ETL, BI and reporting and reporting tools effectively with minimal analysis and effort.
What is the Enterprise Information Architecture (EIA)?
The EIA is the data or information blueprint for how data is to be organized across the entire
organization. Blueprints or design documents are required to build anything complex and computer
applications are no exception.
The EIA is best expressed as a series of data models, which are graphical representation of data and
the relationships between data. Because of the scope of the enterprise, a series of data models are
required that are structured in a top-down hierarchy to provide increasingly more detail as the business
area or activity being described is presented.
2
The single top-level model that is the 'big-picture' of how it all fits together is the "Enterprise Data Model".
The Enterprise Data Model incorporates and depicts the integrated data requirements of the
organization in a single logical data model. It is the primary data model and foundation data model for
strategic planning, communicating information requirements throughout the organization, implementing
integrated systems and organizing data in the lower-level Business Area, Data Warehouse and Data
Mart models.
Below in the hierarchy and linked by corresponding key entities from the Enterprise Data Model are
Business Area Models. Each Business Area Model is constructed from a core of entities from the
Enterprise Model, which insures that Business Area Models will have common keys, attributes and
definitions throughout the data architecture.
Each major 'subject' in the Enterprise Data Model has additional information and detail that cannot be
addressed completely in the Enterprise Data Model due to lack of space and an inappropriate level of
detail for a general audience. That additional information is contained in one or more related Business
Area Models.
For example, the 'CUSTOMER' entities in the Enterprise Data Model are the foundation for an expanded
and more detailed analysis provided by two related business area models:
• Individual Customer
• Legal Entity Customer
Business Area Models are structured in a manner consistent with what you would expect. At the higher
level is the Enterprise Data Model with a higher level of detail and in the lower-level business area model
is the additional knowledge and content in terms of additional entities, attributes and supporting detail.
Business Area Models contain the greatest level of detail and provide the lowest level of data granularity
in the model hierarchy - while maintaining definitions consistently across the entire EIA. This approach
supports integration of existing models and development of new models. As new information is added
to a Business Area Model it may also be propagated to the Enterprise Model, Data Warehouse Model,
Data Mart Model or application models.
The Business Area Models are also related to each other upon common data.
A 'CUSTOMER' entity in one business area model should closely align with a 'customer' entity in a
related business area. You can conceive of them as being 'duplicates' except in practice there are
minor attribute variations due to the specific focus of each respective business area.
3
An industry that operates independently of other industries is rare. This means that the data that is
common between industries must be represented as such so that it can be shared.
The common core of the EIA must be applicable across related industries to support the organization as
it moves into new industries and business opportunities.
For example, the ADRM Retail Banking Enterprise Model integrates easily with the ADRM Brokerage
Enterprise Model and ADRM Mutual Funds Enterprise Model.
The ADRM 3G Wireless Enterprise Model integrates easily with the both the LEC/Long Distance and
Internet/Data Services enterprise models.
This enables ADRM clients to merge all or part of two or more industries upon data that will be common
to them. This is the foundation of common data that make an EIA come alive.
Using Enterprise Data Models for the merger or acquisition of two businesses is a natural application.
When two major banks merged, ADRM banking models were used as the target for integrating their
operations as well as data warehouse development.
A merger of a bank and a brokerage firm would have the resulting capability to combine or share
customers, which they should naturally be able to do. They could also share marketing and financial
statement data structures as well as a variety of similar business data.
At still a lower level in the EIA data model hierarch - Data Mart, Data Warehouse and specific application
models are the 'working' data models or physical data models derived from corresponding application
logical data models to meet specific processing and information requirements.
The entities, attributes, definitions and various physical characteristics establish the foundation of metadata or "data about data".
Applied Data Resource Management (ADRM) develops and markets best-of-breed EIA's over seven
industries and 35 lines of business. We have found that companies operating in the same industries
require the same basic information ("best-of-breed") in order to operate.
Starting with a best-of-breed EIA solution and then tailoring it for the specific organization is the best way
to reduce the long and uncertain development cycle and costs associated with these efforts and predict
the outcome within the difference between the template EIA and the changes to be applied
How is an Enterprise Data Architecture Implemented?
Before you can implement an EIA, you must have an EIA. That means either you build one from scratch
or you acquire one and tailor it to your needs.
4
Building an EIA requires budget, resources, people and a project plan that may be difficult to acquire,
manage and deliver upon.
Budget funds must be found for a project that does not necessarily have a tactical deliverable.
Therefore, it is hard to tap any single department for the funding, which will be in the multi-millions of
dollars.
Data analysts, data modelers, managers, CASE software and the other resource components are
expensive and require specific expertise a. Resources available in-house are usually already allocated
to critical projects. Bringing in external resources is inefficient because you have to teach them the
industry, your specific business and then ask them to "look into the future" and create an architecture to
support the business in that future. This is risk prone due to the number of variables, skills sets and
limited experience that can be applied.
Management familiar with the EIA development cycle are few. Those that have successfully pulled off
an implementation within budget and schedule are fewer.
All together, it presents a picture with many variables, considerable expense and a deliverable difficult to
predict. This is not a combination that normally inspires people to volunteer or contribute budget.
However, the importance to the organization is compelling and the benefits to senior management are
obvious. The EIA is something that must be addressed ultimately in order to avoid the 'thousand cuts" of
maintenance and address data quality and applications that miss the mark and have to be redone at
considerable expense and resources.
The alternative to procure an EIA is also limited because there are relatively few choices. Nor are EIA's
a common software commodity and all equal in approach or functionality. Few vendors develop them
for resale because of the relatively limited number of opportunities compared with packaged
applications, the skill sets required, the detailed industry knowledge and content required and the sales
requirement to be at the customer precisely when the EIA is considered or required.
Having selected candidate vendors the customer must then decide which potential EIA data model set is
most applicable and then whether it has enough applicability to be worth procuring.
There are several criteria upon which this decision should be made:
(1) How complete are the models?
(2) How detailed are the models at each level?
(3) Do the models represent a 'best-practices' industry model?
(4) Are definitions complete at the entity and attribute level?
(5) How closely do definitions match you view of the world?
5
(6) Are relationships consistent with your business view?
(7) How clear are the models?
(8) How easy to modify and extend the models?
(9) Is the format of the models easy to view and understand?
(10) Is the EIA provided in an industry-standard CASE tool?
(11) How easy is it to manage the models?
How complete are the models?
The EIA data models should address each area of interest with a robust set of attributes for each
supporting entity and key relationships linking the entities.
You should 'see' your business in semantic terms that are clearly understandable as you investigate
the EIA models. The definition of each semantic term will determine the true value of the
corresponding data.
Significant areas of interest to your business that are not supported should be noted. The more of
these that exist, the more significant will be the task to make the models fit your environment.
Definitions should be complete and industry-specific. Thought for reuse of data should be evident in
entities that are shared between data models.
Data models should be carefully crafted just as any other software component and should exhibit this
characteristic both graphically and in content.
How detailed are the models at each level?
Data models that consist of 'blank' or undefined entities indicate that they are incomplete in terms of
their thought process and analysis.
A 'CUSTOMER' entity with only a few attributes provides little value and leaves too much analysis
work to be done. A proper template CUSTOMER entity should have 40-60 attributes with
associated foreign key-related entities providing reference context and data.
This enables the client to easily determine if the model definition of CUSTOMER is consistent with
theirs.
The onsite modification of CUSTOMER by the client should be a decision-and-editing process based
on the content provided by the template models. It should not be the start of a detailed discovery
process for the client.
6
Do the models represent a 'best-practices' industry model?
The EIA models should be designed for your specific industry. While there are many common elements
across industries that can and should be applied (CUSTOMER, CONTACT, GEOGRAPHY etc.), this
must be done within the context of a specific industry in order to succeed.
The 'ORDER' that you place with a brokerage firm is indistinguishable from the 'ORDER' that you place
with a retail firm. Only the semantic term binds them and any work based upon a common semantic
definition would fail.
Do the models represent good, practical business practices?
The data to support your business should be clearly evident in terms that are readily understandable.
It makes no sense to adopt a set of models that are too conceptual or do not represent a view of world
as it really is.
Remember we are establishing an architecture that must be populated with existing data and/or
industry-standard data. If that framework isn't established, you will have an empty set of models that
provide no benefit because the data doesn't exist to populate the applications built from them.
Beware of artificial concepts and terms that are alien to how you do business and the existing data.
For example, an entity named "BUSINESS PARTNER" that is defined as representing 'customers,
employees, vendors etc.' is too general. It is a comfortable conceptual term because it leaves the
specific definition of each of these to someone else with all associated details. However, it does not
provide the benefit to the business that would exist from complete and independent definitions of each of
these.
It is always easier to consider the detailed definitions and decide to generalize than it is to generalize
and then determine that the specific details are required but do not exist.
Are definitions complete at the entity and attribute level?
Without complete definitions, the work is undone. It is the definitions at the entity and attribute levels
that determine the true quality of the data models. Without complete, quality definitions the meta-data is
incomplete and the definition work still be done.
Incomplete definitions indicate incomplete thought in development of the models. We cannot nor should
we assume the definition from the semantic name as the 'ORDER' example above describes.
7
Applications will be loaded with data consistent with the definition of the entities and attributes.
Common names but different data due to different definitions will result in applications that should be
able to talk to each other but in fact cannot.
Shared or common definitions and data structures are necessary in order to map legacy applications to
the new EIA, promote metadata consistency and support truly integrated systems over time.
How closely do definitions match you view of the world?
Definitions that are quite different from your internal definitions indicate either that your organization has
not thought out definitions completely or that a considerable amount of work remains.
Definitions that do not exist, are trivial or lack industry context are red flags and should represent real
concern.
Most likely, your organization has a variety of definitions in a wide-number of applications that need to
be considered, refined and mapped to a common definition. The EIA should provide that common
definition or at least provide a place to put it when it is resolved.
Are relationships consistent with your business view?
Relationships between entities should represent basic, common-sense business relationships without
artificial business rules applied by the EIA vendor. If they do, then you can modify them for specific
cases.
If relationships do not support the required foreign-key relationships it indicates once again that the
overall design was too generalized, not detailed enough or poorly represented in the data models.
All of these things will require considerable extra work on your part.
How clear are the models?
The data models should be easy to understand. The ultimate audience should be an extended
audience all of whom are not trained data modelers. It should still be possible for programmers,
analysts and executives to get the information that they require from the data models with minimal
coaching.
While they might not actively query the models or repository directly, they should feel comfortable getting
definitions for entities, visualizing relationships and exploring attributes. Part of the value of EIA data
models is providing a vision of the 'possible'.
8
For example, it is not simply CUSTOMER that is important but also CUSTOMER TYPE, CHANNEL,
MARKET, MARKET SEGMENT and all the supporting entities that provide the richness of a true
definition of CUSTOMER.
How easy to modify and extend the models?
Once the EIA data models are procured, they will need to be modified or tailored in various ways to
become those of the specific client. This process can proceed over time and be relatively trivial where
there is a tight fit, but there are always modifications to be applied.
You need to have confidence that this work can proceed smoothly and independently of the third party
data model provider. A format and style of data modeling that is clear and evident is the best indication
for success here.
Look for data models that name entities as they really are and in market standard terminology.
Is the format of the models easy to view and understand?
People need to understand and contribute to the process over time in order for an Enterprise Information
Architecture to succeed.
• To succeed it must be used.
• To be used it must be understood.
• To be understood it must be fully and completely documented
• To be used it must be clearly presented
• To be used it must exist in a CASE tool that is easy to use
Is the EIA provided in an industry-standard CASE tool?
The data models must be used and maintained. This requires that the data models be available in a
CASE tool supported by a stable vendor with a sizable existing customer base.
Porting data models to a new CASE tool is extremely difficult, time-consuming and error-prone and
should not be undertaken lightly. Selecting data models supported by an industry-standard CASE tool
is essential.
It may well be wise as an organization to migrate to the CASE tool holding the EIA data models if it
supports all the functionality required by the organization.
9
How easy is it to manage the models?
Part of your EIA strategy must be the dissemination and distribution of content via data models or
subsets of the data models.
Are you set up to print or plot your models to share with teams? E-size plotters are relatively
inexpensive (under $5,000) and can provide a lot of benefit for the money. They make it possible to
distribute models in a format that shows everything of interest without turning 8"x11" pages. Looking
through hundreds of pages will guarantee that the data models are used as seldom as possible.
Data models should be able to be segmented into smaller sections so that they can be distributed with
just the right information needed without confusing the receiver. Sometimes we just want to focus on a
relatively small segment of the model in order to get the information needed without surrounding detail.
The larger and more extended the organization, the more certain that data consistency issues exist.
Each new project contributes to an increase in the data 'gaps' as they define new requirements
individually as best they can to meet schedules and budget requirements.
As senior management focuses upon tactical systems to meet pressing and immediate needs the future
and on-going costs to 'integrate systems and data' grows both in complexity and cost.
The ROI is difficult to quantity at the macro level or project-by-project but the overall costs to address the
problem can be approximated by the supporting budgets for the efforts intended to address the related
problems.
Integration and Reconciliation Of Disparate Systems
The Enterprise Information Architecture (EIA) establishes a 'stake in the ground' for reconciling the data
and relationships between different data in disparate applications.
It provides a known variable to aim at without which there would be constant warring and argument
about which is the system of record.
It defines the official data semantics to be extended in new applications and to be used as the language
of interpretation between existing and legacy applications.
In the case of legacy and existing applications, it provides a common target 'data language' that may
never be perfect because the cost of analyzing and re-architecting those systems may be too great.
Nevertheless, it does provide a means of understanding, decoding and integrating the key data in a
common manner to provide the essential information need by the organization.
10
In the case of new systems, the Enterprise Information Architecture (EIA) can provide dramatic benefits
immediately and long-term.
Immediately it can provide the information in the form mandated by the organization via the enterprise
data architecture. Long-term by being consistent with the stated data objectives of the enterprise, it will
result in reduced maintenance costs to correct errors and extend the application to meet new
requirements.
A completed EIA does not guarantee that change and conflict will not occur. Having built the EIA,
reconciled and mapped data and identified the key players, it is a certainty that new issues and
requirements will arise having an impact on the work performed.. The EIA provides a framework for
predicting and analyzing the impact of these activities.
This impact analysis must provide a view of what systems, data and stakeholders will be impacted by a
proposed change or extension to the EIA. It is critical that the impact of changes be determined before
they occur not after.
The EIA provides the means for capturing knowledge and content to assist in the information sharing.
The use of an enterprise repository may assist in organizing and reporting the EIA content, guarding
against lost data and providing a means for wide-spread dissemination of information across the
enterprise.
A detailed EIA supporting a 360° view of the enterprise provides a data architecture that can be applied
form the perspective of the interested party.
For example, a detailed MARKETING Business Area Model that is derived from the Enterprise Model
can be used by a Marketing application secure in the knowledge that the definition of PRODUCT they
are using will be the same as the one used by SALES, FINANCIAL REPORTING, BBB and so on.
It is the availability of detailed data down to the attribute level the provides immediate tactical project
benefits and the derivation of that data from an overall enterprise model and corporate perspective that
provides long-term benefits to the entire organization.
Far from being a rigid mandate that hamstrings developers and project managers, the EIA provides both
a framework for accelerated application development consistent with enterprise information goals and
objectives and a vehicle to document and start to resolve difficult issues.
The EIA must be able to support varied views and requirements consistently and in a timely manner with
minimal additional analysis or effort.
11
Stakeholders
Who are the stakeholders and users of the Enterprise Information Architecture?
Just about everyone that has a stake in building applications, integrating data or reporting data that must
have the same meaning in order to be accurate:
• CIO
• Senior executives
• Data architects
• Project managers
• Software Developers
• DBA's
• Data auditors
The Enterprise Information Architecture is a significant and critical IT component for an enterprise
seeking to achieve all of the advantages discussed.
It is the corporate vitamin that can re-energize IT efforts by:
• Increased sharing and reuse of data
• Streamlining the development cycle
• Eliminating redundancy
• Increasing efficiency and productivity
• Reducing costs
• Establishing information as a corporate asset
• Creating a more responsive information environment
• Supporting improved data quality
• Supporting integrated change management
It's not inexpensive nor easy but it is essential. That there are working core applications in place does
not preclude it's importance but rather accentuates what could have been achieved already had a
practical, working Enterprise Information Architecture been in place.
The Enterprise Information Architecture can be implemented either as a single effort or in individual
stages suitable to the resources and requirements of the organization.
The important thing is that the effort begins with the greatest chance to succeed at each milestone.
The benefits do outweigh the costs in the long-term.
ADRM believes and has proven that a template industry-specific Enterprise Data Architecture is the
most cost-efficient and predictable way to approach the EIA.
12
About ADRM
Applied Data Resource Management is the leader in the development of industry-specific data models
for enterprise planning, data warehouse, data mart and applications development. ADRM products
provide the data and industry knowledge that enable clients to apply state-of-the-industry knowledge to
analyze requirements and implement solutions for a wide range of applications.
More information about ADRM can be found on the web at www.adrm.com or contact Kevin
Schofield, VP Sales and Marketing, at [email protected].
About Applied Data Resource Management
Applied Data Resource Management, Inc. specializes in clearly defining the information requirements of world-class organizations in
a variety of industries and architecting intellectual property based products to help organizations in those industries more effectively
capitalize upon their information assets and opportunities.
More information about ADRM can be found on the web at www.adrm.com.
Applied Data Resource Management
824 Corriente Point Drive
Redwood City, CA 94065
Tel. 650-508-0503
www.adrm.com
© 2004 ADRM Software
. All rights reserved. The trademarks and service marks shown are trademarks of ADRM Software or its affiliates and may be pending or
registered in the United States and other jurisdictions. Other marks are the property of the owners of those marks.
Printed in USA 08/04. All information is as of August 2004 and is subject to change.
13