"No code" apps and data effectiveness

Data is the lifeblood of organizations today. But the quality of the data we collect is often wanting. While it's a good start to collect a more thorough set of your critical data in the first place, often the systems that are put in place are done so without enough thought about getting that data back out.

Recently I have engaged with clients who have run into this problem with Salesforce1, Quickbase, Zudy, Caspio, and other "no-code" app builder type offerings. These products are not really platforms per se and don't necessarily require highly skilled technical resources but neither are they fully featured end-user applications.

Instead they allow smart but less tech-saavy users to create applications covering gaps that are not big enough for custom development or a COTS product but too complex for office productivity solutions like spreadsheets.

For example, a single department within a larger organization may need to manage a workflow particular to their small team but not really relevant to anyone else. Or a smaller local government agency like an office of civil rights or a public library system often has very unique data tracking needs.

"No-code" apps fill this role well but often their very flexibility leads to poor data model choices.

A good example is a company I worked with that was using Salesforce to track vehicles in its fleet. The problem was that the development shop they had hired took the approach of modifying the standard Salesforce app by renaming things and adding a few custom objects instead of designing a completely custom application from scratch.

While this was a very reasonable and cost-efficient approach to get their data captured, repurposing of the data model in the standard app instead of creating a fully custom data model meant that the existing user interface drove the data model directly.

This put the developers under the artificial (and likely unconscious) constraint of hewing to the existing data model. Data was put where it could be not where it should be. The result was that while all their data was somewhere, it was often in multiple places.

For example, data on the assigned drivers for each vehicle could be stored in three different places depending on what task the data entry person was doing. If they were adding a new vehicle, the driver data would go in one place. If they were adding a driver without assigning a vehicle to them initially, it would go in another. And if the data for a previously existing driver had been imported from the previous version of the database, the users would need to update that in a third location.

This meant that something as simple as "how many drivers do we have" was difficult to answer. The app had been built with a focus on vehicle tracking as that was the immediate problem but little thought was given to anything beyond data capture for that purpose.

I ended up helping them redesign their data model to include a "drivers" table (among other things), an obvious solution but one that would have been much easier to implement if the data model had been developed from scratch instead of re-used. Cleaning and processing data after the fact to ensure that there were no duplicates is a real chore. But because they started with the goal of simply repurposing the existing application, any higher order thinking on long term problems was not part of the process.

This nearsighted approach to data model design is not particular to Salesforce, Quickbase, etc. But while their relative ease of use and flexibility is a strength in terms of quick ROI (Return On Investment), it too easily leads organizations down shortcuts that turn out to be dead-ends, blocking them from making effective use of their data.

It's the data equivalent of storing your money underneath your mattress: the immediate problem is solved but the data generated cannot be leveraged in any other way.

Next time your organization starts working with Salesforce or something similar, take a step back and think about what you would like to do with the data once you've got it. Think about the universe of reports you would like to see, not just the workflow data you'd like to capture. Spend some time imagining what other aspects of your organization you would want to gain insight into once the immediate problem is solved.

You'll find that some simple changes in design choices up front will increase the ROI of your data, turning it from a superficial exercise in checking-the-box to a source of insights and levers to make your business more effective.