With Enterprise Metadata Repository (EMR) and Enterprise Conceptual Data Model (ECDM) creating a neat blueprint of enterprise data and systems infrastructures is easy.

ECDM facilitates business vision realization by quickly focusing on an area of interest, within the enterprise data and process blueprint, and determining impacted functions/activities and data stores, and how they need to adjust to embrace the new or revised business mission. ECDM also quickly identifies potential new functionalities that are missing from the enterprise as-is state, and it provides high-level view of the best place to insert the new functionalities and data stores in the to-be state.

ECDM is pure conceptual business content. Its methodology as stated herein uses axiomatic principles that, unlike the logical and physical data models that must adhere strictly to the rules of normalization, with ECDM it is desirable to use de-normalized data structures that capture master reference data with entity data classes. Moreover, the number of entities in ECDM are reduced by listing repeating Data Classes.

EMR is a great tool for capturing the physical world: platforms, applications, programs, databases, data streams, data models, etc. But ECDM conceptualizes business and data functionalities to the highest abstraction level. And with EMR & SQL, ECDM easily correlates the conceptual world that executives relate to with the physical world that techies relate to. Hence a bridge is formed. Without ECDM, EMR is a weak tool because one would need to know where to look to find what one wants.

We define ECDM data taxonomy at the highest level as the basic accounting mechanisms of Income and Expenses. All enterprise data and systems functionality is subordinate to these categorizations: business revenue generation, client and account support, transaction generation and processing, and all informational activities that include not only Legacy Systems Business Displays but also Data Warehouse and Data Marts Business Intelligence displays. All these functions fall into an ECDM enterprise focus of interest: a Business Area.

ECDM Business Area diagrams (EBAMs) and Business Area Narratives are the basis for ECDM design. The identification and definition of EBAMs, and the subsequent decomposition of Business Areas into ESAMs, is illustrated cursorily in chapter 1 and thoroughly in subsequent chapters. Coalescing conceptual metadata with physical metadata is an integral part of the process of developing and using EMR and ECDM.

This book also discusses data modeling concepts and Data Architecture methods, as these are necessary tools to describe the mission of developing ECDM and EMR. Principles in Data Life Cycle and System Development Life Cycle (SDLC) methodologies are also expounded.

As the industry has shifted its focus from systems architecture to data architecture and Enterprise Data Architecture, it has become necessary to abstract application data models to the higher-level Enterprise Conceptual Data Model.

ECDM methodology herein introduces 2 new data architecture concepts that are the highest-level conceptual building blocks of ECDM.

 Enterprise BUSINESS AREA Model (EBAM)

 Enterprise SUBJECT AREA Model (ESAM)

EBAM can be 1 level, 2 levels, or more, depending on the size and complexity of the enterprise I.T. infrastructure. Each EBAM is decomposed into an ESAM which is the highest-level Entity Relationship Diagram (ERD) within the enterprise.

ESAM ERD is at a much higher level than application logical and physical data models. ESAM uses reduction and summary techniques to greatly reduce the number of conceptual ERDs, entities, and attributes in the enterprise data blueprint. But when it is necessary to know the details, EMR maps the conceptual ECDM ESAM components to the fine details of application data models, technical platforms, databases, tables, columns, programs, files, business displays and more.

What is an Enterprise?

An enterprise is not necessarily a corporation, and large corporations have multiple enterprises, each being a division of the corporation. An enterprise model does not capture all divisions of corporate business activity; it focuses only on aspects of the business that have synergy with one another. For example, General Electric Corporation is engaged in various businesses – financial broadcasting (our friend CNBC), manufacturing (GE appliances – who doesn’t have one), consumer credit, consulting services, etc. – and GE would not create an enterprise model that captures all of its business revenue streams in one ECDM and EMR. But it could have an EMR/ECDM for each of its revenue streams.

ECDM supports not only data structures for corporate homegrown systems, but also data structures for canned software packages. In addition, ECDM and EMR should capture all data that supports business activities, including data that is handled manually and is not produced from automated systems. In short ECDM and EMR are a means of quickly identifying all data that an enterprise uses, regardless of technical platform or physical data storage medium.

What constitutes an enterprise for purpose of creating ECDM varies from corporation to corporation, depending on its size and the number and types of revenue streams it has. We assume the definition of “enterprise” within a large corporation is resolved, and we focus on developing and utilizing ECDM within each enterprise. But every multi-enterprise corporation has common support functionalities and data models that interface with ECDM. These types of models are also discussed.

Where an enterprise has difficulty in responding to business competitiveness and regulatory challenges, building ECDM alone may not be enough, and partial or total overhauling of the enterprise business and technical operation may be necessary. In addition to building ECDM and EMR, this includes creating a business-mission statement that addresses what the business is currently and what the business should be in the future for the enterprise to thrive. With this re-engineering approach, the business functions and the organizational structure that support the business activities will need partial or total overhauling.

2 Architecture Approaches

1. Effort is driven by ECDM and EMR development only. This is the faster, cost-effective route. For large enterprises that have robust systems and technologies, this is enough.

2. ECDM is complemented with review of the business mission and key objectives, business functional decomposition, functional and systems re-engineering, and possibly also organizational realignment to support the enhanced business vision. This approach is desirable when an enterprise has archaic, problematic systems that don’t respond well to change; and cause loss of business and high maintenance costs.

These approaches are described in more detail in chapters 1, 5, and 7. Chapter 2 describes the essence of Data Architecture which, for those who are not familiar with this topic, is prerequisite reading to chapters 3 thru 7 that describe how to build and utilize EMR and ECDM. Chapter 7 covers what else must be done to use the 2nd approach that complements the development of ECDM and EMR with re-engineering some or all of the enterprise business and technical architecture.