Author: Jason Martin

Enterprise Architecture – It’s All in the Name

Written by Jason Martin on April 24, 2012. Posted in Articles.

If you’ve been practicing enterprise architecture (EA) or any other formal approach to business analysis for any length of time now, you’ve probably noticed a world of “support groups” growing up around the topic. There are many online blogs and focus groups on LinkedIn and other social media outlets. I hope you have taken advantage of these, as they contain a vast resource of information for every practitioner.

Stick to the point

Like many social media sites, there are always the posts that meander from the topic. You’ve all seen these where someone injects a veiled ad for their multilevel marketing endeavour or their favourite political cause. These are irritating but easily dismissed. Perhaps more disconcerting are the posts that sway from the topic to some closely aligned technical skill. Maybe Java code is closely related to XML, but the topic of the group needs to be respected.

A recent post to which I felt compelled to respond questioned the proper “scope” for an enterprise architecture project. Having been around this game for more years than I like to admit, this prompted me to respond and later to write this article. Without noting a year, I’ve been doing analysis since the early days of “structured analysis” and all of the many methods and tools that followed. I’ve seen the use of improved analysis techniques applied in many ways and supported by many tools. This is not to speak of the plethora of creative terms that every author seems compelled to use in describing the same techniques. This may sell books, but it often complicates and confuses the neophytes in the business.

Project Scope

This most recent post looking for the proper “scope” seems to be from one of those new-to-the-practice analysts. Enterprise architecture is exactly that…”enterprise.” The proper scope for an EA project is the enterprise! Anything smaller is just a contributing project within the enterprise and should be shown as a project area within the enterprise architecture. Most projects are at this smaller scale because few of us are privileged to get the proper sponsorship to do truly “enterprise” architecture. Enterprise is a tricky term, and must be carefully defined as part of the project initiation and charter. (You DO have a project charter, don’t you?) This leads to a whole host of questions about sponsorship and the customer of the EA. Hopefully your EA products are used by senior management for strategic planning purposes. At lower levels they may also be used to guide specific projects, but that is a secondary benefit. The EA should reflect the enterprise and therefore its greatest use is in guiding that enterprise’s strategy. It’s an interesting aside that the Project Management Institute’s Project Management Body of Knowledge (PMBOK) goes into great detail to define projects within programs, but there is nary a mention of the term “enterprise.”

Where does it end?

Scope of the enterprise can be difficult to state. First, your sponsor may not have the purview of the entire enterprise. That’s doesn’t mean that your architecture should be limited by your sponsor’s authority. You may not be able to go into complete detail in those areas outside your sponsorship, but you must include them in the architecture. They DO exist, even if only to interface with your enterprise. In some organizations, you may find that your enterprise crosses many difficult boundaries, some of which are politically impossible to cross. An associate once began trying to do an EA for “health care” in the Department of Health & Human Services within the U.S. government. It quickly became obvious that the enterprise involved more than the political limits of the Department. The Department of Defense runs one of the largest health care operations in the world, but it’s beyond the scope of the Department of Health & Human Services. How do you model this? It would be a travesty to ignore the existence of such a huge and somewhat parallel enterprise. But how does one include such an organization into the models when it is completely outside your sponsorship?

The scope of the EA must take into account the true “enterprise” while also respecting the limits of authority within the organizations. The interfaces and redundant data across multiple boundaries of authority must be noted and respected while building models that are useful and representative of the true functional enterprise.

Overall

Scope is always one of the first and most difficult definitions for any project. Certainly trying to model the enterprise makes for some difficult decisions before the work can even start. Don’t fool yourself into claiming a scope that is only part of the true enterprise, even if your authority is limited. Your sponsor’s limitations do not change the facts of what the true enterprise entails. Model the true scope and then carve out projects inside that scope for incremental progress. Each project should plot against the overall enterprise like a mosaic taking shape.

Don’t forget to leave your comments below.

Overcoming Resistance to Enterprise Architecture

Written by Jason Martin on March 22, 2011. Posted in Articles.

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.