REST isn't undead in the enterprise... its still born

Its always depressing to see fanbois bleating and moaning about their beloved technology or piece of bling not being universally liked. This is normally put down, in a wonderfully immature way, to the failure of "the other side" to see their point of view rather than any innate failings of their beloved approach. SOAP is not Dead - Its Undead is a classic of the genre.

Why hasn't REST succeeded in the enterprise? Not of course because it isn't actually any better than SOAP for enterprise scenarios and is indeed much, much worse in many. Nope.

But first there is the reason why REST is successful

His presentation showed that 73% of the APis on Programmable Web use REST. SOAP is far behind but is still represented in 17% of the APIs.

This is like going to France, doing a language survey and declaring that French is the most popular language in the US. So what would doing the same query on the likes of Oracle, SAP, IBM or Microsoft's enterprise technology stacks deliver? I assumed the number to beat would be huge and got ready for some serious searching.... but the number to beat is 2368... errr seriously? I've worked in single enterprises where they had more SOAP endpoints than that. When you include the libraries of WSDLs from SAP and Oracle and the Behemoth that is Oracle AIA has so many that Oracle don't boast about it as it might make it look complicated. Back in 2005 folks at Oracle boasted about over 3000 web services across their applications. Now before people bleat about this being proof of SOAP complexity... that just makes you a hypocrite if you on one hand use the ProgrammableWeb stats as "proof" of RESTs success but then try and use the massive volume of WSDLs out there as proof of SOAP's "complexity.

I'm also here not even into the global standards that use SOAP every day for B2B, people like SWIFT, Open Airlines... shall I go on and on? 2400 APIs is a success? SOAP isn't anywhere near that? Like I say its like going to France and claiming French is the most spoken language on the planet.

All this just proves what I've said for a long time. REST works for information traversal, but its not set up for the enterprise. So what is the issue with REST not displacing SOAP in the enterprise?

"All the tools, hires, licenses & codebase has been built around SOAP for a decade," Loveless wrote on Twitter. "Hard to turn on a dime."

Wow, the bare facedness of this statement is hard to beat. REST has been kicking on this door for over half of that time and some folks argue that in fact it predates SOAP. So it really is bullshit to claim that its all the fault of tools & codebase. SOAP replaced old EAI approaches in a couple of years in new enterprise projects. We went from a situation with everyone in about 1998 doing proprietary EAI integration, with occasional CORBA for RPC, to everyone by 2002 doing Web Services with some JMS. People in 2005 were telling me that REST was the future and REST would win, and now SIX YEARS LATER people are bleating about 10 years of SOAP adoption...

If an approach is better for integration in the enterprise it will be adopted. REST isn't better, yet, for enterprise integration because it fundamentally remains a developer approach not a professional enterprise approach. SOAP isn't complex, technically it might suck (hell my father said "great we've now got enough processing cycles to burn that ASCII-RPC has finally made it") but conceptually its simple, and when managing complex estates with lots of different people that conceptual simplicity on the head.

Michael Cote of Redmonk hits the nail partially on the head when he says

"As enterprise development teams start including cloud technologies in their applications, incompatible cloud platforms and APIs will be a huge road block," said Michael Cote, analyst at RedMonk. "We're already seeing a clamoring for tools and services that integrate this spaghetti bowl of end-points, and they're only going to become more important to realizing the benefits of cloud development."

In other words the lack of a formal contract and standard interface mechanism remains the real reason why REST isn't being adopted in the enterprise.

What SOAP did was solve a problem that the enterprise had. How do I describe integration interfaces so my systems on different technology stacks can communicate and do so in a way that enables my teams to work independently of each other. REST does not solve this problem in an effective way and bleating about "dynamic interfaces" being "better" misses the whole point of what has made B2B and Machine 2 Machine integration successful down the years, namely a focus on people-centric approaches rather than technical centric ones.

Unfortunately with REST there appears to be an active movement to stop this professionalism creeping into it and defining new standards that will actually make REST better for the enterprise.

REST needs a standard way to publish its API and for a way to notify changes in that API. This is a "solved" problem in IT but for some reason the REST community appears to prefer blaming others for the lack of enterprise success of their technology rather than facing up to the simple reality:

SOAP got some things right and the biggest thing it got right was a shareable and toolable contract (WSDL) which enabled interfaces to be published in a standard way which included by functional and data standards.

SOAP isn't undead, its very much living in the enterprise and indeed being the only real viable approach when integrating package solutions from a number of vendors (a massive piece of enterprise IT). REST however barely registers, less than 2500 APIs after all these years of development? Pathetic.

REST for the enterprise isn't undead... its been still-born for over five years.

Technorati Tags: SOA, Service Architecture

The three magic questions of business SOA (and IT Strategy)

Having a chat with someone today I was reminded of a presentation I gave a few years ago. I went to the client knowing that they'd spent a lot of money in the last few years on an IT "refresh" and the word SOA had been used rather a lot. The programme wasn't seen as being a success and the business were bitching that money had been wasted.

My opening point was that the business was sort of right and so I posed three questions

1. Do you have a clear vision of where you want your IT estate to be in 3 years
2. Do you want the IT estate to reflect that vision
3. Do you want the costs for IT to reflect the different values in that vision

The answers were "No, Yes, Yes" which wasn't a huge surprise but was my real point to both sides of what had turned into a political mudslinging competition.

IT had set off to try and do 2 and 3 without knowing 1 and the business had effectively said "we don't know what we want... but we know its not that". Neither of these was a good idea. So the focus therefore was on creating that vision (a business service driven vision) and doing the heatmap that meant IT could then align itself (number 2 and 3) to that vision.

Now I've said before that IT and Chairman Mao have a lot in common but there is another famous phrase that applies here

"A journey of a thousand miles begins with a single step"

Now that might be true, but its really important to know where you are going otherwise you look like a bit of a pillock in a thousand miles.

So can you answer the three magic questions of Business SOA and IT strategy?

Technorati Tags: SOA, Service Architecture

One year on: zero progress for Enterprise REST as Java races backwards

Just under a year ago I blogged about how REST and Sun had put Enterprise IT back five years so I thought it was about time to update that view and see what has happened in the last 12 months in the enterprise integration and governance space.

So on the REST front we've seen.... ummm.... struggling here.

Lets be clear, I'm talking here about REST as an enterprise integration approach, not as a way of exposing a Web API for content aggregation but as a functional integration approach for enterprises. Something to replace the "fundamentally flawed" WS-* that REST is so much better than. So what is the progress this year? Zip, zero, nada. Yup a few minor tweaks into enterprise stacks that say they can produce REST interfaces, but in reality most of them can't and the key problems of interface publication, versioning and testing remain unsolved.

Am I being harsh on REST? I don't think so. Its had more than enough time, and hype, to address the real problems of enterprise computing and step out of the niche, and in revenue terms it is a niche, of Web content aggregation. REST is great for that niche, but that wasn't the pitch made, the pitch made was that REST was great, WS-* sucked and REST would solve all the problems that existed with WS-*. This hype, and the smart people who followed it, has led to a stagnation in enterprise integration that is really hitting enterprise computing in real revenue terms. Its slowing the adoption of cloud computing and generally meaning that IT departments are less credible and less successful than they should be.

So one year on and REST continues to flatter to deceive.

What about Java? Well here the story is actually worse. I honestly believe that the REST crowd are a smart bunch of bunnies and are trying to solve problems, just not realising that most developers aren't as smart as them and that interface dynamism is actually a bad thing. With Java that is sadly not the case. With Mark Rheinhold now actively subverting the JCP and the debacle in the JCP generally over the last year its hard to think that the situation is doing anything other than getting worse.

What does this mean for Enterprise IT? Well a couple of things, it means that SAP, IBM and Oracle the three headed beasts of most IT estates don't have a clear future integration improvement roadmap, its all still based around WS-* as it was 4 to 5 years ago and they are all adding proprietary "tweaks" which "help" people when using their platforms. It also means that their core platform, Java, is stagnating and not getting some of the fundamental changes it needs to address the cloud and dynamic scalability. In particular the continuing "kitchen sink" approach of the Java dictatorship means that reduced profile VMs that are tuned to specific tasks (like Mobile potentially) just aren't being addressed which is leading directly to a fragmentation in the core operating platform.

What does then mean? Well with REST it means that enterprise IT shops are relying on WS-* for integration but still coming across things like vendors not having WS-Security support and with the decline of WS-I the number of "strange" defects is liable to be on the rise. Efforts around more formal contract approaches are dead. This means that the "spaghetti" of enterprise IT, which looked to improving in the first 6 years of the new millenium is actually now getting worse again. REST aimed at WS-* squarely and surely and has certainly hit it with a wounding shot, unfortunately it turns out that REST is incapable of being the replacement for WS-* it wanted to be. REST is Brutus, WS-* is Caesar.

And with Java? It means we are seeing language fragmentation and platform fragmentation which means that the support costs of IT estates are going to rise and so the on going challenge of reducing operating costs to enable investment in new solutions is swinging back against the business and towards entrenched IT estates.

I really can't see how a large scale enterprise IT programme is better off in 2011 than it was in 2005.

Technorati Tags: SOA, Service Architecture