Enterprise platforms such as IT service management platforms, workflow platforms, and digital service platforms often accumulate complexity over time. This complexity usually arises from custom processes, bespoke integrations, uncontrolled customization, and duplicated functionality.
To control this complexity, organizations adopt different governance models that regulate how the platform may evolve.
This document describes four progressively stronger governance approaches:
- Standardization Policy
- Strict Standardization Policy
- Ruthless Standardization Model
- Enterprise Platform Constitution
These models represent a maturity trajectory from flexible adoption to highly controlled enterprise platforms.
1. Governance Model 1 — Standardization Policy
Description
The Standardization Policy encourages the use of vendor-provided capabilities and standard processes but allows flexibility where business needs require deviations.
The focus is on encouraging best practices rather than enforcing them strictly.
Organizations adopting this model typically aim to reduce unnecessary customization but accept that some customization will occur.
Key Characteristics
- Vendor capabilities preferred
- Configuration preferred over customization
- Custom integrations allowed with review
- Business process deviations tolerated
- Limited enforcement mechanisms
Advantages
- High flexibility for business units
- Easier adoption of the platform
- Fewer governance barriers
- Faster initial implementation
Disadvantages
- Customization tends to grow over time
- Platform complexity increases gradually
- Upgrade effort may increase
- Difficult to control technical debt
Suitable For
- Early-stage platform implementations
- Organizations new to enterprise platforms
- Decentralized IT environments
2. Governance Model 2 — Strict Standardization Policy
Description
The Strict Standardization Policy strengthens governance by enforcing vendor standards more actively and introducing formal approval processes for deviations.
Customization is allowed but carefully controlled.
The objective is to balance platform stability with business flexibility.
Key Characteristics
- Vendor process frameworks required
- Customization requires governance approval
- Integrations prioritized according to vendor support
- Technical debt tracking introduced
- Formal architecture reviews implemented
Advantages
- Improved platform consistency
- Reduced customization growth
- Better upgrade compatibility
- Improved governance visibility
Disadvantages
- Slower implementation cycles
- Governance overhead increases
- Potential resistance from business units
- Some legacy complexity may remain
Suitable For
- Organizations with established platform programs
- Enterprises running multiple platform modules
- Environments requiring moderate governance
3. Governance Model 3 — Ruthless Standardization Model
Description
The Ruthless Standardization Model actively seeks to eliminate unnecessary customization and complexity.
In this model, customization is treated as technical debt and is aggressively managed and reduced.
Processes must align with vendor standards unless a compelling exception is approved.
Key Characteristics
- Mandatory vendor process alignment
- Customization is considered technical debt
- Customization reduction programs implemented
- Architecture gate reviews are required
- Process rationalization initiatives conducted
Advantages
- Significantly lower platform complexity
- Faster platform upgrades
- Improved stability and reliability
- Reduced long-term operational costs
Disadvantages
- Business processes may need significant adaptation
- Strong governance required
- Cultural resistance possible
- Innovation may feel constrained initially
Suitable For
- Mature enterprise platform environments
- Organizations running large-scale platform deployments
- Environments prioritizing long-term sustainability
4. Governance Model 4 — Enterprise Platform Constitution
Description
The Enterprise Platform Constitution represents the most mature governance model.
Instead of policies alone, the platform is governed by architectural laws that define non-negotiable principles for platform use.
These laws establish strict rules regarding customization, integrations, process ownership, and architectural compliance.
The platform becomes a core enterprise infrastructure component governed similarly to financial or regulatory systems.
Key Characteristics
- Architectural laws governing platform use
- Strict ownership requirements
- Full transparency of platform artifacts
- Strong architectural review processes
- Systematic technical debt elimination
Advantages
- Maximum platform stability
- Strong architectural integrity
- Minimal technical debt accumulation
- Highly predictable platform evolution
Disadvantages
- Significant governance overhead
- Reduced flexibility for local needs
- Requires strong executive support
- May be perceived as restrictive
Suitable For
- Large enterprises with mature platform programs
- Organizations treating the platform as strategic infrastructure
- Environments requiring strong compliance or regulatory control
Comparison of Governance Models
| Governance Aspect | Standardization Policy | Strict Standardization | Ruthless Standardization | Platform Constitution |
|---|---|---|---|---|
| Governance Strength | Moderate | Strong | Very strong | Maximum |
| Customization Control | Limited | Controlled | Aggressively reduced | Constitutionally restricted |
| Process Alignment | Encouraged | Required | Mandatory | Architectural law |
| Integration Strategy | Prefer vendor integrations | Vendor integrations prioritized | Vendor integrations enforced | Integration of ownership law |
| Technical Debt Management | Minimal | Registered | Actively reduced | Structural elimination |
| Architecture Reviews | Occasional | Formal | Mandatory gate reviews | Constitutional governance |
| Complexity Reduction | Limited | Moderate | Active | Structural |
| Upgrade Stability | Moderate | Improved | High | Maximum |
Maturity Trajectory
| Maturity Stage | Governance Model | Focus |
|---|---|---|
| Early Platform Adoption | Standardization Policy | Encourage vendor standards |
| Developing Platform Governance | Strict Standardization | Control customization growth |
| Mature Platform Operation | Ruthless Standardization | Reduce complexity and technical debt |
| Strategic Enterprise Platform | Platform Constitution | Govern the platform through architectural laws |
Practical Observations
In practice, most organizations operate between Strict Standardization and Ruthless Standardization.
Early platform deployments often start with flexible governance, but as the platform expands across departments and services, stronger governance becomes necessary to maintain stability. Organizations that fail to strengthen governance frequently encounter:
- Uncontrolled customization
- Expensive upgrades
- Fragmented processes
- Duplicated integrations
A structured governance model helps prevent these issues while maintaining the platform as a sustainable enterprise capability.
How about ServiceNow?
In my opinion, most ServiceNow products, especially the mature ones, should be implemented out of the box (e.g., Platform Constitution from day-1). This means companies should only use the ServiceNow products for what they were intended. And yes, that will require procurement of multiple ServiceNow products. Some products, unfortunately, are not quite mature yet and need to be customized to make them better fit for purpose (e.g. Ruthless Standardization). The technical debt should be documented and reverted to Out-of-the-box when the product has been innovated and has become more mature.
ServiceNow supports a blend of Practices of multiple commodity frameworks. For that reason, when recommending mutiple products on the platform, I recommend using ServiceNow’s OOTB process guides, which complement each other, rather than customizing ServiceNow to become compliant with ITIL, IT4IT, SCRUM, SAFe, ISO27K, ISO85K, TOGAF, or company-specific variants thereof. Even then, not everybody uses the same frameworks so, you may have to configure the platform ti cater for your blend. Special word of caution: do not let your policy makers ruin a suitable practie. Tell them that majority of the Fortune 500 compnaies uses ServiceNow, and most of them must comply with the same legislations, and they typically do (unless if they have customized the platform).
It is possible to configure your own Integrations with ServiceNow. In general, I recommend using the Integration products that are provided/supported by ServiceNow. Use of integration/customisation products of partners may be considered, but could be a slippery slope. Over the last 20 years, I have seen quite a few products that kick-started the integration, but that became a millstone around the neck when it came to upgrades. As a rule of thumb, it it takes more than three-four weeks to test/deploy a major platformrelease, you probably have taken a wrong turn somewhere. If you cannot upgrade until the partner provides an updated store product, you should definitely rethink using that product. Same applies when a 3rd party product is an impediment for adding new out the box plugins to the platform.
