SAP Goes to SAPPHIRE 2017, part I

Part of the fun and challenge of following SAP is that its present and future are defined by the intersection of its own peculiarities and the peculiarities of the markets it lives in. This interplay means that SAP, like many large software companies, isn’t just a single company with a single overarching strategy: it’s really many companies with many strategies. The trick for SAP is to make sure they overlap more than they contradict each other.

SAP is kicking off SAPPHIRE next week – its annual May user conference held in conjunction with the ASUG user group’s Annual Conference – with an interesting mix of overlap and contradictions at play. It’s a cloud company that has to play to an on-premise user base and a platform company that is striving to be relevant in an increasingly crowded platform market. It’s the guardian of a 30-year legacy of industry-specific business process leadership trying to understand what these processes look like in the context of digital transformation at the edge of the enterprise. And it’s a leading-edge technology company looking to differentiate what being on the leading edge with SAP really means.

SAP is hardly alone in this regard, and not just because its competitors from the legacy days are facing a pretty identical set of challenges. This is also because its customers – ASUG members and non-members alike – are struggling with a reverse image of the same set of problems. There are some big issues on the table for customers surrounding digital transformation and all that entails (which sometimes seems as though it comprises everything and anything new and different.) And if digital transformation is the answer du jour, then the question boils down to understanding where the technology to enable a company to digitally transform –platform, development environment, interfaces to data from all over the universe, APIs for IoT, ML, AI, and the like — will come from.

Here’s the trick for SAP (and the rest of the market): If SAP’s customers, and its prospects, can be enticed to respond with “SAP” every time a tech decision involving some aspect of anything remotely smelling like digital transformation takes place, all will be right with the world and SAP’s stock price. If those reflexes are tuned to respond with some other vendor’s products, there’s going to be trouble.

To refine this dilemma more clearly: digital transformation for an existing company requires two phases, transition and then transformation. Transition involves the necessary upgrade to go from 20th century on-premise (and UX challenged) IT systems to 21st century, largely cloud-based systems. Transition, particularly to the cloud, is what started big time in 2016 as issues like security and privacy drove companies large and small to embrace the cloud and the vendor-managed security that it provides. It’s sort of Y2K all over again: While Y2K was bogus, digital transformation is or will soon be very real, and the effect is similar in terms of the ensuing market-wide upgrade.

Transition to the cloud presents a problem, however, when it comes to setting the stage for fulfilling those vague digital transformation mandates: cloud means “fit to standard”, which means no more customization, which means that if technology is put to use providing unique competitive advantage – which is what the transformation phase is about –  it’s going to have to be built on the “edges” of the newly transitioned cloud back office.

Transition, however widespread it is, has become problematic for incumbent vendors, SAP among many others. The reason is that SAP has enough customers running older versions of SAP ERP with enough customizations that, for some, their transitions are no longer upgrades, they’re full-blown implementations. That’s problematic for incumbents: if a company has to effectively reimplement to transition, then maybe it’s worth looking into changing back office vendors the way Seibel CRM customers jumped ship when CRM went to the cloud with Salesforce.com. So much for incumbency.

But, leaving aside the panic-inducing thought that all this talk about digital transformation is forcing customers to think about changing vendors, the even bigger issue comes when a company is done transitioning, or at least setting it in motion, and wants to start the actual digital transformation process. Because, as if things weren’t complicated enough, when a company starts to move to transform and build those killer edge apps that strategically differentiate the company, SAP’s path to glory starts getting muddier.

Mudpuddle number one is that SAP has never been the exclusive enterprise provider for the majority of its customers, and all those other non-SAP enterprise systems are in a forced transition too. This means that any given SAP customer of any size and longevity is also transitioning the non-SAP parts of the company to other cloud  products, each replete with a platform, dev environment, and interfaces to all the cool ML/AI/IoT stuff that transformation is supposed to be all about. Result: platform proliferation.

Mudpuddle number two: In addition to platforms for non-SAP software, SAP now runs or will soon run on four non-SAP platforms, Amazon’s AWS, Microsoft’s Azure, Google’s Google Cloud, and IBM’s Softlayer (Softlayer? Sounds like a fancy mattress cover to me. Considering how it stacks up against the others, it might as well be.)  This means that each of these cloud vendors’ non-SAP “stuff” is available to the SAP crowd, and a good part of that “stuff” is the “stuff” SAP expects its customers to use to build those edge apps. Result: platform conflict in the cloud.

Mudpuddle number three is that the core ingredients for creating and staging the next generation of software, be it “packaged” or custom developed, are becoming commodities before the market opportunity has even begun to move from POC to massive enterprise-wide investments. IoT is the best example of this: GE started down the IoT road with Predix in 2013, basically trying to boil an ocean that had no water in it. Now that there’s a trickle of IoT projects seeing the light of day, IoT as a platform has become a commodity such that at this point in 2017, IoT is a checklist item on comparison tools like the Rightscale one in the link above. Result: questions about the revenue stream from edge-enabling technologies abound.

Final, deepest, and messiest mudpuddle: the emerging influence of the line of business developer. While each vendor has their particular advantages, and SAP is chock full of them, all this cloud/platform/dev tools/API stuff has changed an important dynamic, to the detriment of traditional incumbent vendors like SAP. At a crucial moment in the market when edge app development efforts are small, largely tactical undertakings, as opposed to large, enterprise-wide undertaking that readily translate into big sales, the line of business manager or developer now has the decision-making power and the tools to take the lead on these edge projects. Most of the competing platforms have heavily promoted so-called “citizen developer” tools – SAP has its own, called Build – and while I firmly believe that the citizen developer market is somewhat mythological, these tools give LOB managers much more freedom in terms of how they develop apps and how much IT resources need to be commandeered to do so.

Needless to say, having the LOB in charge isn’t necessarily good for incumbent “legacy” vendors – the LOB folks lack the brand loyalty that IT has cherished in regard to its incumbent ERP systems – even if those vendors are successfully transitioning older back-office systems to their new cloud+platform offerings.

For SAP, this confluence of non-SAP app upgrades and platforms, the commoditization of “edge” technology, and rise of the LOB developer is threatening to rain on the quarterly successes that SAP has been reporting to Wall Street and its partner ecosystem.

And therein lies a tale.

Which, because this post is already too long, will be continued shortly.

Leave a Reply

Your email address will not be published. Required fields are marked *