Developing an enterprise architecture (EA) is a easy task (like brain surgery) – all you have to do is identify the things in your organization you care about, see how they are interrelated
and document them. The difficult aspect of the EA process is not the development of the EA itself, but determining how to use the EA. Some organizations use the EA as a method of actively managing
corporate resources (active EA use); others use it as a method of documenting their corporate goals, structure, business processes, data and technology (passive EA use). Both applications of an EA
are correct – it’s a matter of determining why you are building the EA. The failure to understand the purpose of the project dooms an EA project to failure – just as
failing to understand the requirements in a system development project dooms it to failure. EA development, like any other development process must start with an understanding of the vision and
then an understanding of the requirements. The vision drives the direction, style and purpose of the EA; the requirements determine the specific items to be stored.
For example, if an EA contains a structure like the one shown in Figure 1, it is possible to review the allocation of funds to IT items in order to ensure the allocation is “correct” in
terms of their support of corporate goals; that is, applications that support the most important processes (as determined by the goals, objectives, strategies) should receive the highest
priority and, therefore, the highest funding amount. This can be further augmented by assessing the quality of the support provided by the application. Those applications that provide adequate
support are less likely to be targets of upgrades or enhancements. Using these types of basis, each IT expenditure can be valued based on its alignment with organizational goals, objectives, etc.,
thereby decreasing the likelihood that a “popular” or “squeaky wheel” expenditure will be approved to the detriment of an expenditure that would have provided an increased
benefit to the organization. This type of active EA use will quickly point out where inequities lie, whether it is in the allocation of IT support to business processes, or organization size to
organization importance.
In the same manner, the EA can also be used to help ensure compliance with OMB Circular 11, Section
300. The Circular requires that IT investments be justified based on their support of organizational goals and objectives. By using the structure identified in Figure 1, the organization can
justify its anticipated IT expenditures in terms of how well the expenditures support the organization’s business processes, the strategies implemented by the processes, the objectives
implemented by the strategies, etc.
Figure 1: Partial Enterprise Architecture Structure
As a second example, an organization can use the same structure, but use it to document how all of the pieces are put together, and use this knowledge as a training basis. More often than not, when
new employees are brought into an organization, they are immediately given a pile of manuals to read, ostensibly so that they can learn what the organization does. This material is often the same
material provided on the organization’s website. While it often tells what the organization does, it fails to tell how the pieces fit together. A complete EA, with well-defined objects and
relationships, tell the reader how the parts fit together. The passive use of an EA is often the first step in an organization’s efforts to manage its assets. By first understanding the
individual pieces of the organization, a knowledgebase is built to move to the next step – actively using the EA as a management device, rather than a documentation tool or a checkbox that
must be completed.
Properly used, the EA is more than a collection of dots connected to each other in a predefined order. It is a collection of items that, while interrelated, can be moved, adjusted and reconnected
as circumstances dictate. Historically, executive managers (or the board) defined the general direction of the organization, while allowing the senior managers the flexibility to define the
specific function to be performed; middle managers defined the processes to accomplish the functions; and staff performed the process. Somewhere along this life cycle, the IT staff became involved
– and magically systems were developed. However, very few people ever grasped the scope or complexity of the organization’s total resources (including vision, mission, process, data and
technology). Moreover, things change – from the most stable (business vision) to the most volatile (technology), and failure to understand the impact of a change can doom an organization. The
impact of an anticipated change should be understood prior to the implementation of the change – whether the change is a restructuring of the organization or the implementation of new
technology.
When a restructuring occurs, the business processes associated with the organizations also shift, but more often than not, the underlying technology is not altered, resulting in a misalignment
between the business and the technology. This results in well-developed systems that met the organization’s requirements at one time, but are suddenly inadequate or failures. Similarly, when
a business process shift occurs, each technology that is touched by the process must also be examined. For example, when a department adopts the use of digital cameras, they may see it as only as
an increase in picture clarity. However, from a technology standpoint, new software will have to be introduced into the environment, new processes must be developed to manage the photographs that
are to be stored and, lastly, there may be a requirement for additional storage.
Neither of these examples is far-fetched – they have occurred and will continue to occur until organizations understand the power of a well-developed enterprise architecture. Remember,
connecting the dots is easy – it is understanding where to put the dots – and why – that is difficult.
