Model Management

Semarchy xDM supports out of the box metadata versioning.
When working with a model in the Semarchy Application Builder, the developer works on a Model Edition, that is a version of the model.

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

Model Editions

Model Changes are developed, managed and deployed as Model Editions. This version control mechanism allows you to freeze versions (called Editions) of a model at design-time and deploy them for run-time in a Data Location.

A data location always runs a given model edition. This means that this data location contains data organized according to the model structure in the given edition, and that golden data in this data location is processed and certified according to the rules of the given edition.

Model editions are identified by a version number. This version number format is <branch>.<edition>. The branch and model numbers start at zero and are automatically incremented as you create new branches or editions.

Model version number example

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

Open and Closed Model Editions

A Model Edition is at a given point of time either Open or Closed for editing.
Branching allows you to maintain two or more parallel Branches (lines) of model editions.

  • An Open Model Edition can be modified, and is considered as being designed. When a milestone is reached and the design is considered complete, the model can be closed. When a model edition is closed, a new model edition is created and opened. This new model edition contains the same content as the closed edition.

  • A Closed Model Edition can no longer be modified and cannot be reopened on the same branch. You can only edit this closed edition by reopening it on a different branch.

  • When a model from a previously closed edition needs to be reopened for editing (for example for maintenance purposes), a new branch based on this old 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: This action creates the first branch and first edition for the model.

  • Close and Create a New Edition: This operation freezes the model edition in its current state, and opens a new edition of the model for modification.

  • Create a Model Branch allows you to maintain several parallel branches of the model. You create a branch based on an existing closed model edition when you want to fork the project from this edition, or create a maintenance branch.

  • Deploy the model, to install or update a model edition in a data location.

  • Export and Import model editions, to transfer them between repositories.

Typical Model Lifecycle

A typical model lifecycle is described below.

  1. The project or model manager creates a new model and the first model edition in the first branch.

  2. Model and application designers edit the model. They design the data hub and applications defined in the model.

  3. When the designers reach a level of completion in their implementation, they deploy the model edition for testing, and afterwards deploy it again while pursuing their implementation and tests. Such actions are typically performed in a development data location. Sample data can be submitted to the data location for integration in the hub.

  4. When the first project milestone is reached, the project or model manager:

    1. Closes and create a new model edition.

    2. Deploys the closed model edition or exports the model edition for deployment on a remote repository.

  5. The project can proceed to the next iteration (go to step 2).

  6. When needed, the project or model manager creates a new branch starting from a closed edition. This may be needed for example when a feature or fix needs to be backported to a close edition without taking all the changes done on 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 first edition. This is CustomerHub [0.0].

  • March: The design of this model is complete. The CustomerHub [0.0] edition is closed and deployed. The new model edition automatically opened is CustomerHub [0.1].

  • April: Minor fixes are completed on CustomerHub [0.1]. To deploy these to production, the model edition CustomerHub [0.1] is closed, deployed to production and a new edition CustomerHub [0.2] is created and is left open untouched for maintenance.

  • May: A new project to extend the original hub starts. In order to develop the new project and maintain the hub deployed in production, a new branch with a first edition in this branch is created, based on CustomerHub [0.1] (closed). Two models are now opened: CustomerHub [0.2] which will be used for maintenance, and CustomerHub [1.0] into which new developments are added.

  • June: Maintenance fixes need to take place on the hub deployed in production.CustomerHub [0.2] is modified, closed and sent to production. A new edition is created: Customer [0.3].

  • August: Then new project completes. CustomerHub [1.0] is now ready for release and is closed before shipping. A new edition CustomerHub [1.1] is created and opened.

The following schema illustrates the timeline for the edition and branches. Note that the changes in the two branches are totally decoupled. Stars indicate changes 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] --->

At that stage, two editions on two different branches remain and are open: CustomerHub [1.1] and CustomerHub [0.3].

Considerations for Models Editions

The following points should be taken into account when managing the model editions lifecycle:

  • No Model Edition Deletion: It is not possible to delete old model editions. The entire history of the project is always preserved.

  • Use Production Data Locations: Although deploying open model editions is a useful feature in development for updating quickly a model edition, it is not recommended to perform updates on data location that host production data, and it is not recommended to use development data locations for production. The best practice is to have Production Data Locations that only allow deploying closed model edition for production data.

  • Import/Export for Remote Deployment: It is possible to export and import model from both deployment and development repositories. Importing a model edition is possible in a Deployment Repository if this edition is closed.

  • Avoid Skipping Editions: When importing successive model editions, it is not recommended to skip intermediate editions, as it is not possible import them at a later time. For example, if importing edition 0.1 of a model, then importing edition 0.4, the intermediate editions - 0.2 and 0.3 - can longer be imported in this repository.