Simple Service Enterprise - part 6

In my latest post, I recapped on the previous posts and started to take Integration from a business point of view. I'll continue to do that here, and try to mix in technical details without it getting too confusing. Wish me luck!

Here's the conversation again:

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

This conversation could happen anywhere, and any time. You've probably created an image in your head that this is in an office or public place, and the person sits close to Tom and Hank.
That is one option - but there are many others:

• The conversation is not real-time, but takes a few minutes, hours or even days
• The people aren't located in the same room or place
• The people don't speak to each other, but use different media: SMS, tweets, IM; even a quick call or email could be feasible here

Would any of that change anything to the content of this conversation? Well obviously the last one doesn't fit in one tweet, but it would in two - other than that, nothing should change, of course. Right? Right.
It would be odder than odd to change anything to the conversation here, just because you're using a different medium.
And it would be even more odd, to change it now, wait for a few years without the medium itself changing, and then having to change it again - wouldn't that be so? Yet that's what the REST fundamentalists advise - and in 5 years or so there will be another "invention", and other people, or the same-ish, who now praise the new new New Black.
REST assured that the majority of those people advocated SOAP a decade ago, for the same lack of (business) reasons

In my eyes, most if not all of these are amateurs who have little to none experience in the field of Integration, and probably all come from one environment: one ERP package, one programming language, one operating system - well maybe 1.5, or even 2 at best

What would make sense? It would make sense that the I's in the picture, the Enterprise Functions, remain unchanged -in essence- while being exposed to the "device layer".
It would mean that you can have the same conversation across any medium: real-life interaction, phone (landline or mobile), social media, text, fax, telex, whatever. Makes sense? Please shout out if you don't think so

Now, into the technical depths of one of these scenarios

Take the mobile device, for example: that would probably be a client-server scenario where the mobile requests an Enterprise Function. For old phones that would be GPRS (offered by GSM) and for modern, WCDMA and HSDPA are offered by UMTS. Those are the physical networks these devices live in, yet doesn't mean they can't use transport protocols like FTP, HTTP, and so on.
So, at least 4 protocols there you can or even should support if you want to "go mobile", i.e. gain market share by embracing the mobile model.
So how about the syntax of "mobile messages"?
Well, anything goes really, doesn't it? What is the syntax Angry Birds uses, or Wordfeud, or Draw Something? You don't know, do you? What if you would love to tap into those mega-favourites?
The message is easy there: the supply isn't in your hands, yet the demand is, so you have to suit up

Basically, this is the lesson to learn for this post: all you Enterprise people who read it, used to the world being mostly blue or green: heads up! The world isn't mostly blue or green, never has been, and really is very reluctant about being treated as such - regardless of so-called architectures devised over a decade ago

Dear ERP people: you can't cover the world in your blanket, because the world does change. The larger your blanket gets, the harder it becomes to change it along with it, and especially: the longer it takes. Your time has come, don't you hear the bells ringing? Your customers do...