In our previous blogs we outlined the key problems facing enterprise architecture, namely: (a) overwhelming complexity, (b) poor integration of concepts, (c) lack of financial relevance, and (d) poor program choice. The real problem with enterprise architecture is, however, architecture. Rather it is the focus on architecture, equipment, kit or stuff which is the real problem. Engineers do what engineers like to do best – build things. Yet, in focusing on structures enterprises fail to take heed of the things that matter financially – functions.
In order to deliver benefit and value enterprise architecture must create a language whereby the ‘objects’ of financial analysis may be moved directly to the design community within a single model. This may be as simple as the numbers on a spreadsheet or as complex as objects within a UML model.
One solution is through capability. Capability provides us with the means to bridge the gap between the design structures of an organisation/enterprise and its functions – the primary functional model being the value chain.
The first level of decomposition from the value chain is the set of Value Activities (Porter provides no further guidance on decomposition and cost allocation). A value activity is the key to differentiation, i.e. by arranging value activities in a unique way companies achieve a competitive advantage through differentiation of their value chains. The specification of a value activity, however, is a capability.
Capability is already accounted for within defence architectural frameworks such as MoDAF and is defined as “the specification of an enterprise’s ability to do something.” Capability is the sum total of all people (roles), processes, systems and infrastructure necessary to perform a function.
Companies and government departments/agencies have many capabilities but all of them should be described at the same level (i.e. primary capabilities) and seen as the instantiation of value activities. Otherwise, the term capability may inspire higgledy-piggledy capability and sub-capability definition. It is our experience that deriving them directly from value activities is the easiest and most efficient means of capability definition.
Once performed, capability definition may be visualised similar to Figure 1. Capabilities stretch over many functions and may not necessarily include all in between. Moreover, once performed, capabilities mustbe checked against financial cost allocation to ensure that they match. There is little point coming up with an ontologically correct definition of an operational asset if the finance department have assigned its costs elsewhere. Given that the primary means of a capability model is for the efficient investment of capital it is best that the work is performed in conjunction with the CFO’s office.
Capabilities are powerful concepts yet poorly understood and implemented worse. Capabilities have the ability to empower enterprise architecture and finally make it commercially relevant.
Enterprise architecture will fail to gain any traction within the corporate environment so long as it cannot achieve a meaningful link between finance and ICT. When it does, enterprise architecture will hold the key to dealing with commercial complexity and organisational entropy.