Overcoming Resistance to Enterprise Architecture
Problem:
Justifying the expense and effort of complete enterprise architecture (EA) modeling.
Documentation:
From the earliest days of systems development, documentation is usually seen as an overhead and sometimes, an afterthought. In the early days, there were even efforts to have “Self-documenting” code. So much for the short-changed analysis and design efforts.
Today, this attitude has carried forward to higher levels of systems and business planning. Enterprise architecture projects often fall victim to the same approach as early documentation. As it is eloquently described in Business Enterprise Architecture (1), the perception of the architecture and its documents needs to be changed from one of expense and overhead, to one of investment in a reusable planning “asset.” The practical, usable enterprise architecture model is exactly that, a reusable asset that should be the foundation of all enterprise planning.
Repository of Enterprise Knowledge
As noted in Working Knowledge (2), only a small percentage of current corporations have made headway in capturing their knowledge in a useful fashion. To capture all the facets of an enterprise for a complete enterprise model is certainly more of an undertaking than many organizations is willing to do, unless mandated to do so. Even those that have made strides in this area, have a difficult time quantifying the value and return on the investment. Some notable examples can be found in customer service support systems such as Hewlett-Packard’s Electronic Sales Partner and in collaboration such as BP’s Virtual Teamwork. These are respected internally as very successful systems, but yet the value of that success is difficult to quantify.
As Davenport & Prusak point out in Working Knowledge (2), any successful knowledge project must show the following nine factors to be perceived a success.
- A knowledge oriented culture (shared knowledge versus just performance)
- Technical and organizational infrastructure to support the effort
- Senior management support
- A defined link to the economics or industry value
- An element of process orientation (distinguishing knowledge from information or data)
- Clarity of vision and a common language
- Nontrivial motivations for use and contribution
- Some level of existing knowledge structure
- Multiple channels for knowledge transfer
Resistance is Futile and the Resistance is Us
The most common examples of enterprise architectures are in government agencies. Why, because they have been mandated to have a documented architecture for budget planning. Even there, however, you will find many examples where the enterprise architecture scope has been short-changed. Where it may meet the basics for the mandate, but fall far short of being the living, planning model that is should be. In some agencies, the models are so high level as to be meaningless. Perhaps these are a good start, but they are not done to the level of being useful planning assets.
The difficulty of any knowledge based EA is to have firmly identified goals, and a realistic timeline for producing it. Keep in mind that the purpose of an EA is embodied in its title: “Enterprise.” If the scope is too limited, you lose the value of the model for planning. You won’t see the “Big Picture” bottlenecks and redundancies. If the scope is too big, you run the risk of losing management support before delivering a useful product. It’s always a balancing act between these concerns.
A Balanced Enterprise Architecture Project
Most EA projects start off with one of the common frameworks in one hand and good intentions in the other; A little management support and some existing infrastructure within which to work. The work will use this infrastructure not only to develop the models, but to make them available for use to the enterprise. Regardless of the framework that you choose (Zachman, DoDAF, UML or one of the proprietary ones,) keep in mind that most of the developed products will not be user friendly to the audience that you are building them for. Right from the beginning, an element of education is necessary for management and expected users.
First, set the expectations for management. Don’t embark on EA modeling only to be cut off when management doesn’t see the progress. Set those expectations from the outset. Make sure the scope if big enough to be useful, but plan to deliver some interim products to demonstrate progress and value. Make the architecture visible from the earliest possible point. Put out browser friendly pieces of the model for users to begin exploring. Get them used to finding and refining their own processes from the models. Let them informally view and refine the models for you. The feedback is usually very effective.
Consider how you are going to make the architecture available to the end users. Most of the current tools will generate nice HTML menus and screens, but it’s still up to the project to educate the users on how to use these for planning and knowledge search. A map of information exchanges or a process flow may not be self-explanatory to your audience. Hold some walkthroughs just to confirm pieces of the models. Leading them through examples from your organization will be vastly more useful (and better received) than sending out some documents for comment or validation. Start early to make the EA a living document and show how it can be used in everyday planning.
Solicit Ownership
From the very outset of an enterprise architecture project, you need to set the expectations and solicit ownership from every corner of the organization. Don’t allow the scope to be diminished to a point where it’s not longer valuable. Again, the term is “Enterprise”. The value is in enterprise level planning and the reflection of changes in the entire enterprise. Identify very early to management how the products will be useful to the audience and how they will be distributed. How will feedback be gathered and integrated into the models?
Involve the users early in confirming and validating the models. Leading them through a few diagrams and products will quickly get them conversant in the modeling techniques.
With careful planning and clear expectations the enterprise architecture model will become a living reflection of the enterprise and a resource to all. The knowledge embodied in the EA should become a reflection of the organizational knowledge throughout the organization captured for reuse throughout time. A valuable asset indeed.
Don’t forget to leave your comments below.
Robert Jason Martin is an author and consultant living in St. Augustine, Florida. His work in business and systems consulting has taken him to most corners of the Earth working with a vast array of industries and governments, including many major world airlines. His first book was a text on the high-performance operating system that enables the world’s largest reservation systems to handle millions of transactions per day. He has designed multimedia and computer based training for a wide audience.
References:
- (1) Business Enterprise Architecture: The Formal Link between Strategy and Results, 2006 by CRC Press LLC by Whittle & Myrick, IBSN 0-8493-2788-1.
- (2) Working Knowledge, 1998 Harvard Business School Press, by Davenport & Prusak, ISBN 1-57851-301-4.