“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?

The Myth of Collaboration

Originally posted on 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 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.

Aside

I will be speaking about the practical approach to integrating enterprise architecture at the SATURN 2014 conference in Portland, OR. Abstract below.

Integrating Enterprise Architecture

In the era when contributing to business value is the principal consideration of IT, large and distributed organizations face a challenge of understanding how their capabilities are realized and how they can synchronously evolve them in alignment with business strategy. Structured information coupled with efficient architecture processes sets the foundation by addressing several issues: 

  • Complex interdependent systems that evolved independently increase technical debt. 
  • Nonexistent, inconsistent, or scattered architecture descriptions make planning difficult and extend the delivery time of solutions. 
  • Unclear dependencies of business capabilities on technology lead to weak commitment to business goals. 

The TOGAF, ArchiMate, and Sparx EA tools are cornerstones of Progressive’s approach to integrated enterprise architecture. By leveraging existing systems-development life-cycle processes and architecture-governance structures, Progressive implemented elements of the TOGAF Architecture Development Method and established consistency in defining and reviewing target architectures. Investing in modeling skills and introducing standard building blocks for architecture models allow architects to describe the systems and capabilities in a uniform way that produces an overall view of the current and future states of the enterprise. This presentation presents a practical approach to implementing integrated enterprise architecture at a large organization. Specific tools, frameworks, and languages serve only as a context for this experience-based story.

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.

Surviving Enterprise Models – breadth over depth

It was with great interest that I read Nick Malik’s post “What makes models interesting“. In his post, Nick speaks about his EBMM model but the fundamental concepts of approaching modeling and the questions it poses are more universal and applicable to all kinds of enterprise modeling. Whether it is EBMM, ArchiMate, UML, or any other “notation du jour” there is always that temptation to add more to the model. I think it is human nature. After we model something with a given standard, we become familiar with the contents of the model and over time it starts to feel as too obvious to be useful. This in turn leads to temptation to “improve” it. Sometimes improvements are warranted and sometimes they aren’t. If they are driven by desire to answer some specific questions that contribute to enterprise value, then great, but if they are driven primarily by model purity or general quest for more detail then you may be well advised to take a pause. We don’t want to model just for the sake of modeling. Instead, we want to use the models for strategic and tactical planning, for architecture alignment across the enterprise, for optimization of operations etc. Just to be sure, I’m talking about enterprise models here. Models that aim to illustrate where the enterprise is and where the enterprise is going. Those who have been exposed to enterprise architecture at a large organization know what I’m talking about. They also know how challenging that is. The reason I’m making that distinction is because when dealing with models that describe specific solution you may want to get to whatever level of detail is appropriate to explain the solution to your audience. If you try the same for the enterprise-level models you may find that it is extremely difficult to tie everything together.

I know that some will question the wisdom of even having the enterprise-wide models and will tell me that I am better off to focus on a specific area or on a specific problem. Well, in the end it all comes down to what questions I am trying to answer doesn’t it? So back to the questions… The questions that we ask at the enterprise level are different from questions asked during implementation of a solution. Some of the enterprise-level questions may be:

  • Where are the undesirable system redundancies?
  • What systems rely on non-standard technology?
  • Which systems cost more to operate?
  • Which critical business processes are supported by high availability applications/services?

Some of the solution-level questions may be:

  • What type of interface is used to access a service?
  • Is service consumed synchronously or asynchronously?
  • What components are used to build an application?

All good questions, but not all of them can or should be answered with the same model. In other words, models have to be fit for purpose. Attempts to mix different concerns usually end in a mess. …And then there is this pesky law of diminishing returns. How much work do we want to put into the upkeep of the models? More detail means every time that detail changes the model should be updated, right? Now take that to the scale of a large enterprise with many system inter-dependencies and it translates into a massive amount of work. Detection of those changes alone is a challenge too because in a large enterprise change tends to be constant and occur in many places at the same time.

If we assume that the architects are the keepers of the models, we need to ask ourselves how much of their time should be spent on keeping the models useful. Useful models should be current and given the breadth and rate of change it implies a significant effort. It seems that architect’s time would be better spent on model driven analysis and planning (a.k.a. architecting). Otherwise, we are approaching the territory of modeling for the sake of modeling, where we devote most of the energy to maintaining the models and not having time to actually use them.

So what practical advice can we employ for enterprise-level modeling? Here are my suggestions:

  1. Ask yourself what questions are you trying to answer with the model and prioritize them. Set out to build models for a few high-priority questions first.
  2. Establish a set of modeling rules that you can apply on top of your favorite modeling notation. This approach will keep you at the consistent level and promote discipline needed to build enterprise-wide models incrementally.
  3. Resist putting more detail into models at least until you can be sure what it takes to maintain them at the current level.
  4. Keep verifying that  the models help you answer the questions for which they were built and adjust accordingly.
  5. Rinse and repeat, starting with step 1.

Happy modeling!

Business Architecture Rising at BCC

Recently, I attended the Building Business Capability (BBC) conference in Las Vegas. I was tempted mainly by the Business Architecture track as I was curious to learn more about the current state of affairs in that field. Here are some of my observations, and conclusions after attending the event.

  • Confusion about Enterprise Architecture and its scope is further magnified by more confusion around Business Architecture. Various speakers made different pronouncements about the relationship between the two. Most saw Business Architecture as a component of Enterprise Architecture but some attempted to present Enterprise Architecture as being about IT and Business Architecture being about business. Another speaker suggested that Business Architecture overlaps with Enterprise Architecture but still is a distinct discipline that must “interface” with the Enterprise Architecture.
    I agree with the majority that sees Business Architecture as a component of Enterprise Architecture. As to other views, well…, I find it fascinating that some people need to complicate things. Of course, Enterprise Architecture is about the enterprise, and the enterprise is about business, DUH! Need we say more? Presenting Business Architecture as something separate from Enterprise Architecture only increases confusion and…just wait, will lead to more frameworks. God knows we don’t need any more architecture frameworks. If you insist, then let’s fix the ones we have by giving them more business focus (…looking at you TOGAF…) instead of inventing new ones. In any case, enough with inventing more distinct “architectures”.
  • Traditional roles of Business Analysts and Architects are evolving. Both roles are pushed to pay more attention to business value and business differentiation. Currently, in most organizations Business Analysts are relegated to requirement gatherers for IT projects. Their main focus is to translate requirements received from business into specific definition of IT deliverables and to perform validation of those requirements upon completion of implementation. There is very little going on there in regard to actual business analysis, not to mention Business Architecture. As Business Architecture rises to more prominence, Business Analysts must assume a role of true analysts and partner with Enterprise Architects in a comprehensive approach to Enterprise Architecture. At the same time Enterprise Architects are pushed to reach out to business and expand their role in the Business Architecture realm to make Enterprise Architecture more business-centric and thus more relevant to generating business value. This will likely lead to interesting dynamic with career paths. Both Business Analysts and Enterprise Architects are told that being Business Architects  is in their future. However, Enterprise Architects also consider themselves well versed in technology, while Business Analysts not necessarily so. So where does this leave us? Will Enterprise Architects become generalists who rely on Business Architects, specialists, for the Business Architecture part of Enterprise Architecture? Or perhaps Enterprise Architecture  will be pushed back to being again only about IT and Business Architects from Business Analyst ranks will direct Enterprise Architects how to shape the IT side of the enterprise?
  • Business Capabilities emerge as the way to provide a common taxonomy that can bridge the gap between business and technology. Capabilities allow architects to focus on “what” rather than “how”. They provide an anchor to relate systems and their underlying technologies to the business context, which includes organization, people and processes. Furthermore, they help break the silos, ever prevalent in larger organizations, which often represent the obstacle to effective Enterprise Architecture.
    Some can argue that capabilities and capability models have been around for a while and there is nothing new here. For me, the new thing was the evidence that companies start registering real successes with capability approach to Enterprise Architecture. It seems that capability models are finally taking off, coincidentally  at the time when Enterprise Architecture, after some soul-searching, is beginning to focus on business value.

Overall, BBC was an interesting conference. Not great, just good. I found that too many speakers were contradicting each other, but truth be told they were simply expressing their own opinions and there is nothing wrong with that. I suspect that the conference was of most value to Business Analysts especially with several BA-oriented tracks. Business Architecture track was messy but it is probably due to the fact that most of us still try to wrap our minds around how it fits with everything else. :-) I will consider attending next year, if only to watch the further evolution of the Business Architecture concepts.

After the love is gone…

Interesting observation published by Forbes: “CIOs And Cloud Computing: How IT Can Get Back In The Driver’s Seat“. While the article appears to apply to management of infrastructure in the world of cloud computing, it is symptomatic of a larger trend.

We have heard of the looming demise of IT for some time now. It started with outsourcing and globalization and intensified with the advent of cloud computing. The trend of “lost love” between Business and IT and illustrated in this article is not uncommon. I think it stems from factors like these:

  • Business sees IT as an inhibitor rather than enabler of achieving business goals faster. The technical debt accumulated over the years starts to demand the interest payments. Delivery takes longer because complexity was not dealt with on ongoing basis. Desperate IT departments try to please the Business and they cut corners, leading to more technical debt. The vicious circle continues.
  • Business sees IT as cost, which ever increases without generating more value. It’s like dealing with a cable TV company. The bill gets bigger every six months but the programming remains the same or gets worse.
  • Business believes they can do IT themselves. Why wouldn’t they? Anyone can build a web site (okay, okay, maybe with the exception of the US government), anyone can buy cloud storage, anyone can write an app or commission writing one for pennies… Of course it is not that simple, but many on the Business side believe it is and droves of cloud service  providers do their best to reinforce that belief.

Having IT relinquish some of its Implementation role in favor of the Advisory role is a good advice. Easier said than done though. It’s like with human relationships. After the love is gone it’s hard to get the flame going again. Is Business predisposed to seek advice from its IT Department, especially when there are so many advisers out there, who are eager to say “yes” to every request? Let’s hope so… This is where the Enterprise Architecture (EA) can lead. Stop talking to Business about interfaces, gigabits, servers, and tools. Instead, start talking about total cost of ownership, speed to market, competitive advantage, quality etc. In other words, speak the language of Business, not the language of IT. But more importantly, don’t just speak that language but start thinking that way too. Business really doesn’t care how IT is done anymore. They want us geeks to figure it out and not to bother them. For us however, it is a matter of survival. In order to serve Business better we must understand what it wants, or… fade into oblivion. We can only understand it if we think like business people.

So yes, again, it is all about the business. Adapt or prepare for extinction!

I love standards, there are so many to choose from!

I love standards. There are so many to choose from!

But seriously, Survey of Architecture Frameworks compiles a list of so-called architecture frameworks. I noticed that it mixes actual “named” frameworks like TOGAF or DoDAF with languages/notations like ArchiMate and with what is probably better described as reference models. It’s okay. All of them have something to do with frameworks, albeit with varying levels of completeness.

It is a useful summary. It is also a sobering experience to see it all in one place and realize how many different approaches to architecture have been developed. It may be a testament to our quest for consistency and perhaps even obsession with frameworks. This reminds me a speaker’s statement from Gartner’s EA Summit 2013 – “…stop focusing on frameworks, focus on business value…”. We often forget why we DO architecture. Instead we put a lot of effort into implementation of architecture frameworks, striving for the cleanest, purest implementation. We argue whether ArchiMate Location element is appropriate to represent a department in an organization or whether “Customer” is better represented by a Business Role or a Business Actor. In the end, it doesn’t matter as long as we do it consistently.