Asphalt that controls traffic type and flow?

This weekend I attended the SAP Inside track NL event, held at Ciber HQ in Eindhoven. The event was great, and I really enjoyed it but would have loved to stay longer and gotten more involved.
What has followed are great conversations and discussions, new people to follow on Twitter and elsewhere, and lots of topics to talk about

One of the inputs for that is the presentation I gave at #sitNL

One of the outputs is a discussion that followed about SOA, REST, ROA or even REStful SOA and other TLA's.
Let me be brief and blunt: they are an absolute waste of time and money, and I will prove that right here and now

Looking at an architectural approach to IT, it's usually devided into business, information, information systems and infrastructure - that translates to people, functionality, programs and machines.
I like to translate that to persons, purpose, vehicles and roads (let's forget air and sea to keep it simple)

As always, the closer you get to people, the more dynamic and flexible you need to be, the more exceptions you see, the more complex it gets.
You can wake me up any time of the night to recite this mantra. I use it for IT, Social Business, Integration - anything

So where do SOA and REST and their offspring fit? That is the question. The awkward thing is, they are handled by the IT people - the business doesn't care about them, it's mere implementation.
But where are they placed? On the infra level, nitty-gritting with HTTP POST and GET and other minute details. URL format, layout, call returns, etc.
Alright, so IT-people implement something on the infra structual level - that would be like saying something about tyres and roads, about which kind of tyres are allowed to travel on what kind of roads, under which circumstances? Maybe one step higher even, vehicles?

In any case, it's on the infrastructure level, so it must be: static, rigid, dominated by rules and simple. Right?
Wrong. It specifically instructs you on how to use the HTTP stack for business services. So it con-fuses business on the infrastructural level - and that is not only uncalled for, it's mixing two separate universes into one

Do you care about asphalt? Do you care about tyre pressure, tyre size, tyre width? Do you even give a damn about how engines work so they can drive the vehicles that bring you from A to B?
Of course not! Why would you? Your interest only goes as far as it needs to go: trains are for long distances so you can work or you want to get from one city-centre to another. Cars are good for anything except traffic jams, where motorcycles perfectly fit in, and foldable bycicles are great to travel the last 1-2 miles from a train or bus station. Fine

As a manager, you don't care what transportation your employees use, as long as they make it to work in time.
Why do buses, trains and airplanes all have the same chairs? Why don't they have various chairs in various sizes, widths, pitches, etc? Because that's too much trouble, and places way too many constraints. And those constraints cost time, and money

So why would you want to constrain and restrict how HTTP is used for communication? You wouldn't, unless HTTP is the only protocol you know. You wouldn't, unless the Interweb is the only place you know. You wouldn't, if you weren't that narrow-minded

I've got to give it to REST that it is far, far better than SOAP. Way. Did I stress that enough? Seriously, I do think so - REST officially has no protocol constraint, not syntax - but not many people know that. (Roy Fielding started his REST as solely HTTP-based but then his dissertation was written for the Web)
But making the same mistake for only 5-10% is still making the same mistake. Do we invent similar limitations to determine how we should conduct a phone conversation, an email conversation, a Skype chat or video call, a Google + hangout or what not? No! Of course not

This is how I picture an enterprise and its constituents, to play a social pun:

At the bottom is the traditional IT-landscape: one big chunk of apps, usually SAP or Oracle, and a whole lotta Specials. For future reference, a Big Data DB is already in place. To the left, the traditional customers and suppliers: B2B and B2C. On top, Social threatening to invade the enterprise, and to the right, Cloud and Mobile.
If you start at the bottom and go clock-wise, you'll find that you go from legacy, established vendors and proven technology to fresh, new-kid-on-the-block hotness. You'll also see that speed of implementation increases, and size of solution decreases.
So right there, a lot of different stubs want to Plug-and-Play into your enterprise. At least your CxO's would like to see them do so at great ease

Now, let's see what drives these constituents on the physical level (a pun at my road metaphor, for those of you who skipped the first part of this post)

SAP traditionally disclosed itself in iDoc format, via file-system or FTP but I find a queueing system such as MQ far more elegant and fit for real-time. The Specials might use any means of transportation and any vehicle - picture them being mainframe, AS/400, UNIX-flavoured or J2EE / .Net applications, and you'll get my drift. As it now looks like, any Big Data (what we used to call DWH) will be in-memory because if performance is not an issue, you need not bother to structure or give hierarchy to your data

B2B? EDIFACT in the entire world save the US, where X12 is used. Some different flavours dependent on industry (HL7 in Health, Swift / SEPA in banking, and XML / XBRL in G2B (governments to businesses). B2C could be in anything as this usually is a bilateral agreement between you and yourself, but XML is almost always found here.
Social Media? Twitter deprecated XML, as did Facebook - they use JSON now.
Cloud will pose issues as people want to lay their hands on the data itself. Real-time integration might be problematic, but synchronisation will be easy and highly likely occur in JSON - or even compressed data. Mobile? Ah, the Specials of the new devices! Anything goes...

A wide diversity, right? Right...

After looking at the message syntaxes (the vehicles), let's look at the transport protocols (the types of roads). I see 10-lane interstate highways (in-memory), toll tunnels (EDIINT's AS1 and AS2), just ordinary roads (HTTP) as well as very long bridges (FTP), as well as off-road tracks (HSPA) and bicycle paths, pedestrian walkways, boulevards and Lawd knows what (the any in internal application integration - A2A)

A slightly less wide variety, but still: would you really like to invent something like REST for all these? Do you want to waste your time describing exactly how to format a URL? How many constraints do you pose on yourself, your company, your clients, customers and suppliers - now and in the future?
There is money to be made - huge amounts and tons of money - in doing business with old and new customers, clients, suppliers, but now also making it easier for your employees to do so via Cloud and Mobile

We are talking about dumb, stupid transport protocols that reside in the infrastructural layer. There are a few of them, and there will be more. If they break, we'll just use another - they are so ridiculously unimportant that we just don't care. What we do care about, are the messages (the information!) we convey across these transport protocols - and that's why we value business document standardisation anytime over nitty-gritty tech; because that's where real interoperability lies

It's almost - just almost - like having a navigation system in our car that directs us to our goal via the optimum route. We really don't care about how that route looks like, as long as we get to our goal in the most efficient way possible