Simple Service Enterprise - part 5

In my first post on SSE I explained why and how I want, and can achieve, and have achieved, an Enterprise Integration paradigm that will give you a device-agnostic, platform-agnostic, tool-agnostic architecture that will free you from being crushed by the two tectonic plates in IT at the moment: diversity in devices, platforms and tools on the inside, and diversity in devices, platforms and tools on the outside

In my second SSE post, I explained why the approaches of the last decade and more (XML, ESB, SOA and SOAP) have failed, and in my third post I dared to state that REST is never ever going to be a solution to solve the issues either.
The reactions I got to that mainly showed me that myopic perceptions persist across techniques - yet replacing SOAP by REST and XML by JSON without questioning the business value of any of those is now being undertaken by the most zealous, and I simply won't have it. Not on my watch

My business is about long term value and benefits for clients and their business partners and customers. I know that, in most of today's world, Integration is an afterthought at best, especially in ERP implementations. Quickly scribbling together an undocumented solution that works for now is what saves many projects.
Some people I know even claim that as a success - as if we don't live in a world dictated by evolution, change, growth. People like that merely give you workarounds to issues, without ever solving problems and handing you the definite solution

Let me tell you: Integration is not a Goal. It's a Means. And it's painless. And it's "proven technology" - with which I mean that successful Enterprise Integration has been in existence for centuries; regardless of technology

How can that be? you might think. It can't be that simple?! you might say. Why has no one told me?!?! you might exclaim. Read on

Enterprise Integration is as simple as day-to-day conversations, or information exchange. Here's an example:

1. Hey Tom! What did the Red Sox do last night?
2. Dunno, didn't watch the game, haven't read the papers. Try Hank
3. Hey Hank! Did you watch the Red Sox game last night? What's the score?
4. Oh man it was quite a game. Lots of excitement, bases loaded with two down, but they scraped it at 15-13

In (1 a Red Sox result service gets adressed. A request is sent, with the proper attributes. The semantics are commonly agreed upon, and the syntax happens to be English, colloquial

The reply to (1 is (2. The service apparently doesn't have access to the required information, and indirectly redirects to another service who might

The service request is repeated in (3 in a slightly different form, yet the response in (4 is satisfactory

That's how we live. That's how we communicate. We address someone, send a message across, and wait for the return

It is as simple as that. Write a recipient address on an envelope and yours on the back, put a letter inside, bring it to a courier, and wait for the courier to return with another envelope, open it, and read the letter.

What is not functioning in this scenario? Nothing. This is a perfect, simple, timeless model for information interchange. Regardless of technology, free from vendors, and independent of so-called independent organisations like W3C and OASIS

So, what's preventing us from using this model and apply it to our IT landscape?

Nothing.

Come again? Nothing. Nothing is preventing you, on a logical level, from (re-)using the same model of information interchange that has been proven extremely successful over centuries.

Technically, there might be some minor issues - but nothing worth the current excitement over SOAP and REST

I'll address the technicalities of this in the next post. In the meantime, ask your technical integration experts for their opinion. I'll go one level deeper in the next post