Why are data applications such a disaster?

Data in an ideal world, in its simplest form is a collection of useful information used to make meaningful decisions. So why don’t data applications do what they say they are going to do or is the problem not really the data application.

As a development team we investigated this data application issue by focusing on the end user (buy in users to an application) and what they perceived to be a data disaster. We were skeptical at first, but surprisingly (as developer would think), we did not find the issue to be with the end user.

We concluded our investigation with the following:

• Procrastination of old-school ideas
• Large amounts of energy and time to work with and build ideas
• Poor software development and ideas
• Technical time to design, the technical person is always busy
• Time required to see value
• Software development complexity
• Specialist required to operate platform
• Hidden service costs
• Business user adoption rate is low
• Data inconsistent and not instant

We also agreed that any data application needed to include:

• Flexibility
• Cheap or no cost feature ad-dons
• Scalability
• Features greater than cost
• Continuous improvements

So how does one go about making sure that the end user is buying into a data application. The end user must be involved in the improvement of a data application but making all end users happy is a near impossible task. We had to identify the problem areas first. So how does one go about making sure that the end user is buying into a data application. The end user must be involved in the improvement of a data application but making all end users happy is a near impossible task. We had to identify the problem areas first. There were many problem areas mostly from the those involved before the end user got a chance to say anything. Something of a traditional approach from start to finish was still in practice, maybe people were comfortable in their own ways.

These ways are always thinking for the end user before consulting the end user, no wonder data applications are a disaster. And CX well it was nowhere to be seen after a few meetings.

Despite all the issues above the main problem lay with the developer.

You see, any non-technical person automatically thinks a developer, knows pretty much everything when it comes to technology. The problem with this thought pattern is the developer believes this is true. This kind of thinking leads to a comfortable developer designing the way they have always designed.

The problem with this approach is if there is no transition by the developer to cutting edge development methodologies, which leads to an end user never getting involved in the application they work on every day.

We concluded with the following improvements:

• The developer needs to design back to front with the end goal of a never-ending application
• The application needs to be light weight, flexible, scalable, and most importantly putting the end user in a seat of control
• Lastly, the developer needs to change from their traditional old school product approach ways and not enforce this on end users who are already in a real cloud world.

One final thought

The traditional old school on-premise developer does not have a lot of time left but then that is up to the end user.

Look out for us on the Genesys AppFoundry or search for us on YouTube. Let us start changing the way forward for end users.