Skip to Content
Introducing mobile applications to an existing system landscape adds a new dimension in complexity with respect to operations since an administrator cannot physically access mobile devices. The demands and expectations regarding efficient and smooth operation are high since disruptions to day-to-day field activities have a major impact on the entire organization. In this blog I will try to help you with operating your mobile environments by enabling you to avoid common pitfalls and to put some best practices for operating mobile environments in use. I would like to start by telling you about my top ten list of things to keep in mind when you think about the operation of mobile landscapes..

When preparing a presentation for TechEd Amsterdam on mobile lately I was trying to wrap up my session on operating mobile landscapes on two slides. I wanted people to remember these things when walking out of our workshop. I came up with the following list that I consider a good summary of the things to keep in mind when planning a mobile project and when operating the resulting mobile landscape.

Here’s my top ten things to keep in mind …

1. Every day tasks are more error prone in Mobile Environments than in traditional IT environments

Sure, the complexity is much higher due to the fact that there’s usually more devices, that you have client, middleware and backend, that there are different technologies like Java on the client and ABAP in the backend involved …

2. Mistakes are hard to fix – since they might require rolling out the software to possibly thousands of clients again

If you have to fix something it means more work than in traditional environments because of the distributed structure of mobile environments.

3. Therefore a good planning is required and strategies on how to deal with potential issues have to be developed

You better plan ahead and have something ready before a problem occurs.

4. Invest a high percentage of your time and resources (up to 30 percent) into rollout and support

A good support and rollout strategy enables you to react to issues in a timely manner.

5. Extensive end user education is recommended since Mobile is a new technology for end users

Education of end users helps you to prevent issues before they occur.

6. Ensure the support is able to access devices in case of problems either directly or by remote login

This speeds things up a lot. It’s only possible for Laptops and Tablet PCs though.

7. Device Selection is crucial. If you choose the wrong hardware or save on the hardware you might pay the price later

The selection of devices is actually the MOST important point. You should have a look at a number of devices and choose one that fits your needs. Spend some time on this especially when you think about getting PDAs.

8. Involve your end users as early as possible. Especially when selecting devices

The success of your project primarily depends on how your end users accept your package – meaning the devices and the software. Usually possible issues come up early in a project when you involve end users and, even more important, end users appreciate being asked. After all your end users are the people that you want to help doing their jobs …

9. Think twice when administering devices. You might delete a device that is still in use. Or, worse, you could delete a large number of devices that are still in use

Small things can have large effects. So THINK when doing things like deleting data from the middleware …

10. Make sure that your sizing fits your requirements

You would like a solution that is comfortable to use and offers enough performance. So make sure that both your device and your middleware are able to handle the expected amount of data.

And an eleventh point to keep in mind that is even more important than the other ten: Mobile Projects Pay Off. You might have to plan things more carefully than for a traditional IT project but you will be rewarded by a much higher return on your investment since most of the infrastructure and software (Backend) is in most cases already payed for before you start the project.

And when do you get the chance in a traditional IT project to deliver software access to 10000 users at a time that had no access to your company’s software before ?

As I said: mobile projects do pay off 😉

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Nigel James
    Karsten,

    Great thoughts. You have obviously been through one or two of these rollouts.
    Take my comments with a pinch of salt because I haven’t but I am interested in the mobile space.

    I tend to cringe when I hear of mobile rollouts and just because I think that over bloated software is being stuffed down a much smaller (network) pipe. It is like everyone is thinking broadband and mobile is like 9600 baud dialup all over again.

    My best experience comes from my blackberry and the browser on that. If sites do not target a mobile device you get very ordinary performance. Now I only have GPRS and not fancy 3G but the difference between sites that think about it (bbc.co.uk) and those who don’t (almost everyone  else) is vast.

    Of course there are two ways to deliver a mobile solution. Custom app written for the device in java or … or having a skinny web app of some kind. This is the same for a desktop app – so its really only the network that has changed.

    Do you have any pointers for making sure your apps are skinny enough to fit down the available bandwidth that might be available to them. I’d love to hear of more real world examples of the problems and how you have overcome them. (but perhaps thats another blog)

    I would particularly like to hear of more examples of ‘mobile projects pay off’.
    Cheers,

    Nigel

    (0) 
    1. Karsten Strothmann Post author
      Nigel,

      Thanks for your comments 😉 You were obviously thinking of applications that are always connected. For those applications bandwidth is a very important factor. SAP NetWeaver applications are usually only occasionally connected though. This means that you get the backend data on your device, work offline with this data, perform your changes and once you have a connection again you synchronize and your data gets transferred to the backend. It’s a whole different concept than the one used by Blackberrys. In a lot of cases you sync using a LAN or WLAN connection. In other cases our customers use GPRS connections. Some people even use regular phone lines which are still fast enough if you just want to sync data.

      It gets a little tricky if you think about distributing the infrastructure, the application or patches. Here you have to see that the packages are not too big and that you choose and appropriate distribution method. NetWeaver Mobile allows you for the creation of something called Setup Packages. These packages hold the infrastructure and the application. To distribute these packages you can use a lot of different ways: download over the Internet or even distribution by Compact Disk would be two of those. With a CD you certainly wouldn’t run into Bandwidth problems 😉

      If you would like to know more about all of this you could check out the “Operations Guide for SAP xApps for Mobile Business running on Mobile Infrastructure 2.5”. You can find it on the service marketplace in the folders for the apps covered in this guide meaning xApp Mobile Asset Management  2.5, xMTT 1.6 and xMAM Version for Utilities 1.0.

      As for “Mobile Projects Pay Off”: let’s take a Mobile Time and Travel project. MTT is used to enable tavelling consultants to enter their working times and travel costs offline while they are travelling and sync as soon as they have a connection again. There’s a number of advantages to using this app like faster billing cycles, compliance to the company’s travel policy etc.  Anyways, let’s not get into the details. Now think about 7000 consultants using this tool. It’s pretty stable, easy to install and very easy to support since it’s Laptop based. The hardware is usually already there – every consultant already has a laptop anyway. So there is basically just an investment in the middleware and in the software plus some project related costs. That’s it. So how long do you think does it take to get your ROI if you can bill your customers a few days earlier for 7000 consultants ? If your 7000 consultants stick to your travel policy more closely ? If there are less bills with wrong data in there ? And most important if you need less people to process time and travel data on your side ?

      Right, it’s not going to take long 😉

      Cheers,
      Karsten

      (0) 
      1. Nigel James
        Thanks for the great example and the alway on / sync difference. I guess an example of an always on app would be a product tracking tool that can can tell that a customer has signed for it that it has been delivered. This is a real time / batch type decision that faces many apps.

        Another app that I have seen my trader friends show me is their bloomburg on blackberry which is great if you need to “sell! sell! sell!” during your 3 hour lunch!

        The MTT example is complelling. Can it do your T&E for you? I really don’t like that admin stuff.

        Thanks again for a great blog.
        Nigel

        (0) 

Leave a Reply