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, 3×5 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.
