[bok-callout]Objective & Outcome
In OMDP Step 2, we validate the first version of the Operating Model resulting from OMDP Step 1 with additional examples. This step is an iterative step to cover use cases that may have been overseen during step 1. The outcome is a new version of the Operating Model with adaptations and extensions where necessary.[/bok-callout]

This OMDP Step is described through a number of example scenarios.

Scenario 1 – Discover Additional Attributes and Relations

Reconsider Example 1 from OMDP Step 1. Consider the following additional spreadsheet that contains additional business terms, but also contains some of the business terms (such as Customer and Account) that were in the first sample. Moreover, the columns two and three reveal new metadata.

Reading out row 1, we identify the following concepts and determine their types (note we combine multiple steps here, see OMDP Step 1 for a detailed step-by-step explanation):

• The asset with name ‘Customer’ is of type Business Term, has Descriptive Example attribute value “SoftWare Inc. purchased 3 hardware racks in 2014” and has relation named “has system of record” with an asset with name ‘CRM’ of type ‘System’ which is owned by a domain named ‘Systems and Databases’ of type ‘Technology Asset Domain’.

Just like for the system of record, we do not have information on the domain to which the business terms belong. Hence we have made some assumptions by introducing a new domain for the systems and databases, and further we assume the terms are part of the sales glossary.

This results in the following requirements for the operating model:

• Column 1: asset type ‘Business Term’;
• Column 2: attribute type ‘Descriptive Example’;
• Column 3: asset type ‘System’;
• Moreover, a relation type ‘Business Term has system of record / system of record for System’.

We extend and relabel the table as follows: 

This results in the following extension of the operating model.

Note that the new business terms (Budget and Amount) in this example do not completely fit into the operating model because there is no definition in the spreadsheet. A further analysis has to determine if these definition attributes can be found elsewhere, or if these do not exist yet. In case of the latter, the terms should be subject of a workflow in order to complete them.

Scenario 2 – Discover Conflicting Examples

Consider the example where a new metadata use case provides examples that conflict with the operating model that was devised in OMDP Step 1. For example, it might happen that a new example contradicts with an asset type, relation type attribute type or domain type that was determined before. There are two possible explanations:

• the metadata case seemingly provides examples that are similar to those analyzed in Step 1 but would lead to another conclusion hence extension of the operating model.
• the metadata case effectively does consist of example invalidating the earlier identified operating model. In this case, adaptations have to be done accordingly.