“Like a Rock” – Business Capabilities and EA

“…My hands were steady
My eyes were clear and bright
My walk had purpose
My steps were quick and light
And I held firmly
To what I felt was right
Like a rock…” – Bob Seger

Enterprise architecture, as a function of an enterprise, continues on its quest to deliver meaningful and recognizable value for the business. Of course, if you ask an IT person the value of enterprise architecture is obvious and it requires no further explanation. Knowing where the enterprise is and where it is going are the key value enablers for those who are tasked with implementation of the strategy. In IT, those are developers, testers, analysts, project managers, solution architects, etc. Increased predictability of the solution delivery is an example of one of those value propositions. However, this value proposition is somewhat inward looking and only indirectly visible to business.

Enterprise architecture is not just about solution delivery. It is also, and perhaps mostly, about strategic planning and portfolio management. After all, Enterprise architect’s job or any architect’s job does not begin after the blueprints are created but way before the first blueprint lines get drawn. In fact, it is the creation of that blueprint that is the source of most of the value from enterprise architecture. Mind you, when I write “blueprint”, I mean it in a larger sense as in “plan” or “strategy” and not just as a set of diagrams.

Strategic planning is predicated on existence of the business mission and the business model that serve as a driving force for everything that the enterprise does. Going further, a concept of a business capability emerged as a useful way to describe what a business needs to do to fulfill that mission in a context of a specific business model. A useful way to think about capabilities is as of individual skills that can be attributed to an organization and delivered through the combination of people, process, information, and technology.

Incidentally, enterprise architecture also looks at people, process, information, and technology. It does it through architecture layers often described as Business Architecture, Information Architecture, and Technology Architecture. While enterprise architecture goes deeper into concepts associated with each layer, capabilities themselves remain at a high level and focus on the question of “what the enterprise does”. Remember, it is not about how it does it, only about what it does.

So what is it that an enterprise does? Surprisingly (or not), there is a set of capabilities that every enterprise has regardless of the nature of the business, location, or culture. Clear examples could be Human Resources Management, Financial Planning, External Relations Management, or Risk Management to name a few. Those are generic ones and they apply to virtually every enterprise with the difference being of course in how those capabilities are realized. More specialized capability models emerged for some industries, which add the industry-specific capabilities. For example, ACORD or Panorama 360 are capability models that are specific to insurance industry and introduce capabilities like Claims Management or Contract Acquisition.

Regardless of what the set of capabilities is, whether it is one of the standard sets or a custom one, the key characteristic of that set is that it is very stable. It doesn’t change unless the enterprise overhauls its business model or significantly changes its purpose. What changes is how those capabilities are realized through people, process, information, and technology.

Given the relative stability of capabilities, they present an interesting opportunity for becoming an anchor for other enterprise architecture concepts. In other words, processes, applications, data, etc., all interact together to realize very specific capabilities. In an enterprise architecture model it may look somewhat like this:

ArchiCapabilities

Fig 1. Example of a conceptual enterprise architecture meta model with capabilities

Processes, Services, Application Components etc., linked to capabilities show HOW the enterprise implements WHAT the enterprise does or WHAT it aspires to do. Now the conversations with business can be more meaningful. Capability is a concept, with which the business is familiar. It can associate costs, efficiency, and quality with each capability when making investment decisions. Since capabilities are usually stable, results of those decisions can be reliably assessed at that level regardless of nuances of underlying implementations.

Imagine a heat-map which shows all of the enterprise capabilities as rectangles. Each rectangle has a different size which illustrates relative annual operating cost associated with a capability. Each rectangle can have a color, which illustrates the relative level of annual investment in a capability. It is a simple picture that can clearly show misaligned investments and drive the discussion about change. In another version the rectangles can be colored to represent relative complexity. Guess what, chances are that high complexity areas will overlay areas with high operational costs. Wouldn’t you like to have those pictures with you, when discussing budget for reducing the technical debt in your IT systems? In yet another version, the rectangles can be coded to indicate relative importance to business. Do the levels of investment in each capability match their level of business importance?

HeatMap

Fig 2. Example of high-level capability heat-map

Now, don’t take that as a statement that an enterprise has to be broken up into a handful of capabilities and analysis done at that level. In reality, high-level capabilities can and should be decomposed into lower-level capabilities that provide more granularity and may be more meaningful in business discussions. Those lower-level capabilities are likely to serve as more appropriate anchors for enterprise architecture concepts that aim to describe HOW the enterprise operates. The combination of enterprise architecture information about processes, information and technology rolled up into lower-level and then high-level capabilities tells the whole enterprise story. Costs, quality, and efficiency data collected at lower-level architecture elements like processes, applications, databases can be aggregated by capabilities and used to present the enterprise architecture in business terms. In fact, this ability to collect, aggregate, illustrate, and influence is the key to success for any enterprise architecture practice.

Approach to enterprise architecture, which is based on business capability models, emerges as a mainstream force that promises to bridge the gap between IT and business. Like a rock, business capabilities are stable and largely immovable. They are what business understands. Like a rock, they can be the foundation for enterprise architecture efforts, providing a common reference point for architects and business professionals.

“…Like a Rock…”, or more accurately, like the Rosetta Stone?

Advertisements

The Myth of Collaboration

Petervan

Rogier Noort  just published a post on his site, for a great part based on an interview he did with me during the Enterprise 2.0 Summit in Paris in February of this year. Rogier’s original title of the post was “Collaboration:  Salvation or Myth”. It’s a great post, and Rogier clearly took the pain to reflect on our conversation. I would label it as “The Myth of Collaboration”. Some people call my point of view blasphemy in a period where everything has to be “social”, “working together” and “collaboration and hacking spaces”. So be it. I just felt there was something deep wrong about it, and Rogier did an awesome job of articulating my thoughts. I have copied the text in it’s entirety, and just added the usual colour emphasis.

+++ Start Rogier’s post +++

Collaboration is an important part of productivity. It’s a highly desired commodity, but seemingly more…

View original post 1,090 more words

Practical EA may be key to its relevance

Most Architects and probably most IT people understand the benefits of a well-functioning Enterprise Architecture capability. Can we say the Business understands it too?

Developing and sustaining EA capability in context of a large enterprise can be very challenging. It is so because organizations usually start with the lot of baggage that has accumulated over the years. The baggage being the organizational silos, technical debt or company culture to name a few. For that reason it is very important to have a clearly articulated value proposition for EA. The value proposition must resonate with the Business and offer some short-term benefits in addition to long-term benefits. Having articulated the value, it is important to focus on delivering on those short-term promises because the failure to do so may undermine EA’s ability to realize the long-term ones. What does it mean exactly, you ask? It means that you may have to take a practical approach to Enterprise Architecture as opposed to a holistic one. It may mean the following:

  • Using architecture frameworks as guides and not as exact blueprints for EA.
  • Maximizing the reuse of existing processes in your organization, however imperfect they may be.
  • Relying on simple and familiar tools instead of pursuing the holy grail of a tool that promises to solve all EA problems.
  • Limiting the amount of architectural information to the level that can be reliably managed while still providing tangible value.
  • Establishing controls to ensure that architectural information maintains its currency over time.

Of course, the list can go on. The bottom line is that in order to run you have to learn how to walk first. Business may never let EA “run” if they can’t see that it can walk straight.

Join me at #SATURN14 for a brief talk about a practical approach to integrating Enterprise Architecture.

It’s a Journey – Don’t stop believing.

Aside

Not sure if I should be depressed or relieved after reading the The Enterprise Architecture Paradox. On one hand it smacks of futility of EA efforts and illustrates the frustrations of EA work, on the other it proves that we are not alone in our “journey”. For the time being we need to keep pushing and continue to realize those invisible wins. Don’t Stop Believing! Worth reading.