PART 4 OF 6
Domain Control Planes Are Emerging Inside the Enterprise
Why Smarter Domains Do Not Automatically Centralize Execution
Automation is becoming more capable inside individual business domains. A marketing system can research a market, plan a campaign, generate content, seek approval, publish material, capture leads, and report cost and results. Service management platforms coordinate incidents, changes, requests, and service operations. Sales platforms manage customer relationships and increasingly automate more of the work around them.
These systems are more than isolated tools. As they gain state, decision-making, execution, and governance within a function, they begin to look like domain-specific control points. That does not make them enterprise-wide control planes. It does make them important to the architecture that an enterprise must govern.
A Domain Can Become a Control Point
A control point has enough knowledge and authority to coordinate work within a defined boundary. It understands the objects, relationships, policies, and outcomes that matter in that domain. It can determine what should happen next, initiate or coordinate action, stop for approval, and record whether the result met the local objective.
The marketing example is instructive because its promise spans a complete function rather than one task. The system described in the demo moves from market research and planning to content production, approval, promotion, lead capture, and measurement. It contains workload-like executions and process-like decisions, but its organizing purpose remains marketing. Its domain scope is what makes it a domain control plane.
The same pattern could emerge in service management, where ServiceNow and its ecosystem may coordinate a wide range of service workflows, or in sales and marketing, where Salesforce and surrounding products may coordinate customer-facing activity. The competitive sets will differ by domain, even if we can use common analytical lenses to examine them.
Horizontal Platforms Have a Different Reach
A horizontal process platform can orchestrate a process in marketing, IT, sales, or HR without being designed for one of those functions. Its value comes from applying a common process model across different domains. A domain platform derives its depth from specialized data, rules, systems, and work practices in its chosen function.
These are different forms of reach. A horizontal platform may span many types of process but rely on integrations and configuration to understand each one. A domain platform may offer deeper native context and control inside one function but have little authority outside it. Neither is automatically more complete. The question is what work it coordinates and which boundaries it can govern.
Domain Control Does Not Mean Enterprise Control
A company can run increasingly autonomous control points across marketing, service management, finance, data, software delivery, and infrastructure. Each may be useful and well-governed within its own scope. An enterprise orchestrator is not a prerequisite for domains to automate useful work within their own scope.
The need for enterprise coordination arises when work crosses domains or when a result depends on interactions among them. A campaign may depend on customer data, approval policy, a web platform, and sales follow-up. A service restoration may require infrastructure changes, application actions, a customer communication, and a financial decision. No one domain necessarily owns the entire outcome.
Shared Governance and Assurance Connect the Domains
The enterprise challenge is to understand how these control points act together. What state did each system use? What authority did it have? Which policies constrained it? What actions did it take? What did it hand off, and what evidence shows that the broader outcome was achieved? These questions apply whether execution remains local or crosses into another domain. Automation observability provides cross-platform visibility into these actions, handoffs, and outcome evidence.
Shared governance and assurance can address these questions without moving every workflow into one central engine. Together with automation observability, they establish common expectations for identity, delegated authority, policy, decision records, cost, exceptions, and outcome evidence. The implementation may be federated: each domain remains authoritative for the state it knows best, while the enterprise can see and govern consequential interactions.
A Repeatable View of a Changing Market
The same three analytical views could be applied at different scopes over time. The 2026 EMA Radar for Enterprise Orchestration focuses on enterprise coordination across domains. A future domain-focused analysis could use workload orchestration to examine runnable work within a function, process orchestration to examine its end-to-end instances, and governance and assurance to examine how actions are controlled and outcomes validated.
Future analysis can compare vertical and horizontal platforms without treating them as substitutes, while tracking how each exposes state or expands its capabilities.
