Skip to end of metadata
Go to start of metadata

The purpose of using the BiZZdesign Team Server differs. There is no one solution for all, but you can organize yourself in a flexible way. This best practice gives you some guidelines about how to set up the structure of your one and only model package.

About the model package

A Team Server (repository) consists of multiple model packages, which consists of multiple models, which consists of multiple model folders and layers/schemes for the catalogs and views. A model package allows you to;

  • Share content
    Reuse objects from a catalog of AS-IS applications in another EA model in the same model package (e.g. an EA model representing a specific project/initiative).

  • Connect models from different types
    Drill down from an EA Business Process object in an EA (ArchiMate) model, to a BPM (BPMN) model that describes the details of that business process using "cross-model" relationships.

  • Move content
    Objects can seamlessly be moved (drag/drop) between models in the same model package.


The golden rule is to work in one model package, this includes the current and future state of the EA. Data needs to sit in the same model package in order to generate views, reports and do analyses. Furthermore, Enterprise Studio cannot check the duplication of objects and relations in multiple model packages. An example of a structure with multiple models in one model package is given below.


Example of a structure with multiple models in one model package

Guiding aspects for separation of the model package

When working together on a model package, different users contribute to a shared model package stored on the Team Server. Each participating user is working on a local copy of the shared model package. Data is exchanged between the users via synchronization by the Activity Console. Model packages are fully separated from each other; models cannot be related over model packages.

The access rights of these users are set on model level, to determine which models the users have write, or read-only access for. For more information about user roles and permissions, please refer to User roles and permissions.

The structure of your model package is for one, thus highly dependent on the number of users in the organization, the role of each user and the access rights you decide to give the users (stewardship).

Some further guiding aspects for the separation of your model package are the following (relevance per aspect differs per organization): 

  • Sandbox and production models
  • Hard separation between enterprise architecture
    Architecture/Solution Building blocks and deployment level
  • Archive section for projects
  • Management only sections (e.g. reporting, ad-hoc reporting)
  • Best practice reference models (IT4IT, ITIL,...)
  • Sections based on different metamodels (ArchiMate, BPMN,...)
  • HoriZZon publication scope
  • Different types of models. More information about the different types is shown below.

Types of models

Enterprise catalog models
Enterprise catalog models focus on a set on core elements that are used for management dashboards. These are often supported by integrations (capabilities, applications, technologies, projects,...).

Portfolio models
Portfolio models are used for portfolio setup and management dashboard reports. They are a good place for standard domain overviews with landscape maps or strategy on a page views.

Domain design models
Domain design models are used for different manually designed views that explain a domain or topic (e.g., a specific capability architecture, information flow views for audit-purpose, etc.). You can add domain-specific elements, such as application services to describe the relevant behavior of applications involved in a capability architecture.

Project design models
Project design models are used for change initiatives. It is recommended to use default diagrams/viewpoints for design and decision making. As for the domain model(s), you can add project-specific elements with the same reasoning as above. It is also possible to add views in design languages, such as BPMN/UML, if you want to describe more fine granular design details.

Content design models
Content models are a location for elements, relations and views that show which elements and relations shall be used to describe architectures. You can use the content model view for quality conformance checks. For more information about quality conformance checks, please refer to Quality conformance checks for ArchiMate models.

Prime navigation models
A prime navigation model is a model that is placed on top of the model browser as a prime entry for model package users. Usually, there is only one view that acts as a starting point for drill-downs into different domains.

Project pitch models
Project pitch models can be used prior to projects, e.g., to investigate where architects see improvement potential. These kind of models also support ad-hoc analysis for specific stakeholder questions without any project involved or without the need to add and maintain metrics for a whole catalog. 

Design documentation models
While EA is primarily a change discipline, you can use the BiZZdesign Team Server for documentation purposes of business processes, significant systems and data architecture. By using design languages, such as BPMN, UML or ERD, you can keep these architecture and process designs apart from the change architecture, or link them together via cross-model relations.

Generic model setup

It is a good practice to setup a generic model in every model of a Team Server. This raises the usability of a repository, since there are not many different places where you would expect elements or diagrams to be located. An example of a generic model setup for a model is shown below.


Example of a generic model setup


The ArchiMate model has different folders (catalogs, diagrams, generated views, model maintenance, portfolio setup) and different layers. A good practice is to make visible what content you want to share in HoriZZon, which is also shown in the figure.  You could use a model maintenance folder to report specific analytic tables or matrices that you want to use for your model house-keeping, but not for sharing.

To keep models lean, you can also delete default layers that are you do not expect to use.

Use of folders

The use of folders is highly important when setting up the repository structure. Folders are most commonly used to organize the models in the package by project, but additional folders may be established to:

  • Organize the high-levels of structure in the repository. 
  • Distinguish different types of architectures (enterprise vs solution, "domain" or "segment" architectures).
  • Separate current state vs future state content.
  • Separate areas for reference models/templates.
  • Separate areas for HoriZZon publication for different stakeholders. 

Two examples that show different usage of folders are shown below.

Publishing an entire portfolio

The structure below is useful for publishing an entire “portfolio” to HoriZZon. In this example the “Application Catalog”, which is in one model, will be published in its entirety. The site scope would be set to the folders ”Objects” and “Published Views".


A more granular publishing scope

The structure below is useful for a more granular publishing scope, where the objects are segregated into separate models. In this example, the views are in a separate model from the objects, but they could just as easily be co-located in the model with their objects.


Helpful tips

  • Start simple. You can always restructure, so don´t worry too much at the beginning about final structures.
  • Objects created in a diagram are located in a default layer of the model in which the view is located. Make sure that these objects are in scope when publishing a site in HoriZZon. A good practice is to create one folder for all the elements and always put this folder in scope.
  • It is often better to create elements in the model browser and then drag them onto a view, instead of creating the element directly on a view. This will create more control, and you will know for sure what is produced where.
  • When an element, such as a (new) application is not yet rolled out in reality, you can capture these elements under project architectures. It is possible to reuse that element in all diagrams, including project and domain diagrams.
  • A prime navigation model positioned at the top gives users a quick link to a start page.