In a recent article, John Moe discusses a taxonomy of approaches to SOA, specifically incremental SOA aka Zero Middleware or Guerrilla SOA. As John says, there are ...
... 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.
These approaches include:
- Web Services: for these types of developers "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."
- Agile: "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)."
- 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 point 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 [to set up an SOA infrastructure in a large company]."
Jim Webber, Dave Chappell, Steve Jones and others pick up on this article, with Dave first commenting on the apparent cost of vendor driven SOA solutions:
My employer (Oracle) would be quite happy if $250M for every SOA project in a large company went towards our middleware.
But then he focuses on the core of John's argument:
The greater cost of any project, whether SOA or otherwise, is the people time. I would argue that trying to do a project based on SOA principles without middleware is just wasting more time reinventing wheels that get built into proprietary frameworks that have to be maintained over time, or worse just left behind by the "Guerrilla" consultants.
Coming from the non-vendor crowd, Steve agrees with Dave:
+1Nonsense to say that the product spend is a huge part of it. Most projects its around 10 to 1 or greater over a long programme and at least 4 or 5 to 1 on short engagements. Anyone who is spending more on licenses than implementation in SOA is a muppet.
Jim, from another non-vendor company, gives some anecdotal evidence to counter this. He discusses a telecomms based engagement that he and his team were involved with:
Prior to our first project starting, that client had already undertaken some analysis of their future architecture (which needs scalability of 1 billion transactions per month) using a blue-chip consultancy. The conclusion from that consultancy was to deploy a bus to patch together the existing systems, and everything else would then come together. The upfront cost of the middleware was around £10 million. Not big money in the grand scheme of things, but this £10 million didn't provide a working solution, it was just the first step in the process that would some day, perhaps, deliver value back to the business, with little empirical data to back up that assertion.
The cost from the vendor was too much, hence leaving the door open for an alternative. Therefore, using the approaches behind Agile and Guerrilla SOA, Jim's team was able to spend ...
... a couple of weeks working through some analysis of the problem, including some simple mathematical models of how the problem domain scales over time, and how the solution would have to compensate. We took the time to understand how to incrementally alter the enterprise architecture to release value early, and we proposed doing this using commodity HTTP servers at £0 cost for middleware. Importantly we backed up our architectural approach with numbers: we measured the throughput and latency characteristics of a representative spike (a piece of code used to answer a question) through our high level design, and showed that both HTTP and our chosen Web server were suitable for the volumes of traffic that the system would have to support.
According to Jim the project went from strength to strength, ultimately delivering the solution the customer was after for relatively little financial expenditure. The success of the first project lead to a second engagement that was also successful. Jim concludes with a direct response to Dave's statement about people costs:
But what's particularly interesting, coming back to the cost of people versus cost of middleware argument, is this: we spent nothing on middleware. Instead we spent around £1 million on people, which compares favourably to the £10 million up front gamble originally proposed. To be explicit:Total cost of working software in production: £0 (middleware) + £1,000,000 (staff) = £1,000,000
Total cost of middleware approach: £10,000,000 (middleware) + £? (staff) = > £10,000,000
Steve has a response to Jim though:
Wonder if he factors in the cost of supporting it over the next 5+ years....
He then concentrates on the figures Jim used in his example, specifically the $10 million on middleware:
[...] if someone is spending $10m on middleware upfront then that person is a complete and utter idiot. I'm really struggling to think of someone who has _upfront_ spent that much on middleware, hell I'm struggling to think of somewhere that has spent that much in total outside of organisations whose total spend is way over $500m a year on IT alone.
Anecdotal evidence in either direction is hard to base any decisions on (worse still, one instance is not a good statistical sample from which to draw any conclusions.) All SOA practitioners, whether or not vendor based, will have in depth analyses of why their projects succeed or fail, but have good reasons to not disclose them. Without truly independent data it will always be hard to judge the true benefits of one approach versus another. However, Steve concludes with an interesting point:
The bit in Jim's post that he doesn't consider is that there were idiots involved in the $10m decision.... and right now my money would be on that.
So the debate rages on.