What Value for Incremental SOA?

Posted by Mark Little on Nov 01, 2009

Sections

Process & Practices,

Architecture & Design,

Enterprise Architecture

Topics

SOA Platforms ,

Methodologies ,

SOA ,

Stories & Case Studies

Tags

SOA Adoption

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:

+1

Nonsense 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.

1. Back to top

   Gorilla middleware is supposed to decrease support costs?!?

   by Jason Yip

   Perhaps it's selection bias, but as far as I've seen the expensive middleware that is supposed to decrease support costs seems to do the opposite in practice.

   Reply

2. Back to top

   Re: Gorilla middleware is supposed to decrease support costs?!?

   by Jean-Jacques Dubray

   I am always suspicious when I read something that talks about "Approaches to SOA" and does not contain a single word about versioning, especially, when "incremental" is part of the approach. Time and time again, the pundits argue about antiquated, decades old, concepts such as cohesion or coupling. Time and time again they argue about the cost of X or Y, when the problem, the only problem, that needs to be solved is "how can I create elements of business logic" that are both shared across different solutions and can be evolved easily without breaking everything that relies on it -of course, at the lowest cost possible.
   
   Unbeknown to the people referenced above (since they never, ever talk about it), SOA technologies such, as Web Services, have delivered real solutions to this conundrum. The keystone of the solution is a forwards compatible versioning strategy supported by the extensibility mechanisms of XML and XML Schema. For some really strange reason, extensibility is good with dynamic languages but when it comes to creating extensible interfaces, all the sudden, it is bad. Almost as if RPC has been entrenched in the DNA of the entire industry.
   
   So yes, incremental is the name of the game in SOA, but without the correct versioning strategy your SOA will come to a halt, making it too costly to change anything (I am not sure Jim cares about that). And no, analysis paralysis is no approach to SOA: you can't govern with what you don't know.
   
   SOA is simple:
   1) govern enough but not more
   2) over time when governance you reach the limits of governance, use forwards compatibility
   3) when you reach the limits of forwards compatibility, use loose coupling (delivered by Service Containers)
   
   By contrast, REST relies simply on "serendipity" for reuse (no governance, no forwards compatibility and strong coupling between the consumer and the provider).

   Reply

3. Back to top

   Re: Gorilla middleware is supposed to decrease support costs?!?

   by John Moe

   I'm flattered to have unkowingly kicked off this debate on Guerrilla SOA.
   
   My main point (besides writing an entertaining article) was to promote the empirical evidence I have seen of the 'Think big, but start small' route to SOA success.
   
   @Jean-Jacques, Regarding governance and versioning, I wholeheartedly agree on the need for them - but to me that is a different debate. I presented on SOA governance yesterday at an Ovum event in London and described some of the many ways this could be done.
   
   @Jason, I agree middleware can be an expensive mistake, and is significantly more complex than usually stated.
   
   Regards
   
   John

   Reply

• Older >