Saturday, January 30, 2016

Enterprise Context - Anchor Models

In last week’s posting, I related the idea of an Enterprise Context as prescribed by Gartner (Gartner, 2011) to a software system’s Context Diagram, recasting it as an Enterprise Context Diagram (ECD). 

This week I want to show how the ECD fits into the process for launching EA, while adding some additional high-level models to the launch process.  Scott Bittler, a vice president at Gartner, gave a presentation at Penn State titled “Enterprise Architecture Pitfalls - Current State First?” (2012).  This presentation cautions EA teams against initially focusing on the current state of the enterprise, providing the following reasons:

  • Working on the current state delays time-to-value
  • It’s a never-ending exercise as the current state is always changing
  • Focusing on the current state encourages incremental thinking
  • Creates a “burden of knowledge” which hinders creative work on the future state.

The presentation makes a strong case for EA teams to avoid focusing on the current state when starting their EA programs.  Gartner’s recommendation for EA launch deliverables is referred to, collectively, as the Enterprise Context.  The Enterprise Context is comprised of:

  • Trends
  • Business Strategy
  • Requirements
  • Principles
  • A single anchor model

It is the notion of a single anchor model that is my focus this week.  The presentation states that this bullet should be taken verbatim, recommending that during the EA launch process, there should be one current state model that captures the entire enterprise, all in a single picture.

While I agree with the idea that EA teams should avoid starting with the current state, I recommend SMBs take advantage of their smaller enterprise footprint and expand the anchor model concept from a single model to a small anchor model series.  Here are the current state models that I recommend for an anchor model series, as part of the overall Enterprise Context deliverables:

  • Enterprise Context Diagram - The details of this model can be found in last week’s posting.  I recommend an ECD for the full enterprise and one for each separate business unit, as the unique environment of each business unit is important to see when planning for the future state.  Each ECD is only one page each, so the effort should be reasonably small.
  • Organization Diagram - This is a slight decomposition of the ECDs, which takes the box representing the enterprise and expands it to add the organizations directly involved in the production process (the departments that add the value described in the value proposition) and the supporting departments such as HR, IT, and Finance (generic default management example).
  • Enterprise Information Model (EIM) - The EIM resembles a data model, but without any data attributes and absolutely no representation of application-specific information.  It simply shows the major business entities that describe the enterprise and how they relate to each other, much like Gartner’s “Bank XYZ Deliverables Navigation Guide” shows how all the EA Deliverables relate to each other (generic default management example).

These three models will provide three important, yet simple, high-level views of the enterprise.

  1. The ECD shows the external environment (for the full enterprise and business unit levels).

  1. The Organization Diagram shows the high-level organization, distinguishing production departments from support departments while retaining the context of the external environment.

  1. The EIM shows the important informational assets and how they related, without the enterprise’s environment or structural organization to complicate it.

The models recommended above will provide an SMB with exactly what models are supposed to provide, that being unique views or perspectives of the same enterprise.  This makes for a simple, yet powerful current state representation with minimal time invested.  This series of anchor models, when combined with the rest of the Enterprise Context deliverables, will give the SMB a solid launching point for EA while retaining Gartner’s recommendation for minimizing the current state efforts during launch.

References

Gartner. (March 2, 2011). EA Must Include Defining Your Enterprise Context

Bittler, S. (2012, January 31). Enterprise Architecture Pitfalls - Current State First?. Retrieved from Penn State EA-872 class material

Gartner. (n.d.). Bank XYZ Deliverables Navigation Guide.  Retrieved from Penn State EA-872 class material

4 comments:

  1. Hi Scott,

    Thanks for posting your recommendations for a series of anchor models. I find it to be intriguing. I agree that there should be multiple perspectives of the enterprise, but from my understanding, a single context is not meant to replace different perspectives, but rather to reconcile them. What do you think?

    -Nate

    ReplyDelete
  2. Hi Scott,

    Thanks for sharing your thoughts on how current state can be captured at different levels in an organization with minimal efforts. Gartner has been a big proponent of future state architecture first and it makes sense that the current state is ever changing, focusing on that will take an EA no where. But I do realize that there are situations which call for better understanding of current state before thinking of future state. TOGAF clearly mentions that there is not one best of creating architecture. Both current state first and future state first have its own benefits and either works. It is up to the EA to decide which comes first in that particular scenario. And this is how my mindset is around current vs. future architectures.

    Thanks,
    Veena.

    ReplyDelete
  3. Scott - thank you for the post, I found it to be very informative. I myself also believe EA teams should avoid starting with the current state as the future state is what will be the main goal and objective in the program. I also tend to agree that every situations is unique and it is difficult to formulate a specific gameplan that can be used as a one-size fits all type of deal.
    -Nick Bongiovanni

    ReplyDelete
  4. Hey Scott, thanks for the great links. I would agree with you about not starting with current state context diagrams. It's definitely like chasing a moving target and therefore never allowing the practice to get off the ground. I am a firm believer that once you have direction, that a current state needs to be developed from an agreed upon time frame. This allows you to produce a change map, showing not only what is but what is missing and allowing value to be placed on the architecture. Also starting with a current state inventory can also be useful. It allows the EA practice to assess those values and identify “low hanging fruit”, shifting the organization to “buy in” on the practice building credibility with the organizations leaders.

    Cheers, E. Mike Lee

    ReplyDelete