SAP meets Cloud: something needs to vaporise first

[Photo by John Kerstholt]

I have been comfortably following SAP Influencer Summit 2011 from my chair, and reading up on the various posts and vids released throughout the process. It won't surprise anyone that yesterday's keywords were cloud, ByD, business, SAPonDemand and sales - thank you, you 350 participants who produced 1,500 tweets during the last day

Many people ask the question: with such a traditional on-premise company, will these extremes form a perfect match that complements and makes for combined strength, or will it just be a very unhappy marriage?

In short: if nothing changes, the latter. The picture above is a type of arcus cloud called Shelf Cloud. So that is how that latter will look like (LOL)

Right, back to business. Of course Cloud is an excellent business opportunity for SAP. As long as I can remember, customers have been complaining about the lack of timely business innovation from SAP. "We've been waiting for this module for almost three years now!" is something you don't like to hear regardless of which department you come from.
Yes, SAP is a monstrous 8-legged mammoth if you consider the whole picture and that is its strength and, as usual, also its weakness. If you've worked in enterprise IT for 5 years or longer you know that repairs have to be made while the factory is running at full throttle: the bigger the factory, the more cumbersome this is

Trying to fit together new pieces while replacing some of the old, all in full flight, gets more difficult when the size of the object increases. In fact, SAP's recent failure to update SAP's Community Network reminded me of that once again. When I look at all the new parts that have been joined to SAP recently, I see that some of them get replaced even before bolted on

SAP's acquisition of SuccessFactors is a good example of this: it is, in Dennis Howlett's words, an addition that totals the count to five different human resource management architectures - there's a bit of a waste somewhere there, if you ask me. As such, this is not the first acquisition SAP has made nor will it be the last, so maybe it's time to adapt the software stack to the "strategy stack"

Cloud to me means SaaS in this matter. Cloud will be extremely interesting for SAP, especially in the first years, as the greenfield aspect will allow for very quick development and deployment of new business-critical innovation at a thus unknown time-to-market: weeks, many even days at some extremes. The old 3-year wait is out the window for the next decade to come. After that, "SAP Cloud" will probably have wrapped itself in a bit of legacy just as Salesforce.com found itself after 10 years with the development of Chatter, and business development that was first measured in terms of years and then in weeks, will settle at months again - unless, unless...

Let's call that the Ghost of Christmas future in Scrooge fashion - we wouldn't want that to happen. Well the first part we would, but not the second part. Having said that and while talking about legacy in the first place, how on earth is SAP on-premise not going to collide and crash with off-premise?
My biased answer of course is Integration - with a capital I. The TIBCO announcement was about a cooperation between SAP and TIBCO with regards to BI and 3D visualisation of that and focused on tibbr. No mention of old-fashioned middleware so far

I would love to see TIBCO partner with SAP in the field of Integration / middleware / EDI you name it. I would dread SAP buying TIBCO and calling the shots as that wouldn't bring out the necessary change: only long-lasting relationships force you to compromise and "meet in the middle", and SAP needs to radically do so if it wants to successfully meet the many challenges it has engaged

There have been talks, discussions and debates about SAP's layers as long as I can remember. I'm talking about traditional OSI-layers here but their amount and content varies. The rise and shine of architecture as an IT profession has somehow caused a continuous shift in layers that seems to have no end, but certainly no goal that I can understand.
At some point I saw an SAP architect proudly present his 9-layer SAP architecture model and I just broke down and cried.
Last year or so they seemed to be back again at a sensible 3 (Data, Application and Presentation) but ever since the introduction of Layer Scalable Architecture seemingly everyone wants to add a new layer every month. Currently LSA is at 7 layers and this foolishness just has to stop. Having an e.g. Quality and Harmonization Layer just means that you're scribbling and screwing around - excuse my French

So, after this long introduction, what is the solution? Simplicity. Extreme simplicity. Back to 3 layers: input, throughput, output, or rather Presentation, Application, and Data. Or keyboard, computer, disk.
That application is a big BLOB in the case of on-premise, and shattergun-like bits and bytes for off-premise. The SaaS services can operate on your on-premise data in real-time, or you can synchronise SaaS data with on-premise on a daily basis, or anything in between.
You can portal-in the SaaS presentation into your on-premise, but to be fair no one's even talking about that anymore. Con-fusing presentation is way too complicated and costly and reinforces the old rule: the closer to the customer / human, the more dynamic, complex, flexible and exception-rich a solution needs to be

That is how I envision a future for SAP: radically simplifying its on-premise software stack and architectural approach, and in stead of adding architectural layers for components that don't perform or fit nicely, solve the problems where they arise. If you can't: take your losses and boot the parts that can't be fitted.
I see enterprises use SAP on-premise for say 60% and off-premise for up to 30% if they play this nicely. Those are just suggestimations but indicate that the (lack of) dynamics of an on-premise monolith just adhere to physics: it serves static, boring, rigid stuff full of rules that hardly ever (= never) change.
The sexy and shiney stuff, on the other hand, must be met with nimble services that simply dance around dynamic, exciting, flexible requirements that change every proverbial day.
And both need to share common ground: in the data layer

You and I see this every day: sea containers being shipped via ocean steamers, letters shipped via mail bags, passengers shipped via huge planes, trains and automobiles (buses): you can supersize what doesn't need to be flexible, but what does need to, must be small. Many, many times smaller - so it can travel freely, anywhere across the globe