Governance Entity Lifecycle

Each Governance Entity has a lifecycle that is enforced by the Computational Governance Platform. Each step of a Governance Entity's lifecycle determines how a resource is impacted by a failing policy or by a metric result within Witboost. Managing the lifecycle through the Computational Governance Platform allows for controlled testing and versioning of the Governance Entities being published and enforced into the platform. All the governance entities that you publish may impact resources along the platform, many of them already in production. The effectiveness of an automated policy system depends on its flexibility, because otherwise, users will begin to complain that the platform is not sufficiently flexible and attentive to the delivery needs of users.

Every Governance Entity has a status that evolves and allows for governance entities to be tested and gracefully introduced into the platform, also allowing versioning and a smooth transition between entity versions both for the platform team and for the different resource developers and maintainers that need to keep compliance with the governance entities.

Versioning of a Governance Entity

The Governance Platform is built in a way that enforcing governance entities is as friendly to the data developers and maintainers as possible. Slow introduction and versioning of the governance entities aim to tackle this, and the statuses for the governance entities are designed having this in mind. When you create a new governance entity, is important not to go to the Enabled status right away, as this could break deployments that are not compliant and may raise complaints from data teams. Instead, providing some time by having the governance entity in Grace status allows the teams to adapt their deployments to the new restrictions you are imposing on the platform.

The same happens when evolving the governance entity through new versions of it. The platform allows for two governance entities with different versions to be active at the same time, and this allows you to have a transition period, where the new governance entity is placed on Grace status while Deprecating the old one, allowing a time window for data teams to evolve their own resources and maintain compliance.

An example of the optimal governance entity lifecycle can be shown in the diagram below.

Versioning lifecycle of a governance entity, where versions coexist with the newest one being in Grace status, while the old one is transitioned to a Deprecated status

• Build: The platform team implements and documents the governance entity.
• Test: When a new governance entity is introduced, it is important to understand its impacts on existing users or use cases on the platform. For this reason, it is important to be able to simulate to understand how many users would be out of policy if it were introduced. Here you can use the test workbench allowing to test new governance entities on all the deployed artifacts.
• Grace Period: Without a grace period, many users may find themselves unable to deploy or perform their normal operations out of the blue, generating frustration. The grace period must be well-declared and have a reasonable duration. The warning level of governance entities could very useful for this purpose allowing to raise awareness among users.
• Enable Period: After the Grace period, the governance entity can be effectively activated and start generating the expected outputs. From this moment on, those who are not compliant will no longer be able to deploy within the platform and their functionality will be greatly reduced, forcing the user to act and comply with the new contracts provided by the platform.
• Deprecation Period: When wanting to eliminate a governance entity, especially if you are thinking of a new version, it is important to have a deprecation path that allows us to define when the old governance entity will be disabled and making it clear to users about the transition, so they can adjust themselves.

Managing Lifecycle

A Governance Entity can assume different statuses, each one limiting the actions that you can perform on the Governance Entity, or the applicability of it against the resource perimeter. It can also influence the governance entity's ability to block a deployment or sending notifications.

Each Governance Entity has a precise status, that describes its evolution. The sequence of statuses, here called lifecycle, is strictly sequential, and can evolve only according to following diagrams. Each status defines how a Policy or a Metric can impact the deployment of a new Resource or Resources that are already consumable in the Marketplace.

To change a Governance Entity status go in the Registry tab and by clicking on the contextual menu, select the status. Only the allowed status based on the current status will be shown.

Evolving Policies

When you create a Policy, its status will be Draft. From there you can evolve it according to the below sequence of statuses.

note

All the times you create a new Policy, a notification will be sent to affected resource's owners, informing them that a new Policy has been registered into the Platform.

Policies lifecycle, as a semi-linear process that starts when a new policy is created.

• Draft: This is the initial status for every new policy. It is the only status where you can still make changes. All of its fields are editable at this stage. Once you evolve it, you won't be able to edit it anymore except by starting a new version. When in Draft, the policy is invisible to the platform, hence it won't be considered when a resource needs to be evaluated; however, you can still test it directly in the platform against its resources' perimeter to assess that it is working as expected.

• Grace: The Grace status allows a period in which data teams can familiarize themselves with the new policy, understand it, and assess how much it is impacting them. In Grace status a policy is not editable anymore, but it is being executed, being visible to the platform and thus appearing in evaluation reports of a resource. However, a policy in grace state won't block the deployment of any resource even if it fails, but will just provide users with warnings or info messages, allowing a graceful transition to a new governance entity or between governance entity versions. Also, policies in grace status can generate info or warning flags to resources already published in the marketplace. Grace policies can be deleted or deprecated without the need of publishing them. Additionally, they can be disabled if needed.

• Enabled: When enabled, if the resource is not compliant to the Policy, then its deployment will be blocked, if timing is Deployment, or produce error flags in the Marketplace, if timing is Runtime. The resource will be evaluated when it falls into the Policy's resources perimeter, depending on the Policy's settings. At this stage, if you want to make changes you will need to create a new version of the policy, taking advantage of the Grace status to allow data teams for a smooth transition for the data teams.

• Disabled: You can disable policies whether they are Grace or Enabled. When Disabled, a policy is invisible to the platform and won't be considered for any resource's evaluation request.

• Deprecated: A policy that is marked as Deprecated denote that it is going to be replaced by a new version or that is being phased out of the platform. A deprecated policy acts as a grace policy, meaning that it cannot block the deployment of a resource but will only produce warning messages. For runtime policies, setting them as deprecated means that they won't produce error flags but only warning flags.

Once you decide that a Policy can be removed from the platform, you can click Delete on the contextual menu.

Evolving Metrics

When you create a Metric, its status will be Draft. From there you can evolve it according to the below sequence of statuses.

note

All the times you create a new Metric, a notification will be sent to affected resource's owners, informing them that a new Metric has been registered into the Platform.

Metrics lifecycle, as a semi-linear process that starts when a new policy is created.

• Draft: This is the initial status for every new metric. It is the only status where you can still make changes. All of its fields are editable at this stage. Once you evolve it, you won't be able to edit it anymore except by starting a new version. When in Draft, the metric is invisible to the platform, hence it won't be considered when a resource needs to be evaluated; however, you can still test it directly in the platform against its resources' perimeter to assess that it is working as expected.

• Grace / Enabled / Deprecated: When a Metric is either Grace, Enabled or Deprecated, it will generate metric values for all the resources that fall into its Resources Perimeter. Metric results will be visible either in the Resource's Control Panel if Timing is set to Deployment, or they will be visible in the Marketplace, as flags attached to the impacted Resource, if timing is set to Runtime. The Grace status starts a period in which data teams can familiarize themselves with the new metric, understand it, and assess how much it is impacting them. When enabled, will continue to generate metric values for the impacted resources. At this stage, if you want to make changes you will need to create a new version. When a Metric is marked as Deprecated, it denotes that it is going to be replaced by a new version or that is being phased out of the platform

• Disabled: You can disable metrics whether they are Grace or Enabled. When Disabled, a metric is invisible to the platform and won't be considered for any resource's evaluation request.

Once you decide that a Metric can be removed from the platform, you can click Delete on the contextual menu.