News Stay informed about the latest enterprise technology news and product updates.

Data transfer latency: Tackling problems related to “people systems”

Last week, the creators of Alpha Anywhere hosted a user meetup to talk about mobile application development – specifically, tablet applications for use in the field and workplace. One of the major pain points discussed was the issue of moving data from user to user across systems in real time in order to achieve the fastest business results.

While some may refer to this as the “latency” problem, Britt Whitaker, implementation consultant at Manufacturers ERP Services LLC, notes that it’s worthwhile to distinguish technology-based latency issues and “workflow-related” latency issues. He claims that within their own organization, even though their APIs are reconstructed to optimize the transfer of data, “it doesn’t really solve the problem: the data got in, but it wasn’t reacted to in real time.”

According to Whitaker, this issue is directly tied to how one has constructed their “workflow link” – the method by which applications alert users that new data has arrived on their tablet or that data they’ve sent has been received. Not only does IT have to worry about how long it takes that data to continue to the next user, but also how quickly is that data processed by the next user in line.

So how did Whitaker and his team tackle this issue? Ultimately, they decided that they were not going to try to develop workflow inherently in an interactive tablet application, but rather would actually construct unique workflow links for individual types of data and applications. To illustrate this point, he provided an example where if one specific user – let’s call her “Britta” – is not in the office, another user, “Alan,” would act as proxy.

“Those are things that, frankly, you don’t want to code into the application itself because people and their roles change – which is, again, a workflow issue.”

The point is, while your APIs may be designed to streamline the flow of data, IT will always have to consider the “people” factor. The solutions to these issues may not always be obvious, especially when people-based processes and roles often change at a rate much faster than IT can appropriately amend their “hardwired” applications.

“Companies should develop tablet apps to eliminate the delay in collecting field data compared to using paper forms, but that isn’t a complete solution,” says Adam Green of 140dev. “We have to change the systems – the ‘people systems.’ Just getting the data there is not enough.”

Have you struggled with latency issues related to “people systems” within your own organization? If so, how did you deal with it, or how do you plan to deal with it? Let us know with your comments.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Hi Fred,
Welcome to the blogging game ;)
I think Britt was really insightful at that meeting. Dealing with the people side of things is super important and he seemed to have a great grasp of it. I wrote about some of what he said about using landmarks to help bolster tablet adoption on the Software Quality Insights blog.
I hate to say it, because I am all for creating and protecting jobs for humans, but sometimes the right move for the business is to let computers handle trafficking information and get people out of the way. If the people who process the information as it comes in are following a precise algorithm o figure out what to do with each incoming form, it's probably better to program a computer to do that instead.
Great articles, Fred and James! There are many valuable use cases for tablet applications in the workforce, to help standing workers and employees in the field increase efficiencies with quick, “glance-able” apps. In our podcast series, we have interviewed developers talking about real-world tablet app implementations, which is a helpful resource for anyone that’s exploring the use of tablet apps in their business:
For me this is a question of loose-linkages versus tight-linkages in workflow. A loose-linkage is a point in the workflow where variation is likely to occur &/or there are a lot of variations/branches. A tight-linkage is where there is no (or less than 5 known and specific) variations which are easy to code for

Where there is a loose-linkage you need to find a way to park or store the work in such a way that the next user in the chain gets some choice over what they do next
Group email boxes, uncompleted task list, ... etc are mechanisms for this
You can also place time based alerts on these for highlighting where something has been sitting for a while

While the control nazis often have difficulties accepting such inefficiencies as might be ascribed to loose-linkages
having visible 'loose-linkage' areas solves many problems
the relevant staff member being unavailable for some reason
the processes changing - this happens more often at loose-linkage points that tight-linkage points
loose-linkages are often at a point of change in ownership within a business and IT gets stuck with trying to agree how the business units handover works
having to code (and test) all the possible variations which might occur at loose-linkages
Changes in UOM/UOWs (Units of Measure or Units of Work) in particular for example where the inbound process might have been done by specific customer but the outgoing work is routed by a customer group