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 Service Oriented Architecture 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.
Service Providers
With Software as a Service (SaaS) becoming more mainstream, the service providers (i.e. vendors) behind these web-based functions are promoting the use of a browser plus widgets approach to developing applications, where you just have to mix and match the SaaS offerings to meet your business requirement. You can then run this on the cloud computing Platform as a Service (PaaS). In fact it is so simple that you don't need an IT department anymore. Of course, not everyone is gullible enough to jump straight into this, but it is an interesting direction that suits the SOA principle, albeit unproven as yet.
Product Vendors
There is still an enormous and growing population of SOA product vendors crowding the market and fighting tooth and nail for your business. Many of them have ingenious software tools that can assist you, and they invariable have a pitch that goes something like this: "Buy our tool and you won't need to buy anything else to do SOA", or words to that effect. The tool vendors are trying to pull a fast one here: either their tool is only part of the Service Oriented Infrastructure you will need, or it is so big that they will want the $250M I mentioned above for it.
So where does this leave the search for true Guerrilla SOA? As ever, it is a case of mixing and matching these approaches to the type of business problem you are trying to address. Step back a little and apply some common sense to the scope and scale of the problem you have, and also be clear from where you are starting and the knowledge and ability you have to go on your journey. There will some problems for which each of these approaches will work for you, but I can guarantee that no one solution will solve all of them. SOA itself is still evolving, so being agile, with a small a, is probably the best advice I can give. Other than not to try Gorilla SOA...
Author: John Moe is Principal Consultant at J Moe Associates, and writes and presents widely on SOA and BPM. With over 25 years experience delivering application development and business transformation programmes, John has made most of the mistakes you will ever make and is keen to pass on this knowledge to help you avoid them yourself. In return he just expects undying gratitude and free drinks wherever he goes.