'Upgrade' equals 'SOA-enabled'
You may not want it, but you’ll get it
To lunch with Willie Fitzpatrick, EMEA vice president of Amberpoint. Given the company’s interest in SOA management software, that being its major sector of operation, he raised an interesting issue that could well affect many developers and users – namely that they may find SOA infrastructure capabilities thrust upon them, whether they want them or not.
He made the point, for example, that there are many thousands of businesses of all sizes which have, as their stated position on the adoption of SOA, some variation on a mantra that goes - "well maybe, but not yet. Let's see how it develops. What we have now is good enough for our needs".
For many of them that will in fact be a perfectly justified and correct decision, but it matters not a jot, for the next iteration of all the major applications they are likely to use – SAP, Oracle, Microsoft and the rest – will be SOA-enabled as a default. You get it whether you want it or not.
It also means that applications developers will get capabilities they have no experience of or training in, offering capabilities that could offer them some tempting short-cuts.
For example, at present any requirement to link Application A to Application B is likely to result in a developer getting the job of building it. Sometimes, that can be a job requiring significant skill. With the next upgrades, the chances are that developers are going to find a wide range of new tools for undertaking several functions that their current environment does not actually require and they have no skills in utilising…….but they may prove very tempting.
This means, according to Fitzpatrick, that IT departments in those companies will then most definitely require what they thought they did not need as they still have no plans to move to an SOA infrastructure. This is good governance, in the form of comprehensive rules and policies that control issues such as how, where and when which applications work with which others, and how they are utilised.
What is more, they will also need some form of SOA infrastructure management system that can integrate with and manage all the applications they might have, and can implement and police those policies across the entire environment. “That,” he said, rapidly moving in to deliver his coup de grace sales message, “is where Amberpoint comes in.”
OK Willie, you got me fair and square. But the fact does remain that, for IT shops in the thousands of small 'c' conservative businesses that don't yet see SOA as applying to them, the next upgrade of the applications is going to give it to them anyway, so they had best start getting ready for it now. ®
Much as I like the idea of SOA, I can't help but feel nervous when I read that everything will be "SOA enabled as a default". To me, SOA implies potentially high latency and a need for controls (ie overheads) to cope with the fact that you aren't quite sure who'll be using your service and what for.
OK, there are real benefits from SOA for a lot of people - but for others (as Martin implies), in some applications, a nice tightly-coupled efficient point-to-point solution may actually make business sense - in the future as well as now!
Much is made of the supposed complexity of software development for parallelism. It has been my experience, however, that the influence of traditional application development thinking and training is the main contributing factor to this myth. Ordinary human beings have no problem developing highly efficient implementations of parallel algorithms which suffer not from the prescriptions of Amdahl's Law, although admitedly do encounter scalability constraints associated with other factors, like managerial span of control and the limits of reliable communications using voice only.
Most, if not all, software that is available for the support of parallel applications is hopelessly tied to the intrinsic limits of computer hardware available in the marketplace over the past 40 odd years. As long as the problem of parallelism is viewed in such a context, the complexity of solutions will only increase.
My suggestion is that application developpers spend a few weeks in a day care for pre-schoolers and watch how they solve such problems as getting toys from a toy bin. Applying the lessons learned to a parallelism problem can result in rather amazing enhancements to applications.