Capability thinking is nowadays catching the attention of the trend watchers such as Gartner and Forrester. However, Capability thinking is an old idea which mainly has been used within strategic management and military domains. This idea is making its way to other domains including architecture. So, how does this idea translate to the discipline of Enterprise Architecture (EA). This is one of the research topics we are working on within our enterprise architecture unit. In this blog I will give it a try to put some ideas together and I will be happy to see your ideas and feedback on this topic.
A capability is the capacity to deliver value by using a set of resources
There are of course many perspectives to look at capability architecture (thanks to my colleague Frank Schalkwijk with whom I’ve been lately involved in insightful discussion on this subject). In this blog I will rather address the business perspective.
But just to avoid the most common trap of a solution push , let’s first see if there are any problem areas we can address with capability architecture. Capability architecture is by the way not an alternative for EA. It is rather one of the many perspectives on EA, but in my view a valuable and refreshing one.
Back to the problem areas, we see and most of us have been involved in or a witness of many disconnected solutions and technology implementations… what a waste! One of the many reasons for this is that many of the promising concepts and technologies have been used and implemented in isolation resulting in silo solutions, which don’t deliver their full potential in organizations. Examples of these concepts and technologies are: SOA, BPM, Cloud, just to mention a few of them. Additional to the solution and implementation problems we also perceive communication problems regarding communicating with and involving business people and mangers in the architecture journey.
I believe the potential of technology and other resources would have been of much bigger impact and value, from a capability-push point of view, when the capabilities of these technologies and other resources are deployed to serve the core business functions of organizations and not for the sake of technology itself. The core business functions, from the business perspective, matters the most as they are directly connected to the business objectives. These core business functions are usually named ‘business capabilities’ in the literature. But I think we all agree that the business functions on their own without support and endorsement of the necessary resources (people, technologies, etc.) won’t deliver any value on their own. This idea brings us to capability architecture, which is the foundation that links the different capabilities together in a consistent way in order to deliver business value. One of the governing principles therein is the separation of concerns, which comes down to the separation between the ‘what’ and the ‘how’ of the foundation. From the business architecture perspective, the focus should lay on the “what”, which identifies the most stable capabilities within organizations. These capabilities are the business capabilities as they are directly related to the business objectives.
Business capabilities are an abstract view of what business functions do. They define the “what’ of the business functions and they are not concerned with organization en implementation issues, the “how” perspective. Business capabilities have attributes such as business value and performance. These attributes help assess their added-value and identify the change area that should be addressed. Business capabilities are also more stable than organization structures, processes, technologies and other resources. Their ‘relative’ stable nature makes them most suitable for building future-proof architectures.
As mentioned previously, this is just one of the perspectives on building sound and result driven architectures, but in my view a very determinant one for staying business-focused and delivering business value. Governance mechanisms such as standardization, coordination and the-how-related aspects deserve, of course, equal attention as well.
In conclusion a few benefits of capability architecture: in my view, the relative stable nature of business capabilities within organizations offers a shared abstract view and a common language, which fosters communication and closes the gap between architects and business people. As a result both parties have the same view of the problems at hand, less frustration, trust between both parties, and a better starting position to deliver greater results (the bottom line). Additionally, the abstract view on the business functions provides a suitable mean to define and scope services and lead to a service oriented architecture, which implement the capabilities.
Capability architecture should align/integrate the available capabilities toward generating value for the business. And that’s what architecture should focus on.
So, what do you think? Is the idea of capability architecture a new paradigm or a new packaging?