EN 
DE Two worlds, two solutions, and what we can learn from each other
Authors: Matthias Essig, WITTENSTEIN electronics GmbH, Benjamin Boost, AIT GmbH & Co.KG
Contribution – Embedded Software Engineering Congress 2015
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?
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.
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.".
The root cause analysis
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:
Option 1 – Configuration files
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—creating and managing the individual configuration variants—is 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.
Option 2 – Customer-specific branches
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:
- 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.
- 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.
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.
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)., PDF).
Two questions now arise:
- Why do two development departments (and in reality, there are many more) seem to be making the same mistakes?
- What is the "right" solution?
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.
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.
The product line – individualization through dependency management
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.
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]). PDF). Another component became apparent, which often has the same scope but is project-specifically customized (Common, Figure 2, see PDF).
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 PDF) outlines this developed dependency approach in a very abstract way, but it forms the core of the product line development.
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 Core the ProjectTemplate offered. The depicted ProjectTemplate with its artifacts Common and Platform serves as a development and runtime environment for the Core as well as a starting point for new customer projects.
So that the artifacts explained so far Core, Platform e.g. DSP and Common To 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.,... DSP, unique versions of Common and Core to reference. Here, Core the part of the product that is used independently of the project, i.e. the reuse share. Common abstracts the part of the product that can be modified to suit the customer and application.
As already described, ProjectTemplate Polyvalent properties:
- Development of core features
- Setting up customer projects
By implementing a reusable core component and a customizable element, setting up a new customer project is now very easy. The general dependencies between the individual artifacts... Core, ProjectTemplate and Customer Project are shown again in the following illustration.
The structure in Customer Project is analogous to the structure in ProjectTemplate built up. The two arrows Branch in Figure 4 (see PDF) reference from the release branches in Common and Platform on the corresponding Develop branches in Customer Project. Furthermore, the dependency is to Core from Customer Project executed as a "read-only" dependency, since core features are never within Customer Project They may be modified. The parts of the software product in Common and Platform can now be used simultaneously with the standardized Core be individualized.
With this approach, WITTENSTEIN electronics has succeeded in solving the paradox of "customer-specific standard software", although it has already been mentioned that the dependency management described is only one pillar for successful implementation.
Customization via package management and extension points
The concept of a product line was the key to success for WITTENSTEIN electronics. However, this approach was not suitable for AIT GmbH. Instead, they deal with a standard product whose number of basic functions is variable and which is extended with further customer-specific functionalities. These extensions can be either new features or modifications to existing features. Figure 5 (see PDF) schematically shows the structure of the application after the dissolution of the monolithic structure.
The base application contains no significant functionalities. It serves solely as a hosting platform and is managed in a separate branch for each customer project. Due to the minimal size of the base application, merging any bug fixes is straightforward.
The integration of the basic functions is achieved via packages. The NuGet package management system is used for this purpose. It enables the deployment of modules with unique version numbers via a central management point (network drive or web server). All basic features are therefore developed in separate projects and published in the package manager via an automated build process. From there, they can be consumed in customer projects. This distribution method guarantees that the basic features in customer projects are protected against any form of modification. Since multiple versions of a feature are available in parallel, it is up to each customer project to decide whether or not to perform an update.
The implementation of customer-specific features, or even modifications to existing features, takes place via so-called extension points. These are permanently implemented entry points in the base application and the base features. At these entry points, both the base application and the base features search for modules with predefined or configurable signatures. If a matching module is found, the specific functions are called and executed.
At this point, the question immediately arises as to where such extension points should be placed in the application and what principles govern the calling of extension modules. However, there is no general answer to this. If your application follows an iterative process, for example, a search for new modules can be implemented at the beginning of each iteration. Subsequently, all found modules are called in a predefined order (see Figure 6)., PDF).
When it comes to the design of the modules, a package is used again. This package contains interface definitions and template files that form the basis for implementing an extension. The development of customer-specific functions by AIT is also significantly simplified. The modules created in this way can then be integrated into the application as packages before compiling the software or dynamically at runtime using appropriate technologies.
As mentioned earlier, this is an example from application development in the Microsoft environment. However, this doesn't mean the basic idea isn't also applicable to embedded software. It's entirely possible to develop all the core functionalities required for your customer projects within a single main application. By using NuGet, individual features can be packaged into small packages. NuGet supports all types of package content – not just binaries. When the packages are installed in their target project, an installation script is executed, placing the necessary files for each feature into the project. Creating a new customer project could therefore look like this:
- Creating a completely empty project
- Install the "Infrastructure" package to create the folder hierarchy.
- Install the desired feature packages (These may also have dependencies on each other, which will be resolved automatically.)
- Adding new custom features
Version-based package referencing now makes it possible to selectively update individual features. If your project is built using an automated build process, the packages can be reloaded with each build, thus preventing changes to core features. Furthermore, creating packages from a central project eliminates the need for a complex branching model for individual features.
Conclusion
To develop customized standard software, a key question must be answered: Which functionalities are part of the standard, and where is customization possible and necessary? It has been demonstrated how dependency management can be used to integrate a range of standard features into a customized main application. In contrast, there is the standardized base application, which can be adapted to customer requirements with features and extensions via package management and extension points.
Ultimately, the realization remains that the individualization of software products is a challenge that must be faced. Those who close their eyes to these challenges will not be able to survive in the market.
Both of the presented solutions have proven successful in practice and are scalable to projects of varying sizes. While the initial effort required for a suitable concept should not be underestimated, the advantages clearly outweigh the costs. Developing customized software while simultaneously standardizing for effective resource utilization are therefore not mutually exclusive – especially with the right concept.
Software Engineering Management – our training courses & coaching sessions
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Software Engineering Management / process, project and product management.
Training & coaching on the other topics in our portfolio can be found here. here.
Software Engineering Management – Expertise
Valuable expertise in software engineering management / process, project and product management is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
