Data governance is top of mind for customers when they embark on their LeanIX journey. Let’s talk about all the subtopics that sit under this broad umbrella and bring it full circle!
Start with subscriptions.
It is important to hold people accountable for updating/maintaining the data on your fact sheets. The way to do this is by leveraging our subscriptions. Out of the box, we offer Responsible and Observer subscriptions. The Responsible subscriber can be thought of as the “SME” of the fact sheet - you trust this person to update the data and ensure it is correct over time. An Observer is more of a contributor - this person can make changes, but isn’t necessarily the ultimate data decision maker.
Now, let’s talk data quality (the Quality Seal).
There is a Quality Seal present on each fact sheet type, and there are ultimately 3 reasons why the seal can break. Let’s “break” it down (pun intended!):
Reason 1) The first reason that the Quality Seal will break is related to subscriptions (discussed above). If a Responsible subscriber makes a change to any of the fields/relations on the fact sheet, the Quality Seal will not break (this is because we trust this person to respond correctly). However, if an Observer makes a change to the fact sheet fields/relations, this person’s changes will indeed reflect on the fact sheet, but the Quality Seal will break. The Observer does not have the ability to Approve the Quality Seal once their changes break it. The Responsible subscriber does have the ability to approve the Quality Seal. So, once an Observer makes a change, it is standard for the Responsible subscriber to review said changes and Approve the Quality Seal. You might be wondering - what happens if the Observer’s changes were incorrect? There is an audit tab in every fact sheet (the “Last Updates” tab) - the Responsible subscriber can review the old and new values here, and manually revert the changes back if necessary. There is no “undo” button. If you’re concerned about Observers making changes because of this very reason, we suggest granting them Viewer access to the workspace - this will cause all the fact sheet fields and relations to be read-only for Viewers.
Reason 2) You define an inactivity period for the fact sheet type, and this period is surpassed, so the Quality Seal breaks. There are 4 inactivity period time frames that an Admin can choose from in the meta model configuration for each individual fact sheet type (Administration > Meta Model Configuration > Quality Seal tab > Quality States renewal interval) - 30 days, 3 months, 6 months, or 1 year. We can’t customize further than this - you are welcome to select one of these options. Let’s say for your Applications, you opt for the 30-day renewal interval. If there are no changes made to the Application fact sheet at all in that 30 day period, on day 31, the Quality Seal will break. This is to ensure that your data is kept up-to-date over time. Some common examples we see include having the Applications and Business Capabilities set with a shorter renewal interval (these fact sheet types typically experience more frequent changes) and the Provider fact sheet type having a longer period set (these rarely change).
Reason 3) Mandatory fields/subscriptions/relations/tags. Admins can configure these (Administration > Meta Model Configuration > Quality Seal tab > Mandatory subsections) if the org decides that the Quality Seal will not be ready for approval unless certain aspects are satisfied. Perhaps your org considers TIME Classification to be a field of utmost importance, and thus, all Application fact sheets need to have this field filled out in order to have the Quality Seal be approved. You can make TIME Classification a mandatory field in this sense. Once it is a mandatory field, the “Approve” option on the Quality Seal will be greyed-out on an individual fact sheet until the TIME Classification field is satisfied with a value. If the TIME Classification field isn’t filled out per this example, the Quality Seal will remain broken.
The Notifications Center: Sending emails from the workspace based on set criteria.
Admins have the ability to configure default email notifications for other workspace users at the org. Visit Administration > Notifications Center (different from Notifications) and sift through the criteria to decide whether you want others to have default notification frequencies set, or maybe you don’t want individuals to have the ability to select “Never” for a given criteria per their personal settings. For example, the criteria, “A fact sheet is updated where I am Responsible” is a common criteria to have a default of “Instant” set. We want Responsible subscribers to know ASAP when the data on their fact sheet has been updated. In this case, it is very possible that we don’t want individuals to select “Never” from a list of drop-down options, so we can un-check Never in our Admin settings for this criteria.
Set trigger notifications with Automations.
Our Automations offer a powerful option to send emails based on certain workspace triggers (Administration > Automations). Let’s walk through two Automations examples. First, let’s say we want Responsible subscribers to receive an email asking them to “review the fact sheet data and validate the Quality Seal” as soon as updates to the fact sheet are made by a non-responsible subscriber. We can set up an Automation that states When an Application fact sheet has a quality state that changes to Broken, Then create an action item (give it a name like “Please review fact sheet and validate Quality Seal”), assign it to Responsible subscribers, and make it due in a week. The outcome of this trigger being met will cause a To-Do to be generated. You can view To-Dos on each individual fact sheet (the To-Dos tab), and you can also review the To-Dos assigned to you and created by you in our Collaboration tab at the top of your workspace. If the trigger for this scenario is met (the Quality Seal breaks), and in the Notifications Center, you make it an “Instant” default for users to receive an email when they are newly assigned to a To-Do, your Responsible subscribers will receive an email under these circumstances. Another Automations example would be a bit more simple perhaps, where you can define something like When an Application fact sheet has a quality state that changes to broken, Then set the quality state to approved. If the trigger is met here, the action will simply be carried out (the Quality Seal will become approved after it had been broken), rather than have a To-Do be generated.
Poll your org with Surveys.
There are 2 use cases for sending Surveys from the workspace. The first is to collect data if you are missing it. For example, maybe your org hasn’t kept track of the TIME Classification for your Applications, but you’d like to move forward with gathering this data. Sending a survey would be the perfect path forward. With the “fact sheet element” and “fact sheet segment” Survey criteria, you can opt to include fields, sections, subsections, etc. from your meta model on the survey. Sticking with the TIME Classification example, you can click and drag the “fact sheet element” criteria onto the Survey while designing it, and select TIME Classification from the field drop-down. When you send your Survey out, recipients will receive a Survey link to their email inbox, and will have the ability to select a respective TIME Classification value (Tolerate, Invest, Migrate, Eliminate) directly on the Survey in their email inbox. The responses a person makes to the Survey (given this is set with the “fact sheet element” criteria) will automatically flow through to the fact sheet. This indeed means that an individual doesn’t necessarily need to log into their LeanIX environment, find a specific Application fact sheet, and manually scroll to the TIME Classification field to make a value selection - the power of Surveys will allow them to do this right from their email inbox. The second use for Surveys is data maintenance - ensuring that fields and relations are kept up-to-date over time.
SaaS Discovery: Finding what you need to rationalize.
How can you rationalize your Applications if you aren’t aware that they exist within your org? Our SaaS Discovery functionality allows for you to connect to a number of different tools via our out of the box Discover Integrations - for example, a SSO source (Okta, Azure). Post establishing this connection, we will retrieve a list of services that your org is actively using per logins via your SSO source. You can then rationalize accordingly if there are duplicate use cases, etc. If you opt to link the services we find within your org to our SaaS catalog, we will also take some work off your hands and maintain certain fields like Name, Description, SSO - Available Providers, etc. over time for you!
Data governance is nothing to joke about - all orgs take this very seriously and leveraging any of the above subtopics will lead you down the path of success. We’ll help you to gain back that power over your data! Chat with your Customer Success Onboarding Manager or your CSM further, or visit our docs to review any of the above in greater depth.