This content is part of the Essential Guide: Next generation Agile: Guide to continuous development
Get started Bring yourself up to speed with our introductory content.

How to make design choices as mobile and IoT applications collide

Many companies are exploring ways to maximize the benefits of mobile and IoT applications to enhance productivity.

The Internet of Things has been getting considerable coverage, causing companies to explore ways IoT concepts can enhance productivity. Often, this research leads to one specific IoT model that shows promise: combining IoT with mobile worker support. Architects and planners charged with designing for this model must understand what the mobile/IoT model really means, address how adding IoT changes the equation in mobile empowerment, and define their own design pattern to represent how mobile/IoT applications will be handled going forward.

Most legitimate IoT applications involve interaction between users and what could be called a sensor and control network (SCN). In process control applications, the SCN is a machine-to-machine, or M2M, network that uses sensor information to drive changes in material handling or processing. These applications might use mobile technology as a means of communicating with sensors, but they don't force major changes in application design as normal industrial control applications would.

Mobile and IoT applications collide in applications where a worker is visualized as moving through a sensor and control space and interacting with elements. If their full potential is to be realized, these applications require very different design concepts than normal mobile or IoT applications do.

Taking the first step

Mobile and IoT applications collide in applications where a worker is visualized as moving through a sensor and control space and interacting with elements.

The first step in designing mobile/IoT applications is to ensure enterprise architecture process models are up to date and reflect the business information flows and activity sequences the mobile/IoT application will generate. Many early attempts at harnessing the benefits of mobile/IoT failed because those benefits weren't linked to specific enterprise processes and flows, and so neither could be validated or supported.

The second step in mobile/IoT application design is understanding what's in the SCN space. Is the application one where a worker gets information from sensors, one where a worker activates networked control elements to perform a specific task, or both? The answer will determine the best starting point for new application design -- is it contextual in nature or registration and activation?

When mobile workers get sensor information from an IoT application, that information can be viewed as enhancing the notion of context that forms the underpinning of all mobile empowerment applications. This approach embodies two broad alternative models: the extended-senses model and the sensor-driven model.

Extended-senses models use IoT sensors to augment what a worker can know about the current context -- the point of activity. Generally, a worker's location establishes what IoT sensor information is available nearby, and that information is collected automatically into the worker's contextual inventory, to be processed as any context data would be. This is an easy model to implement because it extends, but doesn't change, the application model for mobile empowerment.

In a sensor-driven model, the application identifies a situation that needs handling based on sensor information, and then alerts and perhaps dispatches the worker to the right spot. This model differs sharply from normal mobility applications because the worker is driven by the application rather than driving it. The context of the job is set by the conditions at the point where the worker is expected to be active, and the goal is getting the worker there.

A key ingredient

The key ingredient in this sensor-driven model is identifying an alert condition in the first place. If a sensor and control network is already being used for process control, facilities monitoring and so on, it might be possible to generate a trigger for IoT/mobile activity from the current process or monitoring application. Taking that approach is wise because it reduces the risk of loading down sensors or sensor networks with additional traffic. If it's not possible to piggyback on current process or monitoring applications, sensor information will need to be analyzed.

If possible, avoid reading sensors from a new application. Most sensor and control applications store sensor data in a database regularly. By running analytics processes on stored data, it might be easier to spot unusual conditions. For example, temperature and humidity changes are easier to view as a trend line because any sudden change would be unusual and likely warrant a visit from a technician. Using DBMS-based analytics as the source of IoT context also will reduce the complexity of finding and reading relevant sensors.

The final point is the importance of consistency. Virtually every user who has looked at the mobile/IoT combination will admit that many applications would fit that description, but few represent the low-hanging fruit that typically drive projects in a new technology area. A major risk is that each application could produce its own software based on a unique approach, and that would compromise application agility and component reuse. It could also create operational problems if the worker empowerment element varied between applications.

Software architects and developers know the accepted way to address these risks is the creation of a design pattern, a template-like approach to a problem that can be implemented as needed. For applications blending mobility and IoT, a design pattern would likely be needed for both the extended-senses and sensor-driven models. It's possible to conceptualize a design pattern that accepted a condition set that represents testable sensor conditions and an optional worker location, and returned a set of values representing sensor results.

It can be tempting to jump in to API design too quickly. Be sure to have enough exposure to the complete range of mobile/IoT applications, at least at the business process level, before committing to specific componentization and API design. Taking the intermediate step of developing one or more formal design patterns will ensure the API transition is made with a broad knowledge of the needs and opportunities the union of mobility and IoT can bring.

About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.

Follow us on Twitter @SearchSOA and like us on Facebook .

Dig Deeper on IoT APIs, Applications and Software

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Have you started to work with mobile and IoT applications?
I would suggest extending the exhortation to think beyond templates for software / app development and DB management to include the transactional communications themselves and network architecture to support them. An complete end-to-end approach is needed to ensure that user-centric design, latency, availability, resiliency and security are at very least adequate for the task in hand and will fully meet provider and end-user expectations / regulatory demands. I seem to be reading very few articles, WPs etc marrying all aspects of solution architecture and design at present and looking at one component in isolation is risky.
It seems weird to me to consider "mobility" and "sensor" apps to be two separate things. Maybe think of it more as "push" vs. "pull"?