"Oracle's Ellison: SOA migration a slow process" no surprise

Just before Christmas, InfoWorld published an article quoting Larry Ellison on the slow uptake of SOA. Among other things, Ellison said "It takes about 10 to 20 years before [you can] rewrite all of your applications [to take advantage of SOA]" therefore implying the benefits of SOA are a long way off yet.

I'm not surprised Larry has had to go on the defensive here. Admittedly as CEO of Oracle I wouldn't like to announce the huge investment in the SOA Fusion Middleware is seeing poor growth (well, at least the criticism of poor growth).... I'm guessing my shareholders wouldn't want to hear that either.

I'm also not surprised that this sort of criticism and concerns are coming about. From my own experience, while Web Services & SOA/BPEL are great enabling technologies, they're opening a huge can of worms in inter-system and inter-organisational communications that haven't even been really broached yet. Just because the underlying Web Service communications allow you to communicate in a standard fashion, it doesn't mean the systems or organisations you communicate to are following any standards internally. And this is where the problems really start ... and you thought the technology was difficult enough?!

I'll give you an example from my past.

We built a Web Service system to take purchase-orders (PO) from numerous point-of-sale (POS) systems, and distribute them to 3 distinct suppliers to complete. The POS systems were all under our control and the POS interfaces were clearly defined.

With the suppliers it was a complete mess. While each supplier did have a web service interface and we were able to use XSLT to transform our invoices into whatever format they required, what they each did with the invoices was completely different.

One supplier did exactly what you expected. Given a PO, they raised an invoice and an out-of-stock record (if necessary) and sent them back. Easy.

Another supplier took the PO, and returned multiple updates to a single invoice as they discovered stock. Our understanding is this is against Australian laws, where an invoice is meant to be a binding document. But never mind.

The final supplier took the PO, sent an invoice record for what they could find, and an out-of-stock record for what they didn't have. However over time the PO would roll out to other warehouses where they could submit an invoice for the remaining part, or then an out-of-stock for what they didn't have. And so on. Groan.

Now the SOA advocate will yell well that's great! SOA will take care of this mess, as you can build different solutions for each supplier. True, but each supplier wasn't guaranteed to maintain these modes of operation. In fact behind the scenes they had manual processes sometimes that dynamically changed the result. And in time we wanted to add over 50 suppliers, all with "interesting" legacy system based processes. It was very conceivable we'd just need full time person to keep track of what mess 1 of those 50 suppliers had got us into this week, changing interfaces, changing processes, making mistakes and so on.

In addition only 1 of the 3 suppliers actually had test systems we could build our application against. And for the supplier that did have a test system we literally had to phone them to ask them to flush the data each time we did a test. So much for quick agile development.

You could argue they should just standardise their systems!? But that's a pretty immature attitude. Most organisations have trouble establishing standards internally, let alone have enough clout and smarts to boss around external organisations; not many of us are a Walmart. In turn those external organisations may have big $$$$s invested in their IT systems, and won't or can't or just change over night. Maybe that's years from now.

So then you say, maybe there should be industry standards! Well there are. We stumbled across some standards, but none were being used by our suppliers, and again they weren't interesting in changing.

....and so on....

So like Larry, I truly believe we're years away from the SOA revolution, and it's something that will seep in an evolutionary sense, no big revolution here I'm afraid. Coincidentally like Larry I predict the real benefits are 10 to 20 years away too, and I'm sure the technology will move on so it doesn't look like what we think it will now.

I have a further problem with Oracle here, or the way they're selling this. Oracle is marketing a technology solution that will solve all of your problems, when integrating systems internally and externally. But in reality you've only just started on this highway to hell, and you're going to have a hell of time working with your organisational peers in enabling SOA for all the reasons mentioned above and more. Oh yes SOA advocates will argue this is solvable, but in my words "good luck, you're going to need it." Several generations of your IT staff will come and go I'm sure before you see huge success.

I'm also a bit suspect of Oracle, and in particular Oracle Australia for focusing so heavily on the SOA arena recently when it's overkill (and overpriced) for most small to medium organisations (which Australia mostly contains). It's another case like the database where Oracle's solutions seem to be pricing themselves out of the market, and creating solutions very few people use (relatively to the entire IT market).

Don't get me wrong, I see a need for SOA technologies, or more precisely the goals of system integration, and I wouldn't bet against Oracle's solution being a technically savvy one, I just don't see SOA as the immediate White Knight to *all* IT's woes.

What are your thoughts on the future of SOA and all things Web Service oriented?