The Semantic Argument

This post was inspired by a Video Report Card for SAP Analytics I was fortunate to be able to participate in with Jon Reed (the sponsor) and included John Appleby, Derek Loranca, and Clint Vosloo. No one paid me anything for that. :)

The last two years have seen a flurry of activity from the Analytics team at SAP. A lot of things that were promised were delivered. New tools like Visual Intelligence, Predictive Analysis? Check.  Xcelsius roadmap (including the new Design Studio)? Check. BI4 stability? Getting checkier by the day. Are their some concerns still left with these items? Sure, but we are certainly better off on these fronts than we were a year ago.

The bigger problem with the current state of the portfolio is a burgeoning list of Semantic Layers for the SAP Analytics tool set (see around 17:19 of the video). We have the Universe (the one that SAP paid €4.8 billion for in 2007 and temporarily referred to as the Common Semantic Layer in BI4 until they realized it wasn't), we have the BW semantic layer, and we have the HANA semantic layer, and none of them talk to each other particularly well (or at least best practice is that they shouldn't).*

Certainly there are some advantages to allow these three semantic layers to continuing growing in their own directions. Innovation that applies to only one data source can be sped up because it doesn't have to worry about integrating with the others. Performance can be optimized because only one source system with its particular constraints must be considered. Unfortunately I don't think that begins to outweigh the disadvantages for both customers and SAP itself.

The disadvantages for customers apply to both legacy SAP and classic BusinessObjects customers. The two key issues I see are the slowing of innovation across the portfolio and the extra work required to maintain multiple semantic layers. Even if SAP wanted to invest for all three data sources (HANA, BW, Universe) simultaneously, it just wouldn't make sense. Investing every minor semantic layer change in each system to work with all of the reporting tools in the portfolio would be absolute murder, not to mention that any change to a reporting tool would need to be run back through three different sets of semantic layer developers to ensure integration. This creates a lot of points of failure at a time when stability has been recognized as a serious source of concern for customers.

If this three-headed monster continues, it also follows that the Total Cost of Ownership of any such system is going to balloon for customers. If the BusinessObjects platform has more things running under the covers that means more or at least bigger patches which means you'll need more administration time, more testing time, and more end user communication and training. And that's just if you employ one of these tools. If you've got more than one semantic layer running you'll need to have experts in each, or one very thinly stretched expert (who will be constantly looking for another job). This also means more training for users, more confusion, and a real loss of goodwill from users who now have to understand connecting to multiple data sources in a  reporting tool rather than just understanding how the Universe works and going from there.

BW isn't either.

Multiple options exist. SAP could continue investing in all three, but that is problematic because of the reasons published above. Encouraging customers to run all of their HANA data through BW has some potential, but it seems that takes away a lot of the benefits of HANA without a lot of benefit from BW. They could invest heavily in HANA semantics and offer fantastic pricing, although that still won't solve the enormous amounts of data that are not and will never be stored in-memory that still need accessed (not to mention the loss of goodwill from legacy BusinessObjects customers whose only solution is buying new software).

In the end the best solution is simple albeit not easy: make HANA and BW work properly through the Information Design Tool (IDT - the successor to the pre-BI4 Universe Designer). I know this wouldn't be easy, but I'm not sure why we have to actively encourage people to avoid the using the IDT when connecting to BW or HANA data sources. Perfect the "common" semantic layer for any data source, and every reporting tool downstream would be able to innovate on features and not just play catch up on connectivity. It would have been better to do this before the release of BI4, spending the million man hours on perfecting the semantic layer with slight tweaks to the reporting tools. I realize that exploding pie charts with sound sell software, but software that is easy to use and cheap to maintain sells itself.

* It's worth noting that we also have legacy .UNV files (from the old Universe Designer and new Universe Design Tool), Analysis Views (for OLAP), Crystal Reports Business Views (which are deprecated but have no migration option). 

Culling the Catalog

Not that long ago (OK, that long ago) the BusinessObjects portfolio consisted of just one tool. In the last 10 or so years, that portfolio has become a bit... bloated (it's OK for me to use that word in the same way it's OK for a flight attendant to call another flight attendant "the stewardess word"). While the robust growth of the product count was justified before (BusinessObjects buying Crystal Decisions was HUGELY important and obviously SAP buying BusinessObjects was the right move in that market), SAP has begun to show that it shouldn't continue to support the full breadth of its home-grown and acquired business intelligence catalog.

The first hint at this culling of the herd was the release of Crystal Reports for Enterprise (CRE) with it's BI4 platform update. This new tool looked exactly like Webi and Crystal had a baby and got the best DNA from each parent. The second, and more obvious signal is the eventual convergence of Xcelsius into the Zen product. With these releases SAP has signaled that they recognize just throwing half the product sheet out isn't good enough and that they need to step back and see what customers actually need NOW, not what they needed years ago.

So what do customers want/need? I think SAP has nailed this spot on by focusing on functions and users rather than tools.

• The core of BI consists of canned reports, currently serviced predominantly by Crystal Reports and Web Intelligence (Webi). CRE is clearly a first stab at converging those two toolsets into something that can be developed by developers in (hopefully) a block or line format with pixel-perfect visualizations from any data source and deliverable in any number of places.
• Self-service BI used to be the domain of Web Intelligence but quite frankly, it just isn't easy enough to use for most users. Unless you are a power user and live and breath the stuff, you don't want to generate a query and format a report. You want to see something more like Explorer, where you search for "Paris leather sales" and it spits you out a number. Power users want to go deeper, but they also want a more consumer-like experience, and Visual Intelligence (or Visi, part of the Explorer family) is going to make those people very happy. For those power-power users, SAP is also adding Predictive Analysis, something it can tightly integrate with its portfolio and not have to pass money down the line because they're just licensing another vendor's technology.
• Finally, there are BI applications, which go beyond just delivering data into something featuring more interactivity and extensibility than we've been able to provide before. If Zen can meet its somewhat lofty goals while still allowing non-developers to develop (as Xcelsius does), then I can buy into bringing all of those use cases under one umbrella.

Some of you will (rightly) point out that I've opened a blog about "thinning" the BusinessObjects portfolio by listing 4 new products (CRE, Visi, Predictive Analysis ,and Zen) but that really had to happen. Overextending tools like Webi (which started as self-service and evolved into canned reports) is what got us in this mess in the first place. SAP is basically reinventing their portfolio to solve current problems without tossing aside the investments so many of us have already made into a specific tool.

Are there still open questions? Sure. Where does Exploration Views fit in (for my money, it is squarely between Core BI and Self-Service BI)? How do they invest in the future without letting their current tools die on the vine (as many have accused Xcelsius of doing)? How do they make sure they don't bet on the wrong horse (something something iPads and Flash)? When are they going to get the mobile piece right (they are getting closer but aren't quite there all the way across the platform)? When will Deski actually be blighted from the face of the earth (not soon enough)?

I know some are confused by the direction SAP is taking its BI portfolio, but I think this is just because most people simply haven't bought into SAP's new commitment to renewal. We aren't used to an enterprise vendor willing to invest so heavily into a completely new direction. Will this new direction give them some new license sales in the short term? Sure, but I don't think enough to offset the cost to develop it (most people with Explorer licenses don't even have to pay for Visi). SAP knows where they need to be in order to lead the market in 10 years, and they're willing to buy into that vision early.

SAP as a Platform (SaaP?)

If you were wondering why I hadn't posted my thoughts on last week's ASUG Annual Conference/SAPPHIRE  Now, it's because I gave them over at ASUGNews.

http://www.asugnews.com/2012/05/22/saps-platform-play-why-bi-pros-should-be-bullish/

Thanks so much to Tom Wailgum for looking past all of the swear words in my first draft and removing this link from the Ricky Bobby quote (NSFW)

Is SAP Still Missing the Mark on Mobile?

We are at a point in enterprise mobility where everyone has assumed it is a given but no one has exactly figured it out. Is SAP shooting itself in the foot by trying to have a big fixed cost (SUP) and high variable costs (uber-expensive apps), meaning that they'll have to talk people into surmounting expensive barriers to entry on two separate fronts. 


Consumerism and Platforms
Most people think that the "consumer experience" is about things working seamlessly and being super intuitive. That's half the story (and a big half, to be sure), but the other half (and the easier half, to be sure) is choice. We've all, I'm sure, read the Google Platforms rant. The reason Platforms are great is because if you can own the data and the infrastructure (which are the most valuable bits -- sort of like the bacon of IT) and you let others extend it and propogate it, you win without doing a whole lot of the work. You want to own the platform.

Let's use mobile Twitter as an example. Sure, you want to sell directly (the mobile Twitter website) and you'd like to have a brick and mortar store of your own (the official Twitter iOS app) and you might even buy a distributor (Tweetdeck), but in the end you really mostly just want people to be writing and reading tweets. That's why you build out an API and let all sorts of other people sell your product for you. And other people selling your product is a good thing. 

That gives people choice, and people like choice (I hate Tweetdeck, but I love Hootsuite, which enables me to continue to use Twitter's core product without using it's distribution). It also generates competition, which makes your product even more valuable in the long run. Enterprise software vendors need to remember that what they really want to own is the tweets data within their systems of record.


Developers Wanted
SAP is getting closer to having a fleshed-out mobile developer ecosystem, but at present it isn't open enough to generate a lot of innovation or competition -- the table stakes are just too high. SAP needs to make sure the price is low enough to engage enough developers to give users choice. Need a mobile solution to approve work orders? It sure would be nice to have a couple of different apps that are inexpensive enough to try out. 


In order to get those apps you need a robust developer ecosystem. In order to get that robust developer ecosystem, you need to leave enough money on the table for those developers, and you need to make it really easy for them to develop software (check out the 4:05 mark of JD-OD's video).


The Back of the Napkin

Per SAP CIO Oliver Bussmann, SAP manages some 12,500 iPads and those iPads have downloaded around 120,000 apps from their Afaria appstore (that's around 10 apps/user). For SAP. Customers, each of those apps will cost somewhere between 25 and 100 euros, so we'll say that these each average $50/app (yes, I did just switch currencies - it's cool, though, since SAP can handle that). That means that for each user, which might download 10 enteprise apps, we've effectively doubled the price of a $500 iPad (presumably people important enough to warrant more memory or 3G connections would warrant more/better apps as well) and that is before the price of SUP, Netweaver Gateway, and Afaria are taken into account. 


To justify that sort of expense for the average mobile-enabled user, you have to basically disable their desktop experience to save on that cost. I for one don't know many people that are willing or able to totally leave their desktop or laptop behind yet. The easy solution? Charge less for apps. The problem is, that's the only place third-party developers can currently make money (and they have to make enough to cover their own infrastructure first).

So Where Are We?
The solution -- and one, I might add, that'll be hard to swallow -- is that SAP needs to give up on making money at every possible point in the "enterprise data to mobile device" supply chain.

1. Give developers access to SUP, Netweaver Gateway, and Afaria for free to learn the technology. This will allow certain shops to participate in the market that never would have otherwise. You'll end up with some crap applications, but you'll also unearth some gems. The free market works in an app store.
2. Charge customers for the mobile infrastructure one-time. Let them connect to it via whatever means they want. This should not be a tremendously high price. How much extra do Workday or Salesforce customers pay for their mobile access?
3. Do what you can to keep App prices down. This will largely be up to the developer, but work with them to encourage "creative" pricing. 

SAP-broadly should be trying to learn from what BusinessObjects is doing in the mobile space. It has had some struggles, but it is poised to move enterprise business intelligence to the mobile device because it has figured out the cost (an enterprise mobile service which isn't cheap but also doesn't seem to be a tremendously huge obstacle) combined with a couple of solid if not perfect free applications. They also have a developer ecosystem that is willing to play because they have low barriers to entry. This means you only have to pay once for the platform and then can distribute it however you see fit. This is the sort of model consumers have come to expect and that enterprises should flock to. 


I understand SAP wants to make money everywhere in the process, but they have to remember that their back-end systems still being relevant in 10 years will be largely dependent on enterprises being able to access and manipulate that data from anywhere. Making it really expensive and unattractive to do that right now isn't going to help on that front.