Thursday, 24 July 2008

SOA what?

Yesterday I had an amusing trawl through various Oracle-related blogs, most of which confirmed my preconceptions about various online Oracle personalities. But I digress!

The one blog entry that stuck with me was this (Aussie) one:
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 was quite taken aback by this. I mean, Larry, for all his sins, knows a thing about getting stuff sold. He knows about backing winning horses. As a user of IBM technology, I'm quite used to seeing them witter on about stuff that is supposed to make stuff easier but actually makes it worse, but why is Larry getting involved with this shit?

More from our intrepid Oracler:
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.
Yep, that sounds about right. It's fucking easy to do this shit when all you have to do is stand up in a room presenting PowerPoint slides, or have a meeting-room bullshit session without thinking anything through, where marketing buzzwords are much more important than anything useful.
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.
Sounds about right, too. So SOA is going to make your life easier, eh? I think it might be more about keeping vast armies of body-shopped consultants off the bench, myself. Or I would if I were cynical, but luckily I'm not.
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.
Ah, well, that's simple: only do business with people who meet your exacting standards. That's what any consultant would tell you.
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.
More eminent sense.

I've long since given up with IT panaceas, I think it was Java that finally burst my bubble. I had lived through "PCs will fix everything", then "methodologies will fix everything", then "4GLs will fix everything", then "CASE tools will fix everything" and then someone said "Java will fix everything" ... and then I realised the whole thing was just like the South Sea Bubble, endlessly repeating these wild and delusional claims. Nothing will ever be a panacea, they will just nibble away at one or other aspect of the total problem.

I think SOA is a particularly malign form of this problem because of the level of complexity it can lead to and additional work it demands. People will be cursing SOA for decades to come.

And it looks like Larry's going to be one of them.

No comments: