Skating to where the puck is

Being an SAP Mentor is an interesting situation. The relationship with SAP usually feels amazingly collaborative, but occasionally uncomfortably adversarial. ThIs is probably a healthy place for a relationship with a massive organization to be. Every organization includes many great people and interactions with those people are always delightful. Every organization is also, as an organization, predisposed to get the answers to certain questions consistently right and the answers to other sorts of questions consistently wrong.

One such question that SAP has consistently gotten wrong in the past is how to push technology adoption among a massive install base. Historically, it would appear that SAP has tended to try to monetize upgrades to underlying technology in order to recoup development costs or profit from its technology offerings. Netweaver, BW, Visual Composer, add-ons like SSO and Gateway, Personas, Business Client, and HANA* are all technologies in which SAP has either underinvested due to lack of direct revenue potential (BW especially) or has tried to monetize. The result is that widely deployed "free" technology from SAP often stagnates while advanced technology with an additional cost often sees limited adoption in SAP's install base.

This outcome is terrible for SAP's business. It makes it very difficult for SAP to keep its application offerings competitive in the marketplace. The reason is that basic application functionality to be competitive is often dependent on improvements in underlying technology. But if technology is either widely deployed and under-featured or decently featured but not widely deployed, then applications need to use only the under-featured technology stack in order to have a large enough potential install base to justify development costs. In other words, SAP often forces itself to build applications on sub-par technology.

We see this dynamic constantly with SAP. One example is UI technology. Clearly a long-standing weakness of SAP's applications has been user-interface and user-experience. The SAP GUI is outdated and SAP's attempts to improve on it like the Business Client have, in my opinion, been torpedoed by SAP's monetization reflex. They haven't initially been better enough to see widespread adoption under a monetization scheme, and with lack of adoption, investment has faded. A similar dynamic played out with SAP's support for Flash and Silverlight as UI technologies for years after it had become clear they were destined for the trash-heap of web-UI delivery technologies.

And yet, over the last 4 years, SAP has been able to overcome this tendency in one area that may be incredibly important to its long-term business prospects around the newly announced S/4HANA. In the case of a key succession of technologies, SAP has been able to do something different, with impressive results. Those technologies: Gateway, SAP UI5, and Fiori**.

Initially, all seemed to be going well. SAP developed Gateway in part due to prodding from influencers like SAP Mentors around the need for a modern, RESTful API layer in SAP applications to allow the development of custom user interfaces and add-ons in a sustainable manner. DJ Adams and others showed the way with projects like the Alternative Dispatch Layer (in 2009), to make development of these APIs easier. Uwe Fetzer taught the ABAP stack to speak JSON. And suddenly one could fairly easily create modern-looking APIs on SAP systems. SAP folded a lot of those learnings into Gateway, which was a great way to push the tools for building modern APIs into SAP's applications and out to the install-base.

Well, it would have been, but SAP made its usual mistake: it attempted to monetize Gateway.

The result of the monetization attempt could be predicted well enough. It would make roll-out of Gateway to the SAP install base slow, at best. Fiori would be delayed because it would need to build out its own API layer rather than relying on Gateway technology. Applications like Simple Finance or S/4HANA that are dependent on Fiori would subsequently be delayed, if they were created at all. Perhaps Fiori's roll-out is delayed by a year, Simple Finance by 2 years, and S/4HANA isn't announced until 2018.

But S/4HANA was announced in January 2015. So what went differently this time?

Fortunately, back in 2011, shortly after the initial Gateway monetization strategy was announced, SAP Mentors like Graham Robinson and other community members stepped in to explain why this was a mistake and push back against the strategy, both publicly and privately. While clearly not the only reason for SAP's change of heart, this feedback from the community was powerful, and ultimately SAP revised Gateway licensing in 2012 so that it made sense for SAP, its partners, and customers to build new applications using Gateway.

This revision set us on the path to relatively quick uptake of SAP UI5 (a modern browser-based front-end framework which leverages the Gateway APIs) and later Fiori and the Fiori apps (most of which are based on UI5 and Gateway APIs). With Fiori, SAP again thought short-term and attempted to monetize Fiori, only reversing course and including Fiori with existing Business Suite licenses after similar pressure from another group of SAP Mentors who had experienced customers' frustration with SAP's stagnant user-experience. These Mentors, community members, and analysts were able to communicate the role Fiori needed to play in guarding against SAP customers migrating to cloud vendors offering a more compelling user-experience story.

Fiori, meanwhile, is a hit and serves as the basis for Simple Finance and now S/4HANA - SAP's recently announced blockbuster refresh of the entire Business Suite offering, which SAP clearly hopes will drive its business for the next 10 years. Would that be happening now if SAP had remained on its standard course of attempting to monetize Gateway? I don't think so. The interaction with SAP on these topics often left some feathers a bit ruffled, but it sure must be nice for those like Graham and DJ to see some of the fruits of those discussions in major products like S/4HANA.

---

*A note on HANA: I think that HANA may be the exception in this story. Unlikely most of SAP's other technology offerings, HANA is good enough to be competitive on its own, and not simply as a platform for SAP's applications. The results are not yet in on the HANA monetization strategy, but things are looking OK, if not great. Of course, Graham has something to say about that, and what he says is always worth reading.

** Fiori is actually a design language focused on user-experience and a line of mini-applications implementing the Fiori design language to improve SAP Business Suite user-experience for specific business processes. However in the context of S/4HANA we can think of Fiori as a prerequisite and enabling component, like a technology prerequisite.

ABAP development - the dream and the reality

Late last week I did a podcast with Jon Reed and Graham Robinson on SAP's developer engagement initiatives. You can watch that here.

This discussion, and the fact that I'm back doing some serious ABAP development after a lot of non-ABAP work, got me thinking about the value SAP's application ecosystem contains that developers would love to add to, to SAP's gain. But it's very difficult to add value in this ecosystem as a developer because of (among other things) the weaknesses of the ABAP development environment. What, I asked myself, would a truly strong ABAP development environment would look like. Here are a few thoughts:

• ABAP system as a decentralized version control system (DVCS) node - An ABAP system should act as a true DVCS node. This is a good explanation of the nirvana you too could experience with a DVCS, with pictures of a cute dog. In short, an ABAP system should, at the package level or at the full system level, be able to commit changes, push those changes to a remote repository, pull changes from a remote repository, maintain branches, and merge (with user input if necessary) those branches. These descriptions use Git parlance, because that is what I know.
• Branch and merge - Related to behaving as a DVCS, the ABAP system should be able to support full branch & merge semantics. I'm not sure how well I can explain this. I'll just tell you, it's a great feeling to have the ability to create a branch of a complex project, rip out an integral component, completely rewrite it, merge those changes back into the main development branch, and have none of the other 3 people working on closely related parts of the project notice any change expect that things just work better. I know. I did it last week. Oh, and I simultaneously made fixes as they were requested on other branches of the project and pushed those out to my co-workers while I was working on that rip-and-replace. Good luck pulling that off on an ABAP development system.
• Namespaces - SAP should make namespaces available to open source projects for free, with minimal bureaucracy. And while you're at it, just do the same for everyone. What do I mean by "minimal bureaucracy"? A web form and account system that saves the namespace to a database after checking that no one else has already registered the same namespace. Why are namespaces important? They address the problem of naming collisions between development projects. Right now, the open source ABAP community mostly develops in the customer namespace. This is a recipe for naming-collision hell. But what other options do people have? SAP should to fix this, and fast. And while you are at it, make the namespaces versioned (see below).
• Improve SAPlink & ZAKE, and include them in the standard distribution - SAPLink and ZAKE are the defacto standard ways to develop and distribute open source ABAP code. They are massive improvements over the status quo, but they aren't very widely installed, and they are not perfect. If SAP wants a healthy ABAP developer community, I'd recommend that SAP join these projects, contribute to them, and make them awesome. Then include (up-to-date) versions of them in the standard Netweaver ABAP distribution.
• Speaking of up-to-date, implement ABAP package and dependency management - Maven is kind of a nightmare, but it works. Let's say I want an mock/fake library like MockA (highly recommended) to use in my ABAP Unit tests. I go out and find it on Github, install SAPLink (which doesn't work properly so I have to go back and activate everything), download the .slnk file, install that using SAPLink (which doesn't properly install some interfaces, so I have to reinstall it), and finally I can use it in my project. But I find a bug! So I report that bug to the maintainer, who is awesome and fixes it in less than a day. My reward? I get to do the whole download, install, install all over again. We should just be able to list library versions as dependencies of our packages, classes, and test classes, and the system should handle downloading and installing them. But this will result in organizational chaos, you say. No, it won't. Because everyone will be using namespaces, and those namespaces will be versioned, so we can have more than one version of a library installed and usable at a time.

Right now it's a bit frustrating to switch between ABAP and non-ABAP development. The tooling in the Javascript and Java ecosystems is so far superior and so much more concerned with developer productivity that it begins to be painful to return to ABAP. I can't imagine what it would be like to come to the ABAP ecosystem with no background.

This is a shame, because it's a nice language in a lot of ways, and the business applications that are accessible through ABAP are an absolute goldmine of information and business process execution logic that loads of developers would love to add value to, in the process creating a great deal of value for SAP. If they could only be productive on the platform. I'd love to see SAP take ownership of the developer experience and make the ABAP ecosystem flourish.

The BW/BObj Rift - We're all just services

Eric Vallo has written a quite wonderful and balanced piece starting to dig into the rift between the BW and BusinessObjects BI communities over on the EVTechnologies blog. As Eric mentions, his blog was the result of quite a bit of back-and-forth between the two of us, the other principals involved in the DS Layer site, and the wider SAP and BusinessObjects communities. Eric was kind enough to kick off the conversation, and I'll continue it here. Hopefully this will evolve into a longer public conversation.

So, let's get started!

Eric did a good job of laying out the different scenarios we tend to see out in the SAP & BusinessObjects customer ecosystem right now. While each of these scenarios is clear, I think there is still a huge amount of confusion within both the BW and BusinessObjects communities about what each set of tools does and what it should be used for. In other words, when do you go for each scenario or tool? In my opinion, this confusion stems from the reality that both toolsets do a lot of things, and there is a lot of overlap. You can build a full datawarehouse and BI reporting solution using only BusinessObjects tools. And you can do the same using only BW tools. Or you can mix-and-match and pull in 3rd-party tools as well. But each toolset certainly has its strengths and weaknesses.

My take on BW's strengths and weaknesses is, perhaps, a bit out of the mainstream. But I think it is justified and, importantly, I think it is in line with SAP's vision for it's data platform. Specifically, I see BW as a set of data warehousing, data management, and systems management services. I admit readily that I've shamelessly stolen this way of describing the concept from others, but it fits so well that I have to use it. So, BW provides a set of services like the following very incomplete list:

• An abstract, platform-independent data warehouse modeling environment
• A service for imposing a semantic model on top of the data warehouse modeling environment
• An analytic engine for executing queries on the data residing under the semantic model
• Security
• Data management services like near-line storage (the ability to pretty transparently persist data in a single semantic structure across two data-stores with remarkably different latency, structure, performance, and cost characteristics while still being able to query that data "live") or archiving.
• Visualization and reporting services

The implementation of this service concept is far from perfect. In fact, today, most of these "services" aren't really recognizable as such because BW is such an integrated intertwined monster. With BW on HANA, we are now starting to see some of these services exposed individually, and the result is rather impressive.

One advantage of seeing BW as a collection of services for the purposes of this discussion is that it becomes much less important whether BW continues to exist. When viewed this way, the whole discussion about whether or not SAP HANA is going to "kill" BW becomes moot. The important question is whether the services continue to exist, either as part of BW, part of the HANA platform, or in another way. It is the services that provide the value, not BW per se.

The same actually holds true for BusinessObjects. Here we have services like the following (again, incomplete):

• A service for imposing a semantic model on existing data models
• An analytical engine for executing queries on the data residing under the semantic model
• Security
• Services for moving data from one place to another and transforming that data
• Services for tracking and analyzing data lineage and quality across multiple platforms
• Visualization and reporting services

BusinessObjects took a much more service-oriented development approach from the beginning, so many of these services are much more obvious as individual BusinessObjects products or product components. You might recognize direct descriptions of Universes, Data Services, or Information Steward, or the host of BusinessObjects reporting and visualization tools whereas in the case of the BW services there is no individual tool we can install to provide the service.

You probably also notice some overlap with the list of services in BW. Hence, the confusion.

The really interesting part of this overlap is that some of these services are provided in pretty similar ways between the two platforms (the semantic layer) while others take a very different approach (visualization and reporting services) or simply don't exist on one platform or another (abstract data warehouse modeling environment, or tracking and analyzing data lineage). It's these different approaches or unique services that differentiate the platforms.

Until SAP matures its data platform strategy and makes some decisions about which overlapping services live, die, or merge on each platform, it's going to be up to customers to do the hard thinking necessary to make the best implementation decisions for them. It is, of course, important to know what services each platform offers, what technique the platform uses to offer those services, and what kind of performance and functional characteristics similar services have on the different platforms. I hope that the podcast series Josh Fletcher and I are working on will help with that discussion across customers. But in addition to these feature considerations, there are also cost, requirements, tooling, and expertise considerations that are going to be unique to each customer.

Personally, I think BW and BusinessObjects tools both have a lot to offer and we shouldn't discount one or the other when we're talking about addressing data warehousing or BI problems. As consultants, we'll have our personal preferences, but we should try not to let that influence our customer advisory roles when addressing early design and tool selection questions.

In the data warehousing space, my strong feeling is that BW's approach (if not BW itself) is a powerful approach to making datawarehousing more accessible. It doesn't solve the basic problems of data modeling and data governance, and it can introduce its own set of problems. But BW does help abstract some really knotty technical and organizational problems that like data consistency, technical governance, platform-specific optimization, and technical change management that must be addressed when building a data warehouse.

Meanwhile, the BusinessObjects approach of a really open, modern, and platform agnostic BI and EIM toolset is a great one. Especially in the ETL and BI space, many of the services that BusinessObjects offers are years, even decades ahead of where BW is with its more integrated and older transformation and reporting engines.

I'm hoping that the two communities can learn a lot from each other by interacting more both technically and socially. In other words, like Eric, I am really looking forward to feedback and teaching through other blogs or Twitter.

And now, back to you, Eric.

"SAP BW for the BusinessObjects Community" video podcast →

I'm doing a podcast series with Josh Fletcher from the DS Layer site on the topic of BW for the BObj community. Our first episode is out, so if you're interested in the topic of BW-BusinessObjects integration and what use BusinessObjects shops could possibly find for BW, you may want to take a look.

In this episode we discuss what BW is and what it can offer, and in future episodes we're going to piece together a Data Services extraction, BW-based data mart, and BusinessObjects-based reporting live. Tune in to watch us crash and burn. ;-)