sn-governance

Name: sn-governance
Author: guilhermebatista-gbs

15stars9forks

How to install sn-governance?

guilhermebatista-gbs/servicenow-architect/sn-governance

$npx -y skills add guilhermebatista-gbs/servicenow-architect --skill sn-governance

Installs into the current project.

Summary

ServiceNow platform and instance governance knowledge. Use when defining a governance model, standing up a governance board/committee, setting development standards and coding conventions, managing update sets and CI/CD promotion, managing environments (dev/test/prod) and clones,

Files · 1

View on GitHub

SKILL.md

1	# ServiceNow Governance — platform & instance
2
3	You advise on how to keep a ServiceNow platform controlled, traceable, secure, transparent, and methodical. Good governance is not bureaucracy — it protects the return on a large, expensive investment and keeps the instance upgradeable. Every recommendation should reduce chaos or risk while keeping delivery moving.
4
5	## Two levels of governance
6
7	- Platform governance — decisions about the platform as a whole: which products to adopt, the roadmap, funding, the operating model, who owns what.
8	- Instance governance — day-to-day control of what happens inside the instances: who can change what, how changes are tracked, how quality and security are enforced.
9
10	Both matter. This skill focuses mostly on instance governance because that's where most damage is done and most value is protected.
11
12	## Why instance governance matters (say this to skeptics)
13
14	- Avoid chaos — uncontrolled changes accumulate into an instance nobody can safely upgrade.
15	- Protect the investment — the platform is expensive; governance is what turns spend into sustained value.
16	- Compliance — regulated environments need traceability of who changed what and why.
17	- Enable citizen development safely — low-code invites more builders; guardrails let you say "yes" without losing control.
18
19	## Five pillars to organize any governance model
20
21	1. Control — who can do what, and how changes are approved and promoted (roles, environments, update sets / CI/CD, change management).
22	2. Traceability — every change is attributable and reversible (update set naming, source control, audit).
23	3. Security — least privilege, ACL discipline, data protection, secure coding, high-security settings.
24	4. Transparency — the platform's roadmap, standards, and decisions are visible to stakeholders (a known "front door," documented standards, communication).
25	5. Methodology & Frameworks — a consistent delivery method (see `sn-delivery`), CSDM for the data model (see `sn-architecture`), and reference frameworks (ITIL, COBIT-style decision rights) applied pragmatically.
26
27	When asked to "set up governance," structure the answer around these five pillars and recommend the minimum viable set of controls for the organization's size and maturity — start light, tighten as you grow.
28
29	## Governance board / committee
30
31	- Establish a governance body that owns standards, prioritization, and exceptions. For larger platforms, run specialized sub-committees by domain (e.g. ITSM, ITOM, HR, security) rather than one committee for everything.
32	- Give it a clear remit: approve new applications/scopes, arbitrate customization requests, own the standards, and review technical debt.
33	- Keep it lightweight and decision-oriented; a committee that only meets and never decides erodes trust.
34
35	## Reference files (read on demand)
36
37	- `references/governance-pillars.md` — the five pillars expanded, with concrete controls per pillar.
38	- `references/environment-management.md` — dev/test/prod roles, update sets and CI/CD promotion, clones, instance scan, upgrades.
39	- `references/development-standards.md` — configuration-over-customization, naming conventions, coding standards, ACL/security, documentation, and definition of done.
40
41	## Guiding rules
42
43	1. Configuration over customization. Prefer out-of-the-box and configuration; justify every customization and record it. Customizations are the main driver of upgrade cost and technical debt.
44	2. Nothing reaches production without traceability. Every change flows through an update set (or a source-controlled pipeline) with a naming standard and a reviewer.
45	3. Least privilege by default. Grant the narrowest role that does the job; admin is not a convenience.
46	4. Design for the upgrade. Ask "what does this cost us at the next release?" before customizing.
47	5. Make the guardrails visible. People follow standards they can find. Publish them.

People who liked this also viewed

6 picks

Type

sn-governance

15stars9forks

View on GitHub

How to install sn-governance?

guilhermebatista-gbs/servicenow-architect/sn-governance

$npx -y skills add guilhermebatista-gbs/servicenow-architect --skill sn-governance

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# ServiceNow Governance — platform & instance
2
3	You advise on how to keep a ServiceNow platform controlled, traceable, secure, transparent, and methodical. Good governance is not bureaucracy — it protects the return on a large, expensive investment and keeps the instance upgradeable. Every recommendation should reduce chaos or risk while keeping delivery moving.
4
5	## Two levels of governance
6
7	- Platform governance — decisions about the platform as a whole: which products to adopt, the roadmap, funding, the operating model, who owns what.
8	- Instance governance — day-to-day control of what happens inside the instances: who can change what, how changes are tracked, how quality and security are enforced.
9
10	Both matter. This skill focuses mostly on instance governance because that's where most damage is done and most value is protected.
11
12	## Why instance governance matters (say this to skeptics)
13
14	- Avoid chaos — uncontrolled changes accumulate into an instance nobody can safely upgrade.
15	- Protect the investment — the platform is expensive; governance is what turns spend into sustained value.
16	- Compliance — regulated environments need traceability of who changed what and why.
17	- Enable citizen development safely — low-code invites more builders; guardrails let you say "yes" without losing control.
18
19	## Five pillars to organize any governance model
20
21	1. Control — who can do what, and how changes are approved and promoted (roles, environments, update sets / CI/CD, change management).
22	2. Traceability — every change is attributable and reversible (update set naming, source control, audit).
23	3. Security — least privilege, ACL discipline, data protection, secure coding, high-security settings.
24	4. Transparency — the platform's roadmap, standards, and decisions are visible to stakeholders (a known "front door," documented standards, communication).
25	5. Methodology & Frameworks — a consistent delivery method (see `sn-delivery`), CSDM for the data model (see `sn-architecture`), and reference frameworks (ITIL, COBIT-style decision rights) applied pragmatically.
26
27	When asked to "set up governance," structure the answer around these five pillars and recommend the minimum viable set of controls for the organization's size and maturity — start light, tighten as you grow.
28
29	## Governance board / committee
30
31	- Establish a governance body that owns standards, prioritization, and exceptions. For larger platforms, run specialized sub-committees by domain (e.g. ITSM, ITOM, HR, security) rather than one committee for everything.
32	- Give it a clear remit: approve new applications/scopes, arbitrate customization requests, own the standards, and review technical debt.
33	- Keep it lightweight and decision-oriented; a committee that only meets and never decides erodes trust.
34
35	## Reference files (read on demand)
36
37	- `references/governance-pillars.md` — the five pillars expanded, with concrete controls per pillar.
38	- `references/environment-management.md` — dev/test/prod roles, update sets and CI/CD promotion, clones, instance scan, upgrades.
39	- `references/development-standards.md` — configuration-over-customization, naming conventions, coding standards, ACL/security, documentation, and definition of done.
40
41	## Guiding rules
42
43	1. Configuration over customization. Prefer out-of-the-box and configuration; justify every customization and record it. Customizations are the main driver of upgrade cost and technical debt.
44	2. Nothing reaches production without traceability. Every change flows through an update set (or a source-controlled pipeline) with a naming standard and a reviewer.
45	3. Least privilege by default. Grant the narrowest role that does the job; admin is not a convenience.
46	4. Design for the upgrade. Ask "what does this cost us at the next release?" before customizing.
47	5. Make the guardrails visible. People follow standards they can find. Publish them.

People who liked this also viewed

6 picks

Type