Is it time for “Guerilla SOA?”

In his blog yesterday, Joe McKendrick alerted us of an agile development-like idea being pushed by colleague by Jim Webber, SOA practice lead at ThoughtWorks, which he terms “Guerilla SOA.” It’s a reaction to the heavyweight, top-down approaches to SOA deployments which tend to feature liberal doses of appservers, ESBs, registries and repositories, and of course, a large dollop of architecture.

In essence, it’s the latest turn on the notion of architecting software for reuse, which dates back to the days of COBOL Copy Books, CASE methodologies, and later, component-based and object-oriented development. Webber is concerned that such top-down approaches typically push architecture at the expense of business priorities, not to mention strangling a project in analysis paralysis. Instead, he urges a more tactical approach that applies SOA to specific business problems pinpointed by stakeholders that he calls “Guerilla SOA.”

Webber went on to describe alternatives to SOAP and WSDL web services standards that could make Guerilla SOA doable. They included “MEST,” which applies RESTful-like approaches (they are used for requesting data, in place of more complex SOAP messages) to message exchanges; and SSDL, which simplifies WSDL service descriptions and appends elements of BPEL process orchestration and CDL choreography to reduce the amount of back and forth chatter for more complex, contract-driven services.

McKendrick said that Webber’s approach reminded him of BEA AquaLogic chief architect Paul Patrick’s notion of “SOA Neighborhoods,” where localized clusters of services emerge to serve departmental or business unit level requirements, and eventually scale through federation.

To us, Guerilla SOA gives us a sense of déjà vu all over again. Barely a month ago, we heard SOA developers -– exactly the types that Webber’s talking about -– take it on the chin from enterprise architects and BPM owners. Namely, that SOA project teams are considered estranged from EAs because they tend to make short-term tactical decisions that may not be architecturally sound over the long haul, and that they are similarly isolated from the business folks who own BPM because they feel that SOA developers (or anybody from the software development organization) just doesn’t understand the subtleties of business processes.

Guerilla SOA also conjures up notions of Agile development, an umbrella concept that describes development, testing, and project management techniques that are designed to be much lighter weight than conventional approaches. Agile stipulates conducting “just enough” planning to avoid analysis paralysis, and it typically encourages intimate collaborations between the business and the different players that are involved in designing, developing, and testing software. The term may not be as sexy, but perhaps a more apt label for Webber’s “Guerilla SOA” might be “Agile SOA.”

Webber brings up some useful points. IT organizations are under the gun to demonstrate that they are more productive and add value. They are overcoming years delivering projects being late, over budget, and under scope. And in the post Y2K, post-bubble environment, they have had to prove their relevance to cynical CxOs who bought the kitty litter that IT doesn’t matter. And, although one of the oft-stated benefits of SOA is reuse (which is akin to saying your software development machine runs more efficiently), CEOs and CFOs are justified in asking why they should care. In fact, the ultimate benefit of SOA is business agility because, if properly implemented, it is architected using loose coupling that enables you to swap pieces in and out as conditions or underlying technologies change.

Nonetheless, in his video podcast, we didn’t sense that Webber had a good answer to the question of how SOA guerillas could scale their efforts beyond small projects. When asked if a service usable for specific scenarios could scale, he responded: “The nice thing is that it works in either because you have specific priorities that the business gives you at any given time and you focus on those, and as long as the business can keep coming to you and saying ‘I now need that this process implemented’ then you can scale up ad infinitum until the point where you automated all of the processes of a given domain…”

We feel that didn’t answer the question. Sure, if you’re working for the same group, you might have enough logical continuity to avoid retracing your tracks. But what about other teams, or what if the project grows large enough that, to respond to a new requirement, you create a new service from scratch because you’ll get the job done much quicker? That’s exactly how spaghetti code (where you have tangles of point programs) gets created –- while it’s quicker to produce, you really don’t want to end up maintaining all that crud.

In other words, you’re back to where you started. Just that this time, you’ve replaced spaghetti code with spaghetti web services.