When defining a practical Project Configuration for productive deployment, having Variability Definitions in separate Architectural Projects doesn’t cut it. Mostly because it becomes very difficult, if not impossible, to maintain consistency of Variability information across separate Projects.
I address two aspects in this post. How to manage Variability Definitions and how to manage Variant Architectures from Configuration (Project) Management perspective. Let’s start with the first.
Using practical Configurations, it is all about the hierarchy of Project Usages. The issue here is how to reuse Variability information across this hierarchy to have it consistent across the organization (or actual Architecture Projects).
The solution is to have Features, Configurations and Variation Points defined in a single Pjoject that holds the complete Variability Definition, which is then consistently used by multiple Projects. Changes in the Variability Definition Project are propagated to all usage points across the domain of 150% Architecture(s) and subsequently to Variant Architectures.
The downside from a modeler’s perspective is that a Process (Workflow) is required to manage the Variability Definition Project separately. If a new Variation Point Definition of Feature needs to be added, it has to be introduced in the upper level Project (usually by a specific Role). But this in turn contributes to security, integrity and consistency.
Now to the second aspect regarding the Variant Architecture Management. A practical solution is to store the 150% Architecture Model in the Trunk and 100% Architecture Models (Variants) in the Branches of the same Project. Branches are Configuration Specific – each Variant is realized to its own Branch.
The Development of the 150% Architecture Model in most cases usually takes place in the Trunk and the snapshots of Variants are realized as required to their corresponding Branches. This is the case when Variant models are used only for analysis, publishing, giving to OEMs, etc.,-- not for further Architectural development.
However, depending on internal processes, changes sometimes need to be introduced in the Variant Model. As illustrated, a third level is required for change introduction. The changes in the Variant Architecture can then be optionally merged back to the second level and then back to the 150% Architecture.
As always, having a proper Configuration Definition and Management as part of the Systems Engineering Methodology is necessary for successful deployment and maintainability. Everyone having access to a single methodical reference is the key for MBSE success.
Things to consider in general: Do you need a MB-PLE approach? Depending on complexity, can variability be solved using other means? Let’s discuss your particular case.
