Sapphire 07: Support, Enterprise 2.0

This morning we, the Blogger’s Corner, have had two sessions so far:

• Uwe Hommel and Greg Pike about Maintenance and Support
• Dennis Moore about emerging tech and “Enterprise 2.0” at SAP

As you can imagine, in both sessions the bloggers were most curious about applying public web think to SAP.

Co-creating and SLAs

With Uwe and Greg, the most interesting discussions were around figuring out how to include “co-creation” (the word that’s better than “user generated content”) in support. The inclination of people “from the web” is to try to throw all support into “the community.” This is an open source way of thinking where helpful people pitch in to resolve problems that come up when using software. Of course, Uwe was quick to point out that companies want “mission critical” support for their software. As I recall, there’s an old, old SAP piece of folk-lore about their software shutting down some Porche factory. When the factory-line is shut down, I suppose you don’t want to wait on responses in IRC.

A fun enterprisey word that kept coming up was “SLA,” or “Service Level Agreement.” An SLA is one of those things, the very idea of which makes * 2.0 and Agile people cringe: a “document” in which IT sets expectations about uptime, availability, and how long it will take to fix things. That is, you’re trying to inject predictability into IT. More important than promises though is the expectations setting an SLA does. It’s hard to work in a business if you’re always defining what your job is, on the fly. And though it’s no golden hammer, SLAs are at least something beyond “keep everything up and running.”

What is Support?

Poking my head into the thread here a little bit, increasingly it seems understanding and selling support is one of the few things software companies will be able to charge for. Sure, this is my old “open source eventually will zero out all licensing costs” scenario which is too much of an “everything’s dead” line of thought to take too literally. More importantly, my sense is that what it means “to provide support” is an ill documented craft itself. Despite that, most open source companies that exist are monetizing on support (with occasional OEM and dual-license sales). I often ask these companies what support means from them. EnterpriseDB’s Andy Astor answered that question well in the content of a commercial open source company: paid support means being an advocate for your customers in the greater open source community.

That’s all the reactive side of support. There’s also the desire to make sure systems don’t became big hair-balls of unmaintainable code. That is, “legacy systems.”

Here are my notes:

Enterprise 2.0 & Emergent Tech

Before lunch, we talked with Dennis Moore, General Manager of Emerging Solutions. Here, the bulk of the conversation was around a Duet update (the Office-based UI that SAP and Microsoft do), Enterprise Search, and which features to pull from * 2.0 think into SAP.

Duet

I’m waiting for Duet to be integrated into Microsoft Project because that’s what I use for everything. –CIO on CIO Lunch Panel when asked what he uses for project management

Jason Wood drilled down into Duet, asking what the biggest hassle has been so far. While no-one is ever going to tell you about “hassles” in public, they’ll tell you about “challenges.” Dennis said that they mostly revolved around non-technicalgical things, what we might call business requirements. Putting it into my own words, for SAP, the issues have been around Microsoft understanding the intricacies for best practices in business process. Sure, that’s why they partnered with SAP, right?

Enterprise Search

On Enterprise Search, we got sort of an architectural overview: you’re searching over objects in the system, so you can take actions on them instead of just “dumb” (my word) keyword searches. See my note from SAP TechEd last year for more context.

Tagging Uncertainty

There was also some commentary on tags as being too two dimensional. The nice analogy here was the need for disambiguation pages in wikipedia. This all didn’t mean throwing out tags, it just called for more gardening of those tags. But, the intent seemed to be a lot more gardening than more * 2.0 inclined people might assume.

And here, we get the biggest soft of difference between * 2.0 think and enterprise think. In Enterprise-think, you’re always trying to eliminate as much uncertainty as possible: that transaction will commit, this tag “hr” really means “human resources,” or I know the state of all my open orders. Whereas in * 2.0, uncertainty is not so much a concern. In fact, there’s a certain suspicion of certainty: once something is certain, it can’t be changed, at least semantically, but often functionally.

To pull a sort of pre-folksononmy enterprise tag, think of titles in a company. Those are sort of “assigned” and highly taxonomic “tags,” applied to either people, teams, or business units. Titles are always going out of whack with the actual work the titled entities are doing. There’s no “Edit Me” link on business cards. So, though a community may know the true title-as-tag of a person, team, or LOB, they can’t change it. In many scenarios that’s great for command-and-control purposes (which aren’t always bad when cash and laws are involved). In others, of course, the lack of “Edit Me” sucks. (Aside: “Edit Me” is sort of like the “View Source” of the Web 2.0 world isn’t it?)

“Enterprise”

I tried to get a sense for what makes Enterprise 2.0 so enterprise. Dennis actually had a nice response in that it was the old “business is complex! transactions! boo!” idea, but he articulated it in a way that was less “boo, you wiki-schmucks!” and more “hey, these long, state-full transactions are out there and we need to provide software for them. His basic premiss was that most * 2.0 technologies were stateless (which is a kinder way of saying “simple”). Where-as business processes (those being the chewing stick of Enterprise Software) are state-full and run over a long time. So, you might have a purchasing order request that has to pass back-and-forth between the requester and 3 different approvers.

Now, while we didn’t dig too deep into it, the point here was that the more control and certainty you want to have over a given process, or workflow, the less 2.0 you can have…hmm…”more control, less 2.0″?

The Need for “Enterprise” Scenerios

While buy into this line of thinking as my first reaction, I’m still at pains to outline a handful of scenerios where I’m like “whao, we need some enterprise functionality.” Don’t take that as naive understanding on my part: the issue is more that when the E-word is brought up with the * 2.0 crowd, it’s usually a lot more FUD than show. Maybe that’d be a good topic for a little video while I’m here: tell me about some crazy enterprisey thing that all this Web 2.0 stuff just blows up on. The point here is that the Enterprise Software Crowd isn’t too good at articulating these deathly complex scenarios to all the rabbig Web 2.0 crowd. The conversation answering why it’s so complex always begins with, “woo…it’s hard to explain because it’s so…complex.” The question is: does “Enterprise” simply equal “complex”?

Here are notes:

(Sorry for the lack of links, I’m trying to publish this quickly rather than perfectly.)

Disclaimer: SAP paid for travel and stay here. EnterpriseDB is a client.

Technorati Tags: sapphire07, atlanta, sap, enterprise2.0, *2.0, search, support