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.

When I was at EclipseCon this year, I sat down with Oliver Wolf from Sopera.de to talk about the newly announced Swordfish, SOA project. Having talked about Swordfish before in RedMonkTV, I ask Oliver to quickly catch us up since last we talked. They’ve announced their release date (which has occurred since this was filmed), including all the compliance and IP cleaning.

Oliver then gives us a very quick overview of Swordfish: a runtime for implementing SOAs. I then ask Oliver what Swordfish’s “take” on SOA is, that is, what’s it’s general philosophy, so to speak of what the definition of an SOA. As Oliver explains, it starts from a decentralized ESB.

We then discuss what this decentralization means for Swordfish’s various SOA components. I then ask how Swordfish came to be and where the project is now.

Getting back to the type of SOA that Swordfish embodies, I ask Oliver what types of workloads Swordfish is suited for. Having announced Swordfish at this year’s EclipseCon, along with more than five sessions on the topic, I ask Oliver what how it’s been received and what people have been asking. Finally, I ask Oliver to tell us how Swordfish fits into the overall Eclipse Runtime strategy.

Disclosure: The Eclipse Foundation is a client, sponsored this video, and paid T&E to EclipseCon.

Earlier this week, Adobe announced an addition to their developer program (Adobe Enterprise Developer Program) than enables developers to deploy LiveCycle ES instances to Amazon EC2. The LiveCycle instances use JBoss’ application server and Adobe is paying for 10 hours of time a month on EC2. Enrollment in the developer program, like Microsoft’s MSDN isn’t free: it’s list priced at $1,500 a year.

Adobe’s Enterprise Roof

LiveCycle ES is document management, workflow back-end, with plenty of general SOA stuff dusted through-out. As a brand, it’s also the home of middleware and enterprise software in Adobe, recently having sucked in project Genesis and, longer ago, open sourced BlazeDS. But, that’s aside from the point.

Trying to make dev lives easier

When I spoke with Adobe last week about this announcement, they had a nicely pragmatic take on it: while they, clearly were proud of LiveCycle ES, the 6 gig download didn’t make for a fun install and setup experience. Setting up any piece of middleware is typically annoying, stackless stack or no. Part of the tool-chain Adobe is providing is built around addressing the setup-deply-run-teardown-repeat cycle: the idea is to make it as easy, and quick, as possible to get a fresh instance of ES.

The goal here was to work with developers, not operations folks deploying LiveCycle ES. That said, it turns out that Adobe does offer hosting LiveCycle instances for those who’d rather do that than host it on-premise.

Developers as leading indicators

As with virtualization, you can look at this developer focus as a leading indicator of wider cloud-use. Many years before virtualization became the bell of the ball, developers were using it to build out virtual labs to get their day-to-day job done without all those under-the-desk server farms. Folks like Austin-based Surgient have been having a go at tooling around these needs for awhile now.

Uptake

Running stuff in EC2 is no huge deal now, but it’s great to see larger ISVs – Oracle, RedHat, now Adobe – formalizing what should be a common development practice. While $1,500 may not be that low of a barrier, for the organization that use LiveCycle ES already, I’m sure it’ll be welcome.

Adobe SaaS Cloud Offerings, Updated

I’ve been keeping an eye on what Adobe has been doing in, as we call it now the cloud for sometime. They actually have had several hosted services for sometime, long enough to EoL some of them. Adobe acquired Buzzword, a hosted, Flex based word processor; finally launching Acrobat.com not too long ago.

Their cloud offerings, as it were, have been largely end-user centric rather than catering to developers. Hopefully, both fronts will expand there, esp. the developer world where Adobe is in the long process of building up a firm developer ecosystem around the Flash Platform.

Disclosure: Adobe and RedHat are clients.

About a month ago, I did a webinar with MuleSource with some advice for IT departments in these “tough times.” You have to register to view the recording, available here, but I’ll tell you it’s totally worth it! ;> You can also flip through the slides above, but the recording is much richer, of course.

The talk is not really technology focused at all, but more focused on the types of things IT folks should be thinking about and doing while they’re waiting for the good times to return. In summary: figure out how save your ass first (hint: tells the people who give you money what they’re getting for their cash), and then, if you can, work on small wins that bring in new revenue for the company. Being something of an SOA basher, somewhat counter-intutively I look at towards the original goals and motivations for SOAs before they went WS-* as a potential framework to help.

Also, the other nice part is that I end up having several side conversations with MuleSource’s Mahau Ma and also from the questions submitted during the talk.

Disclosure: MuleSource is a client and paid for this webinar.

This coming Wednesday I’ll be co-hosting a webinar put on by MuleSource, entitled “Building a Recession-Proof SOA Strategy”. The talk will go over the idea of using a leaned-up approach to SOA to help build the type of enterprise architecture needed to get through tight spending times. The idea here is that controls, governance, and the reporting capabilities that those two enable can help IT departments survive in tight spending times as we have now.

Put another way, here’s the longer synopsis:

With the arrival of an economic downturn, and with the looming prospect of tight budgets in 2009, IT managers are all taking a hard look at their project portfolios to separate the “need-to-have” from the “nice-to-have.” How does your SOA plan fit into all of this? Does it make sense to pursue SOA in this environment? Join RedMonk Industry Analyst Michael Cote and open source software provider, MuleSource for a 60-minute webinar. In this webinar, Michael Cote will build a case for why leveraging the benefits of SOA is all the more crucial in a tight budget environment. During this time, Michael will also explain how to leverage techniques such as open source software, pragmatic architectural choices, and proper governance techniques to maximize ROI and minimize risk.

If you’re interested, sign up now and we’ll see you there ;>

Disclosure: MuleSource is a client.