SAP, Integration and Star Trek: the future is now

I commented ranted on an SDN post yesterday. Submitting it failed, and I lost the +/- 500 words. A bit more miffed after that, I wrote the comment anew in Notepad, and copy/pasted that - it worked.
I got a few reactions, some of which inviting me to post on the topic on SDN via a blog post in stead of just a (lengthy) comment. While I appreciate the invite, I'll just do it here for now

Let me explain about Integration first. I'll keep it short, but if you like the long version, there's my free eBook on Enterprise Integration

Enterprise Application Integration is about getting information from one container into another, across frontiers of time and space. As Star-Treky as this may sound, it is much simpler and involves a lot less Tech, if any - but the journey is equally exciting. I have been practising Integration for over 15 years now and call me a bore but I would love to do it for yet another 15 years, and then some

The starship Enterprise has as a mission "to boldly go where no man has gone before" - and that is exactly the goal to have in mind. Integration is a necessary evil, and a means at best: certainly not a goal

The starship Enterprise (Enterprise from now on, not to be confused with my usual word for fat-bottomed multinationals, thank you) is a vessel, which can carry people, packages, other spaceships, fighters, humans and droids or androids alike: it can encompass pretty much everything.
In Integration terms, the Enterprise is the envelope that can carry messages and their cargo. All kinds of messages: old-fashioned, current, brand-new, and even unknown. EDIFACT, X12, SWIFT, SEPA, HL7, XML, JSON, CSV, flat file - some of these are related, similar or even identical; but the Envelope can carry them all.
This Envelope makes everything transparent for headquarters: they just deal with the many starships there are, and address them in a uniform way, because they are uniform. This way, the universal diversity that lies underneath is hidden to the business. Headquarters simply exchanges business information between itself and the starships, and that's the end to that

The Enterprise can also transport all these messages in various ways: of course it can transport itself in its entirety, at various speeds: regular speed, light-speed, warp 1 through 10, you name it.
Next to that, it can deploy messages by the hundreds, dozen, or even per person: it can use other carriers for that, beam people and cargo up and down, and even separate itself from its core.
In Integration terms, the Enterprise can support high-volume to low-volume, and high-speed to low speed. It is capable of batch and event-driven alike, regardless of transport protocols.
There are certain limits to each means of transportation, of course - but there's a best approach and one or more alternatives to any of them

The Enterprise has the bridge, or central command, that logs and monitors each and every movement: nothing goes unnoticed or untraced. All information comes together here, and is handled as uniform events, no matter what they are. Decisions can be made that will trigger other events, and if we conveniently ignore the fact that all the tough decisions that make an episode exciting are 100% exceptions, there is a mega "iceberg" below the bridge that handles all the rules.
In Integration terms, the Enterprise can support Business Process Management (done below the bridge out of sight) as well as Complex Event Processing (done on the bridge). All in all, it's an Event Driven Architecture that allows for both branches

So, there we have it: the uniform business-envelope supports all messages, all transport protocols, and central monitoring and logging. By doing so, it allows for handling rules (BPM) as well as exceptions (CEP) and errors

This is what Integration is all about: getting information from A to B across frontiers of time and space. Everything else isn't about Integration:

• XML? Limiting the Enterprise to only carry humans, or droids, or cargo - you'd have to build three separate Enterprises to allow for only these three types of passengers
• SOAP? Limiting the Enterprise to only beam up and down, in between planets that support it
• REST? Forcing the Enterprise to beam down to places that support it, and beam up from other ones that only support beaming up
• Web services? UDDI? xBPELx? Guess what...

What has SAP's integration strategy been so far? Not building an Enterprise, that's for sure.
Netweaver facilitated building carriers and fighters at best. XI was a carrier, but couldn't carry cargo, only lifeforms: it had no support for the most widely used B2B standards, it supported XML or flat file at best. PI was a little bit better, or should I say less bad, but converts life-forms to cargo and vice-versa under the hood (it's entirely XML-based)

Is this future-proof? Hell no - it's not even present-proof, or past-proof for that matter. Any-to-any is the base requirement: support of any message kind, any transportation means, and transformation of any message to any other message, respectively transportation means.
Like I said in my comment: apparently there hasn't been a need for SAP to develop such an Enterprise scale platform. However, if you look at how SAP's revenue and profit has evolved over the last 7 years, you'll see that revenue per employee hasn't grown, whereas profit has taken a 20% nose-dive

This next decade (and these past few years have already shown a few signs) will give SaaS an increasing piece of the enterprise software pie. Social will come in sideways, taking another bite. Mobile will continue to create applications at the speed of light, and real-time time-to-market will finally become business as usual - if IT can keep up. What does that mean? An end to adopt, and a beginning of adapt. Survival comes to those who can adapt, business opportunities will be harvested by those who can manage them.
All different types and kinds of humanoids, cargo, carriers and teleportations will come to life. And it will all happen at warp 11+

Is it time for a cunning plan for SAP? I most certainly think so. Would e.g. TIBCO-like Integration capabilities enable them to take on this decade and next? Oh yeah, definitely. Does that mean they should they buy TIBCO? Most definitely not - that will merely repeat the Oracle-BEA scenario