This post originated from an RSS feed registered with Java Buzz by Bill de hÓra. Original Post: The integrator's dilemma Feed Title: Bill de hÓra Feed URL: http://www.dehora.net/journal/atom.xml Feed Description: FD85 1117 1888 1681 7689 B5DF E696 885C 20D8 21F8 Latest Java Buzz Posts Latest Java Buzz Posts by Bill de hÓra Latest Posts From Bill de hÓra

Points of disruption

We can see the market looking at 3 things to provide value in software solutions:

1. Simple protocols and formats
2. Open source infrastructure
3. Agile methodologies

All of these are disruptive.

The first is what we're talking about here - formats and protocols that are sufficient for most users. The other two amplify the first and are worthy of a brief mention.

Open source as disruptive technology to traditional per seat, per CPU, licensing models has been beaten to death by Tim O'Reilly among many others - today everyone selling products into the integration and middleware space has to factor OSS into their plans.

The reason agile methods are disruptive is because software methodologies are closely aligned to business and procurement models. How you go about delivery has a first order effect on how you get paid, and how much. Agile approaches also favour what Scott Ambler calls 'generalizing specialists', rather than actual specialists, something that runs counter to much of industry's organisational and training practices. Notably, the Standish group is still telling us that 65% of projects are failing in way or another. In that context, providing a process that get the figure down to even 40% and say, halves the post-live defect count and you have in your hands a disruptive business model.

A services dilemma

Using the Christensen playbook, we should consider whether WS specs and tools are being commoditized by disruptive technologies. If so the natural progression for them and the software based on them is to move up the value chain. When the mass market for enterprise technology is either over-served by technology, quality or the price is too high that leaves an opportunity for disruptive technology to take hold at the bottom end of the market.

I worry this may put out some people who feel that WS are a disruptive technology, but when you see RSS usage figures doubling twice a year, you stop and think about what's really disrupting what. But, REST as it appears in the HTTP Web seems to have a broader potential set of uses than was originally imagined by WS proponents, especially in conjunction with simple formats like RSS or Atom.

In the case of WS, it's possible that the broader market is over-served. Statistically speaking, relatively few organizations needs all that serious stuff, all those extreme 'ilites. What most organizations need is cost-effective, stable, flexible software with reasonable TCO. So if the number of people who really need 'serious' high-end systems is relatively small compared to those who can't afford or don't need all the technology, what we can expect is that the market will be served by inferior technology at margins the providers of serious tech will be typically unwilling to meet. The suggestion is that those providing the disruptive technology will enter a growth market.

Naturally, some people will object to classing the Web, REST, RSS et al as inferior technology. The point is that this stuff is good enough for a growth market. And following we should expect that good enough tech will improve and those supplying it will move up the value chain, while the technology itself probably gets cheaper.

What's driving WS?

Should we accept that people are either being supplied excessive technology requirements and architectures through WS or simply can't/won't afford to procure in the first place? I think we should, but there's nothing sinister here, rather it's a quite simple outcome of enough 'what if' questions. What if the database server goes down? What if the transaction fails? What if the network goes down? What if we have 1M users online? What if someone tampers with the data? What if we get slashdotted? It's all about listening to your customers and taking care of them . It should make sense to do this. This is a good thought process to go through.

The problem is that the concerns are often answered without taking cost into consideration, without anything that looks like risk assessment, without a thorough examination of the requirements.

The burn rate for such things fits the classic J curve - a modicum of improvement has a disproportionate cost the rate of which increases as improvements are added. Software people don't always consider the J-curve in answering what if questions - where they do, answering them by climbing to the summit of the curve is not ideal and is something that currently separates software from engineering. Engineers will establish ratios and determine fitness for purpose. Engineers understand the effect, necessity and relative cost of part tolerances. They know the properties of their materials and structures under a variety of environmental conditions. They have a good understanding of solution cost. They know they might get sued. Engineers even have a physics. Yes, engineers do get it wrong, but generally, the software industry isn't strong on this.

Good enough opportunities

Finally, REST advocates like to paint an appealing picture of a Web governed by open standards that mesh well with one another and over which XML documents conforming to industry-standard schemas with well-documented semantics are transferred. Few who actually work down in the trenches suffer from this delusion for long. Even a dirt-simple idea such as the XML format RSS becomes an interoperability mess in practice.

This is easy to agree with. What is less easy to understand is how fifty plus specifications from the WS-* canon will improve the situation.

How are complicated WS specs going to help with interoperability a way the dirt simple stuff does not? There doesn't seem to be anything special about REST that would make it prone to interop problems over WS specifications. The interop story on WS has not been spectacular, but is getting better [2]. I'm neutral on the relative merits of their interoperability and much more interested in how much interopability is actually required case by case. What seems to be special about REST from this point of view is that it's fit for purpose and cheap by comparison, once you establish that you aren't served best with the complexity and capabilities implied by WS.

Once again, it appears that REST is a fine idea for simple scenarios where bad stuff can happen with impunity and corner cases can be disposed of arbitrarily. Building secure and reliable applications for situations in which serious money or human lives are at stake is another matter.

I don't think anyone should read that and draw the conclusion that REST is an irresponsible technology and WS is not. What's really worth bearing in mind is that serious money is relative, reliability is relative, security is relative. In one sense, the polarization (you're secure or you're not, it's reliable or it's not, it's serious or it's not) and the drive toward higher levels of performance and complexity are entirely rational. As Christensen has pointed out, it's what happens when you listen to your best customers and try to maximise existing profit centres. This attentiveness inevitably forces WS vendors up the value chain and out of areas where they believe it's not worthwhile selling into, leaving a gap for simple technology like REST to step into. It means when you take into account the J-curve, there is a risk of abandoning a growth market by thinking interms of absolutes and overlooking the notion of fit for purpose.

Conclusion

If we accept that WS based technology is being disrupted at lower and mid ends of the market then it becomes clear that there is no absolute technology winner between REST and WS [3]. What to choose becomes a question of establishing your relative requirements. However we can expect that vendors servicing the low end will move up the value chain over the coming years and as a result claw away at WS based revenue - Christensen's model does not predict a steady state of affairs.

If dirt simple equates to good growth and better profits, then the missed opportunity arises when simple and simplistic are conflated. When the WS contingent are looking at the REST and syndication crowd and saying more or less, 'here's a nickel kid', they may want to stop and take a second look at what the kid is doing with that nickel.

[3] This does not mean the public debate is reduced to a tourniquet fest, only that we need to take a focused look at what the customer actually needs.