BOLT — The Four Principles¶
B · O · L · T — Business Ownership, On-Demand Agility, Low-Code Platforms, Trusted Enablement
TL;DR
Two principles are owned by business (B — Business Ownership, O — On-Demand Agility), two by IT (L — Low-Code Platforms, T — Trusted Enablement). They interlock: business speed works only within IT-enabled guardrails, and IT enablement has value only when business teams use it. Remove any one and the model breaks.
Applies To
Audience: Business Leaders · Platform Team · CIO/CTO BOLT Tiers: All Frameworks: BOLT
The four BOLT principles are not independent capabilities. They are a system — two owned by the business, two owned by IT, all four required for the model to hold. Remove any one of them and the model breaks down in a predictable way.
Why Principles Matter Before Tiers¶
Most delivery model failures are not process failures. They are principle failures — an organisation that adopts the four delivery tiers without internalising the four principles will find the tiers reverting to the old model within months. Business teams will wait for IT to approve everything. IT will treat citizen development as a risk to be managed rather than a capability to be enabled. Shadow IT will emerge. Ownership will become ambiguous again.
The principles are the culture. The tiers and roles are the mechanism. Both are required.
B — Business Ownership¶
Business teams define requirements and lead solution delivery aligned with operational needs.
Business Ownership is the principle that fundamentally changes the delivery dynamic. It is not a delegation of risk to business teams — it is a recognition that business teams are often the most qualified people to define, build, and own solutions for their own processes. They understand the problem. They live with the solution every day. They know when it is not working.
What Business Ownership means in practice:
Business teams do not submit requirements and wait for IT to deliver. For solutions within the appropriate tier — particularly Tier 1 and Tier 2 — business teams own the solution end-to-end: - They define what the solution needs to do - They build it (or direct its building) - They test it and sign off on it - They maintain it and support their own users - They are accountable when it works and when it does not
What Business Ownership does not mean:
Business Ownership does not mean unsupported or ungoverned. It means that within the guardrails that Trusted Enablement (T) has established, business teams have genuine autonomy. The guardrails are not a negotiation — they are the conditions that make Business Ownership safe and sustainable.
It also does not mean that every solution is owned by the business. Complex solutions that require enterprise architecture, regulated data handling, or system-of-record integration belong in Tier 3 or Tier 4 — where ownership is shared or IT-led. Business Ownership applies within the tier boundaries, not across them.
The accountability shift:
One of the most significant changes BOLT introduces is explicit business accountability for solutions that were previously delivered by IT and then handed over. Under BOLT:
- A Tier 2 solution built and owned by a business team is the business team's responsibility — for maintenance, for support, for keeping it compliant, and for decommissioning when it is no longer needed
- The Platform Team does not inherit ownership of solutions it did not build
- Ownership is documented at creation — not discovered when something breaks
Why this matters for the enterprise:
Organisations that maintain IT ownership of all solutions — regardless of complexity — create a bottleneck that limits the pace of business change to the pace of IT delivery. In a world where business processes change faster than IT investment cycles, this is a structural competitive disadvantage. Business Ownership, properly governed, removes the bottleneck without removing the governance.
O — On-Demand Agility¶
Subject matter experts build and iterate solutions rapidly without traditional IT queues.
On-Demand Agility is the principle that gives Business Ownership its speed. It defines that within the governed platform, business teams can start building immediately — without a project intake, without a budget approval cycle, without a security review, without joining an IT delivery queue.
What On-Demand Agility means in practice:
For Tier 1 and Tier 2 solutions, the time from "I have an idea" to "I am building" is measured in days, not months: - The platform is already accredited — no new security review - The connector library is already approved — no new integration approval - The workspace is already provisioned — no infrastructure request - The data classification boundaries are already defined — no new data handling assessment
The citizen developer or power user opens the platform, starts building within the approved workspace, and uses approved connectors. The guardrails are built into the environment — they do not require a human approval process for every solution.
The difference between agility and chaos:
On-Demand Agility is not the same as uncontrolled development. The distinction is important:
- Agility without governance produces shadow IT — fast, ungoverned, and invisible until it creates a problem
- Governance without agility produces backlogs — controlled, visible, and too slow to be useful
- On-Demand Agility within BOLT produces governed speed — fast delivery within a structure that ensures security, compliance, and accountability
The guardrails that Trusted Enablement (T) establishes are what make On-Demand Agility safe. They are not a constraint on agility — they are the condition that makes agility sustainable.
Iteration as a design principle:
On-Demand Agility also means that solutions can be iterated quickly. Business processes change. Requirements evolve. A Tier 1 or Tier 2 solution that takes two weeks to build should take two days to modify. This iterative capability is one of the strongest arguments for low-code platforms in a business ownership model — the people who understand the process can change the solution to match the process, without a change request, a development sprint, or a release cycle.
L — Low-Code Platforms¶
Enterprise platforms that enable rapid development of apps, automation, and AI-driven agents.
The L pillar recognises that the platform is a capability in itself — not just a tool, but an enterprise asset that requires deliberate management, evolution, and governance. The Platform Team's ownership of the L pillar means they are responsible for ensuring the platform remains capable, secure, and relevant as business needs evolve.
What the L pillar covers:
The Low-Code Platforms pillar spans the full technology layer of BOLT:
- Platform capability — which features are enabled, which are restricted, and why
- Workspace strategy — how environments are structured to support different tiers safely
- Connector library — which integrations are approved, at what classification level, and what the process is for requesting new ones
- Licence management — ensuring the right licences are available for the right users at the right tiers
- AI and Copilot capabilities — which AI features are enabled within approved classification boundaries
- Platform evolution — assessing and onboarding new capabilities as the platform vendor releases them, clearing them through the security / compliance function before making them available to business teams
Technology-agnostic by design:
BOLT is designed to be applicable to any enterprise low-code platform — not just Microsoft Power Platform. The L pillar is intentionally technology-agnostic in its definition: the principles of managing a low-code platform, maintaining a connector library, and governing workspace strategy apply regardless of whether the platform is Power Platform, Salesforce, ServiceNow, OutSystems, or any future platform the organisation adopts.
Currently, BOLT is implemented on Microsoft Power Platform. The framework carries forward to any platform the organisation adopts next.
Platform as a product:
The most mature implementations of the L pillar treat the low-code platform as an internal product — with a product roadmap, a backlog of capability requests from business teams, a release cadence for new features, and a customer (the business teams) whose satisfaction is measured and managed.
This product thinking is what separates a Platform Team that reactively responds to requests from a Platform Team that proactively enables the organisation. The L pillar is the mandate for the latter.
Power Platform — Current Implementation:
| Capability | Status |
|---|---|
| Power Apps (Canvas and Model-Driven) | Enabled across Tier 1–3 |
| Power Automate (Cloud Flows) | Enabled across all tiers |
| Copilot Studio | Enabled for AI agent development |
| DLP Policies | Configured — connector usage controlled |
| Dataverse and Workspace Strategy | Defined — Dev, Test, Production environments established |
| CoE Starter Kit | Deployed — visibility, telemetry, monitoring active |
| AI and Copilot Features | Enabled within approved classification boundaries |
| Training and Learning Paths | Published for citizen developers, power users, and fusion team members |
T — Trusted Enablement¶
IT provides secure platforms, guardrails, and oversight to ensure scalable and compliant delivery.
Trusted Enablement is the principle that makes all the others sustainable. Without T, Business Ownership creates uncontrolled risk. Without T, On-Demand Agility creates shadow IT at scale. Without T, Low-Code Platforms become ungoverned tools rather than enterprise assets.
T is IT's value proposition in the BOLT model. Not as a gatekeeper that controls access and approves every solution. Not as a service desk that responds to requests. But as an enabler that builds the secure, governed platform on which business teams can operate autonomously and confidently.
What Trusted Enablement means in practice:
The Platform Team, under the T pillar, is responsible for:
- Platform standards and guardrails — the rules that govern what can be built, how, and in which workspace
- Security pre-approvals and accreditation — working with the security / compliance function to obtain platform-level approvals that remove the need for solution-level approvals at Tier 1 and Tier 2
- Connector library management — maintaining the approved connector catalogue, assessing new connector requests, and retiring connectors that no longer meet security requirements
- Citizen developer enablement and training — ensuring business teams have the skills, guidance, and support to build within the guardrails correctly
- BOLT processes, templates, and best practices — the operational infrastructure that makes the model repeatable
- Monitoring and oversight — using CoE tooling and platform telemetry to maintain visibility of what is being built, by whom, and whether it remains within approved boundaries
- New capability assessment — evaluating new platform features and clearing them through the security / compliance function before enabling them for business teams
The distinction between gatekeeper and enabler:
The gatekeeper model — where IT approves every solution before it can be built — creates the backlog that BOLT is designed to eliminate. The enabler model — where IT designs the guardrails once and business teams operate within them — scales without creating bottlenecks.
The shift from gatekeeper to enabler requires IT to invest upfront in: - Thoughtful guardrail design — guardrails that are genuinely risk-calibrated, not maximally restrictive - Clear communication — business teams can only operate within guardrails they understand - Responsive exception handling — when business teams hit a genuine guardrail they need removed, the process to request and assess an exception must be fast
Trusted Enablement across tiers:
The T pillar operates differently at each tier — with oversight increasing as complexity increases:
| Tier | Trusted Enablement Character |
|---|---|
| Tier 1 | Platform-level pre-approvals cover the solution. Guardrails enforced by environment. Monitoring in place. Individual solution review not required. |
| Tier 2 | Platform Team onboards the business team and confirms the solution fits within pre-approved boundaries. Security / compliance function informed and monitoring. |
| Tier 3 | Line of Business IT co-develops. Security / compliance function mandatory sign-off on architecture, data flows, and integration points. |
| Tier 4 | Full IT-led SDLC. All enterprise governance standards apply. Security / compliance function mandatory sign-off throughout. |
How the Four Principles Work Together¶
The four principles are designed as an interlocking system. Each principle depends on the others:
B needs T — Business Ownership is only safe if Trusted Enablement has established the guardrails within which business teams operate. Without T, B becomes ungoverned self-service.
O needs L — On-Demand Agility is only possible if the Low-Code Platform is properly configured, accredited, and maintained. Without L, O has no platform to be agile on.
L needs B — The Low-Code Platform exists to serve business needs. Without Business Ownership as the guiding principle, the platform becomes an IT asset that business teams reluctantly use rather than a business capability they champion.
T needs O — Trusted Enablement's value is demonstrated through the speed it enables. Without On-Demand Agility as a visible outcome, the T pillar looks indistinguishable from the traditional gatekeeper model it is designed to replace.
Together: Business teams own and build rapidly (B · O), on a platform that IT manages and secures (L · T). This is the BOLT contract.
Common Misconceptions¶
"BOLT means IT is no longer involved." IT's role changes — from delivery queue to platform enabler. IT is more involved in design and governance under BOLT than under a reactive delivery model. The involvement happens earlier and at the right level of abstraction.
"BOLT is just citizen development." Tier 1 is citizen development. Tier 2 is business-led delivery. Tier 3 is fusion team collaboration. Tier 4 is IT-led enterprise delivery. BOLT covers the full spectrum — citizen development is the most visible tier but not the only one.
"BOLT removes security controls." BOLT removes redundant security review processes that were applied to every solution regardless of risk level. The underlying security controls — DLP policies, data classification boundaries, connector approvals, workspace isolation — are more structured and consistently applied under BOLT than in ungoverned citizen development.
"Any solution can be Tier 1 if the business wants it to be." Tier assignment is based on objective complexity criteria — not business preference or IT appetite. A solution that requires enterprise system integration, regulated data, or complex architecture belongs in Tier 3 or Tier 4 regardless of how simple the business team believes it to be. The escalation process exists for this reason.
Part of the BOLT Framework — powerplatform.wiki Last updated: March 2026 Last reviewed: March 2026