Exploiting mobile devices to empower workers at the point of activity is the next frontier in productivity enhancement...
for most companies. These new apps often demand different design practices, including interfaces and component models. In many cases, these apps involve Web-based front-end elements based on RESTful principles.
At the same time, these productivity-enhancing apps may involve existing components connected using SOA principles. To make this evolving mixture work, architects should employ tiered app principles for information presentation, examine context and state control carefully, and be prepared to rethink some interface and ALM decisions.
In mobile contextual apps, workers can be expected to use a mobile device on scene to get information or assistance on a specific task. In nearly all cases, information will be available through traditional apps, but the specific circumstances of the mobile worker make accessing it in the normal way difficult or inefficient. That means mobile contextual apps are based on information services that can conform delivery to the limits of the devices, limit the need for worker navigation of menus, and bridge across traditional app lines.
Models for contextual apps
Most architects find the logical model for such an app is that of an agile front-end that is device- and context-aware, drawing information from existing app components, but not replacing the apps the components were created for. Thus, mobile contextual services are cross-grain with respect to current app processes, including ALM.
The objective is to increase flexibility and agility without breaking current app models. The goal is to use Web technology to create a GUI and app portal that will serve to insulate current apps and components from changes.
Tiered apps are common, but mobility and contextual services introduce two issues: worker context and performance at scale. Context will often come in part from the mobile device (location-based services), but will often require some worker input. Performance at scale means defining clear boundaries for delay and availability and insuring these are met even when large numbers of workers are served. The latter is critical because it's difficult to predict the precise number of simultaneous points of activity.
Worker context is a new contributor to the stage of activity within a multi-step task. Virtually all mobile contextual services will define a specific sequence of expected tasks and will have to be followed with minimal worker interaction. The expanded version of state can be maintained in the device or the app. Either mechanism is suitable, but where state information is voluminous, it's important to note that device-kept state can increase mobile network traffic and delay.
State control in the app has disadvantages, as well. Software components that have to maintain state for users are more difficult to replicate. Take care in designing the scale-in and scale-out of Web-based front-end tasks to ensure state information is not compromised. This often means state or context control at the app level should be applied to the gateway component between the Web-based front-end processes of the app and the legacy SOA-based application flows.
It may be best to visualize two levels of load balancing and scaling when back-end state control is in use. The first, involving front-end Web-based components, would be stateless or rely on state or context from the mobile device. The second, the on-ramp to the actual application components, would employ back-end state control. To avoid having to distribute state databases across a wide geography, front-end components could be assigned a specific on-ramp gateway.
The combined set of front-end and gateway components become virtual users of existing app components, likely linked with each other via SOA versus REST. The mobile contextual services are often cross-grain with respect to normal workflows, and thus may not use existing service bus logic for steering and sequencing. If they do, they may have to be adapted in the BPEL to accommodate ad hoc mobile or contextual inputs and normal workflows through the same logic.
Dualism may break current interface models, either suggesting current componentization plans be changed to accommodate mobile and contextual use, or that new information elements be added to the data package passed to a component. If component data models are changed, modifications in the BPEL will need to be made for legacy workflows to limit the impact.
The other area of impact is ALM. Because mobile and contextual services are almost event-driven in their flows, traditional ALM may lose relevance. This will likely demand placing greater emphasis on unit-component behaviors for each app element and separate testing or certification of workflows and worker contexts. This is facilitated if it's possible to think of a worker's activity as personal workflow, but it will likely be necessary to coordinate changes in operational practices with ALM to ensure all scenarios are covered.
If mobility becomes the rule in worker empowerment, current efforts to accommodate mobile contextual services may be the entry point for driving major changes in app design. Keep this in mind when adding mobile worker support in order to be prepared for a mobile-driven future.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
More on mobile app development
Enterprise mobile app development tutorial