03.25.08
Must SOA be a Long Slog?
Responding to our January blog on prospects for SOA in a recession, Progress Actional VP Dan Foody posited that SOA should be positioned as a cost savings measure. “Consistency, avoiding duplication (notice I didn’t say “reuse” even if that’s what I was referring to), and consolidation are all instrumental to managing costs. And SOA gives you these,” he wrote a couple weeks back.
We had a chance to speak with him today and trade thoughts. He avoids the term “reuse” by stating that SOA can provide the same kind of virtualization strategy to applications that hypervisors provide to OS platforms. In that sense, he views SOA as a way to reduce redundancy, which could be a polite term for reusing rather than reinventing application logic.
Foody concurred that promoting SOA as a long journey might not be the best strategy, given the short half-life of CIO tenures. “The people who first listened were enterprise architects, and that was the message that best appealed to them,” he stated.
“Maybe it’s heretical, but maybe we should bring web services concepts back into SOA,” he said, stating that at least you could build web services without having to get hung up in top-down architectural exercises. “We started off right with web services, because it was a reflection of the value that you could deliver to an individual project.” By web services, Foody isn’t limiting matters to SOAP and the WS-* stack, suggesting the simpler, more accessible RESTful-style services might be
Of course, that riles up prognosticators like Microsoft’s Nick Malik, who rail that building “JaBOWS” (actually, it’s JBOWS), a term Joe McKendrick coined several years ago, means you wind up with the web services equivalent of the spaghetti code you were trying to get rid of in the first place.
Nonetheless, Foody continued by taking fault with the notion that SOA had to be done exactly right, the first time. “The trap we got caught in was that you have to be perfect from day one,” providing as an example, trying to arrive at an enterprise definition of what constitutes a customer. Of course, data warehousing guru Ralph Kimball told us the same thing roughly a decade ago, meaning this has proven a perennial enterprise challenge.
Instead, Foody recommends an iterative approach, which is to model only as much as you need to build services now while still providing freedom to act when circumstances change. That’s where he pitches the argument of having the kind of instant feedback loop that run time SOA governance tools, like Actional’s, provide, in order to enable the agility that SOA can deliver.
Recessions tend to discourage the kind of long-term thinking that grand enterprise architectural exercises are supposed to support. In that sense, SOA has been caught up in the middle – roughly six years after the current incarnation of the concept emerged with web services, there remains considerable debate as to whether it makes sense to take a project or architectural approach.
Of course, the happy medium is the “architected project” approach, where you try applying more iterative approaches to refining services, rather than defining them as part of some grand scheme. If that sounds familiar, it should, because those were the lessons supposedly learned after the CASE debacle, which gave rise to rapid application development (whose roots also began in a recession).
Towards that end, we’ll be interested in what ZapThink’s Jason Bloomberg has to say when he addresses that topic head on at IBM’s upcoming Impact conference.