THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

In Part 1 of this series, I discussed the importance of understanding why the enterprise architecture (EA) is being developed as being a crucial element to its success. In this article, I will discuss what items could be contained in the EA and touch briefly on how to organize the objects.

Two of the most basic, underlying questions regarding an EA (after deciding why the EA is being built) are:

What do I put in my EA (metamodel)?

How do I organize those items I am putting in my EA (architectures)?

Metamodel

The design of the EA’s metamodel (the types of data to be stored in the EA) is analogous to the design of a database – if the metamodel is wrong, the system will not be as successful as it could have been. Similar to a database structure, the metamodel of the EA can be changed, and will change over time, but the more accurate it is to begin with, the less impact each change will have to the overall structure.

Architectures

While both questions raised above are important (What do I put in my EA? and How do I organize those items I am putting in my EA?), the first question is considerably more important. Regardless of which framework is selected, you are organizing data about your enterprise – and therein lies the more important question: What data do I want to collect? For the sake of clarity, assume the data is organized into 4 architectures:

• Business – Where we are going? Who is going to get us there?
  
  
• Data – What do we need to know to get there?
  
  
• Process – What do we need to do to get there?
  
  
• Technology – how are we are going to get there?

Business Architecture
The business architecture (Where are we going? Who is going to get us there?) contains the Object Types that establish the purpose or direction of the enterprise (the enterprise’s vision, mission, goals, objectives), the methods to determine if the purpose has been achieved (measures), and the organizational structure to accomplish the purpose (organization). Once these Object Types have been gathered, they must be linked to each other to form the hierarchy of guiding principles and tied to the organizational units. Depending upon the organization’s nomenclature, a hierarchy similar to the one shown in Figure 1 will be developed.

Figure 1: Partial Business Architecture

Data Architecture
The data architecture (What do we need to know to get there?) contains the Object Types that define the pieces of information in which the enterprise is interested. These may be grouped into some type of logical organization (subject areas, data models, common themes, etc.) but are independent of the departments which create/use them, and are independent of the technologies (systems, databases, flat files, spreadsheets, 3x5 cards) which implement them. Figure 2 shows one possible organization of a data architecture.

Figure 2: Data Architecture

Process Architecture
The process architecture (What do we need to do to get there?) contains the Object Types defining the functions and processes performed by the enterprise without being organized along organizational or technology lines. This architecture is based on a functional decomposition of the enterprise, with each level of decomposition representing an additional level of detail. In addition to the functional decomposition diagram, the process architecture may also contain data flow diagrams, use cases, swim lane diagrams, or any other diagrams that link processes together and provide an understanding of what the enterprise does.

Figure 3: Process Architecture Hierarchy Diagram

Technology Architecture
The technology architecture contains the Object Types that identify the IT equipment (servers, switches, routers, etc), applications (in-house developed applications, COTS/GOTS packages, drivers and utilities), and other IT items that implement the business, data, and process Architectures. The technology architecture contains the most tangible aspects of the enterprise and is, therefore, the architecture that is most easily understood by the majority of the organization, although not necessarily the most important.

Figure 4: Technology Architecture

Object Type Specifics

In addition to identifying each of the Object Types to be included in each architecture, the specific pieces of information about each Object Type must also be evaluated. The selection of Object Type Attributes is heavily dependent on the purpose of the EA. For example, if the purpose behind the development of the EA is to build a technology portfolio, then specific attributes such as Server RAM size and CPU count is of utmost importance to the project; however, if the purpose of the EA is to ensure the enterprise’s use and acquisition of technology is aligned with corporate goals, then the low-level server attributes listed above are of lesser, if any, importance. Instead, the EA should be focused on the business processes (and thereby goals and objectives) supported by the server.

Tip: An Object Type is roughly equitable to a Table and an Object Type Attribute is roughly equitable to a field in a Table.

Some sample Object Types and their Attributes from a goal-oriented architecture are shown in the table in Figure 5; however, they need to be tailored to each enterprise’s nomenclature.

Object Type Relationships

Tip: Identify business reasons to connect objects. Don’t connect objects to enhance the size of the model – it just adds complexity, without adding benefits.

Just as the architect needs to determine which Object Types (goal, entity, process, server, etc.) are to be stored in the EA, the types of Connections/Relationships between the Object Types must also be determined. As information about the enterprise is being collected, information about the interactions between the objects is also being collected. For instance, while collecting information about the enterprise’s goals and objectives, information about the divisions and departments responsible for achieving specific goals and objectives is also gathered. Similarly, while learning about the business processes, information about the automated support will also be gathered. There are literally thousands of Relationships that can be made between the Objects Types in the EA. Just as the architect must determine which Object Types are to be included, the architect must determine how those Object Types are to be related.

Summary

Remember the adage, “Just because you can, doesn’t mean you should,” and apply it often to the selection of Object Types, Object Type Attributes, and Object Type Relationships. The EA is a management tool to help define the enterprise. It is not a picture of all possible items and all possible connections between the items.

In the next article, I will discuss how to populate the enterprise architecture that you have designed.