Last week, SAP and Google made an announcement about a partnership based on Google Maps that is reflective of a refreshing new openness at SAP to doing things that were essentially unthinkable under past management regimes.
Under the deal announced last week, Google is going to support SAP Business Analytics use of Google Maps as part of all different types of SAP applications. This means that SAP products will eventually come with geographic mapping capabilities that offer the ability to visualize data that are powered by Google Maps. SAP applications will start to look a bit more like consumer web sites that use Google Maps used to find stores or to show statistics by region or any number of things.
Another implication is that the ability to manage and explore large data sets using Google Maps, SAP’s HANA in-memory architecture and other capabilities will become productized. Geo-spatial visualizations will be designed and delivered in the context of a business process. Given the capacity of HANA and the amount of data stored in a typical SAP application, it is likely that the ability to manage and use so-called big data will also start to be productized.
One might ask, what’s the news here? After all, SAP has supported use of the data in its applications by firms like ESRI that offer advanced geo-spatial mapping capabilities. In addition, SAP customers have used Google Maps with SAP data anytime they wanted to.
The news here, to me, is that SAP is now saying that a core capability that could potentially be used in all of its products will come from the cloud and come from a third party. This means that the more than 10,000 developers who work at SAP will now be able to incorporate Google Maps type functionality into its core functionality. For SAP Business By Design, the Software-as-a-Service offering, using cloud based services is natural, because Business By Design is delivered in the cloud. But for SAP Business Suite, that includes SAP’s flagship ERP application, this is a radical departure. SAP takes the operational quality of its products very seriously. The company was publicly disappointed by the recent outages at Amazon Web Services. Now, despite the worry that was raised by that event, the company seems to be going full speed in using a cloud-based component. There is little doubt in my mind that this attitude of openness will lead to more such announcements about approving other cloud based components into its arsenal.
Again, it is fair to ask, “Isn’t this obvious? Why wouldn’t SAP use the best components to build its applications regardless of where they came from as long as they were high quality?” The answer to anyone who has watched SAP or any large company is simple. It is big news when SAP or any large company can overcome its cultural barriers and do what makes sense without some painful prompting.
In this case, SAP is overcoming a legacy of an insular engineering culture that could accurately be accused of suffering from a “not invented here” complex in the past. In a sense, how could it be otherwise? Most leading companies suffer from their success. SAP is rightly proud of its engineering history. The company created a system that started at the dawn of the software industry in the early 1970s based on some key principles — what SAP CTO Vishal Sikka calls Timeless Software — and is still going strong today. In that same time period, several generations of software companies have come and gone. SAP built and deployed many software innovations before they became widespread. The ABAP language used p-code and a virtual machine long before Java did the same thing. Abstractions of the data layer, devices for inter-application communication, synchronization of master data, and client/server UI found their earliest and widest deployments in SAP applications. To this day, practices like the nightly build that is used by Java development shops is really a remediation for the fact that there is no formal way to track dependencies between modules. Such capability has long been a part of ABAP Workbench. You don’t need a nightly build because you know what to recompile when something has changed.
The only problem with SAP’s pride in its history is that it has sometimes shut the company’s eyes to new ways of creating software. It appears that this announcement may mark a turning point to increased awareness and use of outside components. If SAP becomes truly open to using more and more outside components, and learns how to use them to create stable, reliable software, SAP could accelerate the pace of change, keeping the stable parts of its applications, but adding the best of what has newly arrived.
SAP has long been open to having other companies use its software. In October 2009, SAP published a guide, “SAP Guidelines for Best-built Applications that integrate with SAP Business Suite”, that has been updated about every other month since that date. This guide explains how to write applications that are compatible with SAP’s software guidelines and standards. This guidance is provided because SAP recognizes that other companies will be building solutions to meet needs that SAP is not going to address. By following this guidance, other companies can create solutions that fit naturally into the SAP Business Suite.
Now SAP will either need a new guide or a new chapter in its current guide that covers how to use Google Maps SAP style. Once SAP developers take up this challenge, and there is no doubt in my mind that they will, it is likely that Google Maps will be adapted by Google to better meet the needs of enterprise applications.
Two vital questions seem worthy of exploration in further columns. The first is: What’s next? What other cloud components will SAP start to incorporate? The second is: Is a bigger partnership possible? Google’s mission is “to organize the world’s information and make it universally accessible and useful.” Much of the information that runs the world is in SAP. Why aren’t Google and SAP working together to make it more universally accessible and useful?
Dan Woods is chief technology officer and editor of CITO Research, a firm focused on the needs of CTOs and CIOs. He consults for many of the companies he writes about. For more stories about how CIOs and CTOs can grow visit CITOResearch.com.
Log in for notification optionsComments RSS