Asset Types

 

[bok-callout]Asset & Asset Type
An Asset is the capital building block for which you want to capture information (in terms of attributes and relations). An asset belongs to exactly one Domain and has a unique name within its Domain. An Asset is the instance of exactly one Asset Type.

An Asset Type formally defines the semantics of an asset in terms of attribute types and relation types that can be instantiated for it. In other words, it serves as a template. Asset types are assigned to one or more domain types.

For example,

  • ‘Personal Privacy Policy’ is the name of an asset of type ‘Policy’. 
  • ‘Customer’ is the name of an asset of type ‘Business Term’.
  • ‘CRM’ is the name of an asset of type ‘System’.

[/bok-callout]

We package a considerable number of Asset Types to start your data governance structuring with. We assign all asset types to one out of five core asset types, as illustrated below.

We refer to the respective pages for their descriptions:

By assigning all assets to a particular type and relating them to one another, we achieve traceability. An example of traceability is shown in the diagram below.

Communities

We have three communities here (depicted by white rectangles): Working Group on Rules and Policies, Finance, and Enterprise Architecture. As explained in the section on Structural Concepts, these communities represent different groups of people who own certain domains. The domains are depicted by the large rectangular colored frames in each community. For example, the community Working Group on Policies and Rules owns the domain Enterprise Rules and Policies. The Enterprise Architecture community owns two domains: Application Assets and CRM Application Reference Data.

Domains

Domains represent logical groupings of assets. Their Domain Type determines what asset types they can hold: e.g., the Enterprise Rules and Policies domain is of the type Governance Asset Domain and therefore can only contain assets of the type Policy or Rule, both being Governance Assets.

 Relations and Traceability

There are several relations instantiated between the assets across domains. For example, Policy “Personal Privacy Policy” governs / complies to Business Term “Customer”. This relation can be read in two directions:

  1. Policy “Personal Privacy Policy” governs Business Term “Customer”;
  2. Business Term “Customer  Policy” complies to “Personal Privacy Policy”.

Another example is Business Term “Gender”. This term has a definition owned by the Customer Glossary Domain clearly supervised by members with a Business Steward profile. In order to further constrain the interpretation of the Business Term “Gender”, one may call in members from the Enterprise Architecture community, to specify what the allowed values are. In the example it concerns only three Code Values “CG_NA”, “CG_FE” and “CG_MA”. This is manifested by means of the following relations:

  1. Code Value “CG_NA” is allowed value for / has allowed value Business Term “Gender”;
  2. Code Value “CG_FE” is allowed value for / has allowed value Business Term “Gender”;
  3. Code Value “CG_MA” is allowed value for / has allowed value Business Term “Gender”.

As a final example, the Business Term “Customer” is also related to a Technology Asset, more precisely a System “CRM” by the following relation:

  • Business Term “Customer” has system of record / is system of record for System “CRM”.

This relation will probably be defined by members with a IT Steward profile who know about the physical location (here: System “CRM”) of certain assets, answering the traceability question:

  • Give an overview of all physical Systems and Databases that record anything about customers in the context of Finance.

More structured this question could be defined as a traceability path in terms of asset types, relation types, and domains/communities:

  • Give all System and Database assets that have a relation “is system of record for” with the Business Term “Customer” in the Domain “Finance”

Each Business Case will have its own traceability requirements that can be represented by paths or graphs expressing queries in which assets are nodes and relations are the edges. They are the foundation for customizing the Data Governance Operating Model. This will result in concrete workflows to build out these paths, as well as extracts of the API to issue the necessary queries.

As a last example, considering the overall diagram with all the relations shown, we could now perfectly answer the question:

which would be useful in case an Issue “Gender Disclosure Issue” was reported related to the Policy.

 

You have to login to comment.