This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Could EA Save Tech Spending?
It probably won't surprise anyone to hear that UC has underperformed versus hopes and predictions, even leaving aside the economic crisis. It probably won't surprise anyone to hear that this year isn't likely to be an improvement. What may be surprising is that tech in general is underperforming, and has since the bursting of the bubble. The reason may be the biggest surprise of all.Tech spending is based on basic cost/benefit analysis, and that's always been clear. If you look at how IT spending has varied over the last 50 years, you can see a deeper truth, which is that major tech paradigms create a fixed set of benefits that justify IT investment. At some point, the features that grab new parts of this fixed benefit set have grabbed them all, and the market falls into price differentiation until a new tech paradigm unlocks new benefits and starts the process over. We've seen two complete cycles of this in the last five decades, and the problem is that we're not seeing the third.
Today's technical revolution is the notion of composable IT and network resources, stuff that can be tuned to the way everyone works. That promises higher productivity, but it's also a lot more complicated than the old messages of "buy a computer and become more productive." Enterprises couldn't get their heads around the whole SOA-and-mashup thing, and so they have not tapped the new benefits. As a result, IT spending didn't pick up when the old personal-computing-driven strategy cycle ended in 2001. It's stayed at about 80% of the long-term average rate of growth ever since, an unprecedented lag.
"Architectures" are the things that define the relationship between technology elements and business benefits, and that assure optimal integration of technology pieces. Some industries have had architectures to define their IT for generations (service providers use the old OSS/BSS stuff), but Enterprise Architectures are a newer thing, and actually likely more a response to compliance and accounting issues than to productivity gains. But if we could get a good EA understanding out there, it could help buyers grab those new benefits, and thus buoy up spending.
The problem with EA today, according to the enterprises I survey, is that it's too theoretical. We have "layers" that create "models" and define "practices" and all of that takes years to organize, years in which nothing is paying the bills of tech companies. Interestingly, enterprises have their own inherent view on what EA should be, and it's even a view that UC can fit into. It's just not very interesting to vendors so far.
Enterprises see EA as a four-layer structure that I'll call "MTOT." The letters are an acronym for the layers involved. "Missions" are at the top, defining what the business wants to do in its chosen markets. "Tasks" are the next thing, the way that the business divides the responsibility for meeting the mission goals among its workers. "Operations" is the third and key layer, the layer that binds technology resources to those tasks effectively, and "Technology" is the foundation layer.
The MTOT view of EA recognizes two very specific technology goals. The first is to create composable views of both information and services at the point where the Tasks and Operations layers meet. This is the "mashup" point, and it's also where any UC activities need to be focused. By making the binding of technology to tasks more effective and more flexible, more productivity benefits are realized. The second is the creation of technology services instead of technology applications, to optimize the boundary between Operations and Technology. Tech planners build tools to present to Operations, which molds those tools to support workers.
EA apologists will protest that MTOT is completely compatible with EA, which it is. The problem is that EA hasn't developed any convincing connection with a benefit case. All too often it's "progress" only in the sense of having momentum toward a given goal, not in the sense of proving any business value to that goal. Even in good times, enterprises didn't find that compelling and they sure aren't going to find it compelling now.
Could it be that UC and other industry mantras have a similar problem? Could we be building layers of technology and complexity and abstraction to the point where the purpose of the process-provable productivity gains on a scale to justify cost-has been lost? For the last 20 years, networking has been an "accepted benefit," something you did because it was the right thing to do. The "rightness" was due to the fact that for a long period of time, business was "under-connected," so the simple validation we had was not only sufficient to win buyers, it was valid. We are not in that world any longer, and we're never going back to it.
If we could make something MTOT-ish work, and if we could get enterprise IT investment back to the levels it had in past strategic cycles, the process could put over one hundred billion dollars back into tech spending in the US over the next four years. It could create an impact on tech bigger than the stimulus package being proposed. The fact that we have never had a lull like this is proof we don't have to be in one now, but abstract thinking isn't going to bring us out, be it called "EA" or "UC."
Every incremental dollar enterprises spend has to be justified by a concrete business case. Models and architectures to do that are helpful only if they have both a persistent linkage to the prize of benefits down the road and a linkage to the assets already in place. Enterprises believe it can be done, and their "MTOT" collective vision proves that. We must now prove we can do it.