Menu
Enterprise Software Development

News and Views - articles and case studies for better strategies

Defining an Enterprise Mobile Strategy

Rick McMullin

Rick McMullin, CTO, bitHeads

 

 

As mobile is becoming more and more crucial in the everyday running of businesses the need to define an enterprise mobile strategy is no longer a nice to have but is a must. There are many different aspects to defining an enterprise mobile strategy. In this post I will merely be scratching the surface of what is involved but hopefully what is presented will be enough to at least ensure that you know what questions you should be asking and answering when it comes time to define your EMS.

 

 

Step 1: Define the business requirements that are driving your mobile strategy.

Not ever company will benefit from going mobile but most mid to large companies probably will and that number grows every year as more and more commerce is being carried out on mobile devices.

 

The first question that always should be asked is why are we doing this? Is there a real business benefit to developing mobile applications or are we doing this just because everyone else is? If you have a tough time coming up with any business reasons to start to develop mobile applications chances are your users will also struggle with why they should use a mobile application that you have developed.

 

The app stores are littered with me too applications so before you embark on your mobile journey make sure that there are some good reasons to make the trip. 

 

Step 2: Know thy user 

The next thing to do is to define who will be using the mobile applications that are developed. To do this it is helpful to segment your user base and decide what if any impact the mobile strategy will have on that set of users. In general there are three broad categories of users to consider:

- Suppliers/business partners — also referred to as B2B users.

- Employees — also referred to as B2E users.

- Customers — also referred to as B2C users.

 

Inside of each of these main categories of user there are additional segments that must be explored as well.

 

You may end up dividing your B2B users into two different sub categories, physical goods suppliers and human resource suppliers.

 

B2E users will likely have many different types. There will likely be an executive group, and a group of users for each of the main departments in your company.

 

For your B2C users, you may find you only have one type of user, or you have the concept of a business customer and an individual customer.

 

Step 3: Define what applications these users need.

Once you have defined who your users actually are the next step is to decide what mobile applications are required to service each of those types of users.

 

With the B2B users you might decide that your physical goods suppliers have requirements for ordering and tracking shipments for a just in time manufacturing facility. For your human resource suppliers you may have requirements to schedule work orders for maintenance of equipment and for both there will likely be billing/invoicing requirements.

 

With the B2E users you will likely have a time tracking application requirement for all users, executive and sales dashboard for the executive group and a bunch of finance, invoicing,  and bill payment applications for your finance group.  In addition you may have warehouse applications for shipping and receiving and a myriad of other applications depending on the different departments in your organization and your main line of business.

 

With your B2C users there may be requirements for checking on the status of an ordered item, keeping track of user preferences for items that have been ordered in the past, customer loyalty programs, appointment booking, finding the nearest branch location of your business and sending notifications of sales in the users area.

 

As you can see the list of requirements across the entire user base can be quite large and well things get complicated  very quickly.

 

Step 4: Define the user experience for each user group/application pair. 

User experience has never been more important than it is when developing mobile applications. You only get one chance to make a first impression and there are few ways to get things right and many ways to get things wrong when developing mobile applications.

 

The purpose of this step is really to define the minimum that you can get away with for each of your user groups. It sounds a bit crass but that is really what you need to do here. In order to better understand what I am talking about it would be helpful to understand the different approaches that can be taken to develop mobile applications.

 

The different approaches that can be used to develop mobile applications:

1. Native application development where you use each platform’s SDK and development language directly.

2. Develop mobile web sites that can be used from any type of mobile device.

3. Develop an HTML 5 application that can be deployed as an application to any mobile device.

4. A hybrid approach that combines some native development with some HTML and JavaScript.

 

In addition the above 4 main approaches there are also several other approaches that are variations of these:

- using a cross platform development environment such as Xamarin

- using the native C++ SDKs that exist on most of the mobile platforms to write all of your common code.

 

Few would argue that the best user experiences for mobile applications are achieved by building your applications using the native development environment for each platform. This however is not always possible. So what you need to do in this step is to define from a cost benefit analysis / user experience tradeoff what type of implementation makes the most sense for each of your applications and user groups.

 

This may mean (and often does mean) that you develop native or hybrid applications for your consumer customers, and mobile websites or HTML 5 application for your internal and business partner users.

 

There are only two reasons to develop your mobile applications using any approach other than the native SDK:

- cost savings by developing for multiple platforms using a single code base

- the knowledge and experience of your existing development team.

 

Step 5: Follow the data. 

This step in the process involves defining what data is needed to satisfy the requirements for the list of mobile applications that you are building (which you defined in Step 3). This is an important step because this will determine what backend systems your suite of mobile applications are required to access.

 

 

Step 6: Keep it secret, keep it safe. 

Another crucial part to defining your mobile strategy is to document your security requirements. This includes but is not limited to your approach to authentication and authorization. For example for your internal users will you be taking advantage of an internal directory such as a LDAP server or Active Directory for authentication? How will you handle the authentication of your customers? Do these new mobile applications place any new requirements on your network security implementation or can everything that is required be accomplished through the security mechanisms that are already in place.

 

Keep in mind that anything that you put into the code of your mobile application can be seen by everyone (especially if you are publishing your application on one of the app stores). 

 

Step 7: Manage those devices

In someways this could be considered part of Step 6, but I have separated it out into its own item because it only involves a subset of your user base and it is also accomplished using different technologies then the security items discussed in Step 6.

 

 

Step 8: Choose your tools

If it wasn’t abundantly clear from reading steps 1 through 7 above there is a lot of work involved in implementing a mobile strategy. Building all of the backend technology required (not even thinking about the client applications) could keep you busy for years. The good news is that there are a class of products available that do most of the heavy backend lifting for you. These are called Backend As A Service applications or BaaS for short (they are sometimes referred to as mobile BaaS or mBasS as well).

 

Stay tuned, or sign up for updates





Your information will *never* be shared or sold to a 3rd party.

Comments are closed