Why Hasn't SOA Lived Up to the Hype?

The two most popular SOA initiatives -- Microsoft .Net and Java Web Services -- both remind me of the old story about the software salesman whose marriage never quite got consummated. Instead, each night the salesman would sit at the edge of the bed and tell his wife how great it was going to be.

Platform-neutral interoperability designed for easy application-to-application communication over the Internet (and intranets) has been the dream scenario promised by distributed computing vendors and pundits for many years. Imagine, if you will, a world defined by a standards-based service-oriented architecture supported by every major software company (i.e., both Microsoft Corp. and EAM, Inc. -- "Everyone Against Microsoft"). Yet, after five years, we're still waiting for this ubiquitous computing fabric to unfold. By now the Internet was supposed to have been transformed into a computing platform rather than a medium in which users primarily just view and download content. What's holding everything up?

First, recognize that technological change almost always comes much more slowly than originally predicted. It takes awhile for new technologies to develop and mature, and for the people who use them to shift paradigms. The good news is that once a technology's ultimate success is achieved, it eventually far exceeds the original prognosticator's initial forecasts.

Consider some past examples.

Once upon a time system software was written only in assembly language. Compiled languages were thought to be too slow and inefficient. But then along came C. Finally, there was a high-level language that could produce fast code. Nowadays, virtually all system software (e.g., operating systems, compilers, database managers, etc.) is written using either the C language or one of its more popular object-oriented successors, C++, Java, and C#.

That transition -- from procedural languages, such as COBOL, C, FORTRAN, PASCAL, and PL/I, to object-oriented programming languages, like C++, Java, and C# -- itself took a lot longer than originally predicted. The problem was the difficulty programmers had shifting paradigms. It was like moving from the pre- to the post-Copernican world (where people had to change from believing that the sun revolved around the earth to accepting that, in fact, the earth revolves around the sun).

Much of the driving force that propelled object-oriented development was the shift from character-based terminal user interfaces to PC-based graphical user interfaces. The event-driven coding required to support GUI applications was radically more complicated than the procedural coding that powered systems designed for 3270 or VT100 terminals. Eventually, though, WIMP interfaces (i.e., Windows, Icons, Menus, and Pointing devices) captured the market.

Next, look at relational database managers. It took many years before RDBMS products replaced navigational DBMS tools like IMS, IDMS, Adabas, or TOTAL. But, today, virtually all enterprise data resides in one of the big three SQL-based RDBMS products: Oracle, SQL Server, and DB2.

So, what's the technological bottleneck thwarting SOA's ambitions? Mainly, we're waiting for software practitioners to discover how to de-couple processing. This paradigm shift, slowly inching forward, requires a transformation away from traditional request-reply synchronous processing (i.e., client-server). In its place software developers need to learn how to create systems based on asynchronous parallel processing. Interestingly, mastery of de-coupled software will also help unleash the full potential of the next generation of dual core processor hardware.

Be patient. SOA is coming. Its long-term impact will be even greater than promised. It just will take more time to mature than originally predicted. That's pretty much the way these things always work out.