thingamy

Quo vadis SAP? - Sapphire 2008 # 2

My favourite takeaway from Berlin is in regard of their Business Process Platform. The basis for most SAP products.

A whiff of disagreement discerned, snippets of enthusiastic arguments heard - engaged voices for opposite views on this obvious core importance for SAP. I say bravo! Creative discords and passionate discussions is what pushed the world forwards:

One camp was adamant that the platform is mature and as such poised to become a platform for all things enterprise software - a black-box-back-end that no firm nor enterprise software vendor could do without. SAP still delivering front ends while inviting others to add their (vertical or not) apps on the top as well - true platform thinking with community included.

Another camp was convinced that the Process Platform is far from mature and should have much growth potential.

I like what I hear - and I agree heartily with both camps!

Based on today's architecture - transaction based - the BPP is mature. As I have many times suggested, transaction based architecture has met it's nemesis, complexity, and will not be able to grow past the types of processes - the easily repeatable process - that the platform handles with great aplomb today.

A perfect black box for all things easily repeatable which I could easily imagine as a "must" underneath all other enterprise software, following the path of databases - you do not see them but you certainly need them.

On the other hand if you look at it from the "run a business" value and do not bother about the technology, well, then I think the life of BPP (in whatever form it can become, not what it is) has only started.

Most work as measured in man-hours is collaborative, sometimes ad-hoc, sometimes quite structured - but as it's about creative work and involves people it's usually barely repeatable. The kind of business processes that consumes acres of time and people resources, being the core business process of health, government, consulting and many other businesses. Thus most probably a much larger market for enterprise software than the existing one (I would argue) while currently barely covered by the enterprise software vendors.

How SAP will solve the conundrum I do not know - but from the outside it seems slightly obvious that the existing BPP black box could be a wonderful "cash cow" and lock-up-the-market tool. The established platform for all to be on. Doable and making sense.

At the same time a new tack has to be undertaken given the large untapped market, but as could be expected from somebody (me that would be) who's been pestering his readers with claims that "transaction based" systems are doomed - I think they have to start over to create a new platform for value adding to the BRP area, a new and potential huge growth area.

The SI shift - Sapphire 2008 # 1

I'm so pleased to find that SAP at times agree wholeheartedly with me, OK, OK, granted that it's rather the other way around ;)

The business of System Integration is in for a dramatic and imminent change.

In fact I heard one SI top executive express with conviction (one-on-one, so certainly with more drama than otherwise allowed) that the current form would more or less cease to exist. The SAP'ies themselves were a bit more diplomatic, but still directly urging their SI partners to focus on a shift "up the value chain".

Just before going to Berlin and Sapphire 2008 I was building a draft run-your-business system for a potential customer, reading the requirements in my usual sceptical mode - then immediately shifting to a mode of business consulting using IT as a mere tool to model, real world test and implement.

And Thingamy is not alone in this - the current crop of systems from SAP increasingly boasts business oriented interfaces leaving the mundane IT stuff hidden. Selling, installing, implementing and even support is thus moving away from being IT centric to be a pure business issue. Already reports of sales to department heads and not CIOs could be heard and the expectation is clear: This trend will only become stronger.

This means that there will be a need for a different kind of partner, or a changed partner expertise makeup required for the new products beginning with BBD - business being the core. "Having 15 years of ERP experience will not be be the thing to have anymore" was mentioned.

What impresses me is that SAP have very clear ideas of the general trend while openly accepting that they're in a learning phase creating the path as they proceed - and involving their SI partners as well as they can. An "extreme business planning" approach after my heart.

But what about the Management Consultants? Any management consultants out there seeing the huge opportunity? If so, mail me as I've got some tools for you as well ;)

P.s. Again my thanks goes out to the kind people of SAP - Stacey Fish for once again looking after us in the best of ways and to Léo Apotheker, Pascal Brosset, Peter Zencke, Doug Merritt and many more for their openness and for not getting flustered by the impertinent questions from our little band of bloggers. We certainly enjoyed it a lot, and how could we not, those guys are definitely on the top of things!

SAP Sapphire - Berlin

Yet again my friends at SAP have graciously invited me to one of their huge get-together - aptly named Sapphire. So Sunday I'm off for a few days with notebook in hand.

I'm seriously obliged to our most efficient hosts, Mike and Stacey, as it gives me a huge opportunity to get under the hood of the industry and in particular of course, the leading player in the Enterprise Software field. And it's always a pleasure I might add. A real pleasure.

When arriving Mike and Stacey will have it all organised for us bloggers, of which many are fellow Enterprise Irregulars - the high point being when top management graciously joins us in "fire side chats" for free discourse. Not to forget roaming the halls and mingling with the all-knowing SDN and BPX folks! So Craig and Marilyn, watch out ;)

For me - such openness is a clear sign of a corporate self confidence not often seen!

As always I'll be having a few questions brewing, mostly big picture stuff as my fellow Enterprise Irregulars are amazingly good at unearthing the important tech and marketing questions du jour, so I'll leave that to their able minds. Just take a look at what Dennis, Brian, Charlie, Larry, Sandy, Vinnie, Dan, Susan, Maggie, Jevon, Mark, Josh, Jason C and Jason B wrote already about SAP following the Sapphire in Orlando.

Without saying too much I suspect I'll be poking around for the some answers to what I raised here. And some more.

[Addendum: Vinnie raised a pertinent question here, and Frank has a very good follow-up here. As always I have my own skewed interpretation of the situation (see my comment at Frank's post) that I will pursue in Berlin methinks.]

Will let you know if I make any sense of what I find, or rather the inverse, if my questions makes any sense!

Hitting the wall - the destiny of enterprise software.

A wall named complexity. Overly complex and utterly self-inflicted.

The problem is banal but hard to overcome; it's the wrong choice of modelling method.

That method, thanks to the gentlemen in Venice 514 years ago and ne'er questioned, makes the complexity 100 times, nay, 400 times more complex than reality pure.

In reality a widget is a widget. One object.

Add "distance management" of the widget in a widget producing or consuming organisation and the double-entry bookkeeping monster roars, requiring precise representation of each and every transaction.

Every order, every task, every move, every change of colour or bent ear - all must be properly documented, then entered into the books or system.

In that model each widget is represented by invoices, purchase orders, sales orders, work orders, bills of lading, journals and reports. The widget itself does not "exist". A paper based model that never knew of modern IT.

But it does not have to be like this, we have IT now. Let a singular data-object represent a singular real-object, then capture the what, who and when onto itself. Not "what" as defined by some GAAP, but rather the "what" as in reality - now moved to warehouse B, now painted blue.
Transactions and events can thus be gleaned from changes to relations and properties: A change of the relation "is owned by" is often what legally constitutes a sale or purchase, thus useful for a (P&L say) report. A change to the relation "is located in" is useful to produce inventory reports at any time and so forth without limits. (This is what thingamy does of course, straight reality modelling albeit slightly enhanced.)
Most important result - one data-object only per real-object, simple as in reality. A reality-model.

So, let's do a simple calculation: Say you have 20 objects to handle, 20 real world things and for simplicity, each goes through ten transactions or events. Then relate them all, objects and transactions/events criss-crossing the organisational fabric.

Thus the maximum number of relations* for the two modelling methods pans out to be:

Reality model: 380 relations.
Transaction / event based model: 39'800 relations.

An increase in complexity over real-world complexity of 10'374%. Or about 105 times more complex.

Now do 100 objects each represented by 20 documented transactions and you'll have 403 times the complexity, an increase of 40'203%. That's how to complicate things in an efficient manner!

Of course systems creating such complexity are big and... eh... complex. They have to handle the self-inflicted transaction and event-based complexity. Selber schuld, kein mitleid as the Germans would say.

Use the reality model and you'll have a system that could be 105 times... eh... 403 times... eh... "better"? It might even avoid the wall.

Or...

Reconcile 39'800 relations instead of 380, query ten times more objects.
Handle fully formatted objects instead of raw data and buy more CPU power.
Save thousands times more manipulated data and bloat your DB size and query times freely.
Create processes for modern world corporations following constraints designed in Venice 514 years ago. Duh.

What can I say?

I can say one thing; forget about tweaking the current systems, you'll have to start over again. A car does not become an aeroplane by adding decals on the doors (SaaS anyone?).

* [n!/k!(n-k)!] where k=2 and relations are not symmetrical thus total is twice the number.