Microservices Matters

Jun 10 2015   4:09PM GMT

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

Fred Churchville Fred Churchville Profile: Fred Churchville

Tags:

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.

3  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • James Denman
    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.
    1,875 pointsBadges:
    report
  • agroden
    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: http://www.alphasoftware.com/podcast/
    40 pointsBadges:
    report
  • PerpetualRocket
    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

    40 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: