Business Information Model

Extracted from the public Notion original. Notion record created 2019-12-11. Last edited 2019-12-12.

The Business Information Model is a view that all stakeholders can use to understand the data required to operate the business, and generated in the operation of the business. It puts the data into broad categories (data domains or subject areas) that when combined should account for 100% of data.

Although the requirement for 100% coverage of all data can be relaxed this should only be done as part of an agreed data governance approach, and the decision should be included in the Core Shared Data Strategy.

Is this a "Conceptual" data model?

In the discipline of information management as it has evolved in IT departments there is a three-tiered data modelling approach that includes these layers:

• Conceptual

• Logical

• Physical

These layers are a great way of managing complexity. They continue to have value. However, there are problems with having your modelling approach locked into this approach, and having the modelling standards fully controlled by IT, if you want a business-driven data governance approach.

So while the Business Information Model is similar to a conceptual data model (and an existing conceptual data model can be used as a starting point) there are key differences from the approaches used by many IT departments.

Business Information Model is like a Conceptual Data Model except:

• There should only be one business information model for your entire organisation. It might clearly show that you have a number of different and unrelated businesses and that the data doesn't interact across those business - but there is only one Business Information Model.

• You shouldn't have to teach "the business" what the words mean. If they business already calls something by a particular name use that name (at least initially)

• If two groups business units use the same name for two different things show this as is in the Business Information Model. Also show the ambiguity so it's clear (eg. "Contracts (from a procurement perspective)" and "Contracts (from a policy management perspective)" would both appear in the model)

• Don't "simplify" or normalise language unless all the stakeholders you already use the shorthand and it's part conversations (outside the modelling process). Classic example is "Party" a business information model should not contain "Party" to mean "any employee, customer, organisation, business unit, etc." as this is a distraction from the business language in the model