SAP Mobile Platform – “Apple of the Enterprise”

Recently, Sanjay Poonen wrote a blog about his vision for mobility, and COMPUTERWORLD published a related article, “SAP Aims to be the Apple of  Enterprise Mobility”. To see how we can turn these visions into reality, I’m going to delve one level deeper and focus on the SAP Mobile Platform. This blog is focused on business-to-employee (B2E) apps.

When Sanjay asked me to join product management for the mobile platform, the first thing I did was ponder what mobile actually means for the enterprise. How is it different from Apple apps and iTunes? In the spirit of true design thinking, Stan Stadelman, from product management, and I whiteboarded how enterprise mobility should work and what a platform’s role is in that picture. We also compared enterprise mobility to the gold-standard of a mobile experience – Apple.

Why Do We Need an Enterprise Mobile Platform?

Apple doesn’t sell you a mobile platform, yet, via the iTunes store, it enables the roll-out of business apps, like Tripit, to millions of users. Granted, I need a development environment to create apps, but if I don’t want to develop apps myself, I don’t need Apple’s xCode. So why do I need a platform in the enterprise world? 

When we look a little closer at enterprise mobility, we see that there are more challenges than in the Apple example. Here are three obvious challenges when you “go enterprise”:

• Cross-Platform: Apple has only one operating system, iOS, but your enterprise will have to deal with more than iOS and cater to Android, Windows, BlackBerry, etc.
• Backend Connectivity: While you and I will run Tripit against the same hosted backend, an enterprise app needs to run against your company’s backend (e.g. a customer relationship management (CRM) app needs to access your customers in your CRM system; a leave request app has to run against your own ERP).
• Security: An enterprise app needs to adhere to your information technology security standards as employees will access your corporate data from the wide open internet – and you will want your business data to be safe.

Yet, the end user expects an Apple-easy experience – without virtual private networks (VPN), the need to enter backend server strings, or prompts for a username/password. Whether users download Tripit, Angry Birds, or your company’s leave request app, they should be able to click on the app to run it. The user expects all these apps to function the same way:

Graphic 1: mobile apps

This is where the mobile platform comes into play. It takes care of the enterprise challenges such as cross-platform, backend connectivity, security, and much more – to keep all of this complexity away from the end user and keep things Apple-easy.

So let’s dive in…

In the following we will discuss

1. the constituencies of a mobile platform
2. what the term “mobile app” means to each of these constituencies, and
3. finally we will put it all together into one end-to-end story highlighting the benefits of the platform for each constituent

Mobile Platform Constituencies

To define the platform correctly, we need to know its constituencies – and we don’t have to look far – SAP’s vision for mobile states them:

1,000,000 developers, 10,000 customers, a billion users

So our constituencies are:

• Mobile App creator (designer / developer – be that SAP’s own apps teams, customers or partners or individual app developers)
• Enterprise customer (administrators / procurement / the business or Line of Business)
• Enterprise user or employee

A successful platform has to cater to all 3 constituencies and their respective mobile app needs

• Create
• Manage
• Consume

And it seems intuitive to center the user experience of a mobile platform around the “mobile app definition” (as opposed to e.g. security profiles, landscape definitions etc). That begs the question:

What is a mobile app?

For the user, that question is easily answered: it’s that little icon on their phone: the Angry Birds, Tripit, or Leave Request

For a developer, that notion of an app is not enough. For a developer, the icon (actually the binary) is just one part of the app – and there might be multiple binaries for an app (one for Apple, one for Android, one for Windows etc.).

For a developer an application is a collection of multiple app components:

• Backend models (e.g. ABAP code in an SAP ERP system)
• Service documents and APIs exposing functions
• Metadata such as style-sheets
• The different native binaries or HTML5 code along with
  the respective web containers for the different operating systems

            

Graphic 2: mobile app components

For the Enterprise the picture of what an app is becomes even more extensive.

For procurement an app are all the different software components described above that the developer creates, but for them it’s also the licensing info associated with it.

For the enterprise administrator, it’s all the above mentioned components plus the enterprise specific items that need to be in place for an app to function in an enterprise. These items include: security policy for the app, user permissions, push notification configuration, custom branding and enhancements etc.

So as you can see, from this discussion, while the notion of an app is very intuitive (the icon on my phone) there is a lot more to it and it’s not trivial to make an app work in the enterprise for thousands of users. It’s like the classical iceberg – there is more to it that what meets the eye:

Graphic 3: enterprise apps – there is more involved than what meets the eye

It’s the mobile platform’s job take care of the items “below the water line” and to reduce this complexity and make things simple again – and Apple-easy for the end-user.

How things should be… End-2-End Platform experience

So what is the overall mobile platform experience supposed to be? What does “Apple for the enterprise” look like? Let’s take a look:

Create the app (Developer)

It all starts with the app creator – be that an individual developer, a customer who wants to develop an app, a partner – small or large – or the SAP app development teams. There are two distinct cases:

• Development of a standard app to be sold (e.g., via the SAP store)
• Development for a specific customer to solve a specific problem

Let’s discuss the case of a standard app that is to be sold to multiple customers.

A developer will need “vanilla” backend systems to develop against. Ideally the platform infrastructure allows him to commission backend systems (e.g. SAP ERP or CRM) in the cloud along with a service to expose the relevant services and data easily (e.g. via SAP Gateway). The developer will want a variety of tools at his disposal to create the different parts of the app we mentioned above:

• Backend models and connectivity services
• APIs exposing backend functions as services
• business logic
• WYSIWYG UI design tools for native and cross platform
  apps

These developer tools should provide a variety of functionality that take care of the enterprise features and thus allowing the developer to focus on the development of his app. These functions and services include:

• Logon module to allow for various authentication methods and identity providers (SSO, Siteminder, Kerberos, certificates etc.)
• offline and sync engine
• Push notifications
• Connectivity and data modeling tooling
• Business logic modeling
• Device simulators for the different platforms
• Testing and simulation tools across all components
• App telematics to capture usage stats of the app at a feature function level
• Container for web apps for all platforms
• Sample code and building block for services such as geo-fencing
• User Interface building blocks
• Access to phone peripherals such as camera, GPS
• LCM support such as versioning and transports across the different components
• Customization and extensibility framework for UI, business logic and backend model
• Troubleshooting and debugging capabilities across the different components
• Support of team development – multiple developers working on the same app
• localization – regional and multi-language support

To give the developers choice of tooling, these services and functions should be delivered as plug-ins into the different design and development tools such as:

• Native app development tools, e.g. xCode, Visual Studio
• UI tools such as Sencha, Appcelerator or SAP’s UI5 designer
• Eclipse
• Backend ABAP designer for SAP applications

Once the app is developed, a developer will want to monetize it via the SAP store, which allows the developer to sell his mobile app around the world without having to establish a sales force in every country. He will also be interested in license and app usage reporting. All of that should be provided by the platform and the SAP store.

In the case of development for or by a customer some of the services are slightly different:

• Usually there is no need to commission a “vanilla” backend to develop against. The customers development landscape can be used instead
• There is no need to push the app to the SAP app store
• The need for customization and extensibility frameworks is lessened – as the customer owns the source code of the app itself

Manage the app (Administrator)

The whole enterprise administration of the app is really the step that does not exist in the Apple world – but it is critical for the enterprise (see here). As mentioned in the intro, there are at least 2 things an admin has to do even in the simplest of cases: he has to connect the app to your own backend and he has to establish a secure user authentication in line with your IT security policy. But that is only the simplest of cases. There usually a lot more to it – e.g. the management of apps across different operating systems. In addition, the administrator has to handle and merge 2 lifecylces:

• The lifecycle of the standard app that the developer / vendor upgrades over time
• The lifecycle of his customizations and configurations to the standard app to make it work in his enterprise

So let’s look at what an enterprise admin would expect from a mobile platform. The administrator has 2 main jobs:

• Get the apps going – initial roll out
• Keep the apps going – sustained operations

The platform has to address both items and ensure that the initial roll out of applications to thousands and sometimes tens of thousands of users is cost effective. Consultants are usually expensive resources and customers don’t want to keep them around forever to get apps rolled.

Almost more important though is the operations of the apps – ideally no consulting help is needed and operations can be moved to lower cost resources.

So, what does the platform have to offer to help with roll out and operations –

• Simple way to connect the mobile app to the customer’s backend(s)
• Security and Authentication: Siteminder, Kerberos, SSO, certificates, SAP portal integration, oAuth, SAML
• E2E tracing, debugging, root cause analysis, troubleshooting tools for quick root cause analysis – superior error-messaging
• Ticket system integration (API) to allow users to automatically submit all the information (stack trace, logs, screenshots) in case of an error in the app without emailing or manual intervention
• Usage reporting and analytics by user, device, app, vendor, region etc.
• Onboarding tooling – allow sending of server strings and logon information to the app on the user’s device without having the user enter it
• Versioning, lifecycle management and transports of all component of the app across the development, test and production landscapes
• Extensibility and customization of standards apps purchased from the SAP store
• Easy upgrades and backward compatibility – server upgrades should not impact the running apps and app upgrades should not require server upgrades
• License management
• Scalability & Performance – clustered or federated landscapes, high availability
• Content management and image processing
• Data integration, orchestration, and connectivity to SAP and non-SAP systems to facilitate end-to-end scenarios such as order-to-cash or procure-to-pay
• Support for testing – e.g. via automated testing where you define the test case  and specify for how many users/ devices across what regions this test should be run to simulate realistic loads

All of these services are designed to reduce the cost of setting up and running the applications.

But there are request for more advanced features such as

• App-to-app integration – as an enterprise you know what apps are on a user’s device so app-to-app integration is possible. E.g. accessing the pricing app from the CRM app – passing the context from one app to the other
• App wrapping to allow you to manage any apps – not only the ones built on the platform
• Control app behavior in user specific or role based context – e.g. only allowing certain employees to use the camera feature
• Social media integration

Graphic 4: mobile platform in the cloud – admin console

Consume the app (End-User)

Well, this one is easy: user downloads the app and starts using it. All onboarding, app registration and bootstrapping is done by the platform: server strings, logon information or certificates are pushed to the user’s device without the user having to do anything – Apple easy!

In summary we have 5 steps:

• Developer creates app and publishes all app artifacts (front-end and back-end) to SAP app store
• App gets certified and developer gets set up to receive payment for each sale of the app via the store
• Enterprise procurement purchases app artifacts and licenses from the SAP Store
• Enterprise administrator configures and customizes the app, transports it thru the system landscape and pushes it out to his users
• End-user gets the app, he is onboarded to the app without having to do anything himself and he starts using the app

Graphic 5: end-to-end picture of an enterprise mobile app – Apple for the enterprise

That is what I would call “Apple for the enterprise” – that’s the goal that keeps me going everyday as a product manager for the SAP mobile platform…

Further information

For live updates on all things SAP Mobile, follow me on Twitter @jenskoerner

Looking for SAP Mobile demos, customer references, roadmaps, performance and sizing information, training, documentation or tips & tricks?

Check out Jim Jaquet’s interview with me at SAP TechEd in Madrid

Carolyn Fitton’s blog 3 reasons why developers use SAP Mobile Platform to create enterprise grade apps

Watch Kevin Benedict‘s Mobile Expert Video Series

Sanjay Poonen‘s keynote at Enterprise Mobility. At minute 44:01 we are demoing the platform

Carolyn Fitton‘s blog 3 for 1: SAP Mobile Platform Meets 3 Different User Group Requirements contains 3 videos that provide a great overview of the value of the mobile platform.