Business technology leaders rarely start from a blank slate. Most organisations already use established frameworks, standards and practices for agile development, service management, enterprise architecture, governance, sourcing, service integration and digital management tools and information architecture. These frameworks, standards and practices are valuable. They represent deep professional knowledge and provide expert-level depth in their respective domains. In this chapter, they are collectively referred to as expert practices.
The challenge is that expert practices often grow in separate communities. Agile development may use SAFe®. Service management may use ITIL®. Governance and assurance may use COBIT®. Architecture teams may use the TOGAF® Standard. Tooling and digital value-chain architects may use IT4IT™. Multi-provider service organisations may use SIAM™.
Each practice can be strong in its own area, but the organisation still needs a shared way to connect business ambition, demand, development, services, data, AI, governance and realised business value.
This is where the Business Technology Standard (BTS) has its role. BTS provides an overarching business technology operating model that bridges the expert practices and connects them across end-to-end value creation. It explains how value is created end-to-end, how capabilities work together, how roles connect, and how governance enables decisions without becoming bureaucracy.
BTS does not replace the expert practices or seek to compete with them. Expert practices provide professional depth in particular areas, while BTS provides the connections between them. This helps organisations use different expert practices together within a coherent operating model, with a shared view of business value, capabilities, roles, governance and end-to-end flow.
SAFe can strengthen scaled agile execution. ITIL can strengthen digital product and service management. SIAM can strengthen multi-provider service integration. COBIT can strengthen governance, control and assurance. TOGAF can strengthen enterprise architecture. IT4IT can strengthen the digital value-chain architecture and management tool landscape.
The practical question is not: “Which framework should we choose?”
The better question is:
Which expert practices give us the professional depth we need, and how do we connect them to business value, roles, governance and end-to-end flow?
BTS and expert practices are compatible when their different purposes are understood and their connections are deliberately designed.
BTS provides an overarching business technology operating model that connects the areas covered by different expert practices. It describes the disciplines, capabilities, roles, governance logic and end-to-end flow needed to turn business needs into operational value. Expert practices provide professional depth within particular areas of this operating model.
Expert practices provide professional depth. They give detailed methods, controls, structures, artefacts or operating practices for specific professional areas.
The organisation-specific implementation connects them. Each organisation must decide which expert practices to use, how they connect, how terminology is mapped, how governance bodies are combined, and how tools support the flow from strategy to value realisation.
Using several expert practices is not necessarily a problem. The greater risk is allowing each practice to develop into a disconnected management system. When that happens, the organisation creates parallel languages, duplicate governance, competing priorities and fragmented accountability.
The guiding principle is simple:
One connected operating model, many expert practices.
Where does this expert practice connect most strongly with BTS?
| Expert practice | Relevant BTS disciplines | Main contribution |
| Core SAFe® / AI-Native SAFe® | Demand, Development, Strategy and Governance | Scaled Lean and Agile execution, portfolio and product alignment, planning cadence, team-of-teams coordination and backlog structures, with additional AI-enabled practices introduced through AI-Native SAFe. |
| ITIL® |
Service Governance, Service Delivery | Digital product and service management, lifecycle management, service operations, continual improvement and management practices for AI-enabled environments |
| SIAM™ | Service Delivery, Service Governance | Multi-provider service integration, service integrator model, cross-provider coordination, integrated accountability and service ecosystem governance. |
| COBIT® | Strategy and Governance | Governance and management objectives, controls, assurance, risk, auditability and enterprise information and technology governance. |
| TOGAF® Standard | Strategy and Governance, Demand, Data and AI | Enterprise architecture method, architecture governance, architecture development, target states and architecture artefacts. |
| IT4IT™ Standard | Strategy and Governance, Development, Service Delivery | Digital value-chain reference architecture, management system design, management-tool and information architecture and value-stream information model. |
SAFe is an established framework for organisations that need to scale agile development across multiple teams, products and value streams. It provides depth in agile execution: roles, events, artefacts, planning cadence, team-of-teams coordination, Lean Portfolio Management and Agile Release Trains.
Core SAFe remains the foundation for enterprise agility, while AI-Native SAFe builds on this foundation to address how organisations operate and create value with AI. This is important for BTS because AI changes both the speed of development and the nature of governance. AI can accelerate learning, planning, experimentation, product development and delivery. At the same time, it increases the need to validate whether what is being built is safe, secure, valuable, governed and operationally ready.
BTS is compatible with SAFe, but it starts from a broader question. SAFe helps organisations scale Lean and Agile execution. BTS helps organisations manage business technology value creation from business ambition to operational value. This distinction matters because not all value creation problems are development execution problems. Many delays, quality issues and adoption problems begin earlier, when business needs are not shaped clearly enough, or later, when solutions are not fully prepared for release, service delivery and value realisation.
The strongest combination is to use BTS for the end-to-end business technology operating model and SAFe for scaled agile execution where agile is the right development approach. In this setup, BTS provides the wider context of demand planning, business design, value stream steering and Minimum Viable Governance (MVG) across the end-to-end flow. SAFe provides the agile execution system for refining, planning, building, validating and improving solutions through agile teams and scaled agile structures.
A practical connection point is the relationship between BTS demand planning and SAFe planning events. In BTS, demand planning defines the business rationale, capability development roadmap, development initiatives and development requests. This ensures that the organisation understands what needs to change, why it matters, what value is expected and what level of commitment is justified before development capacity is consumed. SAFe planning can then use this prepared demand to align teams, objectives, dependencies and delivery commitments.
The terminology can be mapped without forcing one model to replace the other. An approved BTS Development Request authorises development and provides the business and governance context for execution. Depending on the development model, the authorised work can then be structured and decomposed into project work packages or agile backlog items. BTS backlog-driven execution can connect to epics, features, stories and team backlogs. The important point is not the terminology itself, but the continuity of business intent from early planning to development execution and value realisation.
BTS also helps avoid a common scaling problem: treating every development need as if it should follow the same agile path. Some business technology changes are well suited to sprint-based development. Others require gate-based governance because they involve major investment, regulatory exposure, broad organisational change, complex sourcing or significant operational risk. BTS allows gate-based, sprint-based and change request-based development to coexist inside one operating model. SAFe can be used deeply where agile scaling is needed, while BTS keeps the wider portfolio, governance and service context coherent.
The AI-native direction of SAFe makes the compatibility with BTS even more relevant. AI accelerates development, but the organisation still needs to know what should be built, who owns the outcome, what data is used, how the service will operate and how value will be measured. BTS complements AI-enabled agile execution by connecting it to demand planning, data governance, service readiness, operating model roles and business value realisation.
The practical recommendation is clear: do not run BTS and SAFe as two parallel operating models. Use BTS to define the value creation system, governance levels, business ownership, demand types and end-to-end flow. Use SAFe to provide agile execution depth for the development parts of that flow.
ITIL is one of the most important expert practices for digital product and service management. It provides professional depth for service practices, service operations, continual improvement and the management of digital products and services across their lifecycle. Its current direction is explicitly shaped for AI-enabled environments, which strengthens its relevance for modern service management.
BTS is compatible with ITIL because service management is a central part of business technology value creation. In BTS, service management is not only an operational practice. It is connected to service governance, service planning, service portfolio, service catalogue, service integration, service release, service operations, user support, continual improvement and retirement.
ITIL provides depth in service practices. It helps organisations professionalise incident management, problem management, change enablement, service level management, service desk, continual improvement and many other practices that are essential for dependable service delivery. BTS does not need to rewrite these practices. Instead, BTS shows where they belong in the operating model and how they connect to demand, development, service governance and value realisation.
The most important BTS contribution is context. ITIL can define how service practices should work. BTS explains how those service practices are connected to business needs before development, to release readiness during development, and to value realisation after rollout. This prevents service management from becoming a separate operational discipline that is only engaged after development is complete.
In BTS, planning and preparation for service delivery start before production use. Operational readiness, support model, monitoring, recovery, service integration, catalogue visibility and user enablement must be considered before a solution becomes a consumable service. This is especially important when services rely on cloud platforms, external providers, data flows, automation and AI agents.
ITIL and BTS also complement each other in the AI era. ITIL gives service management guidance for digital and AI-enabled environments. BTS places AI-enabled services within the wider operating model: data ownership, AI product governance, service lifecycle, operational readiness, access management, release governance and value realisation. Together, they help ensure that AI-enabled services are not only technically powerful, but also supportable, controlled and valuable in daily use.
The practical recommendation is to use ITIL as the digital product and service management expert practice inside BTS Service Governance and Service Delivery. BTS defines the end-to-end value creation context; ITIL provides depth in product and service management practices.
SIAM, or Service Integration and Management, is especially relevant when services are delivered through multiple internal and external providers. It provides a structured approach for integrating services from different providers into a coherent, integrated business-facing service organisation.
BTS and SIAM are strongly compatible because modern business technology services rarely operate inside one provider boundary. Services depend on internal teams, suppliers, cloud providers, technology platforms, data platforms, automation tools, security services and increasingly AI-enabled operational capabilities. The user experiences one service, but the organisation must coordinate many contributors behind it.
In BTS, service integration is a core capability within Service Delivery. It ensures that services, providers, operational processes and dependencies operate as one coherent ecosystem. SIAM provides deeper professional practices for this integration challenge. It helps define the service integrator role, provider coordination, cross-provider processes, integrated performance management and shared accountability in a multi-provider environment.
BTS adds the wider business technology context around SIAM. Service integration does not exist only to coordinate suppliers. It must also connect to service governance, sourcing, contracts, supplier performance, service portfolio, release readiness, service catalogue, operational resilience and business value. A SIAM model that coordinates providers well but is disconnected from service lifecycle decisions will still struggle to create sustainable value.
This distinction is important. SIAM can define how the service ecosystem should be integrated. BTS defines why the service ecosystem exists, how it is governed, how services are funded, how demand changes the ecosystem, how new services are released, and how operational feedback creates future improvement demand.
AI makes the relationship even more important. AI agents and digital workers may increasingly form part of service operations. They may monitor services, support users, analyse incidents, prepare decisions or execute defined tasks. This creates a new kind of multi-provider and multi-actor environment. Service integration must coordinate not only human teams and suppliers, but also automated and AI-enabled operational capabilities.
The practical recommendation is to use SIAM as the multi-provider service integration expert practice within BTS. BTS keeps service integration connected to business value, service governance and lifecycle direction; SIAM strengthens the operating model for complex service ecosystems.
COBIT is an expert practice for the governance and management of enterprise information and technology. It provides a structured way to think about governance objectives, management objectives, controls, assurance, risk, capability assessment and auditability.
BTS and COBIT overlap in governance, but they serve different purposes. BTS defines how business technology value creation is governed as part of the operating model. COBIT provides deeper governance and management objectives, control thinking, assurance structure, capability assessment and auditability.
In BTS, governance is designed around Minimum Viable Governance (MVG). This means just enough decision points, roles and structures to keep value creation aligned, controlled and moving. BTS governance is expressed through enterprise governance, value stream governance, end-to-end flow governance and value governance approval points. It is designed to ensure that business technology decisions are made at the right level and connected to business value.
COBIT can strengthen this by helping organisations assess whether governance and controls are sufficient. It can support audit, risk, compliance, control design and governance maturity assessment. It is especially useful when organisations need to demonstrate that information and technology governance is systematic, traceable and aligned with enterprise objectives.
The compatibility is strongest when COBIT is used to design, assess and strengthen the governance and management controls required by the BTS operating model, rather than as a separate operating model BTS defines how business technology works. COBIT can help assess whether the governance system is complete, controlled and auditable.
This distinction helps avoid governance overload. If COBIT is implemented as a separate governance structure beside BTS, the organisation may create duplicate forums, controls and reporting. If COBIT is used to strengthen BTS governance, it improves control without weakening flow.
AI increases the relevance of COBIT-style assurance. AI-enabled services, automated decisions, data-driven operations and digital workers all increase the need for governance over information and technology. BTS connects AI governance to the operating model, roles, services and value creation. COBIT can strengthen control objectives, assurance questions and governance assessment around those capabilities.
The practical recommendation is to use COBIT as the governance, control and assurance expert practice that strengthens BTS Strategy and Governance. BTS provides the value creation governance model; COBIT helps ensure that governance and controls are robust enough for enterprise risk, compliance and assurance needs.
The TOGAF Standard is an expert practice for enterprise architecture. It provides architecture method depth, architecture governance concepts, architecture development practices and a shared professional language for enterprise architecture work.
BTS and TOGAF are compatible because enterprise architecture is a critical BTS capability. In BTS, enterprise architecture improves the structural quality of demand by ensuring that planned changes align with business capabilities, processes, data, solutions, platforms and architectural direction. It ensures that business capabilities, processes, data, solutions, platforms and ecosystems evolve coherently. It prevents local development decisions from creating long-term business technology debt.
TOGAF provides professional depth for the architecture community. It offers method, structure, architecture development practices, governance concepts and architecture artefacts. BTS does not need to replace these. Instead, BTS explains how architecture is used in the wider operating model.
The key BTS contribution is to connect architecture to demand and value. Architecture should not only document the current and target state. It should actively shape demand planning, value stream direction, business capability roadmaps, development initiatives, development requests and service lifecycle decisions. In BTS, architecture is not a separate expert activity that happens before or after value creation. It is part of the value creation flow.
This is especially important in the AI era. AI agents may carry business logic across applications, interact with users, use data from multiple systems and trigger operational actions. Enterprise architecture must define where business logic belongs, which systems remain authoritative, how data flows are controlled, how access is managed, and how AI-enabled capabilities remain interoperable and governed.
The practical recommendation is to use TOGAF as the enterprise architecture expert practice inside BTS. TOGAF strengthens the architecture method; BTS ensures that architecture actively guides business technology value creation.
IT4IT is an expert practice for the digital value chain and the management architecture behind digital product and service delivery. It is especially relevant when organisations want to improve the management system, tool landscape and information model that support end-to-end digital value creation.
BTS and IT4IT are compatible because both recognise that digital management must operate across a connected value chain. BTS defines the business technology operating model. IT4IT can help define the management system, information objects and tool architecture needed to run that operating model.
In many organisations, planning, development, release, service management, financial management and portfolio management are supported by separate tools. This creates fragmented data, weak traceability and manual reporting. BTS requires visibility across the full flow from business ambition to realised value. IT4IT can help design the management-tool and information architecture that supports this visibility.
The strongest compatibility is around operating model tools. BTS defines the capabilities, roles, governance points and end-to-end value creation flow. IT4IT can help structure how information moves across strategy, portfolio, requirement, development, release, service, request, incident and consumption records. It is especially useful when organisations want to implement BTS through integrated tool platforms and common information models.
IT4IT should not be treated as a replacement for BTS governance, roles or business ownership. It does not define the full business technology operating model in the BTS sense. Its value is strongest when used to design the digital backbone of management tools and data objects that make the BTS operating model operational.
The AI era increases the importance of this management backbone. AI agents and automation support governance, planning, development and service operations more effectively when the underlying management data is structured, connected and reliable. IT4IT can strengthen this digital management architecture. BTS defines what the operating model needs to achieve with it.
The practical recommendation is to use IT4IT as the digital value-chain and operating model tooling expert practice. BTS defines the value creation model; IT4IT can help design the tool and information architecture that makes the model visible and executable.
The most effective implementation approach is to start with BTS as the shared operating model and then place expert practices where they add depth.
First, define the BTS value creation flow. Clarify how business needs move from strategy and demand planning through development, release, service delivery and business value realisation. This gives all expert practices a shared context.
Second, define which expert practices are used in which capability areas. SAFe may be used for scaled agile development. ITIL may be used for digital product and service management practices. SIAM may be used for multi-provider service integration. COBIT may be used for governance and assurance. TOGAF may be used for enterprise architecture. IT4IT can help design the management-tool and information architecture that support this.
Third, map the terminology. An approved BTS development request authorises development and provides the business and governance context for execution. The authorised work may then be structured into project work packages, agile backlog items or other execution artefacts according to the chosen development model. A BTS backlog may map to team, product, project or service backlogs. A BTS service portfolio may be supported by ITIL service management practices and IT4IT information objects. The aim is not to standardise every word, but to ensure that the organisation understands how artefacts connect.
Fourth, avoid duplicate governance. If a SAFe portfolio forum, an ITIL change forum, a COBIT governance forum and a BTS steering forum all make related decisions separately, governance becomes fragmented. BTS should provide the shared governance logic, while expert-practice bodies should be connected, combined or clearly positioned where appropriate.
Fifth, keep business value visible. Expert practices often optimise their own domain: agile flow, service quality, architecture consistency, control maturity or tool integration. These are important, but they must remain connected to business outcomes. BTS keeps the focus on end-to-end value creation.
Finally, respect the intellectual property and licensing of each expert practice. Describing compatibility is not the same as reproducing protected materials, graphics, courseware, detailed method content or certification materials. Organisations should use official sources, accredited materials and appropriate permissions when implementing or training expert practices.
Leadership reflection
Do our expert practices strengthen one shared value creation flow, or have they become separate management systems with their own language, governance and priorities?
This chapter references third-party frameworks, standards and practices descriptively to explain their relationship with BTS. It does not reproduce proprietary framework graphics, detailed method content, training or certification materials, or protected publications.
Third-party names and marks remain the property of their respective owners. Their ownership and permitted use are governed by the current trademark, copyright and licensing terms of those owners. No endorsement, sponsorship or affiliation is implied. Official acknowledgement requirements should be verified against the relevant rights holder’s current guidance before publication.
SAFe® / Scaled Agile Framework® / AI-Native SAFe
SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile, Inc. SAFe materials, graphics, courseware and other protected content are subject to Scaled Agile’s applicable permissions, licensing and usage restrictions.
ITIL®
ITIL® is a registered trademark of PeopleCert International Ltd. ITIL materials, certification content and protected publications are subject to PeopleCert’s applicable terms, permissions and usage rules.
COBIT®
COBIT® is a registered trademark of ISACA. COBIT materials, framework content and related intellectual property are subject to ISACA’s applicable usage guidelines and permissions.
TOGAF® Standard
TOGAF® is a registered trademark of The Open Group. The TOGAF Standard is a standard of The Open Group and is subject to The Open Group’s applicable licensing and trademark rules.
IT4IT™ Standard
IT4IT™ is a trademark of The Open Group. The IT4IT Standard is a standard of The Open Group and is subject to The Open Group’s applicable licensing and trademark rules.
SIAM
SIAM is a trademark of EXIN. The SIAM Body of Knowledge is maintained by Scopism, and related materials and certification content are subject to the applicable rights and permissions of their respective owners.
