Hans Wierenga, vrijdag 28 augustus 2009
The synthesis of Enterprise Architecture and Information Economics
The success statistics of IT projects make for miserable reading. Many of the failures are the result of basic patterns of organizational behaviour, which, although not peculiar to IT, are particularly damaging to IT investments. Enterprise architecture supports a project portfolio approach by means of which these patterns can be avoided. When the project portfolio approach is used in combination with information economics, the result is a powerful instrument that avoids the misuse to which information economics is prone, and enhances the ability of enterprise architects to shape the decision-making process.
When it comes to IT, almost every organization has a resource allocation problem. There are limits to what an organization can invest in its IT, in terms of time, attention, corporate willpower and money. If too many resources go to projects with only a marginal contribution to the organization’s success, it won’t have any left for the IT that adds the greatest value. In fact, given that badly chosen projects are much more likely to fail than good ones, the odds are that these projects will go wrong, leaving the organization worse off than it started.
However, avoiding bad IT investments and choosing good ones is much easier said than done. There are many forces at work which make that a major challenge. Precisely the things we need to harness in order to turn good ideas into good practice – emotions, organizational politics and corporate willpower – are very easily derailed into selecting and supporting bad ideas. No wonder that the success statistics of IT investments make for miserable reading. For at least the last quarter century, the pattern is the same, year in, year out: about a quarter of all IT projects are abandoned before producing any useful result at all, 40% deliver a result which is far less than was originally envisaged, and on average projects exceed original estimates by 50% in terms of project duration and 100% in terms of costs.
In order for organizations to be consistently successful with IT, a new approach to selecting IT investments is required. This article discusses how Enterprise architecture - the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model - can provide this approach.
Before discussing the contribution of Enterprise architecture to successful IT investments, it is illustrative to consider why investments in IT go so wrong so easily. These reasons are associated with basic patterns of organizational behaviour, which, although not peculiar to IT, are particularly damaging to IT investments.
Most IT investments start with an idea, which then becomes somebody’s “baby”, and that person then ensures that the idea is implemented. Once started, projects - like babies - must misbehave very badly indeed in order for the parent to stop caring for them. When a project encounters major difficulties, it is mostly too late to ask the question “What if we had adopted another project?”, not just because it’s very difficult to stop a running project, but also because you know what you have, but not what you will get if you abandon the current project in favour of an alternative solution. The fear that an alternative will turn out to be even worse is often crippling.
Conventionally, organizations have tried to eliminate bias in the selection of projects by means of a scoring approach, in which various projects are compared. Typical current scoring approaches include Parker and Benson’s Information Economics and Kaplan’s Balanced Scorecard. Such approaches reduce the danger of choosing the wrong projects, but do not eliminate it. One problem is that they start after the projects have been identified; that is, after the projects have become somebody’s babies. No matter how objective the approaches purport to be, it is unreasonable to expect people to be unbiased when assessing their own babies, particularly if their assessment is the basis on which they are to be compared with others. Another problem is that there is no guarantee that the most promising projects are even entered into consideration. Even if the rules were to be applied strictly and impartially, as long as only a tiny proportion of all the babies out there are entered into the beauty contest, the winner is unlikely to be the most beautiful baby around.
Upwards of 75 percent of the total costs of an information system are incurred after the project that gave it birth has run to completion. An approach that overrates the importance of the costs of the project, and underrates the importance of the post-project costs, runs the risk of selecting projects that may be beautiful babies, but become ugly adults. Unfortunately, the IT world is full of ugly adults. Regrettably, project selection approaches such as Information Economics and the Balanced Scorecard contribute to this problem. They are implicitly biased towards the selection of projects which are made artificially simple, and therefore score low on costs and risk factors. The trick is to push all the complexity of interacting with the rest of the world out of the project and onto someone else’s plate. Such projects are like spoiled children: everything else is made subservient to them. They result in information systems that are not prepared to respond to the myriad changes that life in the real world entails.
The fact that so many IT projects fail has resulted in a fourth syndrome: the foster child. Organisations have become so distrustful of their abilities to manage IT projects that they farm out their responsibility to other parties which they hope are better equipped to handle them. The organisation tries to have as little to do as possible with the development, configuration and maintenance of its information systems. This abdication of responsibility is not such a problem when it is concerned with information systems that are not substantially different from one organisation to another. But it can result in disasters when it concerns the information systems which express the organisation’s identity – the systems with which the organisation distinguishes itself from its competitors or, as is often the case with government agencies, support tasks which are unique to it. Turning over the responsibility for the development of your own flesh and blood to foster parents does not fundamentally solve the parenting problem: the lack of expertise that prevents you from getting your child to do what you want will also tend to prevent you from getting a foster parent to do what you want. But it does introduce new sources of delays, misunderstandings, errors and costs.
The Enterprise Architecture of a firm consists of the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model. The discipline of Enterprise architecture enables an organization to reach agreement on a framework of concepts, approaches and standards, in order that separately managed projects produce results which work together for the good of the organization as a whole, despite differences in ownership, business priorities, project timeframes and IT-products.
One application of Enterprise architecture is to produce a list of the IT investments that might add value to the business. The starting point for such a list is the operating model, in which the way in which different parts of the business add value are outlined. Enterprise architecture provides tools to systematise this analysis of added value and to couple the results of the analysis with a library of best practice solutions, in order to generate a list of potential business-related projects. This list must be extended with projects to develop the infrastructure and context that the business-related projects need, and the resulting list must be sequenced on the basis of time dependency between the projects. Finally, a project portfolio consisting of those projects which add the most value, have the shortest time to market and the lowest risks can be selected.
The project portfolio approach makes Enterprise architecture an ideal way to avoid the syndromes outlined above. It addresses the “nobody’s child” syndrome by enabling an organization to identify and assess a priori all the IT investments that it could carry out. It prevents the “spoiled child” syndrome, in which projects are artificially simplified, by providing frameworks which make it clear where the complexity should be allocated. Further, it provides ways in which the costs after project completion play a decisive role in the selection of projects. It mitigates the “hands off my baby!” syndrome by providing a better understanding of both the contribution of a project to the business, and of how the continuation of the project compares with alternative approaches in terms of complexity, benefits and risks. And it identifies the situations in which an information systems solution must be tied to the identity of the organisation in order that the organisation can distinguish itself from its competitors. Where such systems play an essential role, enterprise architecture can be used to ensure that the organisation acquires the skills it needs in order to manage their development.
But Enterprise architecture does much more than just help organizations avoid problems. It also helps them to harness opportunities. The emotions that lead to the “hands off my baby!” syndrome are very useful if applied to healthy projects, and an unbiased declaration of health is very conducive to finding the right person to adopt a project. Such a declaration of health is a sign of success. Given that success has, as they say, a thousand fathers, that simplifies the task of finding the right one. Enterprise architecture harnesses the organizational politics that are so destructive when things go wrong in order to discuss constructively what must happen when an IT project that brings substantial benefits to the organization as a whole distributes the benefits and efforts unevenly amongst business units. By making the business advantages of IT investments more tangible, it requires extensive investments of corporate willpower only when projects extend beyond the business unit boundaries.
Enterprise architecture enables organizations to avoid pitfalls that scorecard approaches fall into. But it works the other way around as well: scorecard approaches prevent Enterprise architecture from going astray. Enterprise architecture can only thrive as a discipline if it has a way of scoring projects which reflects the value that the architecture adds. Nothing is more deadly to the practice of Enterprise architecture than scoring approaches which assess non-architected projects as being cheaper, less risky and quicker to market than the equivalent architected ones. Regardless of whether they actually mean anything, scores are perceived to be objective and real, and those who propose solutions that do not conform to the scores must justify every deviation from them on a blow-by-blow basis. In this matter we must be prepared to learn from history: it was only once Parker and Benson introduced the contribution to business strategy as a structural part of their Information Economics approach that we began to see project portfolios that were strategy-driven, instead of just including strategic benefits in the list of intangible benefits for each project separately and unrelatedly. Enterprise architecture is a form of strategy, and, like all strategy, it demands that strategy conformance is the norm and therefore needs no further justification, whereas deviations from it must be justified individually.
But it goes further than that. The process of translating architectural benefits into scores makes us think more deeply about the relationship between architecture and business benefits. For example: some Enterprise architecture approaches ignore the fact that even a small increase in the number of elements in an IT solution leads to a large increase in the complexity of the project management required to implement it, and hence to increases in the risk and in the time to market. This problem is particularly acute in technology-inspired approaches. By adopting scoring mechanisms from Information Economics or the Balanced Scorecard approach, these impacts can be put on the agenda, so that organization which adopt these technologies are aware of the risks as well as of the benefits.
The potential synergy between Enterprise architecture and Information Economics is enormous. It enables organizations to minimize bad investments by creating an environment in which they are evidently less attractive than promising ones. It benefits Enterprise architecture as a discipline by relating it more specifically to the business.
However, we have only just started scratching the surface of the potential that this synergy promises to deliver. It is time we started digging deeper. It is time for a new specialization: architectural information economics.