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 |
 |
| 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
I agree with your observations. In fact it has always struck my how my peers who started in software like I did often can't make the transition to architecture when it is very much the same practices exercised at a higher level. The problem is, as engineers, we always want to solve the whole problem down to the last semi-colon rather than stop at a high enough level.
ReplyDeleteWhat I wanted to suggest was that there are enterprise modeling models/practices that support what you suggest. I would recommend, if you aren't familiar, taking a look at things like BizBOK, BPMN, Archimate. Particularly the idea of Events. Much like events in an Event Driven architecture system (think Topics, Publish/Subscribe) your enterprise can be defined in terms of events. In EA871 we talked about the enterprise being an open system, events are the direct inputs and outputs of that system.
We have discussed the idea of mapping all of the events that the business agrees make up the enterprise. We'd then group and classify them into business capabilities, supported by technologies, and so on. I have talked with some EAs who have successfully mapped their high level enterprise in this way. I think this would be a good way to get a fairly detailed context of how the enterprise works.
Yes Scott! Now this is enterprise architecture. If you like the enterprise context diagram view, you should also check on the concepts of value chain from Michael Porter's work and value streams from the lean techniques.
ReplyDeleteOur organization often leans on a common value chain model to facilitate communications and keep IT on the same page with our other business units. This stuff seems obvious, but if nobody sits down and draws up a standard model, then everybody is just scrambling in the dark.
I like your comment, "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. " It is very indicative of my company.
ReplyDeleteWe have been trying to establish a common language without much success. But we need to succeed in order for everyone to be able to communicate effectively.