In another article, we talked about software implementations and asked you whether your company relies on standard solutions for purchasing. Here we are now dealing with the question: Do we have to forego customizability with standard solutions? And: What do we mean by configurable software?

Standard software: Many terms - one principle

Let's start at the beginning. We decide to buy a so-called standard solution. What is that anyway? There are bound to be different opinions on this, just as there are different terms, such as out-of-the-box or commercial off-the-shelf (COTS) software. We define a standard software here primarily with reference to the way the software is developed and maintained by the supplier.

The development of a standard software runs along a single path without any branches . On this main development path - also known as a trunk - releases are then created sequentially, which always contain new functions (also known as features). In this way, the standard solution continues to evolve over time. This also ensures that an earlier release of the software can be easily updated to a newer release at any time. This is referred to as the release capability of the software, a very critical point in configurability, which we will come to below.

The development strategy is crucial

Different customers or users of the software can therefore have the same standard software but with different release statuses. In the case of standard software, there are at no time parallel versions which have arisen from a common earlier release (i.e. branches) and which cover different customer requirements. To be precise: Such parallel versions do not exist "externally", i.e. towards the market. Internally, development can have different branches so that different teams can work on different parts of the software in parallel. These development branches are then simply merged into a market release at the appropriate time. This is called merging.

The supplier's development strategy should now be (at least in our opinion) to reconcile as far as possible all the different needs of the various customers by finding generic solutions. These broadly applicable solutions can then be configured customer-specifically in order to nevertheless take account of the customer's specific situation. This is where we first encounter the term "configurable".

With such a development strategy, compromises must of course also be found in certain situations, e.g. by deliberately implementing only one of several solution variants for one and the same customer need, which can then either not be configured at all or only to a limited extent. In this case, the software supplier has to accept that he will not be able to satisfy all customers in order to pursue his strategy consistently. All customers will then benefit from the advantages. We will come back to this at the end of this article.

The configurability is in the database, not in the source code

So now to the central concept of this text: Configurability. Others also speak here of parameterization or similar terms. The configurability of a standard solution can be explained as follows.

In the case of a business application with a common 3-tier architecture, a typical software installation consists of an application server (middle tier) and a database server (lower tier). The user accesses the application server via a client (upper tier, in the case of a web application this is the browser). Per installation, settings(configuration values) can now be stored in the database of the system, which control the behavior of the system. However, the application server is based on a specific release. Nevertheless, users notice different functionalities or behaviors of the system, depending on how the system is configured.

The crucial point is the following: The mentioned configuration values are in the database (at most in configuration files in the application server), but never as part of the source code in the application server. Real configuration therefore has nothing to do with a customer-specific further development or adaptation of the source code. This would result in unpleasant branching, which would then endanger or even make release capability impossible. This is exactly what makes further development expensive for the customer, since such further developments have to be made separately for each customer and the individual customer cannot profit from a comprehensive further development for all customers.

Configurability therefore does not mean, in particular, that adaptations are made by programming the source code. The adaptation of the source code always and exclusively takes place through generic further development of the basic functionalities of the standard software and leads to a new release. Existing configurations can simply be adopted in the new release. This is the release capability of configurable or already configured standard software systems.

How do you recognize configurable software?

This question is not so easy to answer from the outside perspective, i.e. from the perspective of the customer who wants to evaluate and buy such software. From the developer's internal viewpoint, of course, this is easy. But in the sales process, the customer may be presented with software that is actually not configurable at all (in the sense defined above) as "configurable", which does not deserve this label at all.

Such a solution may rightly be called standard software because it is developed along a single release path. But it was not built from the outset with a development strategy that implements functionalities generically and makes them adaptable through configuration. The "configurability" of such systems is then effectively implemented through further development. Of course, this is not sold to the customer in this way.

Some simple features of (truly) configurable software are the following:

• A customer-specific configuration is cost-effective because it involves little implementation effort for the supplier.
• The configuration can be implemented quickly in terms of time (with the same justification).
• The system remains release-ready at all times, i.e. upgrades to future releases cost nothing, neither money nor effort.

In the case of PQFORCE, for example, a customer configuration (of the entire system, mind you) means an approximate effort of ½ to 2 days, depending on specific wishes and scope of detail. And when we offer a new release, it can be easily installed for each customer without any effort.

poll/110626]

The advantages of configurable standard software from the cloud

Finally, we would like to list the most important advantages of configurable standard software from the cloud compared to individual software. Software like PQFORCE...

• ...is significantly cheaper to procure. And we're not talking percentages here, but factors. Simply because no expensive development project has to be financed. And the configurability even enables customer-specific adaptation at extremely low cost - for all those customers who do not want to settle for the out-of-the-box solution.
• ...is ready for use in a very short time after purchase. Setting up a PQFORCE client takes a few minutes (sic!), and the pilot operation can thus start immediately. Here, the readiness of the customer's organization is rather the braking factor.
• ...makes it possible to use economies of scale. The further development is driven(crowdsourcing) and financed(crowdfunding) by an entire customer portfolio.
• ...offers regular innovations (feature releases) in short cycles of a few weeks, which can be initiated by customers and used immediately as soon as they are available(DevOps principle).

So it's no wonder that today the trend is clearly moving in the direction of cloud-based standard software. If this is then also really well configurable, then you as a customer have all the advantages on your side.