Another view: could 'guerrilla SOA' add to the tangle?

There's been no shortage of push and pull lately between those wanting to see smaller, grassroots SOA efforts versus those advocating more calculated enterprise designs.

My colleague from the SOA Insights podcasts, Tony Baer, said while he agrees with the concept of "Guerrilla SOA" discussed here last week (inspired by Jim the World Wide Webber), he wonders out loud if the approach doesn't exacerbate the current dilemma facing many SOA efforts. That is, too many unconnected SOA efforts will simply lead to a lot of unconnected SOA efforts, with little to no value for the business at large.

Tony also surmises that Guerrilla SOA has been around, at least in spirit, for some time. Lately, the operative term for this bottom-up approach has been "Agile Development," an umbrella concept that describes development, testing, and project management techniques that are tied closely to specific business projects. (Tony admits Guerrilla SOA sounds like a lot more fun. Agile Development just sounds too boring.)

Whether its called Guerrilla SOA or Agile Development, the problem with these kind of approaches, Tony says, is that SOA continues to be perceived as something that may deliver some benefits to IT operations, but provide no perceivable benefits to the organization as a whole, especially in terms of business agility. Tony questions how, exactly, "SOA guerrillas could scale their efforts beyond small projects."

With a bunch of guerrilla SOA projects brewing across the enterprise -- all tied to specific business problems, but not "bleeding" into other projects -- Tony wonders if development teams would be creating tangles of spaghetti code, therefore making things more complicated than before:

"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, Tony concludes, "you’re back to where you started. Just that this time, you’ve replaced spaghetti code with spaghetti Web services." He agrees that Jim Webber’s Guerilla SOA "asks some valid questions about over-engineered SOA, but we don’t feel it yet provides enough answers to avoid software development’s age-old headaches."

These objections sound very familiar to the issues just raised by Nick Malik the other month around "bottom-up" SOA. Namely, that everyone ends up doing their own thing -- services get built for single, more tactical purposes, but really can't be extended to anything other use in the enterprise. A thousand services bloom, but relatively few are actually shared.

This raises a couple of questions, of course:

• Is Guerrilla SOA the same as bottom-up SOA?
• Is the sharability or reusability of services the most important business driver (and benefit) of SOA?

For now, let's assume the answers to both questions is a qualified "yes." (With the understanding that no two SOA efforts are alike.)

For many, many companies and their SOA proponents, Guerrilla SOA may be the only way to go. How many companies are really providing support for large service-oriented projects, or for middleware platforms to make things happen on a grand scale? Yes, the C-level executives can get very vocal about increasing business agility through better technology, competing on analytics, and running things "smarter." But they always want it all done with less money and fewer resources. Many SOA teams or proponents will need to push these transformative changes through on a showstring, with no budget and little active support from the executive suite. What choice do they have but to engage in "Guerilla SOA" tactics to get things on a service-oriented track? In the big picture of things, SOA is part of the inevitable march to software automation and industrialization. SOA isn't going to sweep organizations with one revolutionary upheaval. Progress is going to be spotty, popping up in different shapes and forms across organizations. While many efforts may result in spaghetti architecture, the time to start SOA is now, to "just do it."