{"id":8162,"date":"2025-11-29T15:24:27","date_gmt":"2025-11-29T14:24:27","guid":{"rendered":"https:\/\/web-dev-weissblau.de\/microconsult\/?p=8162"},"modified":"2026-02-10T16:31:59","modified_gmt":"2026-02-10T15:31:59","slug":"the-paradox-of-customer-specific-standard-software","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/das-paradoxon-kundenspezifische-standardsoftware\/","title":{"rendered":"The paradox of "custom-specific standard software"\u201e"},"content":{"rendered":"

Two worlds, two solutions, and what we can learn from each other<\/h2>\n

Authors: Matthias Essig, WITTENSTEIN electronics GmbH, Benjamin Boost, AIT GmbH & Co.KG<\/p>\n

Contribution \u2013 Embedded Software Engineering Congress 2015<\/h3>\n

Product customization is a central theme found in almost every type of product and in every industry. It is therefore also a core issue in software development. Every customer wants software that meets their specific requirements. Standard software, whether in the embedded or application domain, cannot achieve this. Nevertheless, the proportion of components used in multiple customer projects is very high in most cases. So how is it possible to reconcile reuse and standardization with the production of customized products?<\/strong><\/p>\n

Both WITTENSTEIN electronics GmbH and AIT GmbH & Co. KG had to address this question. Their circumstances could hardly be more different. WITTENSTEIN electronics GmbH develops innovative, customized mechatronic drive solutions that give its customers a competitive edge in their markets. AIT GmbH & Co. KG, on the other hand, is a solutions partner for software development based on Microsoft .NET technologies.<\/p>\n

Clearly, these are two completely different areas of focus. Consequently, the two companies developed two different approaches to developing customer-specific standard software. However, it quickly became apparent in the discussions that neither solution is technology- or industry-specific. Both approaches can be implemented using any technology. It turned out that the central question is not "how," but rather "what.".<\/p>\n

The root cause analysis<\/h2>\n

So what happens if, at the beginning of development, one doesn't ask "what" but focuses directly on solutions, i.e., "how"? Two different fundamental models are very common in practice:<\/p>\n

Option 1 \u2013 Configuration files<\/h2>\n

This approach involves enabling and disabling functionalities via configuration files. During development, this solution appears very straightforward: a software application with maximum functionality, the so-called 150% solution, is implemented, and deactivation options are integrated at the appropriate points. The actual complexity\u2014creating and managing the individual configuration variants\u2014is often overlooked. This becomes particularly critical when new features are added to the existing software, as these must be considered in all previous configurations. Nevertheless, this can be a practical solution if only minimal adjustments are required between the individual variants. Complex merge processes are eliminated, but extensive integration testing is necessary.<\/p>\n

Option 2 \u2013 Customer-specific branches<\/h2>\n

This approach starts with an initially developed software product. This is defined as the standard solution, continuously developed on a development branch, and synchronized on the main branch. When a customer-specific solution is required, a separate branch is created for the customer from the main branch. All individual customizations are implemented in this customer branch. However, this solution leads to the following problems:<\/p>\n

    \n
  1. Troubleshooting issues in the customer solution that affect the standard branch cannot simply be merged into the main branch. A partial merge is necessary to avoid including these specific features in the main branch.<\/li>\n
  2. Features that only affect a subset of customers must be developed twice, as they can only be shared via the main branch. However, this would mean that all future customers would also be affected.<\/li>\n<\/ol>\n

    To circumvent these problems, branches are usually not merged. The corresponding lines of code are transferred using clone and own. Besides the high susceptibility to errors, traceability is also eventually lost. This solution leads to chaos with approximately 10 or more customer branches.<\/p>\n

    The previously outlined solution variants were implemented in the software products of both companies. However, they did not achieve the desired success due to the disadvantages also listed (see Figure 1).,\u00a0PDF<\/a>).<\/p>\n

    Two questions now arise:<\/p>\n

      \n
    1. Why do two development departments (and in reality, there are many more) seem to be making the same mistakes?<\/li>\n
    2. What is the "right" solution?<\/li>\n<\/ol>\n

      First, it's important to note that these are by no means serious errors made by the developers. When developing a client project, the primary focus is on meeting specific requirements. No client will give you extra time or budget to develop a framework that can then be sold to other clients. Non-functional aspects such as modularization, maintainability, and extensibility of the software are therefore given lower priority. Furthermore, common programming principles like YAGNI (You Ain't Gonna Need It) or GALAP (Generalize As Late As Possible) practically preclude developing a framework at the beginning of the product lifecycle. So, no mistakes were made. Rather, this illustrates the lifecycle of a product family.<\/p>\n

      Now the question of the "right" solution needs to be answered. But can there even be THE right solution? An examination of the companies WITTENSTEIN electronics and AIT shows that this is probably not the case. But why did these two companies develop two completely different concepts? Both address the core problem, namely "reconciling individualization and standardization." A closer look at the two approaches will provide clarity below.<\/p>\n

      The product line \u2013 individualization through dependency management<\/h2>\n

      A product line consists of several individualized products that share a number of common features and thus form a cohesive group. Only by considering the various aspects of a product line was the high variance of end products at WITTENSTEIN electronics made possible.<\/p>\n

      In light of the previously discussed (failing) approaches, a product line offers further significant advantages: The reuse of already developed components in subsequent products and the associated increase in efficiency regarding development time is just one example. The key to product line development lies in leveraging the commonalities between the products within the line and in the presentation and handling of the different products. Since previous individualization concepts proved largely unsuccessful, it was necessary to explore new avenues. To this end, a scoping analysis was used to identify the components of the delivered products that are present virtually unchanged in all products (Core, Figure 2, see [reference]).\u00a0PDF<\/a>). Another component became apparent, which often has the same scope but is project-specifically customized (Common, Figure 2, see\u00a0PDF<\/a>).<\/p>\n

      This seemingly trivial, yet far-reaching insight led to an immense initial effort, which, among other things, resulted in the dependency management approach presented below. Figure 3 (see\u00a0PDF<\/a>) outlines this developed dependency approach in a very abstract way, but it forms the core of the product line development.<\/p>\n

      In order to develop core features independently of project-based business and to have a basis for creating new customer projects, in addition to the\u00a0Core<\/em>\u00a0the\u00a0ProjectTemplate<\/em>\u00a0offered. The depicted\u00a0ProjectTemplate<\/em>\u00a0with its artifacts\u00a0Common<\/em>\u00a0and\u00a0Platform<\/em>\u00a0serves as a development and runtime environment for the\u00a0Core\u00a0<\/em>as well as a starting point for new customer projects.<\/p>\n

      So that the artifacts explained so far\u00a0Core<\/em>,\u00a0Platform<\/em>\u00a0e.g.\u00a0DSP<\/em>\u00a0and\u00a0Common<\/em>\u00a0To merge multiple components into a fully functional project, the Dependency Manager from AIT GmbH comes into play. The Dependency Manager is used to create a cohesive system for each platform, e.g.,...\u00a0DSP<\/em>, unique versions of\u00a0Common<\/em>\u00a0and\u00a0Core<\/em>\u00a0to reference. Here,\u00a0Core<\/em>\u00a0the part of the product that is used independently of the project, i.e. the reuse share.\u00a0Common<\/em>\u00a0abstracts the part of the product that can be modified to suit the customer and application.<\/p>\n

      As already described,\u00a0ProjectTemplate<\/em>\u00a0Polyvalent properties:<\/p>\n