2013: Not The Year Of The CIO – Yet Reply

It is highly unlikely that this will be the year of the CIO.  Tom Curran is entirely correct that CIOs need to get closer to business units to prove their value.  After years of uncontrolled IT budgets and then recent vicious cost reduction programs CIOs need to prove that they are more than email, storage and security.  CIOs need to be proactive in supporting the cost of businesses and that means developing capability.

Firstly, there are 3 types of business tech: (i) embedded systems such as robotics, (ii) operational systems such as customer ordering systems, and (iii) management information systems  such as email, ERPs, ERMs, collaboration tools etc.  The first two are largely accounted for in the cost-of-goods-sold but the latter is usually accounted for as overhead in SG&A.  Although their worth is unquestionable (could a large company really do without email these days?), it is these MIS systems which are notoriously hard to prove the value of.

There is still little evidence that MIS directly increase profitability.  Corporate IT spending largely increases in accordance with SG&A costs which tells us 2 things: (a) that as companies grow and increase their revenue they increase their management commensurately, and (b) IT is bought to connect this management.  There is not some inflection point where systems are bought, magic happens and companies become organised.  Organisation is the job of the business but enabling that by bringing distributed human communities together through electronic communications is the primary purpose of MIS.

Picture1

In order to become the critical enabler that it has always wanted to be IT needs to focus on capability and not just costs.  Although Tom suggests that this will be achieved through in-house architects I would suggest that in-house capability is too hard and costly to maintain at the requisite level to actually analyse and build business capability.  The only function that should be retained and honed, in-house, is information mangement.  Businesses need to be absolutely certain about exactly what information (at an atomic level) actually makes them money  – and how.  Outsiders without the context, peripheral information, subtext and political insight cannot adequately contribute to this role.  Only once the business understands its financial the anatomy of its fianancial dependencies can it adequately source architectural support in order to build business capability.  The business which misses the point and only develops architecture is just gilding the lily and will just be rewarded with a higher overhead burden which they need to chargeback to disgruntled internal customers.

Is this achievable in 2013?  The likelihood of this belies my underlying assumption that CIOs do not belong in the C-Suite.  As critical as technology and information is to business it is only a critical enabler and not a separate function in itself.  Due to the radically different skills which the technical community possess I do not believe that they will ever be able to set the agenda in non-digital industries.  Putting CIOs in the C-Suite merely overemphasises the importance of technology as an end and not merely the means.  It is here I think that standard operations should stop abdicating its responsibility and start setting the technical agenda and this will certainly not happen in 2013.

Develop Capability Not Architecture: the next frontier in ICT delivery Reply

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.