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).

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

3. 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

Enterprise Context Diagrams

We learned in EA-871 that the most important deliverable from an EA initiative is “change” (Gartner Clarifies the Definition of the Term 'Enterprise Architecture, 2008).  I completely agree with that assertion, however, in the nascent phases, I believe the primary deliverable needs be a establishing a common language between the business and IT.   

At my current employer, the business has a difficult time expressing their needs and issues, while IT consistently has difficulty understanding the business and rarely knows when information is incomplete or inaccurate. This problem is severely exacerbated by the fact that the business is a high-volume law firm - a business domain notoriously known for confusing jargon (worse than IT in my humble opinion).  We need to improve our communication, we need a common language, and I believe that starts with establishing proper context for the enterprise and the business units within, which is the focus of Gartner’s paper “Q&A: Why EA Needs an Enterprise Context (2011).

Gartner mixes several elements into the Enterprise Context, such as strategies, trends, principles, and the development of core models.  It is the development of one specific core model that I want to focus on - the Context Diagram - the first and most important model in my opinion, whether there is a formal EA program in place or not.  

As a software developer at EDS, I learned about Context Diagrams as part of EDS’ Software Development Methodology (SDM), which borrowed from the structured analysis and design research by Ed Yourdon, et al. (1970s).  Context Diagrams were conceived as a software analysis and design tool with the purpose of conveying the simplest and highest level representation of a software system.  The entire system would be represented by a circle in the middle, with all the inputs and outputs notated around it (a simple hub and spoke diagram).  This establishes the system’s context, or in other words, its environment.  See the Context Diagram example below.

Basic Context Diagram

What struck me in changing my thinking from software development to enterprise architecture, is that an enterprise, like a software application, is a system with inputs and outputs, and the exact same Context Model can, and should, be used to describe an enterprise at the highest level and in its simplest form.  There does not need to be any changes to the theoretical approach whatsoever.  The middle circle is simply a system of any type (anything with inputs, some form of transformation, and outputs) and since all systems must have inputs and outputs, we notate the sources and targets around the middle circle and then notate what is exchanged.  We have now fully established the environment of the enterprise (on one page!), which, at my current SMB, not a single person from hourly staff to the top-level executives has full awareness of.  What a great foundation to build a common language from. I'm including (below) an example Enterprise Context Diagram for a generic default management law firm (my current business domain), to illustrate what a small leap it is from a software analysis and design tool to an EA tool.

Enterprise Context Diagram for a Generic Default Management Law Firm

There are three important points to make an Enterprise Context Diagram as effective as possible:

• First, remember that this is now a business model, not an IT-centric application model, so when notating the exchanges, do not limit your thinking to digital information.  You should be capturing all exchanges, be they digital, raw materials, or finished products.
    
• Second, do limit the input and output relationships to those involved in the enterprise’s value proposition.  In other words, don’t capture the relationship with the firm that restocks the vending machines in the lunchroom.  This is ancillary to the value proposition and does not need to be expressed.  
  
• Third, include the enterprise’s value proposition on the Context Diagram.  It should be short enough to include in the corner.  When a clear, short value proposition is combined with a graphical depiction, it makes for a powerful sheet of paper.

A final recommendation is to remember that an Enterprise Context Diagram is also a starting point for further decomposition down to the business units, lines of business, and departments.  They are all systems that can, and eventually, should be expressed with a simple one page Context Diagram.

References

Gartner. (2008). Gartner Clarifies the Definition of the Term 'Enterprise Architecture

Gartner. (2011). Q&A: Why EA Needs an Enterprise Context

Yourdon, et al. (1970s). Structured Analysis and Design Methods

EA for SMBs

The past eight years of my thirty-plus year career have been at two small-to-midsized businesses or SMBs, as I’ll refer to them hereupon.  The prior twenty-plus years were spent at public corporations with sales in the billions and employees in the thousands.  For context I’ll offer Gartner’s definition of an SMB from their IT Glossary:

A small and midsize business (SMB) is a business which, due to its size, has different IT requirements—and often faces different IT challenges—than do large enterprises, and whose IT resources (usually budget and staff) are often highly constrained. For the purposes of its research, Gartner defines SMBs by the number of employees and annual revenue they have. The attribute used most often is number of employees; small businesses are usually defined as organizations with fewer than 100 employees; midsize enterprises are those organizations with 100 to 999 employees. The second most popular attribute used to define the SMB market is annual revenue: small business is usually defined as organizations with less than $50 million in annual revenue; midsize enterprise is defined as organizations that make more than $50 million, but less than $1 billion in annual revenue.

Prior to enrolling in the EA program, I asked some program representatives from Penn State if EA was just a big company thing or if the importance extended to SMBs.  The answer was an emphatic “yes it’s just as important to SMBs”, as I knew it would be, and as I already believed.  However, real-world EA, both in practice and in theory, seems tilted toward the “bigs” (which will be my hereto reference for any organization bigger than an SMB) as it probably should be, but not to the exclusion of SMBs.  Some of my observations:

1. Out of four primary business experiences during my career, the two bigs had EA programs as far back as the 1990s, while the two SMBs, to this very day, have more of a shoot-from-the-hip approach to IT (and a lot of chaos to show for it).
2. Most of the books, articles, and research material, if not written specifically from the perspective of a big, seem to imply the context of a big.
3. Most of the students in the EA program are from bigs or the government sector.

 

My point being, the bigs seem well represented; the SMBs, maybe not so much.  With that said, my intention for this blog is to make EA theory, with its genesis in the bigs, more relatable and pertinent to SMBs.  

I knew I wanted to make SMBs the focus of this blog while going through this week’s EA872 readings, which address wise execution of EA, with the implication that EA has already been sold and introduced to the enterprise.  I think selling the concept of EA in large enterprises, while not trivial or easy, is still somewhat of a forgone conclusion.  The bigs seem to accept the need, they mostly trip on the execution.  The SMBs struggle with formality and will resist buy-in from the beginning if offered only promises.  

To offer a couple of examples of how EA theory for the bigs can be slightly morphed so it is a bit more pertinent to the SMBs, let’s consider two articles from Gartner: Enterprise Architecture: Just Enough, Just In Time (2006) and EA Must Include Defining Your Enterprise Context (2011). Both articles contain lessons and recommendations for managing scope while in execution mode.  As I put forth above, SMBs have buy-in challenges and one of the best ways to address this challenge, is to execute EA in a limited fashion without necessarily formalizing it - IT leadership at SMBs have this flexibility.  By following the recommendations from the articles for developing a small set of valuable models and for defining the enterprise context, both reasonable undertakings at an SMB without the need for investment, we can show real-world value to leadership and use that as the plan for selling a broader EA program.    

It’s kind of like the notion with job promotions, where people will do a job before they’re given the title, then when given the title, they continue to do the same job with maybe slightly expanded responsibilities.  At an SMB, it seems wise to do some EA before selling it as a formalized initiative, after which, we will continue to gradually expand EA’s reach and impact.