Embarking on an SAP mobility strategy requires some technical decisions to be made early on. Here Danielle Cullen explores the key focus areas for SAP customers.
The first stage in embarking on any SAP mobility strategy is to determine the what, where, who, how and why.
- What: What applications are to be developed? What functionality will be offered?
- Where: Where will the applications be accessed from? Can we assume near-constant online access or does offline access need to be offered?
- Who: Who will be accessing the application? Will the users be employees, customers or some other party?
- How: How will the application be accessed? Will all users have the same device type, for example, BlackBerry or iPhone? Or will there be a diverse range of device types including PCs, laptops and mobile hardware?
- Why: Why is the application being built? Is the goal to increase productivity or sales? Is it being used as a marketing tool? Or is there some other reason driving the development?
Once these decisions have been made, there are some key technical considerations that follow shortly after. These include the types of applications to develop, whether to implement a Mobile Enterprise Application Platform (MEAP) solution, and how to handle security.
Web vs. native applications
There are essentially two different types of mobile applications – web and native. So what’s the difference between them and why choose one over the other? Web applications are basically mobile-optimised websites. They can be developed to recognise the type of device calling them (for example, iPhone, BlackBerry, PC) and to change the screen layout accordingly.
Web applications are often used when there will be a variety of different devices accessing the application – for this reason they are popular for customer-facing applications. They are also often cheaper to develop than native applications. There are a few additional technical considerations – web applications need to be hosted somewhere (just like normal websites) and the technology used by the web application to talk to SAP also needs to be decided (for example, Java or .NET).
Native applications are developed for specific operating systems using a native programming language (for example, Objective C for iPhone and iPad developments). Unlike web applications, they can take advantage of much of the inbuilt hardware such as cameras and GPS locators which may be useful for certain SAP-integrated applications such as online incident recorders or work order management tools. Native applications also tend to perform better than web applications (no waiting for a website to load each time) and can be designed with the hardware in mind, leading to a more user-focused and less generic solution. As a general rule of thumb, many companies who are developing internal applications for a specific device type (for example, workflow approvals for BlackBerry users) tend to pursue native application solutions.
Web applications are more commonly chosen by companies who have a variety of in-house device types, or who wish to reach a wider audience – for example, by offering online shopping carts to customers.
MEAP solutions
As enterprises embrace further-reaching SAP mobile strategies, more companies are looking at MEAP solutions such as those offered by Sybase, Syclo or Sky Technologies. These solutions are used as a type of middleware and are an alternative to building solutions that talk directly to SAP from the ground up.
The advantage of implementing MEAP solutions is that access to the SAP servers is controlled and consistent, and they provide a central repository for mobile development work. Many MEAP solutions offer development tools to actually build applications to interface with them – often leading to a quicker, more simple development process once the MEAP is installed. And most MEAP providers offer accompanying Mobile Device Management (MDM) software, allowing companies to easily roll out (and roll back if necessary) applications to users.
And the disadvantages? Well, these solutions can be expensive compared to building individual applications. Not all mobile devices are supported by all MEAPs and the in-built development tools do not always allow for the same build quality as stand-alone solutions. Also, applications built using MEAP solutions are often limited to internal users only (that is, employees over whom the company can control their mobile device) and so may not be the best solution for companies wishing to reach customers, suppliers and other external users. Plus there are extra hardware considerations, and an extra level of development and support is required for these types of solutions. MEAP solutions can provide significant benefits to customers wishing to implement a large number of mobile applications for internal use as quickly as possible. In such scenarios, the advantages far outweigh the drawbacks. However, companies with a different target audience, and different goals and objectives, should consider carefully if this solution is the right one for them.
Application security
Security is naturally a significant focus for companies embarking on a new SAP mobility strategy – and ties in closely with MDM. It’s essential that data cannot be accessed from mobile devices if they are lost or stolen – yet, at the same time, applications should be easy-to-use for legitimate users. Of course, the level of security required also depends on the type of application being delivered. A simple application showing customers their nearest store location needs no security at all. On the other hand, an Incident Report Tool used by managers would need the highest level of security possible.
SAP mobile applications talk to the SAP servers using an SAP username and password (when a direct non-MEAP solution is in place) – however, this also poses problems. Many companies now implement Single Sign On (SSO) and so users do not know their username and password. Their logon is often linked to their network username and password – which requires an extra level of verification if the application is being accessed outside of the network, that is, by a mobile device outside of the office.
Furthermore, it can be cumbersome for the user to enter so much data each time the application is accessed, and does not tie in with the way that many other applications in the market work. We often use a multi-tier approach to application security, and the type of application being built will generally determine the security approach taken. For example, if the application performs a relatively simple and safe operation, then very few, if any, security measures are required. However, for more sensitive applications that require a greater degree of security, one solution often recommended is to have a registration process the first time the user accesses the application.
In this case, the first time the user opens the application, they register their device with SAP and create a unique fourdigit pin number. All subsequent use of the application simply requires the user to enter the pin number. The SAP credentials and device ID are sent to SAP automatically on each request and if these credentials are verified, then the request is processed. In this way, we can provide greater convenience for the user and a higher level of security for SAP and the organisation.
This solution is also elegant for lost or stolen devices. When a user attempts to access SAP a simple check to determine if the device has been registered as lost or stolen determines if data is permitted to be retrieved – and can even send a message back to the application to instruct it to wipe itself completely from the device.
This solution is just one example – however new security models are being developed and released all the time. As more SAP customers embark on SAP mobility strategies, it is predicted that an increasing number of ‘plug and play’ security models will be released to the market.
Considering these technical factors when starting out on the SAP mobility journey is important. While many companies in the future will likely have a combination of web and native applications, using MEAP and non-MEAP solutions, and even different security models for different applications – understanding the options available at the start and making good, informed decisions will ultimately lead to more robust, cohesive and effective mobile solutions.
Danielle Cullen is operations manager at Clarimont Consulting (www.clarimont.com), a specialist consultancy specialising in end-to-end mobile solutions for SAP.
This article was first published in Inside SAP Winter 2011.
