Updating the Building Blocks in the SCOLVO App

Updating the Building Blocks in the SCOLVO App

Our app has been known and appraised by our clients for the quick and easy implementation that is due to the unique development method we use. Such building blocks make updates more comfortable, too.

building blocks

 

When our clients build an app with us, they want to grab the opportunity to implement it quickly while still getting the full functionality needed in a particular role, in a specific industry. Any time these companies save on implementation and the onboarding of the team, they can immediately translate to increased productivity and profitability. They have been enjoying the benefits of the ready-made building blocks based on Scolvo’s industry-specific expertise in financial services, utilities or retail – you name it.

But we have also understood that the same simplicity and ease of use that building blocks provide is necessary for updates, too. Despite all due diligence during the implementation, the needs for new features or data options unavoidably emerge. Datasheets are incomplete. Not enough space for adding new assignees. Status update options not satisfactory. That’s just business as usual.

In a typical scenario, the updates mean a lot of hassle. Take an example from logistics: the sender takes on delivering a unique cargo and decides to require additional identification criteria from the recipient, to make sure the shipment is safe. So it wants to add another field to the app, for an ID number.

No big deal, you think? The traditional solution is to rewrite the code, to redefine the database, and to issue a new version of the app for all the users to make the changes visible. But our mantra of simplicity and the Scolvo app that we built accordingly doesn’t allow us to settle for something so long and complicated.

To prove our app’s value even in this situation, we have recently opted to store and manage the data using a more flexible method: a semantic database. It is driven by a configuration file that is in charge of telling both the backend and the admin interface how to handle the information. So when the client asks as to add a field, we expand the configuration file, and it tells the backend how to structure the new data and tells the web admin interface how to display it.

The semantic data management also makes maintaining data consistency simple. A “flow engine” keeps the modifications in order even if the network doesn’t allow for instant synchronization. In our logistics example, status updates for the loading and discharge of shipments will always appear in the order set by the workflow, regardless of network availability. When several changes happen in the offline mode, like the tasks of loading and unloading a truck get done, the flow engine will make them wait in line until it accesses a network and will make the updates in their original order. Because of keeping all modifications this way, they can instantly go live without causing chaos in the management of previously and recently added data.

For the clients, this background procedure is mostly invisible. They only see that the app can be seamlessly updated and they can manage the workflows or users correctly even when they add some new data to the mix.