SOA Hits a Speed Bump (but not a Dead End)

In the February 23, 2009 issue of InformationWeek magazine, there's an interesting article on the "state of SOA (Service-Oriented Architecture)" titled, "Trouble Ahead, Trouble Behind". That title happens to be a line in a song ("Casey Jones") written and recorded by the Grateful Dead, and it makes you wonder if the article's author, Roger Smith, sees SOA as having one foot (or more) in the grave. Some folks do (the article cites a blog post, "SOA is Dead; Long Live Services," issued by Anne Thomas Manes), but Smith makes it clear at the outset that he's optimistic about the architecture's long-term prospects: "Reports of SOA's demise have been greatly exaggerated." To back up this contention, Smith shares insights gleaned from a recent InformationWeek Analytics survey of 270 business technology professionals. Responses to this survey do indeed indicate a slowdown in SOA implementations - a finding that corroborates a report on the topic published this past November by Gartner (also cited in the article). A slowdown, however, is not the same as a full-stop, and Smith emphasizes that the InformationWeek survey data show continued forward progress on the SOA adoption front, albeit at a more deliberate pace than in years past.

The current economic downturn surely has something to do with this, since SOA isn't free and getting project funding is increasingly tough, but Smith points out that "Far and away the major reason respondents who aren't evaluating or implementing SOA cite for not pursuing the initiative is a lack of a viable business case - 43% say it's because SOA initiatives have developed a reputation for overpromising and and underdelivering." Overpromising and underdelivering? Is it possible that SOA has been over-hyped? Oh, yeah. Here, Smith puts much of the blame on vendors that "sold the concept to CIOs and other corporate decision makers as being about specific (and expensive) products like Web services or SOA management products, enterprise service buses, SOA gateways, and hardware acceleration devices for Web services." The hangover resulting from drinking in all the vendor hype about SOA is also mentioned in an article, written by Steve Craggs and published last May in Mainframe Executive magazine, titled "Why Do SOA Projects Fail?" Craggs writes that plenty of people in IT departments are also guilty of having oversold SOA, becoming more enamored with SOA technology itself than with it's application in support of business objectives.

Craggs, like Smith, sees SOA as being a positive for adopting organizations, and in his article he provides a lot of useful information in a "lessons learned" format. In so doing, he lays out the primary reason for optimism with respect to the long-term viability and growth of SOA: fundamentally, it's all about the reuse of code associated with application services, and "It's not until a critical mass of reusable services has been assembled that the benefits [of SOA] start to mount to measurable levels. However, once this point is reached, benefits seem to grow almost exponentially." Roger Smith makes a similar point in the aforementioned InformationWeek article: "we believe that a snowball effect will arise over the coming years: As more Web services can be invoked, more applications will be written to invoke them. With the increased availability of Web services components, application designers will evolve from thinking about application architectures as monolithic, siloed software efforts and move toward the exploitation of configurable, component-based SOAs."

Now for a DB2 tie-in. Last week, I delivered a couple of presentations at a meeting of the Michigan DB2 Users Group. The first of these was on DB2 stored procedures, and I was really struck by the level of interest in the topic as indicated by all the follow-on questions and discussions that proceeded from the presentation. I see the continued growth in organizations' use of, and plans for, DB2 stored procedures as supportive of SOA thinking, given that it shows:

1. An inclination towards abstraction and looser coupling of application system components. A developer writing a program that will call a DB2 stored procedure to accomplish a database function (lookup or update) does not need to have knowledge of the database schema that would otherwise be required if the program were to issue the SQL DML statements (SELECT, UPDATE, INSERT, DELETE, etc.) associated with the database function. That makes it much easier to effect back-end database design changes in a way that minimizes disruption of front-end application code. It also promotes reuse of encapsulated database functions (a DB2 stored procedure can be invoked by any language that supports the call syntax, including Java, C#, Ruby, Perl, Python, and PHP, to name a few).
2. A "database-layer" mind set. An application developed in accordance with SOA principles is characterized by a distinct layering of functional components. Of course, you could stuff a lot of business logic in a stored procedure, but in my experience organizations have used DB2 stored procedures to encapsulate data-access logic in a form that can easily be invoked by business-layer programs (which often run in servers that are physically separate from the database server, though SOA does not depend on such physical separation of layers). Because these stored procedures are focused on data retrieval and/or update, as opposed to business actions based on retrieved values or results of updates, they tend to be relatively simple versus the more "vertical" (referring to inclusion of business and perhaps even presentation logic) programs associated with a monolithic-style application architecture. This facilitates stored procedure development and deployment, and that story gets even better when you look at SQL itself as the stored procedure programming language (as I've mentioned in an earlier blog post, mainframers should be psyched about the delivery of native SQL procedures with DB2 for z/OS V9).

SOA dead? Not hardly. Has the pace of SOA implementation efforts slowed recently? Yes, but an SOA project is not a sprint-type event. It takes time to realize the benefits of SOA adoption. As a longtime distance runner, I know the importance of going at a sustainable pace if you want to reach your goal. DB2 people, in gravitating more towards stored procedures and making life easier for application developers wanting to access DB2 databases using all kinds of programming languages and application servers, are helping to lay the groundwork for future SOA success stories.