SAPPHIRE Now - huge surprise, good stuff and a couple of important issues

I have to admit I went to Orlando and this year's SAPPHIRE Now with lower than normal expectations.

Boy was I surprised, and in a good way.

Overall I found a turbocharged and far, far nimbler SAP. To the extent agile that our freshly printed meeting agendas sometimes had the executive descriptions wrong. New units, new responsibilities, new groups emerging on the fly - like the day before. I promptly gave up understanding the intricacies of their hierarchies and went with the flow and what people actually were up to.

It even seemed to me that the people had the same attitude, the "heck let's do this and bugger the old structure" confidence. And for sure, Vishal Sikka, Jim Hagemann Snabe and Bill McDermott all displayed an assured poise I haven't seen before among SAP top executives. All well supported by a fun loving, iPad toting Professor Plattner roaming the halls.

[Cartoon by the ever great Hugh "Gapingvoid" MacLeod of course]

I am the archetypical sceptic, but on the grand scale my hope for SAP long term got a huge boost. And I still like them a lot.

Now to the first disclaimer; SAP graciously paid for my trip and lodging and the ever efficient Mike Prosceno and Stacey Fish had it all in their able hands making our stay a great pleasure. Not to forget the ever helpful and good friends at SAP like Marilyn Pratt, Ann Rosenberg and many, many more.

My second disclaimer is that I'm creating software that I once declared was "not meant to compete with SAP, rather to make SAP irrelevant" - which now has grown to become a "development and run time platform" to allow the likes of SAP to make their old technology and concepts irrelevant instead. This obviously adds quite a bit of tint to the glasses I'm wearing, so read accordingly. But notably; our interests are aligned overall.

From that point of view, certain news made me happy, even if the results are not yet in:

Jim Hagemann Snabe clearly stated that their "old stack" would be challenged and that they will work with partners to create a future stack. This is a very radical shift, only six months ago any new idea or concept was seen through the filter of "how can this be added to our existing stack?".

That "on demand" is a clear and important part of the overall strategy is another issue that pleases me. And it's more important to SAP I think than merely new deployment mechanisms, it will touch the whole organisation and speed up the shift towards new stacks as well. Now we're talking about products beyond the suite; Business by Design, definitely an extremely promising product but still born by the old beast. The will to see "on demand" as something more than extensions and add-ons could be gleaned from new (and generous?) funding made available as well as separate organisational groups, all good in my view.

With "on demand", even for stodgy Enterprises, things change by force of nature: Transparency and speed are the new factors - long term, waterfall and cards-close-to-chest is dead, costly products devised by committees is a non-starter. SAP is now entering, for a part of their portfolio, the world of Google and others where new products are picked up, thrown at the wall - if it sticks fine, if not, redo and rethink or try another. Of course with more solidness than what Google and others might get away with, SAP still has a brand and mission critical type of use to look after.

An interesting aspect of that is that the notion of "success" changes as well: If a four-years-in-the-making product from SAP of yore fell flat on the face it would be an unmitigated disaster and taint the brand, hence cards-close-to-chest. In the world of try early, fail fast nobody bothers and it's seen as brawny - and innovative in fact. So SAP, please stop defending new products in that area, listen, retry and go about life with your head held high. (Could point to a certain recent product that is well executed, nice looking but has many puzzled as to what it is - name withheld but for those in know; it had three names so far..;)

Now they will need more than a new attitude and agile organisations, they will certainly need new and different technologies if they are to "throw a bi-weekly product or two" onto the market to see if they stick. (Here my own interest comes into play, our platform is built for that of course. If they say they are "Real" real time I will say we are "Agile" agile).

Despite all the new and great I found there are still a couple of issues I would raise again, now with a much higher hope they will actually do something about these (both definitely seen through my tinted glasses):


1. Still no reaction to a huge potential market and opportunity they're missing out on.

Two and a half years ago I wrote a post after attending their "Influencer's Summit" in Boston: "SAP missing the biggest opportunity ever". As most of my readers know it's about the ERP vs BRP market.

Now, 30 months later the BRP (Barely Repeatable Process) market is as big (twice that of ERP (Easily Repeatable Process)) and still utterly virgin as to lack of process based IT support while having a huge upside value-wise for the customer (2/3rd of resources spent in BRP is on manually driving the process and not on value creation). And of course the ERP market is as well covered, very competitive, utterly mature and even more incremental value-wise for the customer.

SAP has killed the old sacred cow of all-growth-from-incremental-add-ons, and they want to double their (stated goal) addressable market: Hence they will need to find a new and virgin market involving existing customers and know-how - and here it is, named BRP.

The first signs that SAP is slowly eying the BRP market can be seen in the launch of products like Streamwork. Too bad though that their first stab do not have process as the core (still only DIY manual process) - dear SAP, please make note of the P in BRP!

If they took BRP seriously, with a P; not only would they have their doubling (actually they could triple it) of the addressable market, they would also be the dominating first mover. But of course it requires some challenging of old assumptions and a dab of new technologies, but they know where to find me (sorry, see my second disclaimer above), BRP is our forte.

So I'm going to repeat it: Do it, and do it now.


2. A missing ingredient in their grand (and otherwise good) In Memory DBMS strategy.

First out I must say there is nothing to dislike about in-memory and columnar DBMS, I liked that since Shai Agassi's days and the term "accelerator", partly coloured by the fact that our DB always was in-memory.

My issue is that their focus is merely on the BMS part of the DBMS; the way they handle the data. They forgot something: The first letter, I always like to start with the first part, the underlying part as that often leads to better solutions - the D in this case.

Nobody challenged the D, or rather "what is the data, why is it in the form it is?". Which inevitably would lead to the architecture of the main applications where such is set and the data is created.

If they had asked me I would have said the following: The format of data today is a model by itself based on old technologies and is not a direct model of reality, specifically, I have these two issues to raise:

a) No split of representation and presentation is bad:

This made sense when you had a correspondent at the battle of Bulge that used pen and paper to represent the ongoing in the same format that it was going to be used for presentation later.

That is the principle of forms and documents and most of the business objects in ABAP: Each data object often representing many real world objects in one go; a letter representing you, your house, the bank, it's office building, the account and so forth. And you know what the complexity brings: Last time you moved, how many letters did you have to send to update you address change? One single object representing your house, then related to you as another singular object, you then related to the bank account and so forth. Change the relationship between you and your old house to the new house once and all is fine.

Split representation and presentation and the data volume falls dramatically, combine the singular objects at will when you need presentation and not only do you get a huge boost to reporting depth and ease but the overall complexity shrinks dramatically.

b) Multiple indirect representations - should be direct representation:

A result of double entry book keeping, a never challenged 515 year old paper based technology.

A widget in today's system is indirectly represented by a multitude of invoices, shipping papers, reports etc. A singular direct representation of objects that is timestamped using relations can deliver the accounting reports with far higher reporting depth, far less objects and no reconciliation issues.

A system holding 200 objects each indirectly represented by 20 objects would be 40,000 times more complex than a system as described above (our stuff is like that).

Then a speed increase of 10,000 as claimed by the in-memory becomes small potatoes.

I am not saying this is attainable overnight, quite the opposite, it would need a long term transformation of the underlying models before it spills over into the DBMS. The In Memory DBMS path is good, but I'm saying that it could have been so much better if SAP had spent (or will start spending) time to challenge the D part of the DBMS.

All in all a most enjoyable SAPPHIRE Now, with much to applaud and lots of reasons why my last few quibbles will soon be addressed I'm sure. Thanks again to SAP for putting up with me!

Bonus point: If anybody was sceptical about iPad being a potential enterprise tool; a day or two at SAPPHIRE would have killed that scepticism. Professor Plattner used it in the keynote demo, enterprise suits of all ages could be seen toting only iPads instead of laptops (perhaps first chance to get away from Dells/HPs with Windows on?) and all trade booths raffled out iPads to anybody showing any interest in their wares. Except Microsoft of course, who raffled out a Zune... and the only guy who signed up for that won it I think... :)

Comments

[Alexander Ainslie (@AAinslie)]

Thought provoking.

Reading 2. a) & b) in the context of 'P' leads me to think that there is valuable use in your thinking and proposed new process paradigm in the defense/homeland security spheres. Perhaps this channel could be a source of solid, scalable and bankable revenue for Thingamy.

Disclaimer: the above comments should be filtered for relativity and validity through 2.5 glasses of very good Medoc, preferable consumed on a Friday evening in Paris - as I have.

[sig]

Alexander,

absolutely, the combination is a must - in my view a more direct model of reality and hence a gain for any user of any kind.

Using semantics (subject, predicator, object) to add "knowledge" precisely as Plato defined it adds reporting depth and object navigation that should please the users you mentioned.

And the fluid filtering mechanism you use, can only be supported heartily, one of the sensible habits of "old Europe" that adds to the whole ;)