There is one central location within XXX (the central D&A environment) for receiving, storing, validating, processing, modeling, integrating and delivering current and historical data and information products from various external and internal (XXX) sources and domains. . The data foundation/data hub is not intended as a conduit for data. Data foundation adds value to the data flow. The central data foundation functions in two ways: as a 'data hub' function and as a DWH/dashboard and reporting function. Both are fully aligned and therefore we use "a single source of truth" both in your planning and in steering based on the realization.

In the previous chapters we discussed the different dimensions of introducing an Architecture Repository. In this chapter we discuss a number of tools that support and simplify the introduction of an architecture repository. We are working on this based on Sparx Enterprise Architect, a modeling tool for various modeling languages. This makes it extremely suitable for setting up Sparx Enterprise Architect as an architecture repository. The elaborations of these tools have all been developed based on Sparx Enterprise Architect.

Exchange of (partial) models based on the ArchiMate exchange standard so that exchange with other (ArchiMate) modeling tools is possible.

Architectural models can always be more beautiful and detailed. This is often unnecessary and even undesirable. These overmodeled architectures must also be maintained and managed at a later stage. In addition, a detailed model is neither relevant nor clear for many stakeholders.

ArchiMate is an enterprise architecture modeling language that is used at a higher level of abstraction and is combined with other modeling languages such as BPM and UML for desired detail.

This section proposes a number of ArchiMate viewpoints for modeling the various building blocks and their mutual relationships. In the diagrams, the viewpoints are only elaborated on the basis of the elements and the relevant mutual associations. A description of the concepts themselves is not provided. We adopt definitions and possible associations as defined within the ArchiMate modeling language itself. ArchiMate has three layers in the core model, namely Business, Application and Technology layer. xBB can be applied in the three layers mentioned above. However, because the perspective in this document for the xBB is mainly on application and infrastructure, the viewpoints have only been developed for these two layers. For the ABB, ArchiMate uses the Behavior column. Since ArchiMate 3, there have been multiple elements within this column. When elaborating in the viewpoints, only the Application_Function and Technology_Function are used. If another concept, for example an Application_Process or Technology_Process, is relevant in an elaboration, this can of course also be applied. For the SBB, ArchiMate uses the Active Structure column. Many different concepts are available, especially within the technology layer. Only the System_Software is used for the implementation in the viewpoints. If another concept is relevant for an elaboration in this dimension, it can of course also be applied.

When applying modeling languages and working in a repository, it is very important that there is agreement on the modeling languages and the modeling and naming conventions. This can be achieved by developing a community where this capability is jointly developed and maintained.

A model is a schematic and simplified representation of part of the (architectural) system. It is often developed in modeling languages such as ArchiMate or BABoK.

The metamodel of the Architecture models and the resulting architecture products must match the context of the organization. This will often be based on one or more modeling languages. Within these modeling languages, a subset will often be developed for the context of the organization. In addition, it must be worked out how a combination of modeling languages is realized. This forms the basis for the metamodel of the architecture repository.

It is possible, preferably, to activate and deactivate functionalities per authorization role. Use should be simple, especially for roles that occasionally use the architecture repository.

Despite the fact that architectural modeling is a very creative process, this does not alter the fact that repetitive tasks such as model validation but also the use of templates can be automated. What and how this automation is introduced is a work process.

BPMN is business process modeling and is used to provide detail for work processes and activities.

Concept is an abstract entity in the metamodel of a modeling language and is characterized by the fact that it can appear in diagrams or views based on the associated stereotype. Here we recognize two specializations of a concept, namely element and connector or relationship.

The architectural modeling languages are often extensive, which is why a subset of entities, connectors and attributes are often chosen. The repository is configurable to make the design specific to the viewpoints of the user organization.

In addition to the configurability of the modeling languages, there is a transcendent metamodel. This must also be configurable so that the modeling language can be configured to the wishes of the organization beyond the modeling.

the introduction of an architecture repository, the associated (modeling) tool will need to be configured and set up so that the modelers can effectively work together on the architecture model and the products.

Connection between two elements, presented visually in a line-based diagram. Each connector can have its own stereotyping, giving it its own appearance and meaning depending on the modeling language.

When developing models and expanding the model by adding new elements in diagrams, introducing a duplicate is a risk. The toolbox is always close by in a diagram and searching in advance to see whether a concept already exists in the repository is often regarded as an extra step in the modeling process. Early detection of the emergence of a duplicate is therefore desirable and can fortunately be automated relatively easily in modeling tools such as Sparx Enterprise Architect.

There are several modeling languages and frameworks available for setting up an enterprise. Think of Archimate, Togaf, UML and BPMN. The search is often for a subset of these languages. To this end, a weighed choice must be made.

After choosing the modeling languages, it is possible to impose further restrictions on the modeling forms. Modeling languages are often so extensive that not all concepts are relevant to the organization. This can simplify use. That is why many organizations opt for further restrictions within the languages. This is done by introducing ViewPoints and Perspectives.

A diagram is a visual representation of some of the repository content. A diagram is often based on a modeling language or a combination of a number of modeling languages. Elements from the repository are placed on a diagram.

duplicate is a data element in the repository that is considered a duplicate based on a number of properties. Duplicates can occur with concepts that can be divided into elements and relationships. Elements Elements are actually the blocks on a diagram with certain properties within a modeling language and an appearance. Duplications can be considered the same based on these characteristics:

• Name of the element (possibly based on missing punctuation marks)
• Version number
• Modelling language and Object type within the language. Also referred to as a stereotype.

Relationships Relationships or connectors are actually the connecting lines on a diagram with certain properties within a modeling language and an appearance. Duplicate relationships can be considered the same based on these characteristics:

• Name of the relationship or cardinalities of the start and end points of the connectors
• Version number
• Modelling language and Object type within the language. Also referred to as stereotype

Due to the joint use of the elements in a repository, modelers must be alert to duplicates, homonyms and synonyms in the model. Preferably, a control process is set up to prevent this. This process is preferably supported by functionalities in the modeling tool.

Descriptive concept that describes a characteristic within a model. The element is a core concept in the model and is an aggregation of several details. Each element can have its own stereotyping, giving it its own appearance and meaning depending on the modeling language.

Short checklist for modeling business process architecture with BPMN

Short checklist for modeling enterprise architecture with ArchiMate

These examples elaborate on a number of aspects of modeling based on building blocks. Consider this example without thinking about the design of the catalogs and the granularity of the building blocks. In addition, only an explanation is given for the diagrams, not for the concepts elaborated in them.

The IDEA AddOn is an open source AddOn to support modeling activities within Sparx Enterprise architect. The IDEA AddOn offers functionalities that are missed in the standard functionalities of Sparx Enterprise Architect. Particularly for architectural modeling and aspects of an architecture repository, a number of functionalities are present in this IDEA AddOn.

A list of proposals, in the form of requirements and requirements for the architecture to be drawn up. But also for the metamodel or the modeling conventions of the architectures to be developed.

1. The lifecycle management of information and related technology used by an organization.
2. An umbrella term that includes all or some of the subject areas relating to the computer industry, such as Business Continuity, Business IT Interface, Business Process Modeling and Management, Communication, Compliance and Legislation, Computers, Content Management, Hardware, Information Management, Internet, Offshoring, Networking, Programming and Software, Professional Issues, Project Management, Security, Standards, Storage, Voice and Data Communications. Various countries and industries employ other umbrella terms to describe this same collection.
3. A term commonly assigned to a department within an organization tasked with provisioning some or all of the domains described in (2) above.
4. Alternate names commonly adopted include Information Services, Information Management, et al.

Exchange of (partial) models based on the BPMN exchange standard so that exchange with other (BPMN) modeling tools is possible.

An inventory document describes the aspects that are relevant when mapping a complex architecture, for example the baseline or target architecture. It is part of the analysis and modeling to establish an architecture.

The architecture repository works with a shared and established metamodel, including the modeling conventions. This prevents dialects and differences in the models within the repository.

Description of the modeling and naming conventions based on a checklist. This makes naming conventions easy to introduce and maintain.

Viewpoints are constraints in the architectural models based on the modeling languages. If you want to use simple architectural models, you should develop this as part of the metamodel.

Data modeling and meta modeling for example models based on UBL and government models. These models are used for data storage, but also for data integration, transformation and validation

Because working with an architecture repository is based on standardization and reuse, this requires discipline from the modeling team in terms of modeling conventions and collaboration. This is only possible if the team works together and views the repository as a joint product.

When using an architecture repository, it is important to determine what and how the architecture is modeled. To this end, a metamodel is drawn up by this role. This includes the modeling conventions, cross-language conventions and design of the repository.

Metamodel consists of a list of various modeling languages relevant to architecture, including a number of submodels and languages. On this basis, the organization can make a selection of the architectural languages and sublanguages relevant to them. In the development of the tools, such a metamodel based on simplified viewpoints in ArchiMate is developed as an example.

The metamodel describes the model of the architectures. This is often based on an architectural modeling language such as ArchiMate. These architectural modeling languages have also been developed in a metamodel

A metamodel is important for an architecture in general and essential for an architecture in a repository. Because the metamodel forms the framework for the architecture, it must be developed and maintained in a work process.

Conventions for a type of modeling.

Responsible for the use and deployment of the models in the architecture repository. Has a coordinating and controlling task for all modeling roles involved in the architecture. Monitors the consistency of the architecture repository and provides modellers with information and training on the use of the architecture repository.

The metamodel and the chosen modeling languages are also joint in a shared environment. Therefore, there needs to be agreement on these artifacts within the modeling community. To this end, consultation forms must be set up to obtain and safeguard this agreement. In addition, the metamodel must be consultable by the entire community.

The architectural process and products are also joint in a joint environment. Therefore, there needs to be agreement on these artifacts within the modeling community. To this end, consultation forms must be set up to obtain and safeguard this agreement.

A technique through construction of models which enables a subject to be represented in a form that enables reasoning, insight, and clarity concerning the essence of the subject matter.

Simplification of ArchiMate is often used within organizations by means of viewpoints. The checklist is used to check whether the modelers have adhered to organization-specific modeling conventions within an architectural language such as ArchiMate.

Architecture largely consists of drawing up models of the domain in question, often using a standardized (meta) model.

The modeling community is responsible for making a number of working agreements, such as: ul> The modeling community does this by:

• Ensuring the design and conventions for the repository
• Developing architectural and modeling conventions
• Provides training regarding the repository design and the modeling method
• Review developments
• Stimulate communication and interaction within the community

Inside the modeling community should jointly introduce the above-mentioned working agreements. Depending on the structure and culture of the organization, different scenarios can be chosen to achieve this Intervision session The modeling community jointly determines what the conventions surrounding modeling are. Within intervision sessions, all participants can submit topics, examples and modeling problems that are discussed and based on discussion, a joint decision is made about the method to be followed and, if desired, the adapted modeling conventions Characteristic of the intervision session are

• On a regular basis a session organized for all modellers
• In these sessions the various participants bring in questions, solutions and suggestions
• Works well in small teams

Model manager Another scenario is that a model manager role plays a pioneering role in introducing a modeling community. The model manager is more active and the modeling community is more passive. Characteristics of the model manager are:

• Model manager determines bottlenecks and chooses a solution approach
• Sometimes a model core team is deployed for support
• Model manager coö ordinates describing the decisions in the repository or help pages
• Works well with large teams

In addition to the use of a modeling language, additional requirements and definitions are drawn up around the Architecture models and products. They are frameworks for architects who develop different types of architectures.

This is an example of modeling and naming conventions that can be used within an architecture repository. This elaboration is an example of how to develop a metamodel and its conventions. In this case for a data architecture development. The metamodel has been developed based on the DMBoK framework. This means that part of the framework has been developed and the others have not yet. Here, particularly from the point of view of the data architect, is an elaboration of modeling conventions and architectural models. Working with meta data requires a white paper on metadata modeling methods.

Checklist of modeling conventions for hybrid data models based on ArchiMate, UML Class and ER diagrams. Specific modeling conventions have been developed for the sub-models. Here only the meta-model how you relate the modeling languages to each other.

Joint modeling is based on agreements about how the joint model is developed and maintained. To this end, the work processes and agreements must be known to all modelers and the agreements must also be monitored.

Within the conceptual model, a modeling language is a description of a number of concepts within the repository where the modeling language describes a subset. The description consists of the appearance and meaning of the concepts.

Depending on the structure of the organization, (partial) models are developed by different teams with different roles in addition to the architects. For example, information analyst, data modeler, software development teams, etc.

Checklist of naming conventions for relational databases based on an item on which the modeler can validate a model elaboration based on the items in the checklist.

The most important architectural modeling languages are configured in the architecture repository so that diagrams can be drawn up within the modeling languages based on the languages and the properties relevant to that language can be set.

Partial models are accessed via HTML pages. This makes it possible to use partial models in an attractive format with easy navigation for stakeholders with little knowledge about modeling tools.

Not every stakeholder can and wants access to the models via complex modeling tools. There is often a need for simple access with an intuitive navigation structure to the (partial) models.

In addition to drawing up architectures, there are also roles that review and approve the architecture artifacts. For example, by testing for quality, feasibility, but also on the application of the modeling conventions and the organizational metamodel.

Short checklist for software modeling with UML

Which modeling languages are relevant within the field of your own organization.

For the metamodel of the architecture, a number of modeling languages are often chosen in which a metamodel and modeling conventions have already been developed.

SIPOC is a simple modeling method for modeling business processes, objects and roles. A number of examples have been given. Copy one of the diagrams and adapt it to the new SIPOCs for a company-specific elaboration.

Is an identification of a concept in which the definition, characteristics and appearance of a concept within that language are determined on the basis of the metamodel of a modeling language. Be aware that the appearance of a concept may be the same, but has a different definition and characteristics within a different modeling language.

When introducing an architecture, the implementation must be guided on several levels. This includes the introduction of a metamodel, the modeling methods and the use, configuration and selection of the tools.

Defining metamodels is important when using an architecture repository. On the one hand, this is done by making a selection of standard modeling languages, on the other hand, this can also mean defining your own modeling language.

This is both model expansion and limitation. Expansion is, for example, adding your own modeling languages and concepts, but also by adding your own element details In addition, it is desirable that restrictions can be set within a standard modeling language. Consider the viewpoints within ArchiMate

In addition to review, the models must be validated. This involves checking whether the modeling conventions and metamodels have been applied correctly.

Drawing up architectural models is on the one hand a creative activity, on the other hand it is a relatively error-prone process. This means that the tooling must optimally support the modeler when drawing up models.

When drawing up architectural models, a number of generic functionalities are desirable, such as drawing, visualization and diagram functions, but also publishing content.

A number of work processes can be defined for drawing up and managing architectures, for example for modeling, reviewing or approving. The repository must adequately support the various processes.

Modeling behaviour of classes for example methods or operations

Ensure adequate training of those involved so that they have knowledge of the chosen modeling methods, the possibilities of the architecture repository and the functionalities in the chosen tool.

Modeling language for modeling software and logical data models.

Reviewing architecture is mainly about the content of the architecture and in this process it is mainly about handling the metamodel and applying the modeling conventions.

Exchange of (partial) models based on the UML exchange standard so that exchange with other (UML) modeling tools is possible.

Webvideo about baseline and target modeling

There is a choice in the application process to hire an employee or not. Model this out in a diagram with a junction. In the event of a rejection, a sub-process is defined, with the HR employee making a motivation and discussing this motivation with the participants in the conversation.

This overview contains an extensive list of possible (partial) modeling languages. Use multiple languages sparingly. Some of ArchiMate is probably necessary. See also the examples in the documentation of modeling languages via the websites that exist around these modeling languages. The Model Wizard within EA is also suitable for further explanation. This is not an exhaustive list and may be developed differently in the context of specific organizations. This diagram provides a detailed description of the most important sub-models and diagram types to provide an idea of the scope and level of detail within the modeling languages.

Model from the baseline architecture (document driven) to the target (repository based) with a list of the required deliverables. This is based on a number of ArchiMate concepts in the implementation and migration modeling layer.

This diagram is a viewpoint for developing a logical data model. This viewpoint indicates which types of object types and connector types can be used when drawing up a logical data model. A few principles apply to the logical data model:

• Logical data model is for all stakeholders (ICT professionals and non-ICT professionals) and must be understood by all stakeholders after an explanation of the metamodel.
• Logical data model is developed in UML Class Modeling.
• For the logical data model, only the Class and Enumeration stereotypes are used.
• The logical model has a hierarchical structure based on abstract and concrete entities with a specialization connector.
• For a logical domain, multiple diagrams can be created if this reduces complexity.
• The logical model is related to the parent conceptual model and to the underlying physical data models. See the hybrid meta data model for this.

When working in an architecture repository, validating models is a step in the work process. A duplicate is easily introduced, especially in an architecture repository of some size. Preventing duplicates and deduplicating afterwards in the presence of duplicates is therefore a functionality that is desirable in a modeling tool to support model validation.

In the detail of the business process for architectural modeling, a number of connections are made clear. Which business objects are relevant to this process (in both reading and writing), which roles are involved in this detailed process.

When developing and managing the architecture in the models and documents, keeping the repository consistent is a challenge within a repository. With a document-driven approach, keeping things consistent is actually impossible. When working with an architecture repository and using tooling, opportunities arise to automate or largely support, especially iterative, tasks. There are important advantages to be gained for architectural teams. It is therefore recommended that careful consideration be given to which activities can be automated and what requirements there are for the modeling team.

The composite service model shows how a service at a higher level of abstraction is composed of smaller services with a more specific character. This office automation model includes an intermediate layer of services, but that is not necessary, you could also make a direct link to Microsoft Office, depending on the context. In this elaboration, only application services are modeled and included in the composition. However, in addition to application services, you can also define business services here. Consider the combination of the implementation of Office and a service desk for questions in case of problems. That is currently out of scope, but will become relevant at some point. Relevant here is that this creates a bottleneck in the ArchiMate modeling. If desired, this bottleneck can be resolved with serving relationships. Embedding ICT business services in the lower architectural layers.

The meta modeler plays a role in drawing up a metamodel for architecture, selecting modeling languages and drawing up organization-specific modeling conventions. This role is very important in carrying out a number of activities in the architectural work process. In addition, the meta modeler realizes a number of capabilities that are necessary for modeling in an architecture repository.

When introducing an architectural process based on an architecture repository, working with a modeling community becomes necessary. This community must ensure that a number of preconditions are introduced to ensure that the working method with an architecture repository realizes the goals and needs of the architecture team. When working with a repository, the metamodel and a collective view around the modeling techniques applied within the team are particularly necessary. In this view you can see that the modeling community is considered a collaboration of a number of architectural roles within the organization.

Working in a repository involves establishing modeling conventions. Not only a selection of the modeling languages and within them a subset of the concepts to be used is being developed. However, the modeling convention is of equal importance. After all, there is joint work on architectural models and the modeling conventions should contribute significantly to the consistency of the models and the prevention of contamination of the repository content. In this elaboration a first global elaboration of naming conventions is given. When implementing a repository, this must be worked out in more detail within the organization per language and for the hybrid modeling languages in use. In addition, a more detailed example has been worked out below the tools as an example.

The building block model consists of the generic entities building block and catalog. These form the basis of a reference architecture. Catalogs are groupings of building blocks within a specific domain. Multiple catalogs will be created that are related to each other and overlap within the visualizations. The advantage of the design of working with catalogs and building blocks is:

• Registers are created of reusable architectural components aimed at a specific field of work.
• The use of building blocks brings standardization and encourages reuse of architectural configurations.
• Building blocks makes the architecture and development process easier.
• Architectural product catalogs aimed at specific professional fields are being developed. This has a positive influence on the service provided to the rest of the organization.

The building blocks have three specializations, the definitions of which have been worked out in detail. These descriptions are elaborated in the paragraphs below. If relevant, additional information has been added to this elaboration, such as links to Togaf and examples of the implementation of these architectural concepts The model uses a pragmatic model with regard to the associations between Service and SBB. From ArchiMate perspective, the route from service is via ABB to SBB. This is characterized by the fact that the functional aspect is well embedded in the building block model. When publishing these models, a possibility is sought to generate reports and web pages that do not contain data relevant to the model for non-architecture stakeholders, which may mean that in a number of situations the ABBs do not have to be developed. Applying the direct association between service and SBB in the modeling does not meet the viewpoints.

Primary concepts In the application layer, the three specializations of the building blocks can be relatively easily related to an ArchiMate element, namely:

• Service <-> Application_Service
• ABB <-> Application_Function, as already mentioned, another behavioral element can also be used here
• SBB <-> Application_Component

ArchiMate relationships can be defined between the elements:

• Service <-> ABB: Realization
• SBB <-> ABB: Assignment
• xBB <-> xBB: Aggregation

The last association, aggregation, is particularly important because it allows composite building blocks to be put together. In addition to the associations mentioned, several types of associations can be selected, such as dynamic associations. When developing the views within this viewpoint, you are free to apply these additional associations, provided they are elaborated in the general viewpoints already present. Secondary concepts In addition to the primary elements and associations, two elements and associations are relevant, but not in all architectural domains. These are:

• Data_Object, for example within the integration architecture, data objects are necessary for describing, for example, reusable message definitions within a building block.
• Application_Interface, also within the integration architecture, for the implementation of, for example, a web service, this concept is necessary as an additional ArchiMate element within the xBB modeling.

Primary concepts In the technical layer, the three specializations of the building blocks can be relatively easily related to an ArchiMate element, namely:

• Service <-> Technology_Service
• ABB <-> Technology_Function, as already mentioned, another behavioral element can also be used here
• SBB <-> System_Software, Node, Network, Device, Path and other technical active structure elements.

ArchiMate relationships can be defined between the elements:

• Service <-> ABB: Realization
• SBB <-> ABB: Assignment
• xBB <-> xBB: Aggregation

The last association, aggregation, is particularly important because it allows composite building blocks to be put together. In addition to the associations mentioned, several types of associations can be selected, such as dynamic associations. When developing the views within this viewpoint, you are free to apply these additional associations, provided they are elaborated in the general viewpoints already present. Secondary concepts In addition to the primary elements and associations, elements and associations are relevant, but not in all architectural domains. These are:

• Technology_Interface, also within the integration architecture, for the implementation of, for example, a web service, this concept is necessary as an additional ArchiMate element within the xBB modeling.

An introduction of an artefact is only relevant in certain sub-areas (geo). In other cases, a language with more detail will be used, such as UML class diagrams or XSD models. In the latter case, an association is made between the modeling language concepts via a trace.

In this work process, the status of elements is adjusted based on their position in the tree structure of the project browser. This allows users to easily see when modeling to what extent an element is generic or (still) specific to a project or modeler.

In the previous chapters we discussed the different dimensions of introducing an Architecture Repository. In this chapter we discuss a number of tools that support and simplify the introduction of an architecture repository. We are working on this based on Sparx Enterprise Architect, a modeling tool for various modeling languages. This makes it extremely suitable for setting up Sparx Enterprise Architect as an architecture repository. The elaborations of these tools have all been developed based on Sparx Enterprise Architect.

This section proposes a number of ArchiMate viewpoints for modeling the various building blocks and their mutual relationships. In the diagrams, the viewpoints are only elaborated on the basis of the elements and the relevant mutual associations. A description of the concepts themselves is not provided. We adopt definitions and possible associations as defined within the ArchiMate modeling language itself. ArchiMate has three layers in the core model, namely Business, Application and Technology layer. xBB can be applied in the three layers mentioned above. However, because the perspective in this document for the xBB is mainly on application and infrastructure, the viewpoints have only been developed for these two layers. For the ABB, ArchiMate uses the Behavior column. Since ArchiMate 3, there have been multiple elements within this column. When elaborating in the viewpoints, only the Application_Function and Technology_Function are used. If another concept, for example an Application_Process or Technology_Process, is relevant in an elaboration, this can of course also be applied. For the SBB, ArchiMate uses the Active Structure column. Many different concepts are available, especially within the technology layer. Only the System_Software is used for the implementation in the viewpoints. If another concept is relevant for an elaboration in this dimension, it can of course also be applied.

These examples elaborate on a number of aspects of modeling based on building blocks. Consider this example without thinking about the design of the catalogs and the granularity of the building blocks. In addition, only an explanation is given for the diagrams, not for the concepts elaborated in them.

Metamodel consists of a list of various modeling languages relevant to architecture, including a number of submodels and languages. On this basis, the organization can make a selection of the architectural languages and sublanguages relevant to them. In the development of the tools, such a metamodel based on simplified viewpoints in ArchiMate is developed as an example.

This is an example of modeling and naming conventions that can be used within an architecture repository. This elaboration is an example of how to develop a metamodel and its conventions. In this case for a data architecture development. The metamodel has been developed based on the DMBoK framework. This means that part of the framework has been developed and the others have not yet. Here, particularly from the point of view of the data architect, is an elaboration of modeling conventions and architectural models. Working with meta data requires a white paper on metadata modeling methods.

SIPOC is a simple modeling method for modeling business processes, objects and roles. A number of examples have been given. Copy one of the diagrams and adapt it to the new SIPOCs for a company-specific elaboration.