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.
| term | example | system of record |
|---|---|---|
| Customer | SoftWare Inc. purchased 3 hardware racks in 2014. | CRM |
| Account | the ledger contains all the income and expense accounts | ERP |
| Budget | the budget for stationary is set for 2014. | DB2-Tokyo |
| Amount | they have spent a colossal amount rebuilding the foyer | DB2-Tokyo |
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:
| business term name | business term asset type | business term descriptive example | system of record | system of record asset type | system of record domain | system of record domain type |
|---|---|---|---|---|---|---|
| Customer | Business Term | SoftWare Inc. purchased 3 hardware racks in 2014. | CRM | System | Systems and Databases | Technology Asset Domain |
| Account | Business Term | the ledger contains all the income and expense accounts | ERP | System | Systems and Databases | Technology Asset Domain |
| Budget | Business Term | the budget for stationary is set for 2014. | DB2-Tokyo | Database | Systems and Databases | Technology Asset Domain |
| Amount | Business Term | they have spent a colossal amount rebuilding the foyer | DB2-Tokyo | Database | Systems and Databases | Technology Asset Domain |
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.
