Model management

Semarchy xDM supports out-of-the-box metadata versioning. When working on a model in the Application Builder, developers actually work on a model edition—that is, a version of the model.

Model management includes all the operations required to manage the versions of a model.

Model editions

Changes to a model are developed, managed and deployed as model editions. This version-control mechanism allows designers to "freeze" versions (i.e., editions) of a model at design time, and deploy them for run time in a data location.

A data location always runs a specific model edition. This means that a data location contains data organized according to the model structure of the given edition. The golden data within this data location are processed and certified according to the rules specified in that edition.

Model editions are identified by a version number, formatted as <branch>.<edition>. Both branch and model numbers start at zero, and are automatically incremented with the creation of new branches or editions.

Model version number example

The first edition of a model in the first branch is version 0.0. The fourth edition of the CustomerAndFinancialMDM model in the second branch is version 1.3, and is typically referred to as CustomerAndFinancialMDM [1.3].

Open and closed model editions

At a given point in time, a model edition is either open or closed for editing.
Branching allows designers to maintain two or more parallel branches (i.e., lines) of model editions.

An open model edition can be modified and is considered as being in the design phase. When a milestone is reached and the design is considered complete, the model can be closed. A new model edition is then created and opened. This new model edition contains the same content as the closed edition.
A closed model edition is no longer editable and cannot be reopened on the same branch. The only way to modify a closed edition is to reopen it on a different branch.
When a model from a previously closed edition needs to be reopened for editing (e.g., for maintenance purposes), a new branch based on the former edition can be created and a first edition on this branch is opened. This edition contains the same content as the closed edition it originates from.

Actions on model editions

Model editions support the following actions:

Create a new model: to create the first branch and initial edition of a model.
Close and create a new edition: to "freeze" a model edition in its current state, and open a new edition of the model for modification.
Create a model branch: to maintain several parallel branches of the model. A branch can be created based on an existing closed model edition to fork the project from a given edition or create a maintenance branch.
Deploy a model edition: to install or update a model edition in a data location.
Export and import a model edition: to transfer model editions from one repository to another.

Typical model life cycle

Below is a typical model life cycle:

The project or model manager creates a new model and the initial model edition in the first branch.
Model and application designers edit the model, designing the data hub and applications defined in the model.
Upon completing an implementation phase, designers deploy the model edition for testing. Subsequently, they redeploy it as they continue implementation and tests. These steps are typically performed in a development data location. Sample data can be submitted to the data location to be integrated into the hub.
When the first project milestone is reached, the project or model manager:
1. Closes the initial model edition and creates a new one.
2. Deploys the closed model edition or exports it for deployment on a remote repository.
The project can then move to the next iteration (starting again at step 2).
As needed, the project or model manager creates a new branch from a closed edition. This may be needed, for example, when a feature or fix needs to be backported to a closed edition without incorporating all the changes made in later editions.

A chronological example

The following example shows the chronological evolution of a model through editions and branching:

January: a new CustomerHub model is created with the first branch and the initial edition, CustomerHub [0.0].
March: the design of this model is complete. The CustomerHub [0.0] edition is closed and deployed. The new automatically opened model edition is CustomerHub [0.1].
April: minor fixes are applied to CustomerHub [0.1]. To deploy changes to production, the CustomerHub [0.1] model edition is closed, deployed, and a new edition, CustomerHub [0.2], is created for maintenance.
May: a new project begins to extend the original hub. For the new project and ongoing hub maintenance, a new branch with a first edition is created based on the closed CustomerHub [0.1] edition. Two models are now open: CustomerHub [0.2] for maintenance, and CustomerHub [1.0] for new developments.
June: maintenance fixes are needed for the hub in production.CustomerHub [0.2] is modified, closed, and sent to production. A new edition, Customer [0.3], is created.
August: new projects are completed. CustomerHub [1.0] is ready for release, closed before shipping, and a new edition, CustomerHub [1.1], is created and opened.

The timeline diagram below illustrates the edition and branch progression. Note that changes in the two branches are entirely independent. Stars on the diagram indicate modifications made in the model editions:

Month    : January       March      April   May        June     August
Branch 0 : [0.0] -***-> [0.1] -*-> [0.2] ----------*-> [0.3] ----------->
Branch 1 :                    +-branching-> [1.0] -**-**-****-> [1.1] --->

In August, two editions on two separate branches are open: CustomerHub [1.1] and CustomerHub [0.3].

Considerations for model editions

The following points should be taken into account when managing the model edition life cycle:

Use production data locations: while deploying open model editions is useful for quick updates in development, it is not recommended to perform updates on data locations that host production data. The recommended practice is to use dedicated "production data locations" for deploying closed model editions only.
Import or export for remote deployment: models can be exported and imported from both deployment and development repositories. Importing a model edition is possible in a deployment repository if the edition is closed.
Avoid skipping editions: when importing successive model editions, it is not recommended to skip intermediate editions. For example, if importing edition 0.1 and later 0.4, the intermediate editions—0.2 and 0.3—cannot be imported into this repository at a later time.