The Need for Timely Software – SAP TechEd 2009

There was no giant news at SAP TehcEd Phoenix a few weeks ago, but in the nooks and crannies there were some previews of things to come and the drawn-out proving of SAP’s notion of “timeless software,” or “pace layering,” as James likes to call it.

But, a technology company can’t be judged entirely by its potential, but rather by its code, and there was little of that shipping in Phoenix. Still, the overall SAP platform sentiment was good, as demonstrated by all of the demos that layered on-top of “old” SAP systems. That sentiment just needs some acceleration on both the customer and SAP.

Timeless Software

Replying to James’ coverage of last year‘s TechEd, SAP’s CTO Vishal Sikka described “timeless software” thus:

I believe [timeless software] addresses the fundamental issue of bringing innovation, including deep technical innovation, in a way that is non-disruptive to customers. With the vast breadth that our solutions cover, without breaking coherence, and given our long-lived relationships with our customers, often decades long, this is a central part of our strategy going forward.

As you observed, we see constant and furious change across all layers of the technology stack: from the fabric of processors, memory and network that grows non-linearly, to the ever accelerating changes that businesses go through, from UI technologies that frequently appear (roughly twice a year) to dazzle end-users, to even programming languages (a major new language shows up every 10 years or so, minor ones more frequently, less time than a mature application lives at a customer), change is the only constant. Timeless Software ensures that we continually bring innovation without disruption. SOA was the first step in doing so, our CRM is showing the way with decoupled UI and mobile experiences on top. BIA is showing elastic data management and more is on the way.”

When it comes to “innovation without disruption” SAP’s story has been the same in recent years, and somewhat unique to SAP. Whereas most technology companies are eager to tell you about The New Thing, hiding their aging cash cows (if they have any) in the background, SAP is eager to tell you about their past and how utterly reliable it is.

Whether you throw it under the words R/3, NetWeaver, ABAP, “landscape,” “core,” or “timeless software,” what SAP is saying is: the software platforms our customers run their business on are mostly just fine, and mucking with them to inject the latest gee-gaw every few years is a bad idea. Instead of changes to core product, SAP’s strategy for evolution is to use an SOA-driven approach to layered applications (though, even that is tediously un-timeless as we’ll see below). Put in the vernacular, the back-end rarely changes, but clients and UI’s will come and go.

To go down the happy path, as SAP’s Thomas Jung put it in a recent enterprise geeks podcast, though many (all?) of the demos shown in the TechEd keynote weren’t “shipping” or even products, “just about anything they showed could be built now.” And that’s the ultimate desire of the SAP architecture – and also why SAP has gotten dinged for maintenance hikes of late: without new code to sell, maintenance hikes are one of the few ways to grow revenue.

Change in the SAP world is slow. At best, you can A-Team style weld on something new and fancy and wait for it to be sucked into the core.

Indeed, to hear many tell it, slow change is exactly what users and customers want from SAP. SAP is not in the game of helping companies be disruptive in their industry. Instead, SAP is in the game of day-to-day business and “protecting the chasm” (a company without a chasm probably can’t afford SAP), to use the Moore metaphor for maintaining the status quo.

And this position frustrates people who cover technology to no end. Popular, US-centric enterprise tech-think is founded on helping companies – even forcing them – to be disruptive. Use chattering class, then, finds a tech company like SAP perplexing because SAP refused to fit the only mold we think exists.

Timely Software

After taking a diffuse path to calling SAP a fuddy-duddy, let’s see what’s not “timeless” about them.

Social Media

Somewhat on time – frustratingly slow, again, for us tech gas bags and 2.0 types – SAP has gotten giddy about “social media.” By this, I reckon, they mean the consumerization of IT, that is, applying all that whiz-bang public web technology and innovation behind the firewall: anything with a 2.0 suction-cupped onto its end.

I’d almost given up on “social media” as a well to keep drawing enterprise water from. From the freshest startup to Lotus, everyone seems to have long ago delivered apps that use “social media” for a fresh go at the windmill of white-collar productivity and sales. Witness Dell making $3 million off Twitter. But, SAP apparently sees that now is a good time to suck it into their ecosystem. There was no end of “social media” mentions with references to Twitter and a quaint case of Google envy. It seems there’s more to this Twitter thing than reading about dogs taking showers, as @ZiaYusuf nicely joked.

Speaking of windmills, one of my fellow Blogger’s Corner members, Jevon MacDonald, had a several goes at finding the actual code (shipping product or service) behind this social media madness with several SAP’ers – there wasn’t really any. There are nice labs projects as always, but productizing seems elusive. Still, there was such a fervor around the topic and several nice demos, if only during Demo Jam.

Business ByDesign

As The Mythical Man Month epigraphs from an old New Orleans menu:

Good cooking takes time.

If you are made to wait, it is to serve you better, and to please you.

Still in the slow-cooker, a perennial topic for SAP is Business ByDesign, SAP’s SaaS product targeted at the mid-market. Since the event that elicited James’ recent commentary on the topic nothing has really changed.

Asked by one of the bloggers (I forget who, apologies) if there was any road-map sharing between BBD and mainline SAP, one SAP’s CTO Vishal Sikka perfectly captured the split problem SAP has with BBD.

First, the Vishal said no. In fact, the business use cases for the two product lines is so different that it’s hard to imagine any cross-over or merging of BBD and the existing SAP landscape. The blogger then reframed and said, surely there’s technologies and practices you’ve discovered in the development of BBD that you can apply to the rest of the company. Vishal’s face lit up, being a technical person, and he rattled off all sorts of lessons learned and technologies that could be crossed over for product development.

While the technology of BBD may be applicable to enterprise software, it seemed, BBD is not applicable to enterprise sales. Indeed, as Vishal put it, BBD is “all about the stuff you need to run a company of 50 to 500 people.”

This has been the story of BBD all along for SAP, and there’s wiggle room on all sides. I have no idea about the enterprise feature fidelity between BBD and classic SAP, and even less knowledge about what’s technologically possible vs. what SAP segmentation allows for. Once BBD is out of its closed pre-release, we’ll see.

See Dennis Howlett’s notes on BBD from SAP TechEd in Vienna.

Threats and Change

Sap does have to new things, esp. as the status quo changes. As slow as large companies may take to change their technology needs, if you’re a status quo arms dealer, like SAP, you easily fall into changing even more slowly. What does SAP see and what should they see as threats?

The Kids

Like all status quo companies, SAP obsesses (this year at least) about changes to the work force that cause changes to the business process SAP implements and executes. Here, there’s the specter of “The Kids.” All these “digital natives” who have expectations (we’re told) not only of the tools they can use to get their work done, but also have shockingly different ideas about authority, team work, revenue generation processes, and “work” itself.

As Robert Brook outlined in one of his recent podcasts, incoming (young) members of the UK Parliament might be expecting to use Facebook, Google Apps, or even Twitter to interact with their constituency. After all, for many, those tools are a large part of how they got there. Or you can see Obama’s machinations to continue using his Blackberry in the White House.

I don’t think “The Kids” are any smarter than previous generations when it comes to work or IT – in fact, as Ed Herrmann pointed out over cookies at TechEd, when it comes to IT, the current iteration of The Kids have had it easy: no command line or loading games in BASIC. Rather, what’s happening here is business IT falling behind consumer IT with respect to usability, productivity, performance, and price.

Vendors will use excuses like compliance, security, and regulations, all of which are real, but still excuses. Their job is to decimate those road-blocks and charge a premium for doing so. Sadly, most business technology vendors don’t see things that way.

Still, for SAP the point is not to foist whiz-bang on their customers before they ask for it, but to get that whiz-bang ready to ship just before their customers know they want it, as Brian Sommer forcefully pointed out in a Blogger’s Corner round table on the topic of sustainability. This is a path that IBM, for example, does marginally well at – ultimately what big, tech commercial research is for: predicting the future requirements instead of waiting for The Customer to discover those requirements and then tell vendors what they want.

In truth, the core processes that run business don’t change much. Rather, the way employees and customers interact with those ancient processes changes. Retail started out with walking up to a counter and asking for what you wanted. Then retailers put the stock on the floor and let customers get it themselves. Somewhere in there was catalog sales, and then Wal-Mart and other big-box stores ravaged the mom-and-pops. And now, Amazon and web buying.

The core process of stocking inventory, giving the inventory to customers, getting the customers money, then re-stocking has only slowly changed over the past 100 plus years. Maybe once we can shoot out tube socks on our desk-fabber after feeding a bunch of shopping bags into the fabber and pirating the sock CAD files…things will really change. But until we’re all favela chic, it’s pretty much the same.

Enabling light change to the interface and touch points for an ancient business process is what SAP wants to be in, and it’s mostly what they mean by “timeless software.” Here, the basic engine and checks on business stay the same, but suddenly you have an iPhone interface where you take a picture of a hoodie you like that a passerby is wearing with your Augmented Reality BuyIt app, upload it to the iPhone-faced store, where the hoodie is identified, and you’re shown near-by store that stock the hoodie or can multi-touch up an order and have it shipped to you.

The interface – the “store” – is different, but the business process of cash-to-carry is mostly the same. What The Kids bring, then, is not some radically new notions of core business process, but new ways of interfacing with the same old process.

Legacy SOA

In theory, SAP software is open enough to deal with these “multi-headed” ways of cash-to-carry (as one process example). Collective sentiment says that in practice, the current SAP install base is not as well positioned as they could be to slap new heads on the beast as frequently as The Kids demand. SAP tech-heads aspire to this service oriented view, but even they recognize that SOA as we know it is too slow and dumb for a hydra-headed business.

Beyond SOA

In his keynote, Vishal Sikka said that SAP needs to go “significantly beyond SOA.” I asked him what he meant by this during a Blogger’s Corner round table. I boiled down Vishal’s answer to a few points:

• SOAP-driven web services (what SOA became) are too slow for direct client interaction – as with RIA driven portals like LiveCycle Mosaic or the “super secret demo” from Thomas Jung during RIA Hacker Night.
• SOA as we know it cannot really deal with large sets of data effectively.
• The stringent governance controls in place for SOAs make changes to the services take too long.

In short, SOA as we know it is suffering from leaky abstractions, like all multi-version, platform-oriented software does.

Big Data

In that same session, I asked Vishal what changes SAP was thinking about making to “the core.” His answer was quick and seemed spot on:

• Make changes to benefit from multi-core and large memory sets, for example, running previously unimaginable data sets in memory rather than having them database-bound. This gets towards doing something in the Big Data area, were no one has really shown they understand what the trend means for mainstream business processes, Tweeting carrots aside.
• Enabling heavy duty-eventing, which usually can be boiled down to “can handle massive concurrent requests, data, and processing.” Indeed, operating at that scale seems to require new technology if the business processes behind Facebook and Twitter are any indication, “cloud” as they’re calling it.

Indeed, during the EU edition of TechEd this week in Vienna, SAP has been speaking to the “beyond SQL” trend and a partnership with Teradata looks like a enterprisey start. The recent interview and demo I did with FedEx Custom Critical’s Adam Mollenkopf is a clear-cut example of what those needs help facilitate.

The Shackles of Success

Which brings us to the biggest threat to SAP: themselves. Long term, elder companies develop a sort of Stockholm syndrome with their customers requests. As mentioned above, they wait until a customer asks for something to deliver new functionality instead of taking the risk to discover what their customer doesn’t even know they want yet. Part of this is getting all wrapped up in how dramatic a technology change is, namely, that it’s always a Big Deal. In fact – and this the secret of all those disrupters – most technological change is minor and the risk of switching over has more to do with there being bugs in the new software than the new software being wrong or, more typically, someone flipping the wrong configuration switch here and there. For fear of something breaking, you avoid new technology, even of the simplest kind.

Instead of submitted to the collective Stockholm syndrome that change is bad, SAP needs to creep in the notion that updating technology is helpful and safe. Their timeless software notion gets at this, but they’re still too slow and steady. Thus far, there’s been little room to experiment, but it seems SAP is starting up a code-driven community where cracks in the status quo can be expanded to chasms.

Why Change?

Still, there’s much talking out of both sides of my mouth here. While the copious demos built on-top of the platform (as Thomas Jung pointed out) are proving out the timeless software notion, part of the problem rests on the customer base matching SAP’s conservatism. Someone has to budge.

Even the most whiz-bang obsessed TechEd attendee and SAP user will tell you that the company they work for doesn’t really (know they) want change. I asked one of these techies if their company was using all the sensors, RFID, and dry-cleaned cyberpunk, internet of things stuff IBM and SAP go on about. Their answer was simple: “nah.” The more nuanced point was better: what exactly do we do with all that data? Would it actually help us sell more? As I joked with him, I’m not sure it matters that carrots tell you when they’re going bad, sure, for high-dollar stuff like FedEx Custom Critical, but truck-loads of consumer items?

And there’s beefier hope from the SAP of past years’ visions: this year, there’s starting to be a glimmer of the imagination it takes to find problems for all those technology solutions. (Yeah, did you notice I put the cart before the horse there?) That is, convince customers they have problems that neatly fit the products you have and the possible new ways of running businesses that new technologies enable. It’s the sort of thing that’s taboo in the enterprise software world, but it’s what being a technology company is all about.

To bring it back to our man James, as reported by Dan Farber, his quick reply to SAP’s slow innovation vision in 2007 sums up the point nicely:

“We have to succeed in evolution to extend [existing customers] without disruption and also enable radical innovation, and do them in parallel,” [Peter Zencke, a member of SAP’s Executive Board and head of R&D] said. “We will evolve existing customers in an incremental way with enhancement packages. The new business process platform is not designed for substitution, but you can run it in conjunction with the Suite. On top of them comes NetWeaver, as execution platform.” Redmonk’s James Governor, who was sitting next me, said SAP’s notion of non-disruptive innovation would be like delivering babies without labor.

Disclosure: SAP paid travel and expenses to SAP TechEd 2009. See the RedMonk client list for clients mentioned.