“I like web services, but at present they represent an incomplete array of immature standards,” he says. “Even when they are complete and mature, they will tackle only part of the problem.”
Speaking to a breakfast management session organised by Computerworld’s sister magazine, CIO, he put forward his own “standards maturity model”. This was cribbed freely, he acknowledged. from the widely used “capability maturity model”.
Of web-related standards only TCP/IP, HTTP and the secure sockets layer (SSL) have achieved the highest status of level 5, truly ubiquitous standards, he says.
XML is probably at the next level down, with relatively few applications still fully supporting publishing and import of XML data.
Of the web services standard, only SOAP 1.2, WSDL 1.1 and UDDI can be said to be truly mature standards, but hardly anyone is using them, putting them at level 3. Their incompleteness, particularly their inability to be conscious of the current state of applications in their message passing between them, has led to the more recent development of a number of other emerging standards, which are still at a less mature level 2.
Assume in 10 to 12 years’ time all these tools make it to his level 5, he says.
“That still only means all my plugs fit all my sockets.”
Voltage standards, to extend the metaphor, the way information is expressed in one application and another, will still need “transformers” to bring them into line.
This kind of standard is not solved by technical frameworks like XML, if one company prefers to talk pounds and another kilograms, he says. It’s a social and business problem, which is typically solved either:
· by legislation and regulation (like a standard online form from Inland Revenue);
· by a dominant player in the market: “Everyone wants to sell to WalMart; if WalMart says you do an invoice this way, you’re not going to try to do it differently.”
· by the economics of competition. IBM Compaq and HP only defined the RosettaNet e-business process standard because they were being slain in the market by Dell’s direct approach, he says.
The synchronous message-passing of “service-oriented” architectures is too rigid, Altman says. He favours an event-driven architecture, where a completed event signals its completion and waits for another process to pick up the result in an asynchronous way.
Older enterprise application integration (EAI) tools offer more in this direction, he suggests.
“Popular opinion is that EAI is outmoded, it’s not popular and it’s too expensive: compared to what — a long Java or C# development? EAI is not expensive or complex; it’s the technology press that have given people that idea.”