Enterprise architecture has long promised the alignment of the technical ICT of the organisation with its business strategy. For the same length of time it has steadfastly failed to deliver this. In order for enterprise architecture to (a) deliver alignment, and (b) execute strategy it must incorporate commercial concepts within the metamodel so that it may directly use both financial analysis as well as legal parameters.
Enterprise architecture has never been solely about infrastructure. Enterprise capacity can easily be catered for in data centre management. Enterprise architecture has been largely focused on enterprise applications integration. Integrating data models and their schema across the distributed enterprise to create harmonious workflows for the fewest people promises to realise the goal of reducing labour whilst purchasing the cheapest software. Enterprise architecture should be about driving the development of ICT architectures and business process directly from the value chain.
Enterprise architecture still provides businesses and departments with the greatest hope for the harmonious analysis and development of the enterprise. It fails largely, however, for the following reasons:
- Complexity of Metamodel. Financial language is not generally incorporated in the language of metamodels. It is possible but not generally done. When I was at EDS Value Management was an architectural discipline within the Agile RightStep® architectural framework. Whilst at Serco a number of us tried to incorporate value against the various objects in architectural models withing the MEGA® modelling suite. However, in order to take advantage of financials modelling tools would need to incorporate stochastic simulations and not just discrete event simulation into their analytical capabilities. This explains the disparity, often large, between architectural models and financial models.
- Systems Engineering. EA still remains largely focused on enterprise systems engineering. It needs to shift its focus to enterprise engineering systems. Where the former focuses on the minutiae of systems interaction the latter is concerned with the integration of one engineering system to another. If the enterprise sees the financial function as an engineering system then enterprise architects should be able to use their ontological skills in metamodelling to create seamless pull-through of analysis from Finance to Design. Some of these concepts will be explored in a later blog.
- Complexity of Programs. EA still remains an ICT skill used to support large programs. In order to capture enterprise relevance it needs to elevate itself from the technically complicated to the organisationally complex. Given that information systems largely exist to reduce organisational entropy, one of EA’s greatest benefits will be to realise the harmonisation of working practices and not merely implementing monolithic technology.
- Lack of Financial Relevance. EA needs to support value management and not just technology management. This is as much a problem of program selection as it is the extension of the metamodel. Automating the Balanced Scorecard still remains one of the best initial EA programs there is. It is relevant to both the C-suite as well as providing a direct and tangible impact on the measurement of strategy execution and financial management.
The answer, therefore, is to focus on capabilities and not on architectures. The former delivers measurable commercial value but the latter will consume the enterprise in a needless pursuit of perfection. In our next blog we will examine how to architect capability directly from the value chain.