Designing a Platform Strategy for the Enterprise Workflow Platform

[Joe Dames]

You Adopted the Platform. You Forgot to Govern It.

ServiceNow started as IT's tool. Then HR wanted in. Then Customer Service. Then Security. Then Facilities filed a request. Somewhere between "departmental ITSM platform" and "the thing every team in the enterprise is building on," the question of who's actually in charge of the whole thing got quietly set aside. This article is about answering it.

---

The Platform That Ate the Enterprise (One Department at a Time)

It starts the same way every time. IT deploys ServiceNow for incident management. It works beautifully. Word gets around. HR asks if they can use it for employee onboarding. Sure — there's a module for that. Customer Service wants to manage cases. Also doable. Security Operations hears about the automation capabilities and wants in. Facilities Management shows up with a request that nobody expected but can't easily decline.

Three years later, seventeen teams are building on the same platform. Four of them have created their own data models. Six have built integrations using completely different patterns. Two have customized core workflows in ways that will probably break during the next upgrade. And nobody — not one person or team — has a complete picture of what's actually running on the platform, what it depends on, or what breaks if something changes.

This is what happens when you adopt a platform without a platform strategy. The tool was right. The governance around it just never showed up.

✦ ✦ ✦

The Problem

Seventeen Teams. Seventeen Opinions About How the Platform Should Work.

The irony of a platform's success is that it creates the conditions for its own dysfunction. The more departments adopt it, the more valuable it becomes — and the more fragile, inconsistent, and difficult to maintain, because every team that joins brings its own ideas about data models, development patterns, integration approaches, and what "good enough" looks like.

What "No Platform Strategy" Looks Like in Practice

The HR team builds a custom approval workflow that duplicates logic the IT team already built — because they didn't know it existed and nobody told them to look. The Security team creates an integration with the identity platform using a bespoke script, while the IT team has a governed Integration Hub connection to the same system. An upgrade gets blocked because three departments have made modifications to core tables in ways that conflict with each other. And when something breaks at an inopportune moment, the question "who owns this?" generates a silence that would be funny if it weren't a production incident.

None of these problems are the fault of the teams involved. They were doing their jobs. The platform just didn't have anyone doing the job of making sure the platform itself stayed coherent.

The solution isn't less adoption. Platform adoption is a good thing — it means the tool is delivering value. The solution is a deliberate, documented platform strategy that establishes who governs the platform, how teams build on it, what shared capabilities exist so nobody has to reinvent them, and what standards keep seventeen teams from producing seventeen incompatible implementations of the same concept.

The Explanation

What a Platform Strategy Actually Contains (and What It Prevents)

A platform strategy is not a governance document that exists to slow people down. It's an architectural agreement that allows people to move faster — because the hard decisions about how to build things have already been made, documented, and made available to everyone who needs them. Think of it less as a rulebook and more as a shared foundation that any team can build on confidently.

There are four components that every effective enterprise workflow platform strategy requires.

1 - A Governance Model That Doesn't Require a Committee for Every Decision

Platform governance works best as a federated model: a central platform team sets the architectural standards, owns the core platform capabilities, and runs an architecture review process for significant new solutions. Domain teams — IT, HR, Customer Service, Security — build within those standards and own their workflows without needing central approval for every change.

The governance model answers the questions that, without it, get answered inconsistently by whoever happens to be building something at the time: How are integrations designed? How are data models structured? What's the standard for approval workflows? When does a new use case require a platform review versus when can a team just build it?

2 - Shared Capabilities That Nobody Has to Build Twice

Every enterprise workflow platform has a set of capabilities that every team needs: approval workflows, notification frameworks, identity verification, integration patterns to common systems. The difference between a well-governed platform and a fragmented one is whether those capabilities are built once, maintained centrally, and made available to all teams — or rebuilt from scratch by every team that needs them.

Shared platform capabilities reduce duplication, improve quality (a capability that twelve teams depend on gets more attention than one that only one team built), and make governance tractable. You can't enforce consistency across seventeen independent implementations. You can enforce it at the shared service layer.

3 - Integration Standards That Don't Create New Debt While Solving Old Problems

As covered in Part VIII of this series, integration architecture is one of the fastest ways a platform accumulates technical debt. A platform strategy defines the standard patterns — API-based integrations, event-driven connections, Integration Hub configurations — and specifies when each pattern is appropriate. Teams don't choose their own approach; they apply the right standard pattern to their use case.

This matters especially as AI capabilities are introduced. A platform where integrations are governed, documented, and associated with service architecture models in the CMDB is a platform where AI can reason about operational dependencies. A platform where integrations are custom scripts in various states of documentation is a platform where AI sees noise.

4 - Alignment with Service Architecture

The thread that runs through this entire series arrives here too. Every workflow built on the platform should be associated with the service it supports in the CMDB. An HR onboarding workflow belongs to the Employee Services application service. A customer case management workflow belongs to the Citizen Services capability. A security incident response workflow belongs to the Security Operations technical service.

This isn't paperwork. When workflows are CSDM-aligned, the platform gains the ability to report on service health in terms that actually matter, route failures to the right owners automatically, and give AI systems the service context required to generate useful recommendations rather than generic observations.

"A platform strategy isn't about slowing teams down. It's about making sure that when seventeen teams build on the same foundation, they end up with a building — not a pile of load-bearing walls pointed in different directions."

The Example

The Upgrade That Took Six Months. And the One That Took Three Weeks.

Nothing reveals the quality of a platform strategy faster than an upgrade cycle. Every ServiceNow upgrade requires testing across the platform's implemented scope. How long that takes — and how painful it is — is almost entirely determined by how the platform was governed before the upgrade arrived.

Without a Platform Strategy

Six Months of Untangling Someone Else's Decisions

The upgrade notification arrives. The platform team begins scope assessment and discovers that three departments have made direct modifications to base system tables. Two teams built integrations that call internal APIs which changed in the new release. One team's approval workflow depends on a customization that conflicts with the updated UI framework. None of this was documented. Some of it was built by contractors who are no longer engaged. The upgrade stalls while the team reverse-engineers four years of undocumented decisions.

Upgrade duration: 6 months  ·  Surprises encountered: many  ·  Documentation available: minimal  ·  Teams who remember building it: fewer than you'd hope

With a Platform Strategy

Three Weeks and a Checklist

The same upgrade notification arrives. The platform team opens the platform architecture documentation, which lists every governed integration, every shared capability, and every domain team's solution scope. Integrations were built using standard Integration Hub patterns — the upgrade compatibility matrix tells them exactly which ones need testing. No base system tables were modified; customizations are scoped appropriately. The upgrade test plan writes itself from the documented platform inventory. Three weeks later, the upgrade is live.

Upgrade duration: 3 weeks  ·  Surprises encountered: none  ·  Documentation available: complete  ·  Teams who remember building it: all of them, it's in the governance record

The upgrade itself was the same in both cases. The difference was six months of technical archaeology versus three weeks of executing a plan that already existed — because someone had the foresight to govern the platform while it was being built, not after it became a problem.

---

Bringing It Together

The Platform Is Worth Protecting

ServiceNow, positioned correctly, is one of the most valuable digital assets in the enterprise. It's the system of action that runs the operational stack, the integration layer that connects systems across domains, the AI foundation that makes intelligent operations possible. It earns that position through deliberate investment — in architecture, in governance, in the shared capabilities that make it more valuable to every team that uses it.

A platform strategy isn't a constraint on that investment. It's the thing that protects it. The organizations that govern their platforms well don't just have a ServiceNow instance that works today. They have one that will still work after the next upgrade, the next acquisition, the next AI capability, and the next department that shows up wanting to build something on it.

Seventeen teams can build on the same foundation. You just have to actually build the foundation first.