Sign up to get full access all our latest Oil & Gas IQ content, reports, webinars, and online events.

Seven Ways Legacy Apps Are Destroying Your Connected Worker Efforts

Add bookmark
Ryan Tsamouris
Ryan Tsamouris
01/10/2023

Connected Worker disconnect

Oil & Gas companies are notorious for following the mantra of “if it ain’t broke don’t fix it”. This applies to apps as well, including those used by field operators or maintenance workers.

We have been using the same app for Operator Rounds for nearly 15 years, and it continues to be the most used mobile app in the field by far. This app gets the job done, and it has been used for so long that we have a well-established user base who is very familiar with its use. It was the first app we migrated from Windows handhelds to Android tablets in 2016, and it continues to be the work-horse app for our Operators.

However, this app has a problem: it’s a legacy app. This translates to being outdated, which can mean it uses old standards, is built on obsolete platforms or architecture, requires old browser versions, does not support modern authentication, not mobile friendly, is cloud allergic, does not have API support, and so on. Legacy apps are old or not built to modern standards, and they will put a drag on your Connected Worker efforts due to these reasons.

Let us expand on the most common issues with legacy apps and how they impact your Connected Workforce:

#1: App is not designed for modern platforms

Your app might be legacy if it meets one of the following:

  • Only works on Internet Explorer
  • Only runs on Windows devices and not mobile friendly on Android or iOS
  • Uses virtualization (e.g. Citrix)

An app meant for your Connected Workers that does not work on a mobile device is a prime example of legacy. This restricts what can and cannot be used in the field, slowing down efficiency and ease of access to information.

This does not mean that your app must be natively built for Android or iOS; however, if it can’t work on a modern browser like Chrome or Edge, and scale from a large screen to a small one, then it’s legacy.

Similarly, if your app only works through virtualization (because it needs Windows 7 or another old operating system), then that is also legacy. This deployment method may work, but I guarantee that your users do not enjoy using it.

#2: No support for modern single sign-on (SSO) methods

If your app does not support your current company SSO methods, then it is definitely outdated. Here are prime examples:

    • App has its own database passwords managed by a few admins. They control all the users on their own or it is not managed by IT. Username examples include ‘jeff’ and passwords are just the letter ‘e’.
    • App does not support modern authentication methods such as SAML or OAuth, not able to hook into your Azure or AWS security controls.
    • App roles and access is not controlled by an Identity Manager.

Field workers that must use different usernames and passwords across apps only creates confusion. These legacy apps also do not align to your cybersecurity strategy where you need insight into who is logging into what from where. Now your app is both outdated and a security risk.

Like what you're reading? Sign up to our bimonthly newsletter to catch up on the latest news, industry insight and events.

#3: No user auto-provisioning, role assignments, or termination

Like SSO above, if an app does not have a method to auto-provision users, then it is a major failing. If you must manually add employees or contractors to an app by hand or through a spreadsheet, then it greatly reduces your ability to onboard (or terminate) user access into the system. It certainly doesn’t scale well when you consider the onboarding for thousands of users.

This also applies to assigning roles to users. We need to not only provision users in the new app, but we must define what rights they have within it automatically.

These features are a must have, and apps without these capabilities are moving towards that legacy column.

#4: Lack of alignment between a primary and mobile app

Vendors looking to modernize their app for mobile may only do so after their largest customer complains. To meet the need and shortcut to compliance, they may acquire a mobile app or develop a new one separately of their primary product. This results in their primary app being different from their mobile one, which can misalign their feature sets and create new issues along the way. We have seen where a web and mobile version of an app are split by two different teams, running on their own timelines!

This strategy can create chaos for workers needing to have the same features or data from the control room to the job site. If you cannot use the same app on both desktop and mobile (and get similar features) then your app is not well designed, in my opinion.

#5: App setup requires you touch every single device

This one drives me crazy. We manage thousands of devices, and if we need to launch a new app to the field it better not require that we physically push buttons or type settings on each device. If on first launch the app is not already configured for our company, then it places an unnecessary burden on users and IT.

Here is what you want with a modern app:

  • For web apps, a short name or email domain that auto-directs the user to the right login page. The user does not have to take any action other than logging in.
  • For native apps on first install, a policy is pushed that auto-configures the app ahead of time, which specifies any needed Server URLs or properties. This can use Google Managed Play Store app configuration, or Apple app configuration, etc.

Any app meant for your Connected Workforce should work seamlessly for the user, from first use to finish.

READ: Connected Workforce: What Oil and Gas Companies Need to Know About Private LTE

#6: No support for data extraction

As many companies are learning, Digital Transformation is built around consuming data and parsing through the noise to find those gold nuggets. Then we build new capabilities and reporting around that data.

If your app does not allow us to pull our data from your app in some fashion, like with a robust API, you’re off the list for consideration.

#7: App does not support modern SDKs

Mobile native apps need to import the most common SDKs, such as Microsoft Intune App SDK, AWS Mobile, Citrix SDK, etc. These give us the features we need to expand our mobile footprint quickly. Not having these does not make your app legacy, but it certainly does not show your app design as being forward-thinking.

Summary

Many of us who are working in Digital Transformation initiatives are looking for ways to revolutionize how we do work, and these legacy apps that we continue to support are getting in the way. If the parties who write these apps cannot adapt to these needs, then they must eventually be replaced.

The Connected Worker needs these features:

  • Cloud first solutions that support modern platforms
  • Full support for Android and iOS, whether through native or web apps
  • Options for modern SSO integration, with support for user auto-provisioning, role assignments, and termination
  • Support for managed app configs for iOS and Android apps to automate app configurations
  • A full API suite that is well documented and publicly available
  • Integrated SDKs that allow us to control the app using our mobile management toolsets

Which legacy apps are you still using today? Have you tackled issues with third-party developers who let their apps get rusty? Let me know by leaving a comment.

Interested in learning more about this topic? 

Join us at The Connected Worker Summit on March 28-30, 2023 and network with over 150 of your industry peers at the Norris Conference Center in Houston, TX., and learn how to evaluate the existing gaps in your connected worker capability and identify the data-driven solutions that will drive continuous improvement across your operations. Download the agenda here.


RECOMMENDED