IT4IT Reference Architecture: IT4IT Reference Architecture – Tutorial (about 60 minutes)

The IT4IT Reference Architecture, today published by The Open Group as the IT4IT Standard, is a vendor-neutral blueprint for running the business of IT: it describes the value streams, functions and information an organisation needs to plan, build, deliver and operate digital products. Enterprise architects, CIO offices, IT operating-model designers, toolchain owners and product leaders use it to decide which capabilities and tools they need and how data should flow between them. After this tutorial you will be able to explain its value streams, read its layered architecture, trace a digital product through its data backbone and use IT4IT to rationalise a real IT toolchain.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: IT4IT is a standard of The Open Group, maintained by The Open Group IT4IT Forum. The edition listed on The Open Group publications site at the time of writing is The IT4IT Standard, Version 3.0.1 (document C24A, published 24 October 2024), a maintenance update that incorporates Technical Corrigendum 1 to Version 3.0 (October 2022) and supersedes it. Since Version 3.0 the document is titled "The IT4IT Standard" rather than "IT4IT Reference Architecture", but it still defines a reference architecture, now centred on managing digital products. Earlier editions were Version 2.0 (2015) and Version 2.1 (2017), whose four value streams are still widely quoted. After registering on The Open Group site you can download the PDF and HTML editions (plus an ArchiMate model file) under a free 90-day personal evaluation licence; continued internal use needs a free corporate or academic licence, and commercial use a paid licence. This tutorial teaches Version 3.x and explains the Version 2.1 vocabulary you will still meet in practice. Verified 2026-10-29; check the IT4IT library for any newer release before relying on edition details.

Who it is for: enterprise and solution architects, IT managers redesigning their operating model, people who own or select IT management tools (service management, DevOps pipelines, portfolio tools, monitoring), product owners in internal IT, and consultants who are asked to "align with IT4IT".

Prerequisites: none. Some familiarity with how an IT department works (projects or products, releases, a service desk, monitoring) helps. Knowing ITIL or TOGAF is useful but not required.

Learning objectives. After this tutorial you will be able to:

Explain the problem IT4IT was created to solve and why it is described as an information model rather than a process model.
Name the seven value streams of Version 3 and describe the outcome each one produces for a digital product.
Describe the five levels of abstraction and say which levels the standard defines.
Explain functional components, data objects and the backbone that links them, and why traceability matters.
Use IT4IT to map, assess and rationalise an organisation's IT management toolchain.
Describe the available certification for people and what "conformance" can and cannot mean for organisations and tools.
Position IT4IT next to ITIL 4, TOGAF, COBIT and agile scaling frameworks.

Lesson 1 – Origins, purpose and scope

The problem: IT runs a business without a shared blueprint

Every company with digital products is, in effect, running a business inside the business. Ideas are proposed and funded, software is designed and built, releases are deployed, consumers subscribe and ask for help, and live systems are monitored and fixed. Each of these steps is supported by tools: portfolio and demand tools, backlog and requirement tools, source control and build pipelines, test tools, deployment automation, service catalogues and request portals, service desks, monitoring and event platforms, configuration databases, cost and usage tools.

In most organisations these tools were bought one at a time by different teams. The result is familiar: the same concept (for example "the application" or "the service") is stored under different names in five places, nobody can say which release caused which incident, cost cannot be traced to products, and every new tool needs a custom integration. Process frameworks such as ITIL describe what people should do, but they do not tell an architect which information must exist, which system should own it, or how data should flow from planning to operations. That gap is what IT4IT addresses.

Where IT4IT came from

IT4IT started as a collaboration between several large enterprises, IT vendors and consultancies who wanted a common reference model for managing IT, in the same way that reference models already existed for other business domains such as telecommunications or supply chains. They handed their work to The Open Group, the consortium that also maintains TOGAF and ArchiMate, which launched the IT4IT Forum in 2014. The first Open Group standard, IT4IT Reference Architecture Version 2.0, followed in 2015, with Version 2.1 in 2017. Version 3.0, published in October 2022, re-centred the model on the digital product and introduced seven value streams; Version 3.0.1 (October 2024) is a maintenance release that folds in a technical corrigendum.

Figure 1 – The main milestones of the IT4IT standard, from the forum's launch to the current Version 3.0.1.

What IT4IT is, and what it is not

IT4IT is best understood as a reference architecture for the IT function. A reference architecture is a generic, reusable description of the building blocks a class of systems needs and of how those blocks relate. IT4IT describes three things for the "system" that manages IT itself:

the value streams that produce outcomes for consumers of digital products;
the functions (grouped into functional components) that must exist to support those streams;
the information (data objects) those functions create and exchange, and the relationships that keep it consistent.

The Open Group describes IT4IT as an information model and reference architecture that complements process frameworks. It deliberately does not prescribe workflows, job roles or organisation charts, and it is independent of any vendor, technology, methodology or organisational structure. You can run ITIL processes, Scrum teams, SAFe release trains or a DevOps platform model on top of it; IT4IT tells you what information and capabilities those ways of working depend on.

Scope

The scope is the entire lifecycle of digital products managed by an IT organisation (or by product teams in a business unit): from strategy and portfolio decisions, through design, build, test and deployment, to offering, subscription, usage, support and operation, and finally retirement. It covers products built in-house and those sourced from suppliers or cloud providers. It does not describe the business processes of the products themselves (how a bank lends money, for example); it describes how the bank's IT capability manages the digital products that support lending.

Why it matters to you

For an architect, IT4IT supplies a ready-made vocabulary and target model, so you do not have to invent one every time a toolchain is redesigned. For an IT leader, it explains where value and cost flow and which data is needed to make decisions. For a toolchain owner, it gives a neutral yardstick for comparing products and for deciding which system should be the authoritative source of which information. For everyone, it provides a way to talk about the IT function as a value-producing business rather than a cost centre.

Lesson 2 – Key concepts and vocabulary

IT4IT has its own vocabulary, and much of the learning curve is learning it. The terms below are explained in plain words; the standard itself gives the formal definitions.

Digital product – something an organisation offers that is enabled by information technology and delivers value to its consumers, for example a mobile banking app, an internal HR portal or a data platform. Version 3 makes the digital product the central object of management.
Value stream – an end-to-end sequence of activities that produces a recognisable result for a stakeholder. In IT4IT each value stream produces an outcome in the life of a digital product, such as an approved investment or a deployed release.
Value network – the Version 3 idea that value is not created in one straight chain but in a network of interacting value streams, internal teams, suppliers and partners that together deliver digital products (Version 2.1 spoke of an IT value chain).
Functional component – a technology-independent building block that provides a specific capability (for example managing a backlog, composing a release or detecting events). It is typically implemented by part of a software tool, but it is defined without reference to any product.
Data object – a defined kind of information that a functional component creates, owns or uses, such as a product backlog item, a release, an incident or a subscription.
Key data object – a data object that is essential for managing the lifecycle and for traceability across value streams; other data objects are supporting or auxiliary.
System of record – the single authoritative source for a given kind of data object. A core rule of IT4IT thinking is that each data object should be mastered by one functional component, even if many components read it.
Backbone – the chain of key data objects and relationships that represents a digital product from idea to running instance. Version 2.1 called it the service model backbone; Version 3 replaced it with a product backbone, which also connects to the offers and subscriptions that consumers hold.
Service offer – the consumable form of a product: what a consumer can request or subscribe to, under what terms. One product can have several offers (for example a standard and a premium tier).
Subscription – the record that a specific consumer is entitled to and is using a service offer, which in turn links usage, cost and support back to the product.
Product release – a defined version of a digital product, from a large feature release to a small patch, that is built, tested and made ready to deploy.
Desired and actual state – IT4IT separates what should be running (the intended configuration of a product instance) from what is actually running and observed. Comparing the two is the basis for automation, drift detection and incident diagnosis.
Level of abstraction – one of five layers at which the architecture is described, from a one-page overview down to a concrete, vendor-specific solution.
ArchiMate – The Open Group's enterprise architecture modelling language, used to express the IT4IT architecture diagrams and models.

Version 2.1 terms you will still meet

Many organisations, tool vendors and training materials still use the Version 2.1 vocabulary, so it is worth knowing it. Version 2.1 organised IT around four value streams, each named after the start and end point of the flow:

Strategy to Portfolio (S2P) – from strategy and demand to an approved, balanced portfolio of investments.
Requirement to Deploy (R2D) – from requirements to a tested release ready to deploy into production.
Request to Fulfill (R2F) – from a consumer request to a fulfilled, subscribed service, via a catalogue.
Detect to Correct (D2C) – from detecting an event or issue to diagnosing and correcting it in live operation.

These four are often summarised as plan, build, deliver and run. Version 2.1 also listed supporting activities that cut across them, such as governance, risk and compliance, sourcing and vendor management, finance and assets, intelligence and reporting, and resource and project management. Its backbone traced a service from a conceptual service (what the business wants) through a logical service (how it will be designed) to a realised service (what actually runs).

Lesson 3 – Structure of the standard

IT4IT Version 3 can be read as a set of nested views. At the top is the end-to-end life of a digital product, from investment decision to end-of-life. Below it sit seven value streams; below those, groups of functions and functional components; and threaded through everything, the data objects that form the backbone. The architecture is described at five levels of abstraction.

The seven value streams

Version 3 replaced the four broad streams of Version 2.1 with seven narrower value streams that together cover the life of a digital product. Each produces a distinct outcome:

Evaluate – continuously assesses the whole portfolio of digital products against business strategy, identifies opportunities and gaps, and decides where to invest, divest or rationalise.
Explore – works on one product's future: new features, ideas, experiments and direction, turning them into a prioritised backlog aligned with strategy and consumer needs.
Integrate – designs, builds, integrates and tests new product releases, from major versions to small fixes, until they are ready to deploy.
Deploy – puts a release into a production or operational environment, creating a new product instance or updating or removing an existing one.
Release – makes the deployed capability available to consumers by publishing service offers that describe how to subscribe and what they get.
Consume – covers the consumer's experience: finding offers, requesting and subscribing, using the product, getting support and eventually ending the subscription.
Operate – keeps deployed product instances running as intended: monitoring, detecting events, handling incidents and problems, restoring service and feeding defects back to development.

The streams are not a waterfall. Integrate, Deploy and Release can cycle many times a day in a continuous delivery setting, Operate continually feeds defects and insights back into Explore and Integrate, and Evaluate draws on information from all the others (cost, usage, quality, risk) to make portfolio decisions.

Figure 2 – The seven IT4IT Version 3 value streams, with the feedback loops that make them a network rather than a one-way chain.

From Version 2.1 to Version 3

The new streams are not a different world; they refine the old ones. Strategy to Portfolio corresponds broadly to Evaluate and Explore; Requirement to Deploy to Integrate and Deploy; Request to Fulfill to Release and Consume; and Detect to Correct to Operate. The correspondence is approximate: Version 3 moved emphasis from "services" to "digital products", added explicit product exploration, and made deployment a stream of its own (in Version 2.1, putting a release into production was partly handled through fulfilment in Request to Fulfill). It still helps when you have to translate an older IT4IT mapping into the current vocabulary. The Open Group's IT4IT FAQ also notes that the classic plan, build, deliver and run grouping has been modernised as plan, source, offer and manage.

Figure 3 – An approximate correspondence between the four Version 2.1 value streams and the seven Version 3 value streams.

Functional components and functional groups

Value streams say what outcome is produced; functional components say which capabilities must exist to produce it. A functional component is defined by its purpose, the data objects it masters and the data it exchanges with other components. In Version 2.1, typical examples were components for portfolio demand, proposals, requirements, source control, build, test, release composition, defects, offer management, request rationalisation, subscriptions, fulfilment execution, usage, event handling, incidents, problems, change control, configuration management, and diagnostics and remediation. Version 3 reorganised and renamed several of them around the digital product and arranges them in functional groups shown on its Level 1 diagram; read the current list in the standard itself rather than relying on counts quoted in older slides.

The important point for a beginner is not to memorise the list but to understand the design rule: each component has a clear responsibility, owns a defined set of data objects, and integrates with others through defined data flows. A commercial tool usually implements several components (a service management suite might cover incident, problem, change, request and configuration), and one component might be split across tools. Mapping tools to components is how IT4IT exposes overlaps and gaps.

Data objects and the backbone

The data model is the heart of IT4IT. Version 3 replaced the old service backbone with a product backbone of key data objects. For learning it, it helps to read it as two connected chains:

The product chain follows the product itself: the digital product, its backlog items, its releases and their designs, and the product instances in their desired and actual states.
The offer chain follows what consumers see: the service offers derived from a product and the subscriptions consumers hold, which in turn connect to usage, cost and support.

Because every key object links to the next, you can answer questions that are impossible in a fragmented toolchain: Which backlog items are in the release that was deployed yesterday? Which subscriptions are affected by this failing instance? How much did this product cost to run last quarter, and which offers generate that cost?

Figure 4 – A simplified view of how key data objects link a digital product to its releases, running instances, offers and subscriptions.

Five levels of abstraction

IT4IT describes its architecture at five levels, moving from generic to specific, a scheme carried over from Version 2.x. The standard defines the first three, which are vendor- and implementation-independent; levels four and five are where vendors and organisations add their own detail.

Level 1 – End-to-end overview: the value streams, functional groups, the main data objects and the backbone concepts on a single picture.
Level 2 – Value stream and functional detail: how each value stream works, which functional components support it and which data objects they exchange.
Level 3 – Detailed vendor-independent architecture: the functional components, data objects, their attributes and relationships, and the data flows between components; this is the level a tool mapping or integration design uses.
Level 4 – Vendor-specific refinement: how a particular product or vendor implements the Level 3 components.
Level 5 – Solution architecture: the concrete deployment in one organisation, with its chosen tools, configurations and integrations.

Figure 5 – The five IT4IT levels of abstraction: the standard defines the first three, vendors and adopters supply the last two.

How the document is organised

The standard is published as PDF and HTML editions, accompanied by the reference architecture as a model file in the ArchiMate Exchange File Format, which architecture tools can import. It introduces digital management and the overall model, describes each value stream, and details the functional components and data objects with the concepts (such as value stream, functional component, data object and abstraction level) that tie them together. You do not need to read it front to back: most practitioners start with the Level 1 overview, then read the value streams relevant to their problem, then go to Level 3 detail only for the components they are mapping.

Lesson 4 – How it works in practice

IT4IT is not "installed". It is used as a lens and a target model in a series of architecture activities. A typical adoption looks like the following sequence, which many organisations repeat in increments rather than doing once.

Step 1 – Frame the problem and the scope

Start from a business problem, not from the model: tool sprawl and licence cost, poor traceability between releases and incidents, slow onboarding of new products, inability to show cost per product, or audit findings about change control. Decide which value streams are in scope. Few organisations tackle all seven at once; Operate and Integrate are frequent starting points because their pain is visible.

Step 2 – Inventory current tools and data

List the tools that support IT management, who owns them and what information they hold. For each, record which kinds of record it creates (backlog items, builds, releases, incidents, configuration items, subscriptions, costs) and which other tools it exchanges data with. This inventory is often a revelation: three or four tools may each believe they are the master list of applications.

Step 3 – Map tools to functional components and data objects

Using Level 2 and Level 3 of the standard, map each tool to the functional components it implements and each data store to the data objects it holds. Mark overlaps (two tools mastering the same object), gaps (a required component with no tool) and broken links (a relationship in the backbone with no integration behind it). A simple heat map of components coloured by "covered once", "covered twice or more" and "not covered" is one of the most persuasive outputs of an IT4IT exercise.

Step 4 – Define the target architecture

Decide the system of record for each key data object, which tools to keep, consolidate or replace, and which integrations are needed to complete the backbone. Express the target in ArchiMate or another notation your architecture team uses. Because IT4IT is vendor-neutral, this target can be used to write tool requirements and evaluate competing products fairly.

Step 5 – Plan and deliver the transition

Sequence the changes in a roadmap of small, valuable increments: for instance, first link deployments to configuration records, then link incidents to the release that changed the instance, then link products to cost data. Each increment should improve a measurable outcome, such as mean time to restore service or the share of changes traceable to a backlog item.

Step 6 – Govern and improve

Keep the mapping current as tools change. Use the backbone to produce information for decisions: Evaluate needs product-level cost, usage, risk and quality data, which only exists if the earlier streams record it consistently. Revisit the model when the operating model changes, for example when moving from project funding to product funding.

Roles that typically use IT4IT

Enterprise or IT architects own the reference model, the mapping and the target architecture.
Toolchain or platform owners implement integrations and act as custodians of the systems of record.
Product owners and product managers rely on the backbone to see their product's backlog, releases, consumers, incidents and costs.
Service, operations and site reliability engineering teams use the Operate stream's data to detect and correct issues quickly.
Finance, procurement and governance staff use subscription, usage and asset data for cost transparency, sourcing and compliance.

Typical artefacts

A Level 1 "capability map" of the organisation's IT management, coloured by maturity or tool coverage.
A tool-to-component matrix and a data-object ownership table (which system masters which object).
Integration designs showing data flows between components, often derived from Level 3.
Tool requirements and evaluation criteria for procurement.
A transition roadmap with outcome measures.

IT4IT with agile, DevOps and product funding

Version 3's focus on digital products fits organisations that fund long-lived product teams rather than temporary projects. The Explore and Integrate streams accommodate continuous delivery: a release can be a single small change that flows through Integrate, Deploy and Release in minutes. The architecture does not care whether a human approves a change or an automated pipeline does; it cares that the change, the release and the instance it affects are recorded and linked. That is why IT4IT is useful when designing a DevOps toolchain: it tells you which links in the chain you will need when something breaks or an auditor asks how a change reached production.

Lesson 5 – Assessment, certification and compliance

Certification for people

The Open Group runs a knowledge-based certification programme for individuals. Its certification page lists an IT4IT Foundation certification based on Version 2.1 and an IT4IT 3 Foundation certification based on Version 3.0. Both test knowledge and comprehension of the standard's terminology, structure and basic concepts; the syllabus for each is published as a conformance requirements document. The conformance requirements also set the learning requirements for accredited training courses, which prepare candidates for the exam. Check the official certification page for the current exam format and prerequisites rather than relying on secondary sources.

A foundation certificate shows that someone understands the vocabulary and structure. It does not show that they can lead an IT4IT-based transformation; that depends on architecture experience, which is why many organisations pair the certificate with practical mapping work.

No certification of organisations

Unlike management-system standards such as ISO/IEC 20000-1 or ISO 9001, IT4IT has no scheme in which an accredited body certifies an organisation as "IT4IT compliant". IT4IT is a reference architecture: you use it to design and evaluate, not to pass an audit. If a supplier claims that an organisation or product is "IT4IT certified", ask exactly which programme, which version of the standard and which components the claim covers, and verify it on The Open Group's site.

Assessing your own alignment

Organisations still assess themselves against IT4IT, in three typical ways:

Coverage assessment – for each functional component and key data object in scope, is there a tool, a clear owner and a defined system of record? The output is the heat map described in Lesson 4.
Traceability assessment – can you follow the backbone end to end? Pick a sample of incidents and try to trace each one to the actual and desired instance, the release, the backlog items, the product and its offers and subscriptions. Every break in the chain is a finding.
Value stream assessment – for each value stream, how well does information flow, how much is manual re-keying, how long do hand-offs take, and which decisions lack data? Lean value stream mapping techniques work well here.

Some organisations attach maturity ratings to these findings; IT4IT does not mandate a maturity model, so if you use one, define its levels explicitly and keep it consistent between assessments.

Using IT4IT in tool selection

Because the Level 3 model is vendor-neutral, it is a fair basis for tool evaluation. Write requirements in terms of components, data objects and integrations ("the solution must master release records and expose them to the deployment component"), then ask vendors to show how their products implement them. Vendors sometimes publish their own Level 4 mappings; treat these as claims to verify in a proof of concept.

Compliance and audit benefits

IT4IT is not a compliance framework, but a well-implemented backbone makes compliance easier. Auditors of change management, software supply chain security or financial controls often ask for evidence that a production change was authorised, tested and traceable to a requirement. With linked data objects, that evidence is a query rather than a week of spreadsheet work.

Lesson 6 – Worked example

Northwind Freight is a fictional logistics company with about 600 IT staff. Its customers use a shipment-tracking app, its warehouses run an inventory platform, and dozens of internal applications support finance and HR. Leadership wants three things: show the cost of each digital product, halve the time to restore service after major incidents, and cut spending on overlapping IT management tools. The chief architect proposes using IT4IT as the reference model.

Step 1 – Problem and scope

The team scopes the first phase to Integrate, Deploy and Operate for three customer-facing products, with Evaluate added later for the cost goal. It records baseline measures: average time to restore service for major incidents, number of tools in the IT management landscape, and the share of incidents linked to a known change.

Step 2 – Inventory

The inventory finds 41 tools. There are two backlog tools, three CI pipelines, two deployment tools, a service management suite, four monitoring tools, two configuration databases that disagree with each other, and a spreadsheet that finance uses to allocate cloud costs to applications. No tool holds a definitive list of digital products; the term "application" means something different in each.

Step 3 – Mapping

Architects map each tool to IT4IT functional components and data objects. The heat map shows overlaps in source control, build and monitoring, a gap in a product-level catalogue, and a broken backbone: deployments are not recorded against configuration items, so when the tracking app fails the operations team cannot see which release changed it. Incidents are linked to a change in only about one in five cases.

Step 4 – Target architecture

The team decides that:

a single product register becomes the system of record for digital products, and every other tool references its product identifier;
one pipeline platform masters builds and releases, and two of the three CI tools are retired;
the deployment tool records each deployment against the desired product instance and updates the configuration database automatically, which becomes the single system of record for actual instances;
monitoring events are correlated to actual instances and from there to the last release;
cloud billing data is tagged with product identifiers so that cost can be attributed by product and later by service offer.

Step 5 – Transition

The roadmap runs in four quarterly increments. Increment one creates the product register and adds product identifiers to pipelines. Increment two automates deployment records. Increment three adds event-to-instance correlation and links incidents to the most recent change. Increment four connects cloud billing to products and produces a first product cost report for the Evaluate stream.

Step 6 – Results and governance

After a year, Northwind has retired several overlapping tools, most major incidents are now linked to the change that preceded them, and restore times have fallen because the on-call engineer can see the last release and roll it back. The first product cost report surprises the portfolio board: an internal reporting tool costs more to run than the customer app. In the Evaluate stream the board decides to consolidate it. An architecture review board now checks every new tool proposal against the IT4IT component map before purchase.

Notice what IT4IT did and did not do. It did not tell Northwind how to run incident management or how to organise its teams. It supplied a neutral model of the capabilities and information needed, which made overlaps and gaps visible and gave a shared language to architects, operations, finance and vendors.

Lesson 7 – Relationship to other standards and frameworks

IT4IT is designed to sit alongside other frameworks. Most confusion comes from treating it as a competitor to ITIL; it is better seen as the information and architecture layer beneath the processes and practices that other frameworks describe.

Framework	Owner	Main focus	How it relates to IT4IT
ITIL 4	PeopleCert (Axelos)	Service management guidance: service value system, value chain and practices	Complementary. ITIL describes practices and ways of working; IT4IT describes the functions and data those practices need and how tools should integrate.
TOGAF Standard	The Open Group	Method and content framework for enterprise architecture	TOGAF is the method an architect can use to develop the IT function's architecture; IT4IT is a ready-made reference architecture for that particular domain.
ArchiMate	The Open Group	Modelling language for enterprise architecture	The notation used to express IT4IT models; teams often model their IT4IT mapping in ArchiMate tools.
COBIT	ISACA	Governance and management objectives for enterprise information and technology	COBIT says what must be governed and controlled; IT4IT helps design the capabilities and data that produce the evidence COBIT-based assessments look for.
SAFe and other agile scaling frameworks	Scaled Agile and others	Organising teams, portfolios and delivery at scale	Define roles, events and flow for delivery; IT4IT supplies the information model for portfolio, backlog, release and operations data underneath.
ISO/IEC 20000-1	ISO and IEC	Certifiable requirements for a service management system	Organisations can be certified against ISO/IEC 20000-1; IT4IT can inform the toolchain and data architecture that supports such a system.
Digital Practitioner Body of Knowledge	The Open Group	Skills and practices for digital product work	A sibling Open Group standard on the people and practice side of digital delivery; IT4IT covers the architecture side.

Choosing a combination

A common pattern is: COBIT or a similar framework for governance, ITIL 4 or a DevOps model for ways of working, TOGAF as the architecture method, ArchiMate as the notation and IT4IT as the reference architecture for the IT function's tools and data. The frameworks overlap in places, so decide explicitly which one is authoritative for which question, and keep the terminology consistent (for example, decide whether you say "service", "product" or both, and what each means in your organisation).

IT4IT and value stream thinking

IT4IT's value streams share ideas with lean and flow-based approaches such as value stream management. The difference is level: value stream management tools measure flow in a specific delivery pipeline, whereas IT4IT gives the generic model that tells you which value streams and data exist in the first place. They work well together: the IT4IT backbone provides the linked data that flow metrics depend on.

Common pitfalls and best practices

Pitfalls

Treating IT4IT as a process framework. Teams try to "implement IT4IT processes" and are disappointed that the standard does not define workflows. It defines functions and information; processes come from ITIL, DevOps or your own practice.
Boiling the ocean. Mapping every component and data object across all seven value streams before delivering anything burns goodwill. Start with one painful problem and a few streams.
Buying a tool to "get IT4IT". No single product makes an organisation aligned. Alignment comes from clear ownership of data objects and working integrations across the whole toolchain.
Ignoring the data model. Drawing value stream pictures without deciding systems of record and links produces posters, not improvement; the backbone is where the value is.
Using out-of-date vocabulary without saying so. Mixing Version 2.1 names (S2P, R2D, R2F, D2C) with Version 3 names confuses stakeholders. State which version your models follow.
Treating the model as fixed. Adopters forget that levels four and five are theirs to define; copying a vendor's Level 4 mapping as if it were the standard hides real design decisions.

Best practices

Anchor on outcomes. Tie every IT4IT activity to a measurable result such as restore time, traceability rate, tool cost or product cost transparency.
Name a system of record for each key data object. Publish the ownership table and enforce it in tool decisions and integration designs.
Use the digital product as the organising identifier. Make a product register the reference point that other tools link to.
Work incrementally. Deliver one backbone link at a time and measure its effect before moving on.
Use IT4IT as a neutral procurement yardstick. Express tool requirements as components, data objects and integrations, then verify vendor claims in a proof of concept.
Combine it with the frameworks you already use. Keep ITIL or DevOps practices for the work itself and use IT4IT for architecture and data.
Keep the map alive. Review the component map whenever a tool is added, retired or upgraded, and through an architecture review board.

Summary and key takeaways

IT4IT is The Open Group's vendor-neutral reference architecture for managing the business of IT; the current edition is The IT4IT Standard, Version 3.0.1 (2024).
It is an information model and architecture, not a process framework: it describes value streams, functions and data, and complements ITIL, DevOps and agile ways of working.
Version 3 centres everything on the digital product and uses seven value streams: Evaluate, Explore, Integrate, Deploy, Release, Consume and Operate.
Version 2.1's four streams, Strategy to Portfolio, Requirement to Deploy, Request to Fulfill and Detect to Correct, are still widely used and map approximately onto the seven.
Functional components provide capabilities and master data objects; the product backbone links those objects, from product to release, instance, offer and subscription, for end-to-end traceability.
The architecture has five levels of abstraction; the standard defines Levels 1 to 3, vendors and adopters define Levels 4 and 5.
Individuals can earn IT4IT Foundation certifications; there is no certification of organisations.
Practical value comes from mapping tools to components, naming systems of record and closing breaks in the backbone, one outcome at a time.

Reflection questions

List the IT management tools your organisation uses. Which IT4IT value streams does each support, and where do you suspect overlaps or gaps?
Pick a recent major incident. How far could you trace it along the backbone (instance, release, backlog item, product, subscriptions), and where did the trail break?
For your organisation, which kind of record do at least two tools each treat as authoritative, and how would you decide which one should be the system of record?
If your company moved from project funding to long-lived product teams, which IT4IT value streams and data objects would become more important, and why?
How would you explain to an ITIL practitioner what IT4IT adds to the practices they already run, using one concrete example from your environment?