- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-09-2023 03:55 AM
What exactly is Data Certification vs CI Attestation? What are the use cases for- each of them? In which scenario which feature should be used?
Solved! Go to Solution.
- 17,442 Views
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-13-2024 10:52 AM
Data Attestation focuses on data currency. You use Attestation to verify that a CI record represents a resources that still exists in your organization. If a CI record fails attestation (e.g. the resource it represents no longer exists) then it becomes a candidate for being retired and removed from the CMDB.
Data Certification focuses on data quality. Fields in records (in CMDB or non-CMDB tables) are reviewed for accuracy and can be updated, or marked as failed and subsequently updated with accurate values.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Wednesday
I would like to place Data Certification for Application Services, to make sure Service Owners are reviewing their Service Mapping for completeness and correctness. Can I certify Relationships as well in this case?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi Marta,
Data Manager supports certifying relationships stored in the cmdb_rel_ci table. That table contains data limited to a parent CI, the relationship type and the child CI. When using this table in a Certification policy, you need to configure a filter condition that will select CIs whose relationships you want to review. That's simple enough if you know a specific CI class you can dot-walk to from a parent CI class, or have a specific CI.
In the case of a Service Instance CI and it's associated CIs, it's not that simple. Using the cmdb_rel_ci table, if you target the Service Instance CI for the parent CI you'll only get the immediate child CIs (e.g. a Business Application and maybe an endpoint CI). You'll miss the CIs mapped to the Service Instance CI. That mapping information is stored in the Service Configuration Item Association (svc_ci_assoc) table, however that table doesn't include connection data or references to the cmdb_rel_ci table making it unsuitable for certifying relationships for a Service Instance.
It can however be used in conjunction with the cmdb_rel_ci table, through a Related List condition. Used this way, it's possible to get a collection of CIs from the cmdb_rel_ci table and filter the CIs so that only those associated with a specific Service Instance CI are returned.
There are caveats to this though:
- This approach is only practical for a single Service Instance CI:
- You'd need a Certification policy for each Service Instance you want to certify relationships in.
- When Service Instances are mapped in addition to associations, relationships are created for specific types - the data filter needs to take these into account. The types are limited and can include (but not be limited to):
- Applicative Flow To::Applicative Flow From
- Depends on::Used by
- Implement End Point To::Implement End Point From
- Runs on::Runs
- Use End Point To::Use End Point From
- The cmdb_rel_ci table can contain millions of records, so evaluating the query to return records could result in a long execution time.
- You should consider if you want to filter out EndPoint CIs that are used primarily for map connections between CIs (as opposed to relationships). CIs from EndPoint classes typically don't have ownership information which would lead to unassigned certification tasks, or just end up as noise i.e. additional unnecessary work. Consider filtering these CI classes out, or not including the Use End Point To::Use End Point From relationship type in the data filter. Your call.
- Certification task assignment will require some consideration - who's responsible for reviewing the relationships?
- The Service Instance owner is an obvious choice, however you won't be able to dot-walk to a user field (e.g. owned_by) for the Service Instance based on the Parent CI field in the cmdb_rel_ci table. In this scenario you would need to assign the task to a specific user.
- Alternatively, the review could be performed by owners of the individual CIs associated with the Service Instance in which case you can dot-walk to user or group fields in the parent CI. The downside is the owners may not understand the context of their CI with respect to the Service Instance. Also, if there's no ownership info then unassigned certification tasks will result.
Assuming you're ok with the above, today you're up for one Certification policy per Service Instance. That's manageable for a small number of Service Instances - if you have many (e.g. > 20) then consider only certifying relationships for the Service Instances with the greatest business criticality.
Here's what the resulting Certification policy filter condition might look like:
And here's the Related list condition, for a Service Instance CI called "CRM":
Here's what a Certification task might look like:
With some trial and error you should be able to get a representative set of CIs and their relationships.
As mentioned, this solution can work for small CMDBs (e.g. < 10M CIs) and for a small number of Service Instances (e.g. 20-30). I recommend always testing on a sub-production instance with representative data sets first.
We plan to enhance Data Manager for Attesting and Certifying Service Instances. Based on what's described above you can probably tell this is complicated and will involve significant effort to deliver a robust, scalable and performant capability.
Hope this helps.
