In previous articles, I have discussed that the two of the most critical factors in determining the success of the enterprise architecture (EA) are knowing why (Part 1) the EA is being developed and knowing what (Part 2)
is going to be in the EA. In this column, I will discuss the third critical aspect of the EA: how to develop an enterprise architecture. There are several approaches to developing an enterprise
architecture. This article describes some of the methods, benefits, and pitfalls of each. However, it can’t tell which is right, as it depends on your own organization, structure, and reason
(a.k.a. why as discussed in a previous article) you are developing the enterprise architecture.
Development Methods
Technology-Based EA Development
One of the most common methods of developing an enterprise architecture is by starting with the technology currently in place within the organization. Many EA projects are started by the IT
department with the premise of “Let’s make a list of all the technology we have, write down how they are interconnected, see who uses the technology, and then figure out why they
use it. Then we can tie everything into the organizational goals and declare victory.”While this method typically develops a detailed inventory of the technology, it often fails to properly gather, document, and understand the business aspects of the organization, as it is
technology-driven, developed by technologists, and primarily driven to support the IT department. Technology-based EAs identify every router, switch, hub, copier, fax, cell phone, COTS package,
in-house developed application, etc., but give little thought as to how the gathered information will be used to enhance the organization’s performance. Usually the data is collected
because it is available and, therefore, easy to obtain. Once the technology items are identified, they are usually linked to the business processes they support which are often identified by
examining each department’s web page or similar documentation. The danger inherent in a technology-based EA is that the existence of the technology is often justified by showing that it is
related to a process, and without the technology, the process would fail. This type of circular justification results in a skewed model, in which the existent technology is assumed to be correct
and required, rather than a supporting mechanism for the business processes. Additionally, critics will often state the obvious – “What do you expect – it was developed by the
IT department in order to justify buying more stuff.”Tip
- For each hardware item (router, switch), find its demographics (size, location, manufacturer, etc.
- For each software item (COTS, in-house developed), find its use, requester, supporting hardware, etc.)
- Etc.
Conversely, since gathering technology information is usually a well defined task, it is typically very easy to start the project and receive immediate, publishable results. Quick results usually
lead to increased visibility and increased support, which is almost always required on IT-based projects. If you decide to build an IT-based EA project, be aware that you have a very short time
to capitalize on the increased visibility and leverage that visibility into additional access to other aspects of the business.
Departmental-Based EA Development
An alternative method of developing an EA is on a departmental basis. By working with each department within an organization, a comprehensive list of business processes is identified and, from
each process, the supporting information systems (and their supporting technology) and corporate objectives that are being met. This method typically develops a stovepipe-oriented enterprise
architecture, in which each organization’s processes are well defined and mapped out, but no enterprise synergies are identified. Instead, an experienced architect must review all of the
processes types encapsulated within each stovepipe in order to identify the overlapping processes and duplications that were caused by the organization perspective. The architect must then
rationalize or normalize the processes into a true representation of the organization’s processes. Again, value can be obtained by developing an EA based on each department’s
perspective. Each department typically knows and understands the business processes it performs, will recognize its own processes in the published EA and will, therefore, be able to use and
support the EA. A similar function must be performed from a data perspective. Each organization typically understands the types of data it collects, uses, and creates but does not understand how
the data is related to other organizations. Moreover, the same data may be named differently, or other data may share the same name – but may mean something different as you cross
organizational boundaries.The primary disadvantage to this approach is that it is based on the willingness of the department heads to cooperate. More often than not, department heads have created their own
“fiefdoms” in which they are the sole “owners” of specific knowledge (process or data). By sharing that knowledge, department heads believe that the organization will
become less reliant upon them – and, mistakenly, the EA project is perceived as a threat.A second disadvantage is the dependency on the architect’s skills and ability. The architect is forced to recognize duplicated, overlapping, or missing processes and data and then must
determine how to resolve the issue. Once the architect has determined how to resolve the issue, chances are another round of discussions and meetings with organizational heads must occur in order
to resolve the issues.
Top Down-Based EA Development
A third approach to the development of an EA is through the use of a top-down methodology. By starting with the senior managers of the organization and identifying the corporate goals and
objectives, the EA is grounded in the organization’s purpose, and not its current organizational structure or technology. After identifying the business drivers, the architect can work with
organizational and process managers to determine the activities performed by the organization, the data used while performing the activities and, lastly, the technology used to support the
processes and data. Under this approach, the architect develops an understanding of the organization without having to “clean up” information that has been gathered – nor does
the architect need to worry about developing an EA based on the current organizational or technological implementations. Most importantly, the EA is grounded in the organization’s mission
and vision and, therefore, is not subject to changes based on a corporate reorganization or introduction of new technology. Instead, the EA is used as a planning basis for a restructuring or
introduction of technology and not an afterthought.This disadvantage lies in perceived time required to develop the EA. A top-down enterprise architecture initially develops high-level corporate objects (mission, goal, etc.) that are not
recognized for their importance by low level managers and their subordinates. Instead, the project is viewed as “another corporate exercise,” thereby reducing the importance paid to
the project. The importance of the project may not be recognized by the majority of the organization until after the business architecture is mostly defined, as is a significant portion of the
process architecture.
Gathering Data
The process of gathering the required data is the first portion of the project that will be visible to the enterprise at large. At this point, the EA’s purpose, scope, and design have been
determined, and now the actual content must be gathered. The first step in the data gathering process is to build an inventory of data sources, usually organized by architecture and, within each
architecture, by specific object type. For example:
Once the data types and information sources have been identified, it is time to collect the data. Each identified data source needs to be reviewed/interviewed in order to gather the information
specified in the data collection matrix. As the data is collected, it needs to be reviewed, clarified if necessary, and placed in the correct architecture. The orientation of the EA (technology,
organization, top-down) will determine which architecture to concentrate on and in which order the architectures should be developed. Continue the data gathering process until all of the data
necessary to fulfill the intent of the EA has been gathered.
Remember the EA is a living object – as you proceed through the development and use of the EA, the purpose of the EA will evolve (either by evolution or design) – be aware of the
likelihood, and plan accordingly.
In the next article, I will discuss how to use the enterprise architecture that you have developed.
