The Governance Topology V.1

[Jakob Anker]

The Governance Topology

A Fundamental Framework for Mapping out Governance

Table of Contents

1 - Introduction 2 - Disclaimer 3 - Why Introduce The Governance Topology 4 - What is The Governance Topology 4.1 - The Governance Onion 5 - The Reference Framework for Govenance Topology 5.1 - Strategic Domain 5.2 - Portfolio Domain 5.3 - Technical Domain 6 - Illustrative Application of The Governance Topology 6.1 - Strategic Domain 6.2 - Portfolio Domain 6.3 - Technical Domain 7 - More on the Authority Component 7.1 - The Authority Reference Framework 7.2 - Authority Thresholds 7.3 - Authority Escalation Chains

1 - Introduction

Welcome, my friend.

Welcome to a practical take on governance and its application. This paper intends to demystify and provide an actionable framework for the continuous maturation of the decision framework that is set in place to monitor, guide, and control a platform's changes.

This document will introduce you to the latest evolution of governance work, as I envisioned.

I hope that it will inspire others and that experiences using it and lessons learned will bring the framework back to its source, from which I intend to continuously improve it.

It is important to understand that I do not claim that the following framework is the final destination for Governance theory, and I will actually guarantee you that it is not. The following theory has been developed through years of work in the area, and it has taken many different forms throughout. The final form has yet to be seen, and I invite you to assist in exploring what works and what does not, and to suggest branches to the framework that have not yet been considered.

When you are finished with this article, I would recommend viewing the follow-up that builds on this topology: The Adaptive Governance Framework V.1 - ServiceNow Community You might think of The Governance Topology as the backbone, the structure on which we can build our processes. This next article will provide you with precisely that.

2 - Disclaimer

This document and its contents are provided as-is. They are not affiliated with, endorsed by, or officially connected to ServiceNow. The views, opinions, and information expressed in this document are those of the author(s) and do not reflect ServiceNow's official position or policies.

3 - Why Introduce The Governance Topology

Through my work, I have advised very large enterprises on the discipline of driving meaningful platform changes. Achieving this requires a disciplined and coordinated effort from ideation. At its core, governance is the practice of guiding questions to an authority that can decide on the next best action in accordance with the business context and direction.

All enterprises that own a platform such as ServiceNow will have a governance function, although not all are explicitly aware of it, and not all would consider what they do governance. Ultimately, any platform change is dependent on a series of actions related to the process of taking in ideas and demands that are prioritized into deliverables that ultimately constitute changes to the platform.

When I initially set out to educate myself with the available theoretical frameworks for governance, I was met with a realization:

• There are many sources.
• The sources tend to be more theoretical than applicable.

What more, when trying to use the frameworks, the conversation would typically sound like this:

"Do you have a technical governance board?"

"Yes, we have a technical board. We call it something else, though, and what they do is XYZ."

"Ah, that is not what a technical board is from the framework point of view; that is more akin to an implementation forum."

"..."

The conversation started to be about semantics, and what we mean when we talk about governance.

This, to me, meant that the language (or my ability to speak it) was lacking.

Therefore, I have designed the Governance Topology to fill in the gaps and make the conversation about governance less theoretical and more practical.

4 - What is The Governance Topology

The Governance Topology is built as an extension of established theory from its domain.

If you are interested in reading more about established theory, I recommend you visit The Governance Sheet, which I previously created as a compilation of resources for different use cases.

Here you will learn about the three different governance domains: Strategic, Portfolio, and Technical.

If I were to recommend one prerequisite document to enable you to get the most out of the Governance Topology I would recommend you start with the Get Started with ServiceNow governance worksheet from the Customer Success Center.

4.1 - The Governance Onion

At its core, the Governance Topology can be presented visually through the Governance Onion.

Figure 1: The Governance Onion.

The Domain

The overarching conceptual domains are strategic, portfolio, and technical governance, which build on classical governance theory.

The Function

The components that lodge inside the domains (e.g., technical board, design authority board).

Note that this framework makes a distinction between two types of Governance Functions. Namely, boards and functions.

Boards are administrative in nature and responsible for managing governance itself (e.g., defining policies that are consumed by other governance functions, monitoring their effectiveness, and refining them based on input).

Forums are operational in nature, and they will be the functions that will be consuming the policies used to make standard quality decisions. The forums are what you will find in all enterprises today, whether explicitly defined or not, and you will recognize them by their decision-making function (e.g., "let's send this solution design back before accepting it", "let's fix these findings before promoting the delivery to an upstream instance", etc.).

An example of a mature governance setup employing both a Board and a Forum

• You will have a Technical Governance Board that
  1. Is authorized to set the technical standards for other forums to follow through with the creation and distribution of technical policies.
  2. Is tasked with monitoring the effectiveness of the forum's ability to make quality decisions and the effectiveness of the policies provided to the forum to arrive at effective decisions.
  3. Is tasked with continuously optimizing the policies and enforcing their use in the forums.
• You will have a Technical QA Forum that
  1. Is authorized to assess incoming deliverables (e.g., update sets) for their compliance with the Technical Standards set by the Technical Governance Boards through its Technical Policies.
  2. Is tasked with identifying low quality and deviations and ensuring they are reverted to an earlier stage of the software delivery lifecycle for remediation before being promoted to an upstream instance.

Governance Function Theory and Reality

In practice, I have yet to find an enterprise mature enough to effectively manage the separation of duties described in Board vs. Forum functions.

In reality, you will typically find a governance function that works as a Technical QA Forum without the guidance and control of a Technical Governance Board, as described in the interplaying dynamics of creating, consuming, and refining policies.

That is not to say that such a setup is not desirable, quite the contrary.

The Governance Topology's notion of Board VS Forum can still be applied, as it provides a blueprint for your enterprise's future in a mature governance setup.

 

The Charter

The Charter is the ground rules that define what the function is, why it is, how it is, and when it is.

You can find charter template definitions by following the link in the introduction to the Governance Workbook.

The Metrics

The managed metrics show whether the individual governance component is efficient in wielding its authority (e.g., # of non-conformities, # of requests).

The Policy

The agreed standards to which the governing function must wield its authority (e.g., when to accept a custom solution design for development, etc.)

The Authority

The Governance Function is granted a set of authorities that detail the decision-making capability embedded in it, including the thresholds for when an escalation to a higher authority is needed.

The Input

The input is the ideas/demands/requests/deliverables that are subject to judgment through the authority-wielding governance functions (e.g., a solution design sent for approval).

The Output

The ultimate product of the governance system is to guide and control changes. The elements that are ingested, processed, and output by governance components through the authority vested herein.

5 - The Reference Framework for Governance Topology

In this section, you will find a reference framework that identifies layers of The Governance Onion as they apply to various domains and sub-areas (e.g., The Technical Domain and its subarea Platform Management).

Keep in mind that the reference framework is under development and not exhaustive at this stage of this document.

5.1 - Strategic Domain

Not filled out in this version.

5.2 - Portfolio Domain

Not filled out in this version.

5.3 - Technical Domain

Development Management	Function
Performance Metrics	Metric
Development Standards	Policy
Business Smart Customization	Policy
Naming standards	Authority
Documentation standards	Authority
Development standards	Authority
Customization management standards	Authority
Release Management standards	Authority
Functional designs	Input
Technical designs	Input
Change documentation	Input
Code	Input
Technical debt register entry	Output
Design qualification and approval	Output
Code qualification and approval	Output
Release plan	Output

Table 1: Development Management

Platform Management	Function
Performance Metrics	Metric
Platform Management	Policy
Platform Access Standards	Authority
Cloning Standards	Authority
Platform Security Standards	Authority
Upgrade Standards	Authority
Performance Standards	Input
Platform Performance Monitoring	Output

Table 2: Platform Management

Environment Management	Function
Performance Metrics	Metric
Environment Management	Policy
Instance Management standards	Authority
Instance Architecture standards	Authority
Application standards	Authority
Performance standards	Authority
User Experience Analytics	Input
System diagnostics	Input
Performance monitoring	Input
Admin Center	Input
Release notes	Input
Application Assessment	Output
Product Adoption Roadmap	Output
Capability Map	Output

Table 3: Environment Management

Data Management	Function
Performance Metrics	Metric
Data Management	Policy
Data Quality Standards	Authority
Data Security Standards	Authority
Configuration Management Standards	Authority
Internal data audit & assessments	Input
PII policies (e.g., GDPR)	Input
Data Ownership	Output
Data Architecture	Output
Configuration Management Plan	Output
Data retention policies	Output
Data security and risk posture	Output

Table 4: Data Management

6 - Illustrative Application of The Governance Topology

As mentioned in the introduction, the intent of this framework is to facilitate governance discussions. It shifts the conversation from "what is governance" on a higher and abstract level to the more tangible "Do you have these governance functions, metrics, policies, authorities, inputs, and outputs, etc., defined?" 

Here, you find an illustrative example of how to apply the framework.

Keep in mind that the goal isn't to have a Governance Topology that is 1:1 with any framework. The idea is that you will be able to use the reference framework to ask yourself, "Does our enterprise have clear definitions for functions and their related dimensions (e.g., policies, metrics, authorities, input, and output)?"

Using the reference framework to map out your current Governance Topology, you will naturally arrive at unclear and entirely missing areas; you will get a sense of the gaps that your setup has to reach a higher level of maturity.

Again, it is not about asking, "Do I have a technical governance board or a technical QA Forum?" No, it is about asking yourself, "Can I see the elements of the Governance Topology in my setup?"—disregarding whether you have functions that act as both Boards and Forums at the same time and disregarding whether you have a single function-wielding authority across different areas of governance (e.g., design, demand, test, etc.).

It is all about ensuring you are covered and understand what a future setup might look like.

6.1 - Strategic Domain

Executive Board	Function
Board Definition	Charter
Performance Metrics	Metric
Legal constraints	Policy
Strategic Direction	Authority
Budgeting	Authority
Governance and Decision-Making	Authority
Board of Directors	Input
Industry Trends	Input
Functional Performance Reports [Portfolio & Technical]	Input
Risks and Opportunities	Input
Budget	Output
Vision	Output
Strategy	Output
Business Objectives	Output

Table 5: The Executive Board

6.2 - Portfolio Domain

Portfolio Board	Function
Board Definition	Charter
Performance Metrics	Metric
Board Charter	Policy
Portfolio Standards	Authority
Functional Performance Reports [Portfolio & Technical]	Input
Potfolio Policies	Output

Table 6: The Demand Board

Demand Forum	Function
Board Definition	Charter
Performance Metrics	Metric
Portfolio Policies	Policy
Demand Prioritization	Authority
Demand Scoping	Authority
Resource Allocation	Authority
Budget	Input
Vision	Input
Strategy	Input
Business Objective	Input
Product Roadmap	Input
Ideas and Requirements	Input
Strategic Planning	Output

Table 7: The Demand Forum

Process Forum	Function
Board Definition	Charter
Performance Metrics	Metric
Process Standards	Policy
Process Change	Authority
Strategic Planning	Input
User Journey	Input
User Story	Input
Functional Design	Input
Process Documentation	Output

Table 8: The Process Forum

6.3 - Technical Domain

Technical Governance Board	Function
Board Definition	Charter
Performance Metrics	Metric
Board Charter	Policy
Technical Standards	Authority
Functional Performance Reports [Technical]	Input
Technical Policies	Output

Table 9: The Technical Board

Architectural Authority Forum	Function
Board Definition	Charter
Performance Metrics	Metric
Technical Policies	Policy
Architectural Standards	Policy
Architectural Change	Authority
Business Case	Input
Solution Design	Input
Architectural Alignment	Output

Table 10: The Architectural Authority Forum

Technical Authority Forum	Function
Board Definition	Charter
Performance Metrics	Metric
Technical Policies	Policy
Technical Standards	Authority
Solution Design	Input
Update Sets	Input
Technical Alignment	Output

Table 11: The Technical Authority Forum

Design Authority Forum	Function
Board Definition	Charter
Performance Metrics	Metric
Technical Policies	Policy
Design Standards	Authority
Solution Designs	Input
Solution Design Alignment	Output

Table 12: The Design Authority Forum

Security Authority Forum	Function
Board Definition	Charter
Performance Metrics	Metric
Technical Policies	Policy
Security Standards	Authority
Solution Designs	Input
Security Alignment	Output

Table 13: The Security Authority Forum

7 - More on the Authority Component

At its core, the Governance Topology tries to make the language of governance tangible and with less room for interpretation.

The Authority component is an element that is specifically designed with this in mind.

Now, we can discuss authorities, what they can (and cannot) do, to what degree or threshold they allow agency for decision-making, and define who wields the authority (and to what degree).

Wielding Authority is having the legal agency and ability to say "yes" or "no" to specific proposals and events. In the context of governance, authority allows individuals in Governance Functions to ensure changes to the platform are intentional, drive business outcomes, and are in line with agreed-upon standards.

7.1 - The Authority Reference Framework

The following list of authorities can be used to map out your governance organization. As with other sections, keep in mind that this is not an exhaustive list.

Authority	Definition
Strategic Direction	Setting the overall vision and goals for IT platform changes to align with business objectives.
Demand Prioritization	Assessing and ranking IT demands based on their importance and impact on the organization.
Demand Standards	Establishing criteria for evaluating and approving IT demands.
Design Standards	Defining guidelines and best practices for designing IT solutions.
Design Changes	Reviewing and approving modifications to existing IT designs.
Implementation Standards	Setting protocols for the deployment and integration of IT solutions.
Test Standards	Defining procedures and criteria for testing IT solutions to ensure quality and functionality.
Release Standards	Establishing guidelines for the release and rollout of IT solutions.
Technical Standards	Setting technical specifications and requirements for IT solutions.
Technical Changes	Reviewing and approving changes to the technical aspects of IT solutions.
Resource Allocation	Distributing resources such as budget, personnel, and equipment for IT projects.
Security Standards	Establishing and enforcing security protocols to protect data and systems.
Compliance Standards	Ensuring all changes adhere to relevant laws, regulations, and industry standards.
Governance Standards	Setting guidelines for the governance and oversight of IT projects.
Change Management	Managing the process of implementing changes to minimize disruption and ensure successful adoption.
Vendor Management	Managing relationships with third-party vendors and ensuring their compliance with your standards.
Budgeting	Overseeing the financial aspects of IT projects to ensure they stay within budget.

Table 14: The Authority Reference Framework

7.2 - Authority Thresholds

Defining authority and who wields it also implies defining to what degree they are allowed to use it before having to escalate to a higher governance function and reach a decision. Authority Thresholds define this dynamic.

It is important to note that thresholds are not easily quantifiable, and the framework is intended to be a conversation component from which we can discuss what the authority should allow us to decide upon, given the context of an actual decision.

Any Authority Threshold framework is unlikely to become more than this, as it builds on subjective categorization through T-shirt sizes. Hardly an exact science, though it can become more accurate if previous decisions of an authority are logged, thereby providing a baseline or precedent that can be relied upon when faced with future decisions.

Additionally, you can enrich the T-shirt size options by establishing examples that can be used to guide and normalize sizing across decisions.

Below, you will find an example definition of Authority Thresholds.

Have a look, and refer to the following example for an introduction on how to read and use it:

The Design Forum wields the Design Change Authority and must approve or reject a proposed solution design that has the following characteristics:

Known Business Objective: True

Increases Technical Debt: Medium

Increases cost: X-Small

Increases effort: Medium

Increases risk: Large

The forum has authority to approve/reject on 4/5 parameters.
Following the Threshold definition it would be advisable for the forum to approach a higher instance of authority before finalizing a decision.
Again, it should be emphasized that this is not an exact science, and will make more sense in some contexts than others.

Authority

Autonomy criteria

Escalation Path

Known Business Objective

Increases Technical Debt

Increases Cost

Increases Effort

Increases Risk

N

Y

XS

S

M

L

XS

S

M

L

XS

S

M

L

XS

S

M

L

Strategic Direction

N

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

N

C-suite

Demand Standards

N

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

N

Strategic Direction

Demand Scoping

N

Y

Y

Y

Y

N

Y

Y

Y

N

Y

Y

Y

N

Y

Y

Y

N

Demand Standards

Demand Prioritization

N

Y

Y

Y

Y

N

Y

Y

Y

N

Y

Y

Y

N

Y

Y

Y

N

Demand Standards

Demand Resourcing

N

Y

N

N

N

N

Y

Y

Y

N

N

N

N

N

Y

Y

N

N

Demand Standards

Process Standards

N

Y

Y

Y

N

N

Y

Y

N

N

Y

Y

N

N

Y

Y

N

N

Director+ level process authority

Process Changes

N

Y

Y

Y

N

N

Y

Y

N

N

Y

Y

N

N

Y

Y

N

N

Process standards

Technical Standards

N

Y

Y

Y

Y

N

Y

Y

N

N

Y

Y

N

N

Y

Y

N

N

Director+ level technical authority

Technical changes

N

Y

Y

Y

Y

N

Y

Y

N

N

Y

Y

N

N

Y

Y

N

N

Technical standards

Design standards

N

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

N

N

Technical standards

Design changes

N

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

N

N

Design standards

Table 15: The Authority Thresholds

You are likely to have a setup where an authority is wielded by more than one Governance Function, which would imply that they have been granted different levels of authority which is representable by having a  specific Threshold Definitions assigned to specific Governance Functions (i.e., on Authority can be wielded by two Governance Functions, and as such they will have different levels of autonomy).

of As a final note, the following table is, of course, completely up for negotiation and should be redefined to fit the functions, authorities, escalation paths, and thresholds that fit the individual enterprise.

 

7.3 - Authority Escalation Chains

The Governance Topology and its Authority definition leverages Wielding Degrees to define this dynamic.

Wielding Degrees come in:

Owner

Escalation Point

Wielder

The Governance Function, defined as Owner, is usually the final escalation point for decisions within a specific area of authority. The Owner is not intended to be the first instance for decision-making, but only to be included when the Wielding Governance Functions meet decisions whose consequences breach the agreed-upon limits for agency.

If necessary, you can define an Escalation Point beyond the Governance Function, which is defined as the Owner of an Authority.

Below, you will find an illustrative example of Authority Escalation Chains. As with the above Threshold definition, this is entirely negotiable in accordance with the context of the adopting enterprise.

Domain	Strategic	Portfolio			Technical
Authority / Component	Executive Board	Portfolio Board	Demand Forum	Process Forum	Technical Governance Board	Architectural Authority Forum	Technical Authority Forum	Design Authority Forum	Security Authority Forum
Strategic Direction	O	W	W	W
Demand Prioritization	EP	O	W
Demand Standards	EP	O	W
Design Standards					O	W	W	W
Design Changes						O	W	W
Implementation Standards					O		W
Technical Standards					O		W	W
Technical Changes					O		W	W
Resource Allocation		O	W
Security Standards									O W
Governance Standards	O	W			W				W
Budgeting	O W

Table 16: The Authority Escalation Chains

More content by Jakob Anker Nielsen

Connect With Me