Let That Be Your Last Battlefield

The Gartner Group’s infamous Technology Hype Cycle is a great study in self-fulfilling prophesies. If you haven’t seen one, they are graphs with a single curvy line that measures hype levels over time. The line shoots up during the exciting times after some technology “trigger” is fired, but then soon plunges despairingly downward indicating the disappointment that whatever was being hyped doesn’t live up to expectations. Next, the line crawls back up (“enlightenment”) and then levels off somewhere midway between the expectation peak and disillusionment canyon. Interestingly, Hype Cycle charts do not gauge time or momentum. They are snapshots.

The 2005 Gartner Hype Cycle for Emerging Technologies (PDF) shows SOA settling into the bottommost part of the cycle – the pit of despair. I think it’s there to stay. SOA was propelled up the hype curve based partly on the additive hype behind web services. And that was because the lynchpin underlying any SOA effort is integration with the constituent applications. Web services may have brought some sorely-needed platform interoperability. But while doing so, web services also perpetuated the problems SOA was meant to mollify.

The real problem is that SOA was never about solution design. It was actually a reaction to the limitations inherent to most enterprise application APIs. It was also partly related to a perennial best-of-breed vs. single-vendor build conundrum: If you buy the best apps from different vendors, they won’t integrate, they’ll all look and act different, and maintenance costs are higher. But buying a single solution locks you into a monolithic dinosaur that (some say) over time hinders business agility. Most enterprises do some of both plus build their own stuff which adds to the problem.

For users, these choices are just as political they are strategic. SOA gets pitched as a roadmap for having it all, which placates stakeholders (a key sales tactic). Big apps, little apps, and online apps happily interact while users blissfully see a single system. SOA is a complex way to hide other complexities, which is no way to solve a problem in the long term. If you worked for a big toolkit vendor with a consulting practice, it was like striking gold.

SOA was invented to cover the basic failure of enterprise applications to provide loosely-coupled access to capabilities. It never represented progress in software architecture. Real change can only come by making individual enterprise applications the best possible citizens in an environment bounded by agreed-to assumptions, like the Internet. But it’s not just about declaring REST beats SOA. REST doesn’t help the situation unless it’s coupled with a solid information strategy – a well thought-out resource model addressing both data and behavior. That point has been overlooked by REST proponents, BTW.

Nevertheless, I’m done with interfaces and typed containers. I’ve thrown it away and see no reason to go back. They do not scale well in large projects and a pain to deal with in integration projects. Their real failure is that specialized interfaces are limited by their authors’ ability to presuppose their use cases. That limits the vectors available to access data and capabilities of the application. It is especially problematic in data-driven solutions, which probably sparked the rise of SOA in the first place.

For data-driven enterprise applications, REST can convey data and behavior with just as much fidelity as any programming model. This isn’t an idle claim – it’s based on several years of work to research how to build an ERP solution suite around REST architecture. Resource policies and URIs can hide data, govern state changes, and provide callers with information schemas. A good programming model tied to these principles can segregate capabilities, processes, and data. In the process it eliminates the trappings of static data container types and procedure-oriented functions that toolkits make easy to create but wind up creating coupling too tight for the Internet (and the Agility) age.

I suppose it reinforces their branding, but Gartner pegs any and all technology to the same shaped line. It’s depressing to think that every new technology has to travel along the same path – especially that one. What’s the point of sticking with an idea through the first two-thirds of the journey? The smart money is to sit out the aggravating part of the cycle – as Gartner well knows. At some point during the enlightenment period, the software industry wakes up and, in scorched earth fashion, bludgeons the world with so much tooling everyone forgets the concept that originally triggered the hype.

I don’t know whether Gartner has REST mapped to a Hype Cycle chart. If they have, then they’ve got it wrong. REST isn’t anything more than what the Internet already has had for many years. The Internet works – the trough of disillusionment (if it existed) happened long ago. Will that starve the vendors and the consultancies of the oxygen that feeds the tooling frenzy? Absolutely not.

Like so many other issues the world faces, applications need to work together and in unique operational situations with far less effort. Applications must presume they are part of a greater machine that controls how and when the application runs and with what data. Whether in the Cloud or not, the successful applications will be those that obviate the need for SOA but work well in mash-ups.