Gartner’s surveys consistently report a level of maturity in enterprise architecture (EA) practices averaging about 2.3 on a 5-point scale (with the minimum already at 1.0). Many of these companies are on their third iteration of EA. In other words, a large proportion of technology-savvy businesses are leading their industries without using (indeed, while rejecting) practices that EA practitioners declare will offer strategic advantages. Are these companies missing big opportunities that would make them even wealthier? Or is EA caught up in its own hype?
Meanwhile, few of the IT consultancies I have known as an employee or client employ many of the EA and PPFM practices that they recommend for their clients. That is not necessarily a criticism: their businesses differ from those of their clients. However, it does suggest that there may be situations (too small, too simple, too diversified) in which an EA investment is simply not justified. In other words, is EA not for everyone?
Restricting ourselves for simplicity to an IT enterprise, the benefits of EA include:
- Reducing redundancy of assets and efforts
- Increasing the standardization and reuse of solutions and assets
- Rationalizing the full set of current and future investments so that they are complementary rather than contradictory
- Speeding incident resolution by showing the physical or logical connections in a complex system
All of those benefits come from cost reductions or avoidances, which can be only a limited proportion of the total current program cost. Retail stores tolerate a certain amount of shoplifting because it would cause too many problems to prevent it entirely; likewise, most organizations tolerate some degree of process inefficiency that to me seems to be in the range of 10 percent. EA would have to eliminate that much waste for executives to see it as a business multiplier worth their time and money. Otherwise, EA is just one of many worthwhile activities aimed at internal operating efficiencies. Some architects may see this lowered profile as undignified, but it is a better place to start building credibility.
If EA is simply to pay for itself by generating tangible savings greater than its costs, what are those costs? Even after achieving stable implementation, an ongoing IT EA practice must as a minimum:
- Keep up with relevant developments in the outside world of technology (and business).
- Develop and maintain patterns for current and future solutions.
- Model, inventory, and keep track regularly churning internal assets.
- Participate in technical decision and oversight activities (project gate reviews).
- Participate in and respond to ongoing organizational planning processes and events.
These tasks are not additional duties for IT operational personnel. Many EA staffs seem to build around a core of three to four persons, increasing with the volume of innovation (project) work. An established EA practice will soon need a repository tool. All of that is just for ongoing operations; the initial implementation often requires perhaps twice as many resources. In round numbers, the ante to get into the typical EA game is about $1 million for the first year or so. This initial investment yields almost no results in the first year, so an organization may well require hard benefits around $3 million to consider undertaking such an investment in EA.
EA may well be able to generate 5 percent savings in IT; if that is $3 million, the supported IT budget would be $60 million, typically supporting an organization with annual revenues on the order of $600 million and more likely over $1 billion. Even if this back-of-the-envelope estimate is off by a factor of two to three, clearly smaller organizations cannot afford an EA practice, certainly not in the way we have been doing it. Yet we know from the earlier-cited surveys that most larger businesses are not doing EA either. We started by asking whether EA is for everybody. Are we backing into the position that EA may not be for anybody?
EA can be an effective tool in solving problems of any scale, as long as we do not try to use a chainsaw to trim our nails. Architects must tailor the EA approach to what is feasible in the organization, not to some desired level of “maturity.” They must:
- Tolerate some (or even a lot of) unsanctioned solutions or unshared data. Think shoplifting. The cost (including the impact) of EA must be kept below the benefits.
- Pick an issue that everyone agrees is a problem and solve that. Then EA will have some credibility.
- Develop in each effort some knowledge assets that will also serve in future efforts. That will reduce not just the cost of the EA work but also the cost of the future solutions.
- Start the smallest initial EA team that can solve the first set of problems. It may not be as grand, but in a couple of years it may be one of the few EA teams that is still in place.
