Microsoft Dynamics Who? Microsoft Pioneers a New Category: MIA Software

Microsoft is emerging as a potent force in the enterprise software market, propelled by Azure and the success of Office 365. The former provides a comprehensive cloud platform and set of services that are, as a platform for enterprise software, second to none. The latter provides an amazing productivity platform and set of services that spans a broad swath of the day to day requirements of today’s business user. And, for what it does, is also second to none.

That’s the stuff Microsoft likes to shout from the rooftops, and deservedly so. What they’re strangely quiet about is the fact that they also have market leading ERP and CRM software products that are right up there with the best of the best. At a moment in the market when public cloud offerings for enterprise software are hot, and the original offerings from leaders like Netsuite and are looking a little long in the tooth, there’s a deafening silence around Microsoft’s Dynamics product line – the mellifluously named Dynamics 365 for Operations, Dynamics 365 for Sales, and the other Dynamics products that have a legitimate shot at market leadership.

The omission isn’t just curious, it’s also tragic. Microsoft’s inability to promote of a solid set of enterprise software is a disservice to its customers and a larger enterprise software market that only gets better by increasing the choices customers can make.

Why is Microsoft so quiet about what should be a major set of assets in the highly competitive and fast-growing cloud ERP market? There’s a clue to be had in the checkered history of Microsoft’s enterprise software aspirations, starting with the acquisition of Great Plains in 2001. Since that first acquisition, and the subsequent acquisitions of Navision and Axapta, Microsoft’s senior execs kept looking at the paltry revenue and margins that these products could command relative to Windows and Office and for a long time basically shunned what later became the Dynamics product line.

That benign neglect was severe enough that there were many times when Dynamics execs confided in me that they might be better off being spun out and run as an independent company or sold to a larger enterprise software vendor. This second-class status was the norm pretty much until Kirill Tatarinov was promoted in 2007 to run the show, whereupon Dynamics began to come into its own. Even through a couple of reorgs that threatened to repeat the past pattern of  neglect, Kirill was able to keep the Dynamics flag flying.

But Kirill left two years ago as part of another reorg that put Dynamics’ fate in the hands of EVP Scott Guthrie, and that’s basically when the silent treatment began.

I don’t blame Guthrie for what looks like that same old indifference, he clearly has other and more lucrative fish to fry, such as Azure and Office 365, the latter of which now has 100 million enterprise users (which begs the question of what very large percent of the global economy runs in part on the Office 365 family – I’m sure the answer would give Microsoft some serious bragging rights.).

More importantly, however, I’m not so sure Guthrie really gets enterprise software in all its complexity and glory. Or maybe he just doesn’t get why Dynamics is that important to Microsoft. Perhaps, just like in the olden days after the Great Plains acquisition, Guthrie’s indifference may be a rehash of an historical perception at Microsoft regarding Dynamics’ limited value to the company.

Regardless, any and all scenarios that marginalize Dynamics are basically a damn shame. And it’s a shame that Dynamics has been placed in the cone of silence – no more conferences, no more analyst events, no more regular briefings – and not just because I’m an admitted enterprise software bigot who likes a dynamic (pun intended) market full of great products pushing the envelope on behalf of customers. It’s a shame simply because I think Microsoft and Guthrie are shooting themselves in the foot in the middle of a very fast and competitive race for a key enterprise software platform prize.

The prize? Leadership in the next generation public ERP cloud, the one that puts classic backoffice ERP into the cloud, straps it to a comprehensive platform full of innovation services (as in the ubiquitous trio of IoT, AI and ML, as well as microservices, etc. etc.), and leads the global economy to the promised age of digital transformation. That one.

But instead of putting Dynamics into the sweepstakes, Microsoft keeps shooting Dynamics in the foot. The latest example of friendly fire came at the Microsoft Build developers conference last month. I’ve been writing a lot about how developer outreach is the new imperative for enterprise software vendors who want to play in the cloud platform business, and I went to Build to take the measure of Microsoft’s latest efforts in this regard. The basic issue is that platform providers need developers who reflexively use their tools, services, and platforms to build those cool new apps that will transform the business world. And historically, Microsoft has done this better than most: witness the fact that Build is one of the larger –if not the largest – pure developer conferences in the industry, and Microsoft’s legions of developers are the envy of the enterprise software market.

The focus at Build on what Microsoft touts as the “intelligent cloud” and the “intelligent edge” did a great job of solidifying what I see as a true leadership position in enterprise cloud platforms. This is particularly true with respect to Amazon and Google, but also more specifically with respect to companies like SAP and, which aspire to be cloud platforms but are basically leading with their apps, not their platforms.

As such, Build was a showcase for all the cool stuff you’d expect as well as a lot of cool stuff that you might not expect, such as what happens when Microsoft pairs the graph API from Office with its newly acquired LinkedIn APIs, or how well Cortana can do live simultaneous human language translation, or Hololens, which is truly in a category of coolness all by itself.

But while Microsoft did a great job of showing off these and other components of its developer toybox/toolkit, by the end of analyst briefing sessions the day before the official start of Build I realized that, at least when it came to talking to the analysts, Dynamics wasn’t part of the developer story. The irony of this is a little mind-boggling when you think that every enterprise software vendor other than Microsoft would give up a body part or two to be able to address the Build audience and show off what their enterprise products and toolkits could do when married to Microsoft Azure APIs, the Office/LinkedIn graph, Cortana’s natural language processing, Hololens, and pretty much everything else under the hood in Redmond.

In other words, while companies like SAP and can only dream of the day when they have a developer audience of the size and scope that Microsoft can command, Microsoft is squandering a huge opportunity to use its developer network to do with Dynamics what Salesforce and SAP wish they could do with their cloud enterprise software offerings.

Like I said, I’m not sure how well the cloud enterprise software opportunity is even understood at Microsoft. As an example, I asked Scott Guthrie during an analyst Q&A session what role he saw Azure and its Lifecycle Services ALM tool playing in a multi-platform, multi-cloud, multi-cloud app world. This wasn’t meant as a gotcha, it was actually more of a friendly lob: helping customers navigate cloud “sprawl” is a top of mind issue in enterprise software, and if you ask Amazon’s SAP team this question – which I did recently – they have a lot to say about their plans to support the integration and orchestration of different vendor apps across their cloud. After all, Amazon runs SAP and Salesforce and Workday and pretty much any vendor app that needs a public cloud provider.

Just imagine if you build a custom process that spanned two different cloud properties – a CRM and an ERP product, for instance – and your cloud provider managed the full lifecycle of the process, helped manage the integration and orchestration, and made sure that the process was immunized against the different upgrade schedules of the cloud properties. And that vendor had some great IoT APIs, and serious support for predictive modeling and data visualization. Wouldn’t that be nice?

Unfortunately, Guthrie’s answer came off like a punt that sailed out of bounds. The way he launched into something about running Linux VMs and Cloud Foundry on Azure made me wonder if I hadn’t articulated the question well enough. Maybe, or maybe not. To the right audience, the question wouldn’t be halfway out of my mouth before it was being finished for me: If I was in a room full of enterprise software customers of any decent size, or the enterprise software vendors themselves, this question would have been instantly recognized as the big question in the enterprise as the move to the cloud broadens and customers are forced to confront the extreme heterogeneity in their cloud portfolios.

(Ironically, or maybe not, Kirill Tartarinov, now the CEO of Citrix, and his exec team spent a great deal of time discussing this very issue at Citrix’s Synergy user conference last month. They made the most of the term “cloud sprawl”, and their solutions to the problem, centered around their Secure Digital Workspace and Software-Defined Perimeter, were spot on. The Synergy crowd ate it up.)

So where does this “deafening silence” leave Dynamics? Right now they’re deep in the damn shame category of technology marketing. I had the opportunity to meet with their CRM head, Jujhar Singh, at a CRM conference in April. In presentations to a small group of analysts, and then later at dinner, the message that Dynamics CRM had made some extraordinarily huge functional leaps came in loud and clear. The upshot of the 30 minutes we analysts had with Jujhar was that 30 minutes wasn’t enough time to be begin to touch on all the cool new stuff, and the consensus around the room was that the cone of silence was a huge lost opportunity for Dynamics.

This is true across the product line: at this point it’s becoming hard to recommend or even pass judgement on such a stealthy product line, and from where I stand this is keeping Dynamics out of a deal flow that by rights it should be deep in the mix of. Whether it’s a question of showing off the next gen enterprise software process flows that can be enabled by combining Dynamics, Office, Azure, and the rest of the stack, or simply competing head to head in the public cloud market against the likes of SAP, Oracle,, or Financial Force, Dynamics is increasingly showing its unfortunate leadership in special category of enterprise software that can best be described as MIA, for missing in action.

There was a time when Dynamics was recognized internally for its ability to be the staging ground for the rest of Microsoft’s technology: if you wanted to see what the full complement of Microsoft’s  desktop, cloud, infrastructure and systems software could do, all you had to do is find a decent-sized Dynamics ERP customer. It gave Dynamics a lot of internal cred, and that cred allowed Dynamics to have a seat at the Microsoft table as a legitimate division worthy of some mention.

Apparently that cred is gone, and with no senior exec actively advocating for Dynamics, a market leading product set is left to languish. There’s not a lot of precedent for success with this model of MIA marketing, and, for the sake of the customers and the Microsoft employees who still bleed for Dynamics, the company should get back on the road and start talking about Dynamics again. Or sell it before missing in action morphs into irrelevance or, worse, DOA. As in dead on arrival.

The Fog of Innovation Marketing: SAP Obscures S/4 HANA’s True Competitive Advantage

If you walked away from SAP’s recent SAPPHIRE event scratching your head about which version of S/4 HANA your company should deploy, you’re not alone. There seems to be a fair amount of confusion about the differences between S/4 HANA On-premise/Private Cloud and S/4 HANA Public Cloud. And  that confusion threatens to derail the growing momentum around the company’s flagship cloud products.

The problem is that SAP is trying to get S/4 HANA Cloud to punch above its weight class by claiming it can meet the needs of a large enterprise, and in the process the company is setting the stage for some serious customer confusion about which version of S/4 HANA is the right one for the job. The irony of these efforts is that in sowing this confusion SAP fails to see that the very thing they’re trying to hide by overselling S/4 HANA Cloud is the very thing that actually imbues the overall S/4 HANA product line with the exact attributes that customers need.

Unfortunately, SAP only has itself to blame for the confusion. The official messaging, to be perfectly honest, seems designed to obfuscate rather than enlighten. I had to go three rounds with SAP to get the story straight, and at times it felt like I was deposing a reluctant witness, rather than having a forthright conversation about what will always be a complicated decision for SAP’s customers.

Here’s the gist of the problem. SAP’s official storyline is that S/4 HANA Cloud is as well-suited to run a large, global enterprise as the on-premise and private cloud versions. This is due to the simple fact, SAP officially maintains, that the on-premise and private cloud  editions of S/4 HANA are built off the same code line as S/4 HANA Public Cloud, which means that a customer can chose either one for their upgrade or migration because they are functionally equivalent.

Those italicized words, however many times SAP executives repeat them – and they were repeated to me more than once  — won’t be true for quite a while, if ever. It’s kind of like saying that a Honda Fit is functionally equivalent to a Honda McClaren Formula 1 race car. Both have tires and engines and transmissions, etc., and both can transport you from here to there. But if you’re going compete on a Grand Prix track,  you might want to leave the Honda Fit at home. And if you’re trying to take your kids to the water park or need to hop to the grocery store for a gallon of milk, I’m pretty sure a carbon-fibre, 220 mph Formula 1 race car wouldn’t be the right choice.

Similarly, if you want to run a global company using a standardized set of business processes, S/4 HANA Cloud is your Honda Fit. But if you want to do something more – run an industry solution like Retail, or a fully-functional warehouse management system, or run the fully functional versions of GRC or GTS, for instance – you’re going to need that race car, and that means running S/4 HANA on-premise and either managing it yourself or having a service provider run it for you in a private cloud.

Notice the deliberate use of the words “fully functional.” Read this carefully: the public and private cloud editions are different, the scope of what they can offer is different, and there are very different deployment use cases depending on what your business goals are. The two products’ roadmaps promise a good deal of convergence in the coming years, and the similarities at some point may outweigh the differences. But it’s highly unlikely they will ever be functionally equivalent: the market demand for some industry solutions may never be big enough to move that part of the code line to the public cloud. We shall see.

What I’m baffled about is the thought that SAP thinks there’s something wrong with this kind of full disclosure. From where I sit this is a huge strategic advantage, particularly because of S/4 HANA’s secret weapon: code equivalence.  Both versions do spring from the same code line, which means that any of the “fit to standard” functionality that a customer deploys today in S/4 HANA Private Cloud can be moved, pretty much seamlessly, to S/4 HANA Public Cloud any time the customer wishes. Of course, the above bells and whistles like GRC or EWM – said facetiously: these are hugely important pieces of functionality for some of SAP’s biggest customers – might have to stay in private cloud mode. But, that’s what SAP Cloud Platform is for, right?

This ability to keep the strategically advantageous parts of the S/4 product line in a private cloud and  move the  rest of the company to a public cloud version while running a single code line is something one other company can do. Who? Well, it’s certainly not Oracle, which possesses one of the best examples of cloud code sprawl in the industry. And the rest of the major competitors are cloud-only companies, no private cloud options available.

Only Microsoft can do something similar, to the extent that the Azure Stack offering allows a company to run a complete version of Azure in a private cloud, meaning that its cloud ERP product, Dynamic 365 for Operations, can also run in said private cloud. But I’m not sure there would a business case for splitting a company into pure cloud and Azure Stack versions of Dynamics 365, certainly nothing similar to the mixed S/4 HANA scenario above.

A further advantage of the SAP approach is that a single code line means process equivalence. This means, for instance, that a new “fit to standard” business process in S/4 HANA, version whatever, could be stress-tested and perfected in one location – say in your offshore subsidiary – and then moved around to world to your other locations in a way that would vastly simplify the change management issues inherent in any new process change. Are these other entities running S/4 HANA on prem or in the cloud? Who cares? If it’s available as “fit to standard”, an identical configuration of the one you’ve created for one line of business can be deployed anywhere pretty much as-is.

In other words, SAP customers can separate the strategic decision to go with a migration or upgrade to the S/4 HANA family from the deployment question of cloud or on-premise, at least for a significant percent of their needs. Start with the real questions about managing the technical and business changes needed to thrive in the coming years, look carefully at what customizations need to move to the new platform, and then figure out what has to run where and how: Cloud vs on-premise, migration versus upgrade, cohabitation of ECC and S/4 HANA vs. HEC, etc. etc. If you’re like most large companies – and many smaller ones – you’re probably going to have to mix it up. Or maybe not. These are hard questions to answer, but they’re much easier to deal with once the more salient business and customization issues have been sorted out.

Ironically, underneath this functional equivalence stuff, SAP overall has pretty much has these goals in mind: Leading customers down a decision path that starts with “what do you want to accomplish” and leaving out the issues of which version can meet their functional needs until the time for such a decision is ripe. To help out, SAP has some pretty robust tools, such as S/4 HANA Readiness Check and the Transformation Navigator, both of which can help customers make careful choices dictated by their particular IT and business realities rather than blindly follow some overreaching marketeering that is clearly intended to push SAP’s cloud market status as much as possible, and to hell with the consequences.

If only SAP would stop pretending that all roads lead to S/4 HANA Cloud. SAP should instead embrace the strength and depth of its offerings and stop claiming that this diverse set of offerings is somehow functionally equivalent, before it gets into hot water with its customers. Pretty much every vendor/customer dispute can be boiled down a couple of simple problems, one of the most important of which is mismanaged expectations. Overselling, underdelivering, obfuscation, confusion – these are the paths to customer dissatisfaction and competitive disadvantage. In this case, this functional equivalence concept is made all the more useless by the fact that what SAP is trying to hide – a product line, based on a single code line, as diverse as the customers it’s trying to serve – just happens to be its biggest strength.

Just tell the truth, the whole truth, and nothing but the truth. It’s really that simple..

SAP Goes to SAPPHIRE 2017, part II

(We’re back, discoursing on the challenges SAP will face as platform proliferation and the shifting of the edge app issue into the hands of the LOB developer influences what vendor’s tools and platform will be used to power its customers’ digital transformations. Where we last left off, I was about to illustrate SAP’s dilemma with a true-to-life story.)


I recently had an experience that, in a nutshell, summarizes the gist of the SAP challenge. I was speaking with an LOB manager working at long-standing SAP customer with a field maintenance problem it needed to solve. The problem was a classic digital transformation story: transform how field maintenance is prioritized by trying to understand what the cost of having a particular asset offline for a particular period of time would actually be. If it turned out that there was no impact, maintenance could be delayed, saving a ton of unnecessary expense and resources. And if maintenance was needed online immediately, the decision to spend the extra time and effort in overtime or other costs could be well-justified.

This meant understanding everything about the asset as well as the demand side of the market in which the company operated. As you can imagine, in its ultimate form this is the ultimate edge app: take existing on-premise data about the asset (ERP data), add real-time operations data about the asset (IoT data), marry it to external market data (unstructured web data), get information about the availability of maintenance people (talent management data) and parts (warehouse management), and plug it into a model (based on AI/machine learning algorithms), and, voilà, you’ve digitally transformed asset maintenance.

Sounds like a Bill McDermott/Bernd Leukert/Rob Enslin dream come true. Except for one little sticking point: this customer isn’t building this on SAP’s platform, nor is it using SAP’s tools. There’s a small license to be paid for accessing SAP’s APIs (because who wants the audit police to show up and ruin everyone’s day), but that’s it. The customer went with another vendor’s dev tools, which meant using that vendor’s platform, and, when the time is right, that vendor’s ML and IoT interfaces.


This is why the elevation of Rob Enslin to the title of Mr. Cloud is so important. Rob’s new title is effectively an asset maintenance transformation at the executive level in its own right. The new role is an acknowledgement that SAP’s manifold assets may be in wide use across many medium and large-size enterprises, such as the one I just mentioned, but that doesn’t mean they’re ubiquitous or even well-known by the SAP crowd. In too many cases the SAP ‘crowd’ consists of the SAP ERP people at the company – full stop – while the customers using SAP’s non-ERP assets don’t think of themselves as SAP customers, a position encouraged by other non-SAP user constituencies who still think that SAP is synonymous with “poured in concrete.”  Rob’s job #1 will be to convert the SuccessFactors, Ariba, Concur, Fieldglass customer base into seeing themselves as SAP influencers, and help convert the non-SAP non-believers to the one true religion.

If he doesn’t, then there will be more and more cases where individuals like the one above, with no particular connection to SAP and a connection to another platform vendor, opts to choose something other than SAP for the next digital transformation project: The more disconnected a user is from SAP the more likely that user is to not opt for SAP technology when the time comes to step up to something transformative.

Among Enslin’s many challenges is to undo this disassociation and build SAP brand loyalty inside these non-ERP and non-SAP assets. And then use that loyalty as the jumping off point for making sure SAP has a seat at the table when digital transformation projects get the green light from LOB management. This won’t necessarily be easy. There’s a lot of incumbency in the non-SAP world too, and SAP’s competitors – and Microsoft in particular – are doing a good job on maintaining their respective cozy positions with their respective line of business users. And I was reminded at the recent SuccessFactors analyst summit that, for many non-SAP ERP users, the SAP brand is seen as anathema: it’s not just that the positives as too low, it’s that the negatives are also too high.

This is why’s Trailhead and Microsoft’s PowerApps are so dangerous for SAP. If the LOB is looking to build a transformative app, Trailhead and PowerApps provides a way to at least get started. And, considering how well both companies are doing marketing these tools, getting a similar reflex motion towards SAP and Build will be problematic.

Which of course is where Bernd Leukert and newly appointed CTO Bjoern Goerke come in. SAP has to not just build great platforms and middleware and apps, it also has to offer great development experiences that are both accessible and known to be accessible. The emphasis on known to be is essential: SAP has been pretty stealthy making its developer outreach programs as well-known to the market as those of and Microsoft. Build’s market awareness is pretty low too – ask most developers what build is and they will tell you it’s Microsoft’s developer conference, currently taking place in Seattle.

In contrast to the massive Microsoft Build event, and must-have, oversold, three day orgy of Microsoft tech products and direction, to date SAP’s developer efforts have been pretty stealthy. I was surprised to find out recently that SAP ran 140 developer events last year, and that one third of the attendance at those events was by developers new to the SAP ecosystem. In fact, to its credit, SAP’s approach has been quite global. But they seem to have missed a few important places where they might be better seen, such as Silicon Valley.

I mention this not because I believe that Silicon Valley is the center of the tech universe, which it isn’t, but because of its perception as the center of the tech universe. While SAP’s rest-of-world efforts are laudable, the PR value of being in the Valley as a means to capture developer mindshare is significant: capturing developer and VC mindshare is essential to being a platform player in search of an army of developers and ISV partners, and the Valley is a key place to go hunting for that mindshare. So job number one, IMO, is to be much more public and visible in the competitive landscape with what developers can do with SAP.

(To its credit, SAP has been touting is new relationship with Apple, and I’ve heard more than one SAP exec talk glowingly about unleashing an army of IoS developers to develop on the SAP Cloud Platform and Fiori. If only such an army existed. I think a regiment might be a better characterization – I think it’s safe to say the percent of IoS developers capable of building enterprise apps is directly proportional to the number of enterprise-class apps in the Apple Store. But early indications are that there is a critical mass of IoS developers building mission critical apps.)

SAP also has to be more out in front of the commerce side of being a platform vendor, and that means more presence for its digital store assets, such SAP’s Digital Store, its AppSource store (which is a showcase store, not a place to actually buy apps the way the Digital Store is) , and, unfortunately, the other stores that constitute platforms for selling partner wares to the SAP ecosytem. A digital store experience is an essential part of the overall transformation of SAP: if SAP is going to be a platform vendor, and attract waves of developers and internal LOB users, and make its mark as the go-to company for digital transformation, then it needs a place to market partners’ assets that is easy for partners to tap into and is intended for a more public commercial audience.

This is a key capability that could help SAP capture LOB users might otherwise go elsewhere. If they find what they’re looking for – or close to it –  in an SAP store they may not be tempted to go running off building new edge apps with other vendors’ tools. Likewise, newly recruited IoS developers will find a familiar commercial outlet for their creativity. In other words, SAP would begin to be seen as a big-tent vendor with broad appeal and not just another ERP vendor gone cloud.

All of which brings us back to the story of the SAP customer who digitally transformed without SAP. Each of these touchpoints – better synergy between SAP assets, better identification with SAP outside the traditional SAP ERP customer base, better developer experiences, more reflexive moves to Build and Cloud Platform – needs to be shored up in order to stop the bleeding of edge apps development from SAP to the competition.

This is what I’m looking for at SAPPHIRE this year, much more than more demos of IoT proofs of concept and machine learning whiz-bang predictive analytics apps. Don’t just show me that you can build great next-gen edge apps, show me why building them with SAP’s platform, dev tools, and Cloud Platform APIs makes them better. Because without the uniqueness of SAP’s advantages leading the message, SAP’s ability to capture the attention of that next non-SAP LOB manager with an IoT or ML problem to solve will continue to… what’s the technical term? Suck.

Messrs. McDermott, Leukert and Enslin have an enormous pallet of assets to assemble into a coherent message worthy of SAP’s total value to its customers. The challenge reminds me of William Gibson’s famous admonition: The future is already here, it’s just unevenly distributed. SAP’s future is already here, but the understanding and use of that future isn’t well-enough distributed, both inside and outside SAP.

The time for that to change is now.

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 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.

SAP’s S/4 HANA: Looking Good, Trying to Look Better

SAP’s S/4 HANA has been called many things, but to characterize it as the future of SAP is far from hyperbole. SAP has minced no words in affirming that the path from R/2 to R/3 to ECC eventually leads to S/4 HANA. The question is not an “if”, but a “when.”

When, however, has been the tricky question  – when will the customers sign on in droves, when will SAP put in the critical mass of the functionality customers need in S/4 in order for the transition to make sense, and when will S/4 become a significant revenue-maker for SAP? Considering the literally billions of dollars at stake on the SAP and customer side, predicting the answer to when has become the SAP watcher’s equivalent of finding the northwest passage or the Higgs Boson. It’s a complicated question to answer, and precisely because of both its difficulty and value, it’s the number one question looming over SAP and its ecosystem today.

Which is why the recent release by ASUG, the SAP user group, of a comprehensive survey of customers’ attitudes and intentions towards S/4 HANA falls at an extremely propitious moment. That release was made all the more propitious by a peak I was given into SAP’s plans to clean up a major problem that has bedeviled customers’ efforts to plan their S/4 projects: The lack of a clear, well-defined and easily accessible path, based on the current and future state of a company’s SAP landscape, that will lead customers to the S/4 HANA promised land.  Based on the briefing I received, SAP has some interesting plans to fix that problem, and those plans could potentially make the next ASUG survey results look very different indeed.

The good news from the ASUG survey is that, at least in North America, SAP customers’ current uptake and intention to buy S/4 HANA is actually higher than many of us, including myself, though it to be. According to ASUG’s data, 61 percent of the customer base will have purchased S/4 HANA by next year, with 40 percent already on board or expected to have been on board by the end of 2016. Only 19 percent said that they are categorically not planning to purchase S/4 HANA, with 20 percent coming under the “don’t know/not sure” rubric.

These numbers are tempered by the problem that has bedeviled SAP’s intentions for S/4 HANA since it was first offered to the market – there’s a big difference between “bought” and “deployed”. Only 8 percent said they were currently live, with another 15 percent in the process of implementing. This has been the story all along – SAP did a good job, maybe too good a job, of selling the first licenses of S/4 HANA. But all too many of those licenses weren’t immediately put to use: for many the S/4 HANA license was used as leverage to get a better deal on other functionality that the customer was more eager to implement, and that meant the S/4 license sat on the shelf.

Assuming there’s a license that’s going to be used, implementing what is the next big question: SAP needs its customers to not just go live, but to go live with as much functionality as possible, or least with as much of the software they actually licensed as possible. The ASUG data shed some light on this question as well: 34 percent are primarily implementing finance, while 26 percent said they were planning to implement the full suite. Other deployments options including supply chain, manufacturing, and HR. Another 26 percent said they didn’t know.

The numbers in the “don’t know” category are important to consider when looking at how SAP plans to help customers discern the correct path to S/4 HANA. With 20 percent of customers not knowing whether they will deploy S/4 HANA, 26 percent not knowing what part of S/4 HANA they plan to deploy, and 33 percent not knowing if they will deploy on-premise or in the cloud – the uncertainty factor looms large in the overall issue of when S/4 HANA crosses that proverbial river to the promised land.

Of course, ASUG asked about the obstacles to S/4 HANA adoption, and their data confirmed what many of us have been saying for a while: S/4 HANA lacks a clear roadmap (15%), details about versions and functionality are lacking (12%), it’s unclear how to get from an existing ECC system to S/4 (13%), and it’s unclear how S/4 can benefit a given company (18%).

Which makes the initiative SAP plans to roll out later this year to help customers figure out the path to S/4 all the more significant, and well-timed considering the ASUG report. The initiative, called the SAP Transformation Navigator, is intended to provide customers with a self-service online tool that lets them define the current state of their ECC 6 implementation and receive recommendations on what the ideal S/4 HANA implementation should look like. The goal is to give a solution architect a starting point for planning the “transformation” based on a qualified assessment of how to get to the optimal S/4 promised land.

Based on the demo I was shown, there’s a lot going on in this tool to address the obstacles that the ASUG data highlights: after entering the current state of their ECC 6.0 system, customers will be able to see what S/4 HANA alone can cover for them as well as what modules such as Ariba or hybris might do for them. Each proposed new module has a pop-up that defines integration scenarios, a roadmap, other information on functionality and how S/4 HANA can benefit a particular company via information from the module’s “value map.”

On paper – or, more precisely, on PowerPoint – the Transformation Navigator takes a swipe at pretty much every potential obstacle to S/4 adoption in the ASUG survey. Roadmap? Check. Version details? Check. How to get there from here? Check. Benefits? Check. If I didn’t know better (but I do) I would say that SAP took the survey results and then created the tool – no matter that the survey just came out last week and the Transformation Navigator has been in the works for months. Credit ASUG for holding up the mirror, and credit SAP for taking a deep long look.

What the confluence of the ASUG data and the functionality promised by the Transformation Navigator gives the SAP ecosystem is important. On the one hand, the ASUG data show that SAP’s existing customers aren’t opposed to S/4 HANA, but it’s clear they could use a lot more help in making the case for why they need to move from ECC and how to do it. That need more than justifies the development of the Transformation Navigator, and, if it lives up to its billing, it’s going to be a welcome tool in the customer’s decision-making processes. On the other hand, ASUG has now thrown down the gauntlet to SAP, setting a baseline for the problems and prospects regarding S/4 HANA that everyone will be able to use to judge the relative effectiveness of the Transformation Navigator and SAP’s other S/4 HANA efforts.

If SAP hasn’t moved the needle in the next ASUG survey, we’ll know that at least one of two things happened: Either the Transformation Navigator wasn’t up to the job, or SAP failed to fill out S/4 HANA’s functionality enough to align it with customer requirements, or some combination of both. Neither would be a happy moment for SAP. Importantly, Transformation Navigator won’t be enough if SAP can’t meet expectations and eventually flesh out S/4 HANA enough to become the replacement for ECC that it one day must become.

Other things could still go wrong for SAP’s plans: buying S/4 means replacing everything (SAP and non-SAP) with S/4 for 55 percent of the customers, according to ASUG’s data.  But only half that many have implemented or will soon implement any S/4 HANA at all, and most of those have just done finance. In other words, the intention is clearly in favor of a broad application of S/4, but it’s a future intention, not a present commitment.

This is one area I’ll be watching closely – if these customers start to fall off the wagon, the repercussions could be serious. The 45 percent that aren’t going full-bore S/4 are planning to do a mix of two-tier and “partial” migrations, both pragmatic strategies that on the one hand make a lot of sense but on the other hand mean that S/4 HANA is not as important or strategic as SAP would like. The ASUG data still show that SAP and S/4 HANA are still clearly important overall, and we don’t know from the ASUG report whether the 11 percent who responded “other” to the implementation/migration question are looking at non-SAP solutions, particularly for tier-two implementations. But if the “other” category grows in size as more customers go from planning implementations to realizing them, or the 55 percent who are going all S/4 start to waiver, SAP’s plans for S/4 HANA will be endangered.

Which highlights the importance of the ASUG report and SAP’s Transformation Navigator. ASUG has an important role in bringing to voice the kinds of problems that SAP hopes to mitigate with Transformation Navigator, and how well Transformation Navigator does in meeting those needs will tell the world a lot about how S/4 HANA is aligning with customer needs. That alignment will improve in time when the Navigator adds non-SAP software to its “before” picture: considering how predominant non-SAP software is in the SAP customer base, showing what S/4 can do to replace and, maybe, improve on the functionality of a heterogeneous environment will be a further boost to SAP’s plans, and provide more fodder for ASUG’s surveys as well.

2017 is turning out to be one of those pivotal years when SAP has to consolidate a lot of new products and technology, along with a logjam of acquired products, and show its customers how the sum of the parts is greater than the whole. Transformation Navigator is just one piece of the puzzle, there’s much more work to be done. But if all SAP did in 2017 was solidify the S/4 HANA story and route to adoption for its customers, and they responded with their dollars and euros, it would be a watershed year.

According to ASUG’s data, the die is cast. What’s on the other side – as S/4 HANA matures and Transformation Navigator starts to do its job – we can only guess.

Until the next ASUG survey comes out.

Looking for Mr. Cloud: The Benioff Scale and SAP’s Cloud Leadership Conundrum

Cloud computing, the artist formerly known as SaaS, has always been a proving ground for dynamic leadership. The standard – brash, outspoken, ubiquitous, successful – was set once upon a time by Marc Benioff, and ever since it’s been easy to measure cloud leadership by what I call the Benioff Scale. On a Benioff Scale of 1-10, where 1 is Ginni (Ginni who?) Rometty of IBM, and 10 is Marc himself, measuring cloud leadership by how many Benioffs a particular leader generates is as good a method as any.

Amazon’s Jeff Bezos clearly rates 10 Benioffs, and Microsoft’s Satya Nadella gets a 10 as well. Larry Ellison – how about if I pass on that one? Meg Whitman – 4 or 5 at best. Larry Page gets a 10, of course, though his enterprise cloud score would be much lower. Infor’s Charles Philips get an 8 for sincerity and vision, but the continued lack of customer momentum towards the cloud drives his overall score much lower.

The point is that the cloud is a marketer’s market, and the higher up on the Benioff scale an executive can go – the more brash, outspoken, ubiquitous and successful the leader is –  the better his or her company’s cloud marketing efforts will be.

Which is why SAP’s current cloud position isn’t looking as good as it could, despite an alignment of assets and strategies that clearly place SAP in the top tier. SAP’s problem with cloud leadership is fundamental: it lacks a Mr. or Ms. Cloud who rates a leading score on the Benioff scale. Absent a leader with the requisite level of internal and external clout, SAP as a whole rates at best 6 Benioffs¸ underperforming its potential by several points.

Not that there aren’t strong contenders inside SAP for Mr. Cloud. (Sorry, I’m struggling to find a prospective Ms. Cloud in SAP’s leadership lineup – despite the company’s honest attempts at diversity, senior leadership at SAP’s is still largely a men’s club.) But the worthy contenders all struggle with the siloing of SAP’s cloud strategy, which yields too many Mr. Cloud contenders, and waters down the company’s overall Benioff score.

So far, the most visible Mr. Cloud is SuccessFactors head Mike Ettling, who wears the mantle with solid authority and credentials, but not enough overall company responsibility to claim the title. On his own I’d give Mike something north of an 8, but because he’s part of a fragmented SAP, he’s dragged down by the company’s overall score. Steve Singh, the SAP board member with the biggest cloud portfolio and a legitimate Mr. Cloud contender in his own right, simply isn’t visible enough to make it to more than a 5 Benioffs score, if that. Bernd Leukert, who waxed eloquent about cloud and HANA Cloud Platform at SAP TechEd in Barcelona last month, is getting higher and higher individual marks, but his technology bailiwick at SAP waters down his ability to raise the company’s overall average. Alex Atzberger, who runs Ariba, has decent Mr. Cloud potential, but his cloud focus is distracted by Ariba’s on-premise customer base and the same fragmentation that lowers scores across the company. And CEO Bill McDermott has too much responsibility for the non-cloud part of SAP – the part that so far actually makes the company’s quarterly numbers work for Wall Street – to be even in contention for Mr. Cloud.

It’s important to bear in mind that Mr. or Ms. Cloud isn’t just about putting a public face to a company’s cloud aspirations, and the Benioff scale isn’t just about feeding at the trough of public opinion. Top scorers on the scale get those numbers because they have internal cloud clout as well. Bezos, Benioff, Nadella – there’s no doubt they run the cloud show at their respective companies, and while each is surrounded by a coterie of lieutenants (almost all men, sorry again, Ms. Cloud wannabes) who own various business units and other parts of the cloud story, no one inside or outside these companies has any doubt who’s running the cloud show.

Not so at SAP, much to its detriment. SAP has nine major cloud properties or assets – S/4 HANA, HANA Enterprise Cloud, SucessFactors, Ariba, Concur, hybris, Fieldglass, C4C, and HANA Cloud Platform – and the lack of a unified, cohesive strategy is SAP’s greatest challenge right now. Much like its customers, SAP is struggling with a siloed cloud approach that is turning out to be an impediment to growth, and, counting the low Benioff scores, market leadership as well. At a time when companies at the top of the Benioff scale are poised to reap enormous benefits from a sudden acceleration to the cloud, SAP – which is definitely reaping serious cloud benefits every quarter – is finding its own cloud structure, or, more concisely, lack thereof, getting in the way.

Don’t think for a moment that SAP is alone is having a surfeit of disjointed cloud properties and strategies – all top Benioff scale companies do too: it’s an artifact of the incessant acquisitions and side bets that cloud vendors have made in order to keep moving the needle. But the command and control structures that run, Microsoft and Amazon mean that rationalizing these companies’ surfeit of clouds can be undertaken without having to fight the kind of rear-guard, tilting at silos battle any Mr. Cloud at SAP would face even to be allowed to take the crown, much less wear it.

But the fight would be worth it. SAP needs a rational, cohesive cloud strategy – articulated loud and strong by Mr. Cloud – in order to push not just the above-mentioned cloud assets, but its new strategic initiatives as well. IoT lives and dies in the cloud (and lately it looks like SAP wants to live or die by IoT, which is going to a little more difficult than it may appear), machine learning isn’t something you install on premise (though I’m sure someone somewhere has tried to buy one of them shiny new Watsons to put in their data center), and that developer-friendly platform strategy that SAP needs to execute is based on something call HANA Cloud Platform after all.

Whether SAP is talking to itself, its partners, individual users, ASUG and other user groups, or its competitors, the need for a unified, cohesive voice to the cloud market has never been greater. I’m pretty sure SAP has got a deep enough bench to make Mr. or Ms. Cloud a reality. But it needs either a lot more courage or a lot more fear to take this step. Right now both are lacking, and an abundance of both, frankly, should define SAP’s mindset for 2017: cloud leadership is there to take, and it’s there to lose. The coming year is going to be a pivotal one, and without a single, strategic cloud voice, the pivot for SAP risks going in the wrong direction.


The Ecosystem/Platform War: How do Microsoft,, and SAP Stack Up?

As the enterprise software market slowly morphs into the enterprise software and platform market, it’s become necessary to carefully define what it means to be a successful platform vendor. Importantly, that definition has nothing to do with technology – okay, maybe a little – but it does have a whole lot to do with people and perceptions.

A platform is really the foundation of an ecosystem, and in the platform wars, it’s the best ecosystem that wins. Nothing else matters. So, when looking at the three top contenders for the leading enterprise software platform ecosystem – Microsoft, SAP, and – it’s important to make sure we understand what having a successful platform and ecosystem really means.

My sense of what makes platforms and ecosystems successful places these companies in what today is a three-way race to the top. Other top contenders – such as Amazon and Google – just don’t have the enterprise DNA to become major players: their consumer tech chops have led them to offer great infrastructure services that have them firmly engaged in a feature/function/price race to the bottom. A latecomer to cloud platforms, Oracle isn’t a serious player – they’re about to muck up their already mucked up platform plans with the acquisition of a multi-platform mess called Netsuite. IBM’s inane focus on Watson and its focus on everything being a consulting gig – no packaged software, please – just won’t make it in the long run either. And Infor, which has the right strategy and technology for the job, so far lacks the customer proof-points that would bring its ION platform and Cloudsuite offerings into the top tier.

But Microsoft, SAP and Salesforce all have some serious assets, and serious aspirations, to be highly successful players in the platform-cum-ecosystem world. And all three have serious – and very different – challenges as they march towards what today is still not a winner-take-all, zero-sum race to the top. So far.

Defining what constitutes a successful ecosystem is simple, using my lying awake at 2 am in the morning definition. When software developers, entrepreneurs, or VCs wake up at 2 am with a hot new idea for a killer app or product, the platform they reflexively chose for building their app is either the easiest platform for them to get started on or the one that provides them access to the very best ecosystem, preferably both. When thousands of developers, entrepreneurs, or VCs make the move to the same platform, a successful ecosystem is born. Move millions, and you’re the platform/ecosystem leader.

What’s behind these reflexive motions towards one platform or another? At this point in the evolution of the market, a successful platform, theoretically, fulfils the full lifecycle of the successful product or service, from nascent ideation to order fulfillment and payment, to renewal and eventual end-of-life, rinse and repeat. This includes a list of functions and capabilities that starts down at the technology level with developer tools, databases, access to services, middleware, and APIs, and finishes at the end-customer level, when a product is purchased and paid for, and implemented or configured in as much of a self-service model as possible.

In between are a host of important functions: open APIs, low-cost or free dev and test environments, a wide choice of dev tools, and databases, and the elasticity to start small and scale big. Cost transparency is also very important – who wants to build a killer app that’s too expense to make a killing on – and a super easy on-ramp for both developers and eventual customers is also a requirement. I’ve seen some platform pricing schemes that look like the spawn of Rube Goldberg and the Code of Federal Regulations: complex, overwrought, guaranteed to send a developer running to mother Amazon in tears. Not a way to succeed in the platform wards.

Increasingly, mother Amazon notwithstanding, having an extremely elastic cloud is just table stakes. What matters more than raw infrastructure is access to specialized business services: APIs for business services that support standard backoffice functionality as well as supporting nascent areas like IoT and machine learning. APIs that connect cloud assets to on-premise assets. APIs that support complex, hybrid environments with mixed legacy and leading edge functionality. APIs for specific industries, geographies, and regulatory requirements. And on and on. The bigger the shopping list for extending applications to the rest of the business world – that vastly heterogenous, mixed up, often functionality irrational, real world that enterprise software customers actually live in – the better.

Then there’s the customer side. There needs to be a massive customer base eager to solve their digital transformation problems at the same time they engineer an upgrade from the primordial ooze of Excel and paper processes. Those customers need to be given a killer user experience that hides the underlying chaos that leading platforms are trying to control. And they need these experiences to be self-service, intuitive, intelligent, and as prescriptive as possible.

Perhaps most importantly, there needs to be a buzz, a coolness factor, an ineffable momentum that draws developers, partners, and customers into the platform’s magical orbit. In a funny way, platforms and ecosystems today need to think more like consumer brands than technology brands, with a focus on the millennial demographic, an ability to exude excitement and vigor, youth and hipness. An ability to be cool, quick, nimble, ever-evolving. A hack on the staid, old enterprise software model of yesteryear.

Finally, there has to be a serious investment on the part of the platform/ecosystem company on making the above happen, particularly the buzz/coolness/magic part. That involves money, it involves senior executive spokespeople rallying the troops, it involves creating an almost religious revival movement that looks antithetical – but isn’t – to the dominant nerdy, basement-dwelling engineering culture that enterprise software was born to.

So, armed with these basic criteria, here’s my assessment of where my leading platform/ecosystem vendors stand. Right now, I’d say it’s a pretty close race, with each one running ahead in certain criteria and behind in others.

Microsoft’s investment in Azure, and the resounding success of Office 365, has placed the company’s platform and ecosystem in serious contention. They have an amazing array of services – database, IoT, machine learning, and the like, some new and very appealing hardware assets like Holo Lens and Surface Hub and a new generation of Apple-butt-kicking PCs, all drawing on the universality of the Office user experience when and where it makes sense. Their recent Dynamics 365 announcement was further proof of where they are heading, which is in the right direction, though the mid-market origins of Dynamics AX means that they’ll have to work hard to legitimize their ecosystem as capable of serving the global, large enterprise market.

Nonetheless, Azure’s Lifecyle Services is without a doubt the best cloud ALM tool in the market, and as the complexity of hybrid cloud environments grows, LCS is going to be an increasingly powerful asset and competitive differentiator. Microsoft can clearly grow into the top tier of the market, but it will take some time and effort.

The big issue for Microsoft, ironically, is that the company is still trying to pivot its ecosystem in the right direction. While there are millions of developers who claim .NET and other Microsoft credentials, the enterprise software ecosystem of the future isn’t necessarily the place where the classic Microsoft developer – tech-heavy, but business light – can excel (spot the bad pun, win a prize J). Microsoft’s ecosystem still suffers from an on-premise, PC-based bias, which means it needs a new class of developer to step up to solidify that top tier position. There’s every reason to believe they’ll make it – Lord knows they know how to build an ecosystem, and Microsoft isn’t shy about spending real money to maintain it – but a developer shift of this magnitude will also take time and effort.

SAP has the top spot when it comes to large enterprises and highly complex environments, though SAP also lacks the ALM tools to support this position. But the capabilities of the company’s HANA Cloud Platform, especially its growing API library, IoT and machine learning capabilities, means that SAP is well-positioned to succeed. S/4HANA, on-premise and in the cloud, when combined with SAP’s myriad cloud assets – Ariba, SuccessFactors, Concur, Fieldglass, and hybris, among others – makes for a compelling platform on which to stage complex business processes that span multiple lines of business and products. In particular, as more and more customers move to a relatively restrictive, one-size-fits-all cloud world, HCP and its tools and services can become the place where customer/industry/geography-specific functionality can be built and staged without breaking the “no blueprint” cloud model.

But SAP also suffers from a paucity of the right kind of developers, and, more importantly, a limited quantity of internal DNA that understands what it takes to reach this new generation of developers. I was recently at SAP’s TechEd conference in Barcelona, and it was a classic case of a vendor pitching tomorrow’s message to last year’s audience – a problem endemic to all vendors transitioning a new platform/ecosystem paradigm.

I think the message that Bernd Leukert, the member of the SAP board in charge of products and innovation, delivered at TechEd was spot-on relative to the new platform/ecosystem challenge, and for the most part I think the Tech Ed audience got it. But the audience, by and large, was old guard SAP partner/developers. The new guard, which does show up for SAP’s Innojams and other developer mini-events, was definitely at Tech Ed, but they were in the minority.

Ultimately, SAP needs to do more, much more, to reach out to a new audience and make that reflexive move to SAP and HCP a given, not an afterthought. SAP’s recent agreement with Apple to unleash the IoS developer ecosystem on SAP’s platform is start, but IoS developers are like traditional .NET developers when it comes to next generation enterprise software: only a few can really step up to the new platform challenge.

Overall, the problem of building a name for itself outside the SAP ecosystem, particularly in Silicon Valley and other tech-centric locales – combined with SAP’s historic allergy to spending the money it takes to build a real developer ecosystem – will be the main gating factor for SAP’s platform and ecosystem aspirations. The spirit is willing, but it’ll take more than good intentions and the best business APIs in the business to make SAP’s ecosystem number one.

Last but not least is Salesforce. Unlike SAP and Microsoft, Salesforce has cracked the developer ecosystem code with Trailhead. While the company’s recent Dreamforce conference was, vis-à-vis the company’s ecosystem aspirations, another example of the “next year’s message, last year’s audience” problem, the Trailhead zone at Dreamforce this year was the exact opposite, a shining example of how to get the platform/ecosystem strategy right: stuffed with people, buzzing, standing room only, gamification to keep things rolling, and lots of woodsy icons to keep the buzz from ever getting too serious. And, most important, present and accounted for was a real ecosystem excited about using Salesforce’s platform(s) to drive real change in the enterprise.

The irony of this platform buzz leadership is the relative paucity of high level business services that has to offer. The company’s vow to be the very best CRM platform sells its post-CRM developers and partners short: while one could argue that the customer is and will forever be the center of the business universe, both SAP and Microsoft offer a broader vision of the enterprise that is likely to appeal much more to those 2 am in the morning insomniacs who are looking to develop the next killer enterprise app.

If all you want is to build off the existing base, which is considerable and intersects heavily with both SAP and Oracle, then the Trailhead ecosystem is where you want to be. But if you need more – a broad range of business services and APIs outside of a core CRM system, as well as comprehensive ALM tools and the like – then might not be the best place for your efforts. Trailhead will support robust functional designs and can appeal to developers and citizen-developers like no other platform, but right now the range of capability is limited. For now.’s platform aspirations are clearly headed in the right direction, and its Trailhead developers are engaged and ready to get going: that’s a pretty potent combination, and one that will keep Salesforce in the running for some time.

The bottom line is that these three top tier vendors are equally strong for different reasons, and that, due to the nascent nature of the platform/ecosystem opportunity, that’s just fine. A three-horse race will make every vendor run faster and try harder. Which means that the ultimate winner, the one that really matters – the customer – will reap the benefit of a classic competitive market evolving into a nascent and highly important new form.

Looking at the sources of revenues for all three top contenders, the transition to platform is still to come. Which is also good for all concerned: Customers aren’t actually as ready as their vendors would like to think, and the vendors still have a lot of kinks to work in their strategies and offering. Time is on all of our sides right now – the quarterly cadence demanded of the public equity markets is going to have to be patient.

But the platform/ecosystem game is clearly afoot, and the transition is as inevitable as previous transitions – to client/server computing, Internet commerce, and mobile, for example  – have proven to be. Which further argues for a good dose of patience. Even in the compressed timeframe that technology markets now lives in, the shift will take time for all – vendor and customer – to absorb.

The tech side is easy, but when it comes to people and perceptions….that stuff just takes time.



Security is a People Problem: Bringing the CHRO to the Table in the Cybersecurity Wars

All the attention on whether Russia or some other nation-state entity is trying to hack the election in November or how organized gangs are flooding PCs with ransomware has obscured that truth about where the real threat to our collective cybersecurity comes from: our employees.

Employees come in many shapes and sizes, but when it comes to cybersecurity, there are two archetypes, the rogue employee and the ignorant employee. The epitome of the former is Ed Snowden, the epitome of the latter is all of us who has been tricked into opening a phishing email or forgotten that we’re not allowed to save sensitive files on our personal Dropbox account. Either way, the vast majority of cybersecurity threats come from the people who work for us and around us, not nameless, faceless entities located thousands of miles away.

Which is why I keep looking around for how Chief Human Resources Officers (CHRO) and their cohorts are responding to this issue, and not finding a whole lot. When I ask the people in the C-suite who are in charge of cybersecurity, Chief Information Security Officers (CISO), about the direct role HR should play in cybersecurity, I tend to get the kind of funny look you get when you’ve asked whether the moon is made of cheese and you’re more than six years old.

Are you serious? After all, the bailiwick of the CHRO is stuff like hiring, firing, benefits, and payroll. What could those processes (and, all the other HR processes that CISOs are ignorant of) have anything to do with cybersecurity?

Plenty, it turns out, both for the sake of stopping the rogue employees of the world as well as keeping Betty and Jimmy from clicking on that fake invoice or “jaw-dropping” offer in a phishing email and unleashing some techno-horror into the company’s IT infrastructure.

And herein lies a tale. I’ve had the privilege of working with the IEEE Computer Society for a number of years now, helping them organize and participating in a series of topic-specific conferences. One of the most recent ones, entitled “Rock Stars of Cybersecurity”, featured a speaker named Steven Bay, whose claim to fame is that he was the guy who hired and supervised Ed Snowden at his last job before, well, Ed Snowden became Ed Snowden.

Steven’s story is an amazing one – regardless of whether you think Snowden is a hero or a traitor – but the kicker comes around minute twenty-four, in case you want to scroll forward to the good stuff in his presentation. The segment starts with Steven giving a quick overview of the separation of duties between systems analysts and defense analysts: Basically the former has access to systems but not necessarily access to sensitive data, and the latter has access to all matters of sensitive data but can’t wander around the IT infrastructure at will. Sounds like a pretty good idea.

Too bad that good idea wasn’t put into practice for Mr. Snowden. The trick to Snowden’s success, according to Bay, is that he was at his systems analyst job on a Friday and starting his new defense analyst job the following Monday. Importantly, considering his goal in taking the job was to download a few terabytes of sensitive NSA data, his credentials from his old job inexplicably remained in place at the new job.  In other words, Snowden’s employer “forgot” that, while he had all the right clearances for both jobs, neither job allowed him to possess the credentials of the other.

And that oversight in the HR basic process of on-boarding and credentialing a new hire is how the greatest cyberhack of modern times was able to take place.

How did this IT/defense analyst credential overlap problem happen? I don’t know the specifics of Snowden’s case and Bay doesn’t really say. But it’s safe to surmise, based on my aforementioned queries regarding the role of HR in cybersecurity, that the HR department, and their colleagues in IT who manage system credentials, lacked the right procedures for handling employees who crossed over the line from systems to defense analyst. We don’t know if Snowden knew about this lacuna, but considering Steven Bay’s contention that Snowden specifically targeted the contract Bay’s team worked on – in other words, Snowden didn’t just show up on that fateful Monday and have his conscience tweaked by some startling revelation about NSA data collection – it’s very likely that Snowden knew about this lack of attention to separation of duties.

Ed Snowden didn’t succeed by finding a hole in the cyber-security fabric of the company or the country’s most powerful and, in theory, secretive spy agency, he succeeded by finding a hole in the credential and compliance processes of the contractor he worked for. So much for creating a dense cybersecurity technology infrastructure: it only takes one smart operative, and all the technology in the world can’t keep the world safe.

Of course, the Snowden case was an especially egregious one, except that the problem of credentials, compliance, and training are at the heart of too many cybersecurity meltdowns, particularly the malicious ones. In what is perhaps the ultimate irony, the US government’s own HR “department”, the Office of Personnel Management (OPM), was spectacularly hacked last year due to a number of factors, including embarrassingly poor coordination between IT and security. But at the bottom of the pile of blame at OPM is the poorly trained employee who clicked on a phishing email and gave up his or her credentials. And because the system lacked basic security features, including multi-factor authentication, the race to download what turned out to be 4 million employee records, including security clearance information and a host of other cringe-worthy data, was on.

Importantly, whether it’s an employee gone rogue or an employee asleep at the switch, cases like Snowden and the OPM breach highlight the fact that preventing these disasters requires the active participation of several C-level big-wigs: the CISO, the CIO, and the CHRO all have a role in making sure the bad guys don’t succeed. But if they do their jobs individually without coordination, which seems to have been the case at OPM, and probably with Snowden as well, then what you get is the perfectly permeable environment for nurturing a major hack.

The old adage in cybersecurity is unfortunately all too true: the problem is that the good guys have to do their job right 100 percent of the time, while the bad guys only need to do their job right once – a successful phishing email or other hack – and all hell breaks loose. Getting it right isn’t just a matter of letting the CISO do her job, nor is it enough to let the CISO and the CIO collaborate. If people are at the root of the global, pandemic cyber-threat of today, then the number one people-person in the C-suite, the CHRO, needs to be in the mix as well.

Just leaving security up to the CISO, or CIO, means we’ll just keep fighting the good fight with the wrong team. And we know far that’s not worked as well as anyone would like.

Le Blueprint, C’est Moi: the Counter-Customization Revolution comes to SAP SuccessFactors

Le Blueprint, C’est Moi:  the Counter-Customization Revolution comes to SAP

Sometimes revolutions start with a shot heard round the world, and sometimes they start with a quiet nudge in a new direction. The latter form of revolution was nudged into being for SAP’s HR customers last April in the form of eight words uttered by Mike Ettling, the president of SAP SuccessFactors, during an analyst summit in San Francisco. Ettling’s eight words have been said before, but the fact that they come from a man who is re-writing what it means to be a cloud company, and thereby what it means for customers to consume cloud services, adds enormous gravitas to the moment.

On the surface, I admit this revolutionary utterance seems absurdly benign. All Mike said was the following: “The blueprint should be banned. I’m the blueprint.” Pretty banal, no?

But behind those eight words are a veritable revolution in what it takes to be an enterprise software vendor and an enterprise software consumer. And while this revolution has already been underway for a while, in the world of SAP this revolution means that the status quo ante of software deployment and lifecycle services was just blown to smithereens.

First, let’s talk about why Ettling is going to become a hero by blowing things up. It’s simple: software projects are historically problematic, and Ettling has a plan to fix that.

The success rate of on-premise software deployment would be an industry shame if the industry had any shame. Instead, we’ve all become inured to the pain. It’s safe to say that up to two-thirds of all software projects fail to deliver on their expected results. Most are remediated, blowing schedules and budgets along the way, and annoying end-users, executives, bean counters, and the IT department to no end. But a significant number are cancelled outright or end up in court, tarring the reputation of the customer, service provider, and the vendor in the process.

To say this is the dirty little secret of our industry is to misstate the problem: it’s our dirty big secret. And it’s not even that secret.

What Ettling is referring to with those eight little words starts with the fact that every enterprise software project uses some sort of methodology as the basis for organizing the tasks to be undertaken by the IT department and its counterparts on the service provider side. The methodologies used in the SAP ecosystem are too numerous to count: SAP has at least four (ASAP, A20, various flavors of agile, and a new one, SAPActivate), and most of its services partners have their own as well.

Virtually every methodology has two basic things in common: they all have five phases, and the first phase is called something resembling “blueprint.” The blueprint phase is pretty much self-explanatory: the internal IT team, along with (hopefully) their business counterparts, sit down with the service provider team and hammer out the details of what needs to be done to adapt a largely generic system to the customer’s specific business requirements.

Sounds great, right? Isn’t imprinting the business requirements on the software what it’s all about? So why is Ettling channeling Louis XIV and declaiming “le blueprint, c’est moi?

The answer is that a significant number of troubled projects start with a troubled blueprint. Why? Because all too often free rein is given to perceived business requirements that ultimately mean a tremendous amount of customization. And that customization in turn leads to a lifecycle of complex implementations, complex on-going maintenance, and complex upgrades. This makes customization the the plague flea of enterprise software: easy to find, easy to spread, hard to get rid of, enormously irritating, and every once in a while its bite proves to be fatal.

The key here is “perceived business requirements.” Sometimes the perception of the business managers is spot on, but all too often the alleged business benefit is really just some individual’s or department’s misconception of what enabling competitive advantage in software is all about. When someone insists on a customization because “this is our competitive advantage” it’s more likely they really mean some variation of “this is the way we’ve always done things around here” or “I want the new software to look and feel just like the old software.” And everyone goes home itching and scratching.

What’s remarkable about cloud software like SuccessFactor’s Employee Central is that customization is severely limited, at least compared to the on-premise world. The limits to customization were originally a matter of efficiency for the cloud provider – too much variation between instances breaks the economies of scale of cloud computing by requiring too much one-to-one support. But what started as an expedient has turned into a virtue:  by building in an increasingly significant amount of best practices into products like Employee Central, customers of SuccessFactors can get a lot of their “perceived business requirements” taken care of without customization.

There will always be some customization – which in the parlance of the cloud is called configuration, meaning it doesn’t require one-to-one service to support it.  And there will always be the high-value consultative services that are needed to truly transform a company’s business, and thereby its IT systems. Configuration, and other services like SuccessFactors Intelligent Services Events, a mix of workflows and net new functionality, allow a fair amount of business-specific functionality to be baked into the system. And for the really hardcore, the HANA Cloud Platform supports custom applications integration with SuccessFactors without breaking the cloud support model.

Herein lies the essence of Ettling’s declaration: customization is not your friend. If you have any doubts about the veracity of that statement just ask the old PeopleSoft HR customers, who customized to their heart’s content and won an expensive and time-consuming upgrade as first prize. Customization is the gift that keeps on taking, and it’s time to put the kibosh on these “perceived business requirements”.

Why this is so revolutionary for SAP is simple: The R/3 juggernaut got its start as the poster child of business process re-engineering, which was a buzz-term ginned up by the big systems integrators to generate consulting services. And where customization is the plague flea of enterprise software, too often these consulting services are the plague rat of enterprise software: a vector for delivering a plague of costs and complexities.

The fact that the entire SAP on-premise economy has been built on this symbiosis is why “le blueprint, c’est moi” is so revolutionary. Take away blueprinting, and you take away a huge amount of consulting services that start during the implementation process and continue throughout the lifecycle of the software. It should be no surprise that when Ettling’s head of customer lifecycle engagement, Richard Campitelli, showed analysts the SuccessFactors SAPActivate methodology, it only had four phases – blueprinting was conspicuous by its absence.

In essence, Ettling is leading a classic revolution, despoiling the rich, dysfunctional relationship between complexity, customization, and IT services. SAP is starting this revolution with its cloud properties, but it’s sure to sweep the company over time.  For too many years, enterprise software vendors and partners have been complacent in a business model that discredits the industry. Vive la révolution.

Happy Trails to You: Gets in Front of the Platform Ecosystem Challenge

If someone were to write the “The Tech Event Manager’s Guide to Engaging a Millennial Audience”, a look at’s recent TrailheaDX conference would be a great place to start. Similarly, if someone wanted to write the “Platform Vendors’ Guide to Building an Engaged Developer Audience”, that same TrailheaDX conference would also serve as an excellent model.

TrailheaDX,’s first shot at creating a developer’s conference focused on getting partners developing on its myriad platforms, which took place last week in San Francisco, was that good. And being that good first time around puts in a position of strength around what I believe is the single biggest challenge facing established enterprise software vendors today: how to pivot from selling apps and services to selling apps and services and a platform that is intended to become the go-to environment for a net new set of applications and services. As well as developers and customers.

More impressive than the keynote’s content and tone, which were noteworthy in themselves, was the tent revival vibe that the keynote elicited. I haven’t seen that engaged an audience of techies since a meeting in 1988 between the newly formed Open Software Foundation and a group of hairy, hoary Unix programmers looking for someone to save them from a perceived “corporate takeover” of the Unix movement by a AT&T and Sun Microsystems.

Their savior appeared in the form of Alex Morrow, an IBM exec who had been seconded to the OSF to run its strategy operations. Alex took the stage in front of a sea of doubters, and by the time he was done leading his flock over the river and into the promised land the open software movement, which in turn begat the open source movement, was born. There was, by the way, much whooping and hollering, and other carrying on as the tablets were brought down from the mountain and presented to the assembled wanders-in-the-proverbial-desert.

Maybe it was the whooping and hollering that reminded me of the OSF meeting. Or the acknowledgment of the hunger in the crowd for some recognition that their nerdy corner of the tech market was important. Or the anti-establishment tone to it all. Or all of the above.

Also striking was the casual, free-form way in which the keynote started: the way co-founder Parker Harris and other assorted speakers, techies, and “Trailblazers” wandering the stage as the crowd filled the theater reminded me of the controlled chaos on stage just before a three-day rock festival is about to start. A fitting analogy, as the event was held in San Francisco’s historic Warfield Theater, which has seen the likes of the Grateful Dead, Bob Dylan and Green Day rock an audience. (Fitting for an iconic 70’s venue, at one point one of the presenters paraphrased Gil Scott-Heron’s poem/song by shouting “The revolution is not televised, it’s at Trailhead.” Which was less cringe-inducing than the highly successful attempts to get the audience to chant “Rad” when prompted: they obliged, and I cringed my cynical curmudgeonly cringe.)

The meta-content also hit the mark, very much in the vein of the aforementioned fictional “Tech Event Manager’s Guide to Engaging a Millennial Audience”. Diversity was a big theme, social action was another. Women and other people who are not the typical white men in suits were on stage, the young leaders of tomorrow were saluted. And before you think I’m being cynical, snarking at the obvious pandering to a millennial audience, let me explain that the pandering worked – not just because there’s a whole chapter in my fictional guide on the value of pandering to a millennial audience, but because it really did work. The audience literally ate it up.

It’s important to note that the event itself was only one part of a larger and more comprehensive strategy of appealing to a new developer community that hopes will eventually become 100 million persons strong. While that number seems a little stratospheric, the logic behind it is based on the notion that in order to succeed as a platform company has to cater to an increasingly large non-techy audience interested more in business outcomes than REST APIs and what’s available on GitHub.

To’s credit, their new developer’s training ground/landing page, Trailhead, makes a good case for how the company plans to bring on this hoard of new developers. It probably won’t be 100 million any time soon, if ever. But the value of Trailhead as a recruiting and training tool makes it more probable that will reach a new, broader audience than anything I’ve seen from the other major platform vendors.

Trailhead’s main offerings are a growing set of “Trails” that are designed to train developers and administrators on everything from basic administration to advanced mobile app development. The trails are effectively a training curriculum, with goals and milestones, that guides the “trailblazer” through an interactive, hands on session using a free account. Trailhead is lightly gamified, so that the completion of a trail or a set of modules is rewarded with a badge, which the Trailhead team have managed to hype up enough that people were talking about using badges as a form of certification and a credential to put on their LinkedIn page.

The badges offered by Trailhead are themselves remarkable. Sarah Franklin, Trailhead’s marketing VP, has 7 badges on her LinkedIn page, including Business Value of Equality, Impact of Unconscious Bias, and Spring ’16 Release. (Okay, here’s a brilliant idea – every new software release has a trail intended to walk the user through the highlights of the new release. How common-sensical is that?) There are also superbadges for skills such as Apex Specialist and Security Specialist. The mix is deliberate – content for beginners, experts, and those who also want to display their corporate social responsibility chops, something that takes quite seriously.

Core to the Trails experience is a deliberate sense of light-hearted fun – very millennial friendly, though it works with cynical, curmudgeonly boomers too – that is assiduously curated by an in-house editorial team. For the most part Trails and modules are developed in-house, but the Business Performance Basics module, co-developed with the Drucker School of Management, is an example of where Trailhead is going with respect both third party content as well as more general-audience, non-techy, business content that will appeal to the “what’s GitHub?” crowd.

I could go on about the value of Trailhead MVPs, like Jennifer Wobser, who helps develop content and makes sure that Trails and modules are based on real-world requirements, not something out of a marketing or training manager’s ivory tower viewpoint. Or the cute woodland icons – Cloudy the Goat, Codey the Bear – that are just kitschy enough to work for an audience used to taking their tech with a healthy dose of penguins and elephants and other cute animal avatars. Or I could go on about the average audience age – definitely sub-40, or the enthusiasm of….pretty much everyone.

The coolness of Trailhead, and the infectiousness of TrailheaDX, are hugely important for’s platform aspirations, and hugely threatening for its platform competitors, particularly SAP and to a lesser extent Microsoft. The importance should be obvious: may have cracked the most difficult nut in enterprise software today – how to excite a global, millennial-oriented development community and draw them to’s development platform world. There is simply no way for a platform vendor – one that is interested in the business of building apps, as opposed to those vendors trying to make their middleware an enterprise platform – to become successful without hordes of developers. Think Apple Apps Store – though, ironically, even Apple seems to be struggling now attract the right quantity and quality of developers to its IoS platform, according to a recent article in the New York Times.

SAP has it TechEd developers conference, but it’s overly didactic, too much like a techy version of SAPPHIRE, and seemingly more targeted at services partners and ISVs than the millennial developer. TechEd isn’t all SAP is doing to entice developers – the SAP Store is a solid first shot at building a commercial experience where developers, partners and ISVs can show off and sell their wares. But the community-building efforts from SAP are complicated by the fact, in addition to an inability to understand that building a developer community is an investment that takes a real budget, that SAP has way too many entry points for prospective developers and no simple way to figure out which is right for which purpose.

Microsoft Build is perhaps the top of the line dev conference right now, but that top dog position is Microsoft’s to lose. I didn’t attend Build this year (which means actually in attendance – you can’t go to a dev conference virtually, despite what Microsoft was thinking when it decided that virtual attendance was good enough. Wrong wrong wrong – developers need to rub shoulders, takes selfies, and share war stories, and so do those who track them).

No matter, I was there last year, and it was pretty amazing. But Microsoft has so many irons in the fire – Azure, Office, Universal Windows apps, augmented reality, Surface Hub, Office, CRM, Dynamics AX, SQL, Skype, PowerBI, etc.  – that the threat of option overload and dilution is way too real. If I want to build the killer enterprise app, where do I begin? Should I use the dev environments that are native to many of these offering – CRM has xRM, AX has X++ — or head for the Universal Windows Apps platform? I think Build should be more targeted to audiences of developers than trying to be a one-size-fits all – otherwise there are too many communities at the same event trying to make sense of too many messages.

Trailhead, of course, benefits from being primarily about CRM. In fact, perhaps a little too focused on CRM considering the broader aspirations of But the ability to focus on CRM is for now a strength. It makes the conference more focused and the audience more cohesive. I think this outcome-based or LOB-based focus is the way to go for building developer communities in this highly verticalized and geographically-focused global economy.

As is, there’s enough work running a relatively cohesive audience through’s development vision. The company suffers from option overload as much as any other vendor – there’s, Heroku, Thunder (IoT) and Wave Analytics Clouds, Lightning UX tools. All and all, on face value this looks a little messy. But showed the TrailheaDX audience an excellent slide, code-named the rainbow, that does a pretty good job defining the different points of entry in terms of their audience and the relative amount of coding each point of entry requires (serious coding for and Heroku, none for Lightning App Exchange and Lightning App Builder, and several “low code” options in between). I think every platform vendor is going to need to start segmenting their developer options in a similar fashion.

A great developers conference is a great place to start, but there’s lots more to do (and get wrong) along the way. There’s the need for a commerce platform, more in the model of SAP Store than App Exchange, that allows a simple, credit-card-based, no contract way or sales-exec-will-call way to buy and deploy apps. There’s also the issue of whether there really is a market for citizen developers, and if that market, which is where is looking for its 100 million-strong developer army, can generate real revenue for its developers and and really useful apps for its users.

And, particularly for, there’s the question of whether focusing on CRM and its allied processes is sufficiently ambitious to make the company’s dreams of platform dominance a reality. Right now’s platform strategy, as Parker Harris told me last January, is to be the best CRM platform around. While there is no direct intention to exclude other domains, so far the messaging is clearly focused on CRM-based opportunities. To its credit, Trailhead’s trails and modules are more generic than CRM-focused, but my take of the conference audience was that there wasn’t a whole lot of non-CRM thinking in the crowd. There were sessions on IoT, AI, and bots, and most of the CRm sessions were generic as well (“The road ahead for Lightning”, “Process Builder roundtable”). But my read of the audience was CRM-nerd heavy, and no real representation from other lines of business.

Again, that’s a positive early on, but not in the long run – at some point will want to entice the next great apps developers in supply chain, human resources, and other domains before SAP or Microsoft make a credible case to these constituents for their platforms. But in the meantime, hats off to for building a program – combining some well-designed and curated-for-fun-and-meaning training modules – that hit what ethologists and cognitive scientists would call the umvelt of the developer community: that perceptual, experiential reality that is unique to these individuals. It’s no small achievement to merely understand that umvelt – to replicate it so clearly is exceptional.

The challenge is on in the platform wars. May the best umvelt win.