Guerrilla SOA

By: John Moe
About 15 years ago I came across ‘The Guerrilla Marketing Handbook’ by Jay Conrad Levinson. The concept was to create branding and lead generation through unconventional and small scale activities and events that could have as much impact as a large seven figure advertising campaign. Unfortunately, a lot of people took this as an excuse to commission irritating and humourless “viral” internet campaigns churned out by clueless marketing agencies. However, the concept of getting maximum results from minimum resources has stuck with me.

More recently, Jim Webber coined the phrase ‘Guerrilla SOA’ to describe lightweight approach to SOA that does not rely on big middleware products. Jason Bloomberg at Zapthink has also championed a ‘zero’ middleware approach to implementing SOA.

It is unfortunate, but not surprising, that the elegant and relatively simple view of SOA has become bloated with a bewildering array of methodologies and products, leading to confusion and bafflement by many of its proponents and potential converts. It doesn’t help when the industry analysts solemnly state that the cost of setting up an SOA infrastructure in a large company is about $250M.

Into this discussion have waded a number of alternative gurus offering to make SOA once more a simple, affordable option – which I will group into this Guerrilla SOA discussion, but also seek to differentiate the approaches to allow you to find a way forward that may best suit your circumstances.

WS-everything
This is a sizable clan of developers for whom SOA has always been both synonymous with Web Services, almost to the exclusion of any other architectural considerations. For them, SOA is all about creating the best WS-* compliant code, in Java or .NET, in the knowledge that each web service can call or be called using the WS standards evolving on the Web. They have no need for ESBs, Service Repositories, or any other fancy technology solutions. They may grudgingly agree to use a standard Portal product, but knowing deep down that they could write a better one themselves.

Agile
Since software writing began there have been rapid application development (RAD) methodologies and approaches to help speed up the software development life cycle. In the Eighties I helped to develop RAD, JAD (Joint Application Design) and plain BAD (Bugger All Delivered) methods, which have since evolved through Dynamic Systems Development Model (DSDM) to the current mess of Agile, Scrum, Lean Development (LD), etc. These approaches apply iterative phases to the meeting of user expectations and typically use whatever rapid development tool or language they can get their hands on. Or failing that, Visual Basic. Agile can be applied to SOA to cut development times, but care must be taken to apply the approach to the development of services, not the whole application, otherwise you will end up with a single application-sized service.

Read On...