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

In my previous three articles in this series, I’ve tried to provide the basic information required prior to establishing an enterprise architecture (Why – Part 1; What – Part 2; How – Part 3) – in other words, you’ve connected-the-dots. You’ve associated business vision, goals, and objectives with data, process, and technological decisions. The title of this series was not selected at random. Many organizations treat an enterprise architecture (EA) as nothing more than a connect-the-dots project that must be performed because a government agency says it must be performed or because it’s the latest buzzword. However, it is – and should be treated as – an integral part of an enterprise’s growth and management plan.

In this article, I will describe some of the activities required to make the EA a usable, useful, and necessary part of the organization – in other words, embedding the connect-the-dots picture into your organization. If you have been following along in the series, you have learned how to:

• Define the enterprise architecture’s purpose – Part 1
  
  
• Design the enterprise architecture – Part 2
  
  
• Select the enterprise architecture’s development approach – Part 3 

This article will discuss how to:

• Use the enterprise architecture
  
  
• Publish the enterprise architecture
  
  
• Maintain the enterprise architecture
  
  
• Govern the enterprise architecture

Implementing an enterprise architecture is more than creating an EA Program Office and then sitting back and watching the results. In order to successfully implement an EA, the enterprise must understand and plan for the organizational and policy changes that are part of the EA process. The concept of an EA, that is, the centralization of knowledge in order to plan an Enterprise’s operations, is anathema to many individuals, particularly those from an IT planning background. Whereas IT planning is oriented toward the use of IT resources to solve particular business issues or to improve business process efficiency, EA operates at a strategic level, where architects help guide the business processes, data, and technology based on the organizational vision and goals. Recognizing the significant difference between the two planning perspectives is the first step in successfully implementing the EA philosophy.

Use the Enterprise Architecture

Tip:The EA is akin to the automobile industry’s prototype – a model that is used, tweaked and worked with, PRIOR to the actual implementation/creation of a new concept or car.

Using the EA is, of course, why you are interested in developing an EA and, therefore, reading these articles. The EA can be used to answer simple “where are we now” questions such as:

• How much did we spend on IT last year?
  
  
• Which servers support business processes X?
  
  
• Which processes support which goals?

However, the EA’s power and strength comes from its ability to support predictive questions such as:

• What systems will no longer be effective if the processes they support are placed into different organizations?
  
  
• What vision, process, data, and technology changes would be required if a new business is acquired?

In other words, the EA is being used as a model for change, not a recordation of changes that have occurred. One is an after-the-fact usage and one is a before-the-fact usage; again, it is not a matter of right or wrong, but how the EA is intended to be used.

Publishing the Enterprise Architecture

Publishing the EA is as important as building the EA itself – the EA is not useful if no one can access it. Therefore, one of the major activities of the EA process is publishing and publicizing the EA. Proper marketing of the EA will require an understanding of:

• Who the audience is
  
  
• How the audience will get to the EA
  
  
• How the audience will use the EA

Similar to other systems, the EA will have a variety of users, each with their own requirements and interests; accordingly, the EA must accommodate the different perspectives.

EA Governance

Tip: Once the EA’s credibility is lost, it will be virtually impossible to regain; and all the time, effort, and money put into its creation will be wasted.

EA governance is the establishment of a structure to govern the development, use, and maintenance of the EA. The governance of an EA is based on a highly coupled set of techniques for effectively managing its implementation and use. Maintaining the EA is as important as the development of the EA itself. Once the organization begins to use and rely on the EA, it must be kept as up to date as possible for it to be useful. If users of the EA begin to find errors or inconsistencies in the EA, they will lose faith in the EA and all credibility will be lost. Typically, 5 techniques are included as part of the governance process: organizations, policies, processes, metrics, and tools. While the exact implementation of each of these areas will vary by organization, in general, they should display the following characteristics:

Organizations
An overall EA Team is required to plan, manage, implement, use, and promulgate the EA. Within the EA team, several sub-teams may be required, with personnel targeted to each area.

Policies
Policies must be established regarding EA contents, data timeliness, and data accessibility in order to ensure the data collected is accurate and useful. Inaccurate data or data that is perceived to be inaccurate will cause users to lose faith in the EA itself, as well as the philosophy. Once it is lost, user confidence is extremely hard to re-gain. Therefore, establishment of polices prior to gathering the data is a requirement for the EA effort to succeed.

• Contents of the EA (what data is to be collected). The contents definition includes the object types to be collected, the information about the object types to be collected, and the relationships between the object types to be collected.
  
  
• Timeliness of the data (how often data is to be collected). Each object type identified in the contents section has its own specific life cycle regarding when it is created, updated, and deleted. For example, an organization’s vision rarely changes, while underlying technology is more volatile. Accordingly, while the vision objects are more important to the organization from a strategic level, their refresh rate will be much longer than for technology objects.
  
  
• Accessibility (who has access to which aspects of the data). Due to the potential sensitivity of some of the data that is collected for the EA, the organization may wish to restrict access to it.

Processes
Processes must be established to implement the policies developed by the Policy Team. For example, once the content of the EA is determined, the processes for acquiring, maintaining, and promulgating the data must be created. Some data about an organization is often readily accessible, often through a public affairs office or the enterprise website. Other data may only be gathered by accessing a specific piece of hardware or software. Similarly, processes must be established for ensuring the data is kept up to date, via some temporal-based trigger (validate the enterprise mission, goals, and objectives once a year or validate the server inventory every 30 days) or external factors (validate the software inventory when a merger or acquisition of hardware or software vendors occurs).

Metrics
One of the basic tenets of an EA is to improve the operational efficiency of the enterprise by managing current operations as well as aiding in the planning of future operations. Part of the implementation of the EA is a set of methods that are used to determine the success of the EA itself. Some metrics that could be implemented include:

• Percentage of funds are allocated to compliant projects
  
  
• Cost per business process as related to relative importance based on vision/goals/etc.
  
  
• Percentage of re-use of architectural components (processes, data, technology)

Tools
Due to the volume and interrelationships of data collected during an EA effort, an automated tool is required to keep track of the information for both the data collection and the reporting aspects. There are a variety of tools available, each with its own capabilities and orientations. The tool that is selected must be compatible with the direction and scope of the EA effort. The tools are typically model-based, allowing the user to inter-relate business, data, process, and technology models in order to assess the impact of the models on each other, as well as the impact of changes on each model. The use of a model allows a user to work with facsimiles of the real world to determine what could happen – prior to actual implementation.

Summary

Hopefully, this series of articles has provided you with some insights into establishing an EA-oriented environment, or expanding an existing EA environment such that it becomes an integral part of your enterprise. Remember, a connect-the-dots puzzle has two aspects – the design of the pattern itself (objects to be stored) and the resultant picture once the dots are connected.