Plan for Success in your Enterprise Architecture Project: Factor in ...

By Tammy Marshall,2014-05-05 14:22
9 views 0
Plan for Success in your Enterprise Architecture Project: Factor in ...For,for,your,Plan,Your,plan,YOUR

    Plan for Success in your Enterprise Architecture Project: Factor in the 3 Amigos


    We have seen enterprise architecture emerge from the shadows into the limelight. The crowning moment for architects was the Clinger Cohen Information Technology Reform Act of 1994 [Ref1] that demanded Federal Agencies have a published enterprise architecture plan before they went out seeking or spending money from the Office of Management and Budget. Further federal regulation based on the Clinger Cohen Act demanded that every Federal Agency have a Chief Information Officer in place whose responsibility was to deliver the enterprise architecture plan in alignment with the OMB’s reference model.

And as the old saying goes, “Be careful of what you ask, because you may just get it!”.

    Since then there has been a flurry of activity in enterprise architecture with varying degrees of success. There have also been spectacular failures. The Office of Management and Budget has audited several enterprise architecture efforts amongst various Federal Agencies and published its findings in a report [Ref2]

    MMC has been working in the area of Enterprise Architectures long before the Clinger Cohen Act and before federal mandates have made the area ubiquitous. Our enterprise architecture related projects have stood the test of time. And in our experience, the chance of success can be significantly improved by paying attention to what we call, the three Amigos: Purpose, Scope and Viewpoint.


    Purpose is the reason you do an enterprise architecture project. Without a purpose, an enterprise architecture simply becomes a sand box play. Purpose may range from the Purpose very mundane: comply with Clinger Cohen to the very ambitious: Implement a Is why you are doing architectural strategy to become the number two supplier of passenger rental cars in the the project in the first United States. place.

    Often, the reason why enterprise architecture projects go nowhere after the initial flurry of activity and the delivery of volumes of reports and very large diagrams is precisely because of the narrowness of purpose statements such as “meet regulatory needs”.

    Purpose is the first thing you put down before starting an enterprise project. The purpose is qualified by anticipated benefit statements to specific stakeholder groups in a specific timeframe.

    The statement of purpose is used as a knife to cut scope. Any scope element that deviates from the purpose must be examines closely because it may add to the project cost without getting the project to its destination.


Scope sets the boundaries for an enterprise architecture project. These boundaries are Scope stated upfront to ensure that any expectations or data needs for types of analyses that go beyond the boundaries will not be met by completing the architecture effort. Scope Sets the boundaries of a boundaries define both the breadth and the depth of the project. Breadth refers to the project in terms of varieties of architecture elements to be considered; depth refers to the degree of detail breadth and depth. with which those elements are refined.

     Copyright ? 1995-2006 Metadata Management Corporation, Ltd. All Rights Reserved

    For example, while modeling the enterprise architecture for a airline, will we also be representing the Federal Aviation Administration for air traffic control, hotels where the aircrew stay on layovers and law offices that are retained by the airline in the event of civil lawsuits or in other litigation? This question can only be answered by the breadth of scope that was selected for the effort. On the other hand, incorporating these elements into the architecture involve more interviews, more data gathering and knowledge representation and therefore greater cost in building the architecture. The depth question, for example, is whether we model the FAA as a monolithic block or break it down into smaller sub-organizations for architecture representation purposes. The enterprise architect is always balancing the cost of expanded scope (breadth and depth) with the anticipated analysis value that results from a broader view.

    Scope specifications can be made in two ways: By ennunciating principles that allow the architect to select only architectural elements that obey those principles OR by enumerating list of items that form boundaries for the architecture. The architect is constrained to use elements only from this list.

What are the elements of scope? The broadest way of organizing scope elements are by

    grouping them into the six categories: WHAT, HOW, WHO, WHEN, WHERE and WHY. In other words, by using the Zachman Framework for Information Systems Architecture [Ref3]. How does one use these six categories to set up scope?


    WHY is the first category we select, because everything else stems from why the business exists in the first place. WHY categorizes motivations for the business. These are either couched as business goals and objectives, or types of missions that the business is involved in, or types of monetary return that the business expects to achieve.

    We start by listing the objectives that are part of the scope of the enterprise architecture. We may wind up selecting only a portion of the objectives to model given the appetite for spending, the deadlines for the project and the availability of expertise.

    We may list the various types of missions undertaken by the organization. Again, only a subset of these missions may be interesting to the project.

    We may list the various instruments of monetary return that the organization invests in. Only a subset of these instruments may be of interest to the enterprise architecture project.


    We select WHAT as a consequence of the motivation question WHY. WHAT we do is a consequence of our overall objective or purpose. WHAT a business does is defined by its Lines of Business, its product set, the list of services that it offers, its areas of business. These in turn lead to key business functions that the business performs.

    Selecting scope involves specifying which areas of business, lines of business will be covered. It may also involve specifying which business functions that relate to these lines of business may be covered. Often the enterprise architect will concentrate on “core” lines of business and postpone the modeling of administrative and support functions for a later project. On the other hand, an enterprise project that is focusing on targets of opportunity for outsourcing will focus on all non-core functions as low hanging fruit.

     Copyright ? 1995-2006 Metadata Management Corporation, Ltd. All Rights Reserved


    The lines of business, and delivery of services and products that are described by the WHAT are supported by business processes which represent the HOWs of doing business. The purpose of scoping here is to select those processes that will be covered by the architecture effort.

    Selecting scope involves laying out the key processes that support previously selected lines of business, mission areas or key business functions and selecting a subset.


    The business processes that comprised the HOW are then used to define locations of interest that the architecture will cover. Locations can either be notional such as manufacturing facility, forms processing center, operations center, data center or they can be regions, states, cities and physical addresses depending on the depth and breadth limitations that drive the scoping activity.

    As architects we try to work with notional items because they are conceptual and can be replicated many times in many places. Using the architecture term data center, instead of a specific data center located in say, Rockville MD allows us to couch the functions performed by the generic data center, the roles of people associated with the generic data center.

    Enterprises that have readymade taxonomies of locations by category have an upper hand in providing scope elements to the enterprise architect. A taxonomy is a classification schema that is a hierarchical arrangement of terms. For example a DoD Taxonomy may break the world into CONUS (Contiguous United States) and OCONUS (Outside Contiguous United States); An other way may be to define the AOR (Areas of Responsibility) as CENTCOM, SOUTHCOM, NORTHCOM, EUCOM, PACOM.

    Enterprises that have lists of generic facilities also have a powerful source for the enterprise architect. Scoping simply involves selecting subsets of these lists for matching the architecture purpose and viewpoint (the other 2 amigos)


    The business process that comprised the HOW are obviously performed by people and organizations. In addition there are other stakeholders whose needs are served by the process or who impact the process in some manner. Examples of such stakeholders are regulatory organizations, customers, and suppliers of material.

    Again, having readymade taxonomies of the stakeholders for an enterprise provides a leg up in scope selection. The WHO category may involve notional organizations such as Air Traffic Control Regulation Authority, Financial Institution, Airline or it may involve real organizations like the FAA, First National Bank of Fairfax or TransUSA Airlines. It may involve notional roles for people such as Database Administrator, Claims Processor, Air Traffic Controller but rarely real people such as James Dobson, Sarah Vaughn or Timothy McFee.

    A taxonomy (or taxonomies) within an enterprise may contain a classification scheme for all roles within an organization.


    There are many periodic events and repeating cycles of activities that characterize the operating environment of an enterprise. These are the items that describe the WHENs of the enterprise. Events occur instantaneously or near-instantaneously and represent elements such as Christmas (For the Retail industry), National Holidays (for the airline industry), Federal Budget Year-End (Federal Contractors). Cycles are series of activities that repeat periodically. Examples of cycles are: Federal Bid Cycle (Federal Contractors),

     Copyright ? 1995-2006 Metadata Management Corporation, Ltd. All Rights Reserved

    FDA Drug Approval Cycle (Drug companies), IRS Income Tax Year (Taxpayer), Financial Year (Accountants), Court Docket Entry Cycle (Legal).

    An enterprise with a corporate calendar of events has an advantage in being able to provide a set of events that the enterprise architect can choose from. Enterprise that have well maintained taxonomies of events and cycles can provide these as candidate scope elements for WHEN.

    Scoping is a fairly straightforward selection activity for enterprises that already have taxonomies for the WHAT, WHO, WHERE, WHEN, WHY and HOW of their business. In fact, by having a published enterprise architecture, enterprises are forced to answer these crucial questions. For those enterprises that have never had to answer these questions

    will have difficulty controlling scope of enterprise architecture related projects.


    The third amigo, viewpoint is slightly different from scope and purpose. Purpose determines why you are doing the enterprise architecture project. Scope determines what architecture elements are in the project and what are out of the project.

    Viewpoint, is the specification of the type of person who is viewing the architecture. This Viewpoint may seem complicated at first, and we will use a simple example to explain this concept. Imagine you are a passenger walking through an airport corridor. From your viewpoint, Is what you can see you are unable to see beyond those locked doors in the corridor and see what’s within. As based on where you far as you are considered, your are blind or oblivious to existence of baggage search are standing. facilities, security interrogation facilities, ticket printing equipment, baggage handlers, baggage handheld scanners, radio traffic with Air Traffic Control or with Airport Security and a host of other items that lie beyond those doors. It is not that they don’t exist; it is just that they do not exist from your viewpoint as a passenger walking through the airport. Now, on the other hand, if you were a authorized airline employee with card access to the door that opens, you are aware of all the things you see behind that door. With a change of viewpoint, what you see has also changed!

    Viewpoint is an important concept in architecture. It is very important to assume the viewpoints that are required by the purpose of the architecture. If the purpose of the architecture is to reorganize the hub and spoke operations of a airline, a passenger’s viewpoint will not cut it.

    For every architecture project, it is important to assert the various viewpoints that will be covered. While presenting the results of an architecture project to a stakeholder group, it is important to present only those elements that are visible to the viewpoint that the stakeholder group represents.

    We have touched upon the three amigos: Purpose, Scope and Viewpoint as critical ingredients for the success of an enterprise architecture project. Our experience has shown that expectation problems come from not setting up (and advertizing) the scope appropriately. Communication problems result from not articulating or validating a viewpoint correctly. And ultimate usefulness or uselessness of a architecture project hinges upon defining its purpose clearly, succintly and based on value to the enterprise.

     Copyright ? 1995-2006 Metadata Management Corporation, Ltd. All Rights Reserved

Report this document

For any questions or suggestions please email