patpitchaya - Fotolia


How to choose middleware for your mobile-first strategy

A key part of going mobile-first is selecting the middleware that aligns with your end goals. In this tip, Tom Nolle examines the factors to consider when picking that middleware.

Mobile middleware was once almost a luxury, but enterprises now realize that mobile empowerment is the basis for...

the next wave of productivity enhancement. Instead of making current applications mobile-compatible, they want applications designed specifically for mobility, and this means finding middleware that aligns with a mobile-first strategy. To get this critical step right, it's important to understand the difference between mobile adaptation and mobile application design, look for a middleware-based mobile architecture, and select specific mobile middleware tools to support that architecture.

There are few businesses out there that have not already faced the need to provide workers with mobile platforms to support some activities. In most cases, this is done by adding a mobile front end to an existing application, a model that minimizes changes to current applications while still accommodating mobile workers.

Going beyond simple mobile-screen adaptation generally requires adopting a mobile middleware tool -- or perhaps several of them. Mobile middleware is divided into three broad categories: the front-end tools that facilitate unified development across a spectrum of devices, the back-end tools that provide integration and mapping elements that link the two. Some tools specialize in one area; others cover them all.

For most users, even the mobile-adaptation approach will eventually involve mobile middleware in the form of a mobile-friendly, front-end system like Bootstrap. This type of middleware can harmonize the presentation of information and help developers avoid having to make device-specific changes. When applications are designed with a front-end middleware tool in mind, they can be adapted to virtually any mobile device and also continue to support workers on laptops and desktop computers.

The problem with a front-end-driven approach is that information needs and work sequences of mobile workers are different than those of fixed-location workers. This difference is sometimes described as being contextual because a mobile worker expects information in the context of their current location, intention and conditions. This requires a more dynamic relationship between the worker and databases or transactional processes, which form the back end of mobile applications.

A mobile-first strategy commits you to design for mobile worker behavior.

Mobile backend as a service, or MBaaS, is a popular marketing term, and so you have to look carefully at the products to ensure that they're doing what you need. Some, such as Modo Labs' Kurogo platform, will provide everything from database and application service connections, to policy-based business mapping, to presentation in a way line organizations can use. Others, like Red Hat's mobile computing architecture, are primarily true back-end elements designed to facilitate developers' connecting mobile devices to application workflows. Microsoft and IBM both provide suites of mobile-development tools that are modular, easily linked with each other and cover all the elements of a mobile application. All of these are suitable for mobile-first development, so long as you match the features to your mobile application model.

And yes, you need a mobile application model for mobile-first development. A mobile-first strategy commits you to design for mobile worker behavior. And while virtually any MBaaS tool will support that goal, not all will support it optimally.

A mobile application model starts with the tasks an empowered worker is expected to perform and breaks these tasks down into logical steps. Each step is associated with a work event that will be generated by the worker and for which the worker will expect a response. Usually that response will contribute to completing one of the steps and advancing the task to the next one. If you develop your application model without reflecting any biases related to current application structure, the model can then be compared to the current structure by comparing work events to transactions. That lets you optimize your mobile middleware tools to your needs.

Mobile adaptation vs. mobile application design

Will simple mobile adaptation be enough, or do you need full-on application design? Consider these factors when answering that question:

  • Mobile adaptation minimizes changes by focusing on the front-end; mobile front ends are added to existing PC applications. Mobile application design often requires rethinking the whole app.
  • Mobile adaptation does not require the use of middleware to link back-end and front-end elements. Mobile application design requires taking a holistic view of both back-end and front-end needs.
  • Mobile adaptation may present issues surrounding information needs and work sequences. Fixing this "context" problem requires a more dynamic relationship between mobile workers and back-end databases, a focus of a mobile application design approach.

Optimization means addressing some basic questions:

  • Do you have a repertoire of applications your mobile workers will expect to use, or are you primarily developing from scratch? If it's the latter, look for comprehensive MBaaS solutions or suites from a software supplier who has full-spectrum development and ALM tools available. This will make the job easier.
  • If you have applications already, are the transactions they support easily mapped to work events? If they are, then back-end integration to workflows will be relatively straightforward, and you can focus your MBaaS selection on tools with more front-end and application access policy mapping capabilities.

The more agile your mobile-first applications are, the more you'll need to address the issue of policy-based application and data access. Many MBaaS middleware platforms include this, but the sophistication varies significantly. At the minimum, a platform should control access to application components and data based on worker identification, but it may be helpful to be able to add other policy controls based on job activity. Remember, whatever you can't do with policies you may have to write into applications on a custom basis.

Mobile accommodation has turned into mobile-centricity as more aggressive worker productivity objectives increasingly drive application design. However, it's also true that the real shift at the application level isn't mobility at the device level, but contextual application delivery. This is likely to shift mobile middleware strategies to broader-based application platforms that support both flexibility in mobile devices -- BYOD -- and agility in supporting worker-generated events through those devices.

Companies need to examine their motives for mobile-first design and where those motives are likely to take them. For those whose goals focus on productivity gains rather than simply on supporting worker interactions on their most convenient devices, it would be smart to start thinking about a mobile-first strategy in the broadest development sense and prepare for a service-based and event-driven evolution in applications.

Next Steps

Review the mobile development guide to testing, security and policy

Learn what makes mobile development the new back-end integration problem

Take this quiz to test your mobile strategy know-how

Dig Deeper on Mobile app development