From package to model supplier


Every company that uses packaged software, sooner or later, runs up against the same problem, namely that the supplier provides its package as ‘standard’. In itself this is not a problem if the customer leaves it like that, but unfortunately this ‘standard’ solution very rarely matches what the customer actually needs. All their additional requirements are subsequently included in customization, and then the misery begins…

Modifying or expanding packaged software with customization has the consequence that the software is no longer so easy to upgrade to new versions. Upgrading incures additional costs doe the customer or he must continue to use the old version. Not having any customization is usually also not an option.

This normally determines how satisfied the customer is with the package, and the additional work is of course an important source of revenue for the package supplier. In the long-term however this customization becomes an ever greater problem, upon which many IT projects have floundered.

One package for everybody?

A package supplier can resolve the customization problem by including the additional functionality and configuration possibilities in the standard. This leads however to an extremely extensive software package of which an individual customer only uses a small part. As a consequence the rest of the functionality must then be disabled on the basis of thousands of parameters with all kinds of dependencies. Moreover, along with the costs for this personalization it can have a negative effect on the performance of the software. In short, this is not a very good solution. Branch specific packages are also available as an option. These often result in higher customer satisfaction than the generic packages. This is primarily because of the size of the software. This only contains the functionality that is really necessary in a specific branch. This is indeed a good starting point, but at a given moment this software also runs up against problems as soon as a new technology is announced. 

Dealing with new technology

For a package supplier it is often very difficult to convert a package to new technology. Think as an example about the step from DOS to Windows, to web technology or apps for tablets and smartphones. Within the software you also have to deal with all kinds of different programming languages and technologies that make the development even more complicated. If a package supplier also supplies customization to its customers, it just increases this problem. Because how does the supplier integrate all this customization into the new technology? This is the reason that they often already stipulate in a contract that the customer’s customization is not part of the standard upgrade to a new software version. This means that a customer must have the customization developed again or must remain with the old version of the package. Incidentally the maintenance costs associated with this last option often increase annually because the supplier wants to discourage the customer from continuing to use this outdated software.

Emergence of the model supplier

A new trend in the software sector is the use of low-code software with a model-driven approach. The above mentioned problems can be resolved with this approach, because the software supplier no longer delivers a standard package, but a functional model that is separate from the technology. This model is then converted to functional software by the development platform. The supplier of the low-code platform must of course guarantee that the developed models can continue to be used for future technologies. A major advantage of this approach is that a combination is made between a general (basic) model with, for instance, logistic concepts and legislation and a customer specific model. Developments, such as changes in the law, can be modified in the basic model and apply for everybody. If something has to be changed in the customer model then this only applies for this specific customer and has no effect on the general model. The major advantage is that the supplier with a low-code model-driven version of its package never has to re-build its software and can even offer the customer customization without it becoming a dead-end street. A real win-win situation for both parties!

Similar posts

Get notified of the latest Thinkwise news!

Be the first to know about new low-code development insights, inspiring customer cases and the latest Thinkwise news.

By subscribing you will receive a weekly digest of our news & blog posts!