Get started Bring yourself up to speed with our introductory content.

Steps to construct APIs and workflows for mobile worker empowerment

Executives can't think of a mobile worker as simply one who doesn't sit in a cube. Rather, empowerment commences by assessing employee needs.

If productivity gains are the benefit engine that drives enterprise technology investment, then the next critical...

burst of speed must surely come from exploiting mobile devices and broadband services. But as one operations executive said, "A mobile worker is more than a worker who's left the desk," and mobile empowerment has often been based on something just that simplistic.

Real mobile empowerment starts by assessing the information needs of workers at the point of activity, then designing workflows that optimize productivity at that point. Finally, empowerment ends with creating APIs that are agile where mobile worker requirements demand flexibility most.

Good mobile empowerment architecture doesn't start with workflows and APIs, but with business flows and processes. To get the most from mobile workers, it's likely that a new enterprise architecture review of their activities will be needed. History says even the best enterprise architects (EAs) tend to build processes around current practices, which means enterprise architecture business workflows are not optimized for mobility.

Working with an activity-driven model

Good mobile empowerment architecture doesn't start with workflows and APIs, but with business flows and processes.

Traditional enterprise architecture flows tend to describe processes and often wire in presumed serial flows of information to match serial applications and processes. Mobility introduces what's a more event- or activity-driven model. That means defining, not how a worker works but what the worker does at specific points in response to certain conditions.

EAs will find that an activity-driven model of business process analysis tends to produce shorter workflows, in that the process steps involved in an activity are confined to dealing with a specific event. Many EAs say that the big difference between a business process description based on a traditional model versus one based on an activity model is that activity-based workflows inherit context from the circumstances of the worker. Traditional models, on the other hand, establish worker context by mapping steps sequentially. An activity-based map of worker information needs is the basis for mobile workflow and API design.

Common workflow phases

At the software architect level, all mobile-empowerment workflows have a common set of phases. First, the context of the worker has to be established to frame information needs precisely. Context means the worker's location, mission and available communications channels.

Second, the worker must be able to drive information delivery and even communications connections based on the task, so there's an event-analysis stage. Finally, the activity has to close itself in an orderly way and represent its completeness status as an input to the context of other events. The flow is then this: Set-Context, Do-Job, Set-Terminating-Conditions.

The specific way these elements combine will depend on the nature of the work and what could be considered activating conditions. If a worker is dispatched along a specific route to perform a series of tasks, then worker location is an element in context and also a driver of work. If the worker is self-directed, for example, then the worker likely has to initiate a process flow explicitly.

Mobile worker empowerment is most likely to need new logic in the Set-Context portion of the workflow. The general mobile model is to assume a worker activates the workflow at the point of activity by doing something specific. At that point, the software must gather worker context from a database. The first step in the empowerment workflow is to create a context map, filling in what the worker can't provide from the device.

Since most mobile worker empowerment will try to leverage current applications, a convenient approach is to consider this workflow model as being initiated by a front-end Web-based process that establishes context, evolving into invoking current information retrieval and process components. That means the entire Do-Job or second phase of information delivery could be represented as a façade design pattern front-ending current components.

The Set-Context and Do-Job phases can be considered as iterative; the worker drives the processes by signaling (explicitly or by conditions) a change in context, which then iterates the Do-Job activity based on context. It's possible this sequencing can be done using standard message-bus and BPEL techniques, but it may be better to visualize this phase as a state-event process where individual requests drive response processes.

Job completion poses a special issue in mobile empowerment because not only does it mean the end of the Do-Job phase, but it also has to govern the transition between this activity and related or successor activities, some of which might be asynchronous or even traditional batch-system processes. When a given activity is completed, workers presumably move on to their between-jobs context, to restart the workflow when either they reach the next point of activity (if they're scheduled) or signal a new start (if they're self-directed).

The activity itself will often trigger successor steps. For example, the completion of a service call may mean a bill has to be initiated and that workflow may already be defined. The purpose of the Set-Terminating-Conditions phase is to restore the worker to the suitable state for undertaking the next activity and to trigger successor or related activities properly.

How APIs and workflows differ

The biggest difference in APIs and workflows for mobile empowerment is the need to maintain context or state through the activity. In most cases this will mean either that the worker's device (via an app) is managing context and state or that a back-end state management process (the context map) is maintained by the process. This map doesn't need to be passed to existing components that provide worker information or process input, but it has to be maintained so that worker requests or events can be deciphered and directed to the right processes.

Another overall issue to watch in API design for mobile empowerment is granularity. Event-driven processes have to be confined to dealing with a single logical event to be effective. It may be necessary to divide some current process steps associated with information delivery and update to make them suitable for inclusion in context- or event-driven flows.

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 at @SearchSOA and like us on Facebook.

Next Steps

Using APIs to manage mobile devices

Basic policies for mobile workers

Mobile APIs present new opportunities

This was last published in September 2014

Dig Deeper on API management strategy

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Are you working with APIs and workflows for mobile worker empowerment?
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

DevOpsAgenda

Close