Synodal software development¶

Who needs a database application?¶

Imagine you are the manager of a small team. Of course you have data to store on a computer: documents, pictures, spreadsheets, presentations, multimedia, etc.

And you want to share this data within your team.

Maybe you use Google Drive. Or –when confidentiality is a topic– you have your own file server where you store your data. And the more you use and share your data, the more you discover that things can go wrong:

• data is replicated in multiple files and it gets difficult to find where the most recent version is;

• a team member accidentally deletes some data;

• it becomes otherwise invalid;

• your system leaks confidential data to unauthorized people.

A database application is meant to fix these issues. That’s why almost every team needs a database application. Most teams actually need a customized database application.

customized database application¶

A database application that is well-suited to the needs of its operator.

Use an existing product¶

Maybe you find some affordable proprietary database application that meets your needs quite well. You will start using it and be happy for some time. Until

• the vendor goes bankrupt;

• or the vendor realizes they can earn much more money from their customers;

• or you realize that you need some change and the vendor refuses –or fails– to adapt your application.

At some point you realize that you don’t want to depend on the software owner regarding decisions like when it makes sense to upgrade, which features to drop and which to develop, or how to implement security controls. You want to be the sovereign owner of your data.

Do it yourself¶

Maybe one of your team members writes an application for you. For example in Microsoft Access, which is an established framework for making your own do-it-yourself database application.

Advantages of doing it yourself:

• both the end users and the developer are motivated to collaborate

• you get exactly what you need

• you are the sovereign owner of your data

Doing it yourself works fine until

• your in-house developer leaves you;

• the application gets more complex and your in-house developer no longer dares to maintain it because every new change will potentially break the whole thing.

• the vendor of the framework discontinues some framework feature your are using;

At some point you might want to stop to “fumble around” or to “reinvent the wheel”. Developing and maintaining a database application is much more complex than it might seem at first glance. It includes for example

• analysis

• deployment

• optimizing and maintaining your application

• writing documentation

• end-user training,

Too expensive?¶

Developing and maintaining your own database application is known to be expensive. Most small teams try to avoid the topic. But let’s talk about it.

• A customized database application is a central element of your information system.

• Information systems are a major corporate asset, with respect both to the benefits they provide and to their high costs.[1]

• Most projects became successful when they had an information system that fitted their needs. And most projects fail when their information system doesn’t fit their needs.

• Sovereignty is inalienable (Jean Jacques Rousseau (1712–1778))

Outsourcing¶

Outsourcing is when you delegate development and maintenance of your software to a professional third-party service provider.

Outsourcing, compared to having your own developer team, has the advantage that the developer learns from other customers, which leads to increased quality of their work.

Your choice of that service provider is quite a risky decision. Whom to trust?

You may choose one of the big and established players who use proprietary frameworks like SAP, or Oracle ADF. It’s expensive, but at least nobody can blame you.

But even the big and successful players have a fundamental issue.

The challenge with outsourcing¶

A fundamental challenge in outsourcing is vendor lock-in. With vendor lock-in, the site operator (you) and the application developer (your service provider) see themselves as opponents who fight against each other. They:

• have opposing goals (one wants to get as much money as possible, the other wants to give as little as possible);

• misunderstand each other (because they speak different languages);

• mistrust each other (because they know that the other is trying to exploit them);

• blame each other when something goes wrong (because the culprit must always pay);

• collaborate reluctantly (because collaboration means additional costs)

The Lino framework is meant to handle this challenge in a new way.

Footnotes¶