Enterprise Architecture – It’s All in the Name
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.