Enterprise Architecture Management Guide[1]

Appendix

A Core Enterprise Architecture Metamodel

Table of Contents

1. Core EA Metamodel – an Introduction. 2

2. Core Metamodel - Rules. 5

3. Core Metamodel – Basic Entity Structure. 6

4. Core Metamodel - a Basic Entity. 8

5. Core Metamodel - Entity Types. 9

6. Core Metamodel - Entity Categories Related in IDEF0 Processes. 10

7. Metamodel Extension - Project Context 11

8. References. 12

9. Glossary. 13

Version History

Version	Date	Author	Description	Note
0.1	11/21/2007	Haiping Luo	Initial draft.

1. Core EA Metamodel – an Introduction

This document describes a core metamodel for enterprise architecture (EA) repositories. The core metamodel identifies common components and structures in EA metamodels. The core metamodel can help establish semantic affinity and assist exchange of information among EA repositories.

This document is divided into sections and sub-sections. The sections are:

1. Introduction: Provides an overview on what is a Core EA Metamodel, how the Core Metamodel is constructed and how the Core Metamodel can be used.

2. Core Metamodel - Rules: Specifies the rules to develop the Core EA Metamodel and the rules to instantiate and extend the Core EA Metamodel.

3. Core Metamodel – Basic Entity Structure: Defines basic information dimensions needed to manage and utilize a data entity and the information contained in the entity.

4. Core Metamodel - a Basic Entity: Identifies a basic set of attributes and relationships that every entity of an EA repository should have.

5. Core Metamodel - Entity Types: Identifies all categories of entities in an EA repository and groups the categories into seven generic Entity Types of “Thing, People, Work, Methodology, Rationale, Location, and Time” that represent the types of enterprise elements.

6. Core Metamodel - Entity Categories Related in IDEF0 Processes: Relates all entity categories through the Process category to set the roles of all entities in the context of achieving the purpose of the enterprise.

7. Metamodel Extension - Project Context: A sample extension of the Core EA Metamodel to address project governance and management context in an EA repository.

8. References

9. Glossary: The acronyms, full names, and definitions or descriptions of terms used in this document.

The sub-sections in this introduction section further explain the meaning and intents of EA meta modeling and the Core EA Metamodel.

1.1. What is a Core Enterprise Architecture Metamodel

An Enterprise Architecture Metamodel is an entity-relation data model that provides a logical data structure to an EA repository. An EA Repository stores documentations including metadata, model instances, and other descriptive information about enterprise elements. Because an EA repository stores metadata and model instances, the data model that structures the metadata repository becomes a metamodel.

A Core EA Metamodel is an entity-relation data model that identifies a minimal set of common data structure for any EA repository. The Core Metamodel can be instantiated and extended to build individual metamodels for specific EA repositories. The Core Metamodel can serve as a common base for individual metamodels of specific EA repositories to establish semantic affinity and to exchange information. Note that the Core Metamodel is a logical relational model. The physical data model of an EA repository could be a relational, object-oriented, or hierarchical model.

Using the Meta Object Facility (MOF) concepts defined by the Object Management Group (OMG, 2006), Table 1 illustrates which meta levels the Core EA Metamodel covers. As Table 1 indicates, the Core EA Metamodel covers both M1, the metadata level, and M2, the metamodel level. This is because an EA repository stores both data and metadata. Also as indicated in Table 1, an EA repository tool’s physical data model might be a relational data model (M1), an object-oriented class model (M3), a hierarchical XML schema (M1, M2, M3), or a combined model types such as OO-relational or OO-XML. EA Tools’ physical data models are not in the scope of the EA Management Guide.

Table 1. Meta Level of the Core EA Metamodel

Meta Level	Object Type	Example	Meta Level Allocation
M3	Meta object model	Class, Object		Repository Tools’ Physical Data Models
M2	Metamodel	Data Entity, Data Element,	The Core EA Metamodel
M1	Metadata/data model	Project (an entity): Project Name, Project Sponsor,	The Core EA Metamodel
M0	Data value	Project A
-	An actual thing in the real world	A specific project

1.2. How the Core EA Metamodel is Constructed

The Core EA Metamodel is expressed as one conceptual entity-relation data model that defines:

· Entity categories;

· A basic set of attributes; and

· High-level relationships.

The Core EA Metamodel can be viewed in different ways or different segments to highlight specific aspects. One of the ways to view the metamodel is to look at its components at different abstraction/decomposition levels. Differentiating the abstraction levels helps illustrate how the Metamodel can be used. Table 2. Abstraction Levels of the Core EA Metamodel, in the next sub-section will allocate the components of the Metamodel into levels and specify how the Metamodel should be used to guide meta modeling for specific EA repositories. The sections following this section will define and present the different aspects of the Core EA Metamodel.

1.3. How the Core EA Metamodel can be Used

The Core EA Metamodel can be used as guidance for developing instance EA metamodels for specific EA repositories. The way to use the Core Metamodel is specified in three Guidance Extents:

· Super Set: If a Core Metamodel object is indicated as a Super Set, the relevant components of instance metamodels should not fall outside the range defined by the object.

· Core Set: If a Core Metamodel object is indicated as a Core Set, the relevant components of instance metamodels should conform to the Core object but can have extensions following applicable rules.

· Reference: If a Core Metamodel object is indicated as a Reference, the relevant components of instance metamodels do not need to be identical with the reference Core Metamodel object, but should be able to map to the referenced Core Metamodel object.

The meaning of the Guidance Extents is further explained in Table 2 and in the sections following this section.

Table 2. Abstraction Levels of the Core EA Metamodel

Abstraction/ Decomposition Level[2]	Components/Objects	Use	Definition and Explanation
Contextual	Entity Types	Super set	An Entity Type defines a most abstract type of thing that exists in any enterprise and that has a set of basic characteristic distinguishing itself from other entity types. Every Entity Category in an EA repository should belong to an Entity Type.
Conceptual	Entity Categories	Super set	An Entity Category defines a group that contains entities with similar characteristics in the context of enterprise operations. Every entity in an EA repository should belong to an Entity Category.
Logical	Relationships	Reference	A Relationship describes the connection between two entities. Relationship instances in an instance EA metamodel can be developed following the relationship patterns identified in the Core EA Metamodel.
Physical	A basic set of Attributes and Relationships for any Entity	Core set	The Basic Set defines a standard set of attributes and relationships. Every entity in an EA repository should contain at least this standard set of attributes and relationships.
Operational	Versioning of the Core EA Metamodel	Reference (change control)	The version of the Core EA Metamodel serves as a reference for mapping and change control of EA metamodels.
Transactional	Instance metamodels created for specific EA repositories	Instantiation	Individual metamodels that were created following the guidance of the Core EA Metamodel are the instances of the Core Metamodel.

2. Core Metamodel - Rules

This section specifies the rules to develop the Core EA Metamodel and the rules to instantiate and extend the Core EA Metamodel.

2.1. Rules to Develop the Core EA Metamodel

2.1.1. Entities should be constructed as structure based, not topic based. “Structure based” means that an entity represents all instances of a thing that are structurally similar. “Topic based” means that an entity represents the instances of a thing that are related to a topic. For example, when a Process entity represents all instances of sequential activities that have a beginning and an end, this Process entity is structure based; when entities are set as Business Process, Administration Process, Financial Process, etc., these process entities are topic based. Topic based entities cause rigidity in regrouping and confusion in selecting. Therefore, the Core EA metamodel builds its entities according to structure similarity.

2.1.2. Entities should be independent of EA frameworks. This rule is a special case of Rule 2.1.1, avoiding topic-based entity constructs. Building entities according to specific EA frameworks causes rigidity in regrouping and confusion in selecting. EA frameworks and other topic related categories play important roles in EA repositories, but their roles are better utilized through categorizing instances, rather than entities. See Rule 2.1.3 for more elaboration on instance categorization.

2.1.3. Topic-based Categories should apply to instances. Applying topic-based categories to entity instances allows maximal flexibility and agility in providing decision support capabilities for EA repositories. Most decision-support capabilities of databases come from the querying power and data calculation power. Instance level categorization enables endless data querying and processing possibilities.

2.1.4.

2.2. Rules to Instantiate and Extend the Core EA Metamodel

3. Core Metamodel – Basic Entity Structure

The Basic Entity Structure of the EA Core Metamodel defines a minimal set of information dimensions needed to manage and utilize a data entity and the information contained in the entity. For an EA Metamodel to function well and serve the purpose, establishing the basic information dimensions defined in this section for entities is essential.

An Information Dimension of a Data Entity defines a group of attributes and relationships of a data entity that serves a purpose together. Any entity in any EA metamodel should contain the following information dimensions for various management purposes:

Element Documentation Dimension. The core purpose of a data entity in an EA metamodel is to document enterprise elements. An Enterprise Element is a unique unit of things, people, activities, etc., that plays a role(s) in an enterprise. The Element Documentation Dimension of an Entity contains all attributes in a data entity and all relationships of the entity that describe the characteristic of an element in the real world. This information dimension enables managing the instances of an element through the EA repository. The documentation dimension contains two sub-dimensions:

Description: a set of attributes and relationships that describe the own characteristic of the element. Examples include: attributes - Element Name, Element Description, Element Version; relationships - (Element is) owned by Organization Unit, (Element) uses Technology.
Context: a set of attributes and relationships that place the element in interoperation and context settings. Examples include: relationships - (Element) plays Role in Activity; (Element is) categorized by Category; (Element) inputs Material; (Element) outputs Product.

Entity Management Dimension. In addition to the attributes and relationships that document an element, a data entity in an EA metamodel should also contain attributes and relationships that describe the characteristic of the documentation instance itself. The set of attributes and relationships that describe the characteristic of the documentation instances forms the Entity Management Dimension of an Entity. This information dimension enables managing the quality of the documentation instance. Examples of the attributes and relationships that belong to this dimension are: (Entity instance’s) Last Updated Date, (Entity instance’s) Last Updated By, (Entity instance’s) Acceptance Status, (Entity instance) can be accessed by User, (Entity instance) has History (of the Entity instance).

Both the Element Documentation Dimension and the Entity Management Dimension enable managing the instances of either an element or its corresponding data entity. There is one more dimension that is essential to managing EA metamodels:

Metadata Management Dimension. Metadata Management Dimension enables managing the metadata of the entity. The Metadata Management Dimension of an Entity contains properties that define the metadata of the data entity. Examples of the properties include: Entity’s Definition; Attribute’s Definition, Data Type, Data Value Domain, Data Length; Relationship’s Definition, Relationship Type. The values of the properties comprise the content of the data dictionary of an EA repository.

This minimal set of information dimensions of any data entity in an EA repository enables a data entity to serve these purposes:

element documentation;
entity quality management; and
metadata’s semantic and format clarification.

These three dimensions of a data entity are logical constructs. How an EA repository physically establishes these dimensions can vary. Database management systems often use relational method, object-oriented method, or hierarchical method (e.g., such as in XML native databases) to construct its data structure physically.

For an EA repository system to provide functionalities and decision-support capabilities, many more meta constructs are needed by the repository applications. The Object Management Group’s Common Warehouse Metamodel can be used to guide the design and development of the meta constructs for EA repository systems.

4. Core Metamodel - a Basic Entity

The Basic Entity of the EA Core Metamodel defines a conceptual entity that specifies a standard set of attributes and relationships for all entities in any EA metamodel. For an EA Metamodel instance to conform to the Core Metamodel, every entity in the EA repository should contain at least this standard set of attributes and relationships.

Figure 1 illustrates the basic set of attributes and relationships. The attributes and relationships are described and explained in the attached file under this link:

http://www.aeablogs.org/cgi-bin/gforum/gforum.cgi?post=101#101

Figure 1. A Basic Entity for EA Repositories

5. Core Metamodel - Entity Types

Figure 2 identifies categories of entities in an EA repository and groups the categories into seven generic Entity Types. The Entity Types are: Thing, People, Work, Methodology, Rationale, Location, and Time. These entity types represent the basic types of enterprise elements.

Figure 2. Core EA Metamodel - Entity Types and Categories

6. Core Metamodel - Entity Categories Related in IDEF0 Processes

An enterprise is basically a place that people get work done to achieve goals. Every element in an enterprise must contribute to getting work done. Figure 3 presents a view that relates all entity categories through the Process category to set the roles of all entities in the context of doing work and achieving the goal of the enterprise.

Figure 3. All Entity Categories Should be Related in IDEF0 Processes