The Open Group IT4IT™ Reference Architecture, Version 2.1
Copyright © 2017 The Open Group, All Rights Reserved.

3 Overview

This chapter introduces the IT Value Chain and IT4IT Reference Architecture. Together these provide the foundation for IT where IT is the service broker to the lines of business.

3.1 What is the IT Value Chain?

A value chain is a series of activities that an organization performs in order to deliver something valuable, such as a product or service. Products pass through activities of a chain in order and, at each activity, the product gains some value. A value chain framework helps organizations to identify the activities that are especially important for competitiveness – for the advancement of strategy and attainment of goals. The IT Value Chain is grouped into two main categories of activities:

With services as the center of gravity, a value-chain based model for IT has been constructed by identifying the critical activities associated with the planning, sourcing, delivery, and management of services. The IT Value Chain content details the series of activities that every IT department performs that add value to a business service or IT service. The IT4IT Reference Architecture breaks these activities down further to a Service Model and the essential functional components and data objects that IT produces or consumes in the IT Value Chain in order to advance the service lifecycle.

Figure 2: IT Value Chain

The functional components in the IT Value Chain are grouped into four primary IT Value Streams and five supporting activities, as follows.

The primary value streams for the IT Value Chain are:

The primary activities are core to the IT function and have a vital role in helping to holistically run the full service lifecycle. These are usually hosted within IT.

The supporting activities for the IT Value Chain are:

The supporting activities help ensure the efficiency and effectiveness of the IT Value Chain and primary value streams. These can be corporate or administrative functions that are hosted in the lines of business and/or IT.

This standard defines the value streams, functional components, and associated data objects that are critical to the service lifecycle.

The guiding principles of the IT4IT Forum state that the framework shall:

3.2 IT Value Chain and IT4IT Reference Architecture

The IT Value Chain is the series of activities that IT performs to add value to a service. The IT4IT Reference Architecture breaks down the activities in the IT Value Chain into four key pillars for IT – the Service Model, the Information Model, the Functional Model, and the Integration Model. Together these provide the prescription for the essential elements that IT must control to manage a service through its lifecycle.

Each IT Value Stream is centered on an essential element of the Service Model and the constellation of key data objects (Information Model) and functional components (Functional Model) that support it. Together, the four value streams play a vital role in helping IT holistically manage the full service lifecycle:

Figure 3: IT Value Streams and Service Models

Each value stream encapsulates the capabilities that are necessary to manage the service lifecycle. These capabilities are realized as a set of functional components and data objects. Functional components are the smallest technology unit that can stand alone and be useful as a whole to a customer. Functional components must have defined input(s) and output(s) that are data objects and it must change or advance a key data object (e.g., state change). Data objects represent tangible, non-trivial data items that are owned, consumed, produced, or modified by the functional components. Key functional components drive core activities within a value stream. Auxiliary functional components are not dedicated to a single value stream and provide relevant data objects to key functional components. Typically, functional components control a single data object or Service Model entity.

Relationships between functional components are controlled through input and output data objects. While the IT4IT Reference Architecture supports various types of integration, this document focuses only on the data-centric integrations referred to as “system of record”. System of record integrations ensure the consistent management of the lifecycle for individual data objects, as well as ensuring that the data objects are consistently named and cross-linked through prescriptive data flows between functional components.

The IT Value Chain and IT4IT Reference Architecture are focused on which functional components and data objects are on the critical path for IT departments to have in place to manage the service lifecycle. The IT Value Chain context is not an exercise in improving IT processes, IT capabilities, or existing industry standard best practice models. Instead, the purpose of the value chain framework is to drill down into the supporting framework upon which those processes and capabilities run and then detail the key elements within and across the value streams that will become critical in the tooling required by IT. The processes in use may change but the underpinning data objects and functional components required to define, develop, and release a service remain the same. Ultimately, IT departments can leverage this functional component-based and data object-based model to define common tooling, drive more predictable quality and delivery, and ultimately realize these goals faster than trying to “go it alone”.

While the IT4IT Reference Architecture is represented as an end-to-end lifecycle, its actual implementation supports iterative development. There is no assumption that any given development initiative follows all steps in the lifecycle; a stable IT service platform may receive repeated iteration on the R2D lifecycle, for example.

3.3 IT Value Streams

The IT Value Chain describes the IT service lifecycle. That service lifecycle is captured in the four IT Value Streams. The functional components within each value stream are responsible for creating, refining, and tracking key data objects across the service lifecycle. The relationships between the data objects that pass between the four value streams during the service lifecycle are well defined.

The following sections provide a short overview of the primary IT Value Streams in the IT Value Chain. Chapter 5 through Chapter 8 provide detailed descriptions for each value stream.

Figure 4: Value Stream Overview

3.3.1 Strategy to Portfolio

The Strategy to Portfolio (S2P) Value Stream provides IT organizations with the optimal framework for interconnecting the different functions involved in managing the portfolio of services delivered to the enterprise. Activities such as capturing demand for IT services, prioritizing and forecasting investments, Service Portfolio Management, and Project Management require data consistency and transparency in order to maintain alignment between the business strategy and the IT portfolio.

Traditional IT planning and Portfolio Management activities put emphasis on capturing and tracking a collection of projects that represent the “orders” from the business for technology enablement. The S2P Value Stream places emphasis on the service and aims to provide a more holistic view of the IT portfolio to shape business investment decisions and connect IT costs with business value.

The key value propositions for adopting the S2P Value Stream are as follows:

Typical activities include:

Figure 5: Strategy to Portfolio Activities

The end-to-end IT portfolio view provided by the S2P Value Stream is accomplished by focusing on the service as the desired business outcome and exposing key data objects often unavailable using traditional planning methods. Defining the key data objects, the relationships between them, and their effect on the Service Models is core to the value stream approach. In addition, it provides inter-dependent functions such as Portfolio Demand, Enterprise Architecture, Service Portfolio, and Proposal functional components with data consistency and predefined data object exchanges in order to optimize the organization’s IT Portfolio Management and service lifecycle management capability.

3.3.2 Requirement to Deploy

The Requirement to Deploy (R2D) Value Stream provides the framework for creating/sourcing new services or modifying those that already exist. The goal of the R2D Value Stream is to ensure predictable, cost-effective, high quality results. It promotes high levels of re-use and the flexibility to support multi-sourcing. The R2D Value Stream is process-agnostic in that, while methods and processes may change, the functional components and data objects that comprise the value stream remain constant. Therefore, it is complementary to both traditional and new methods of service development like agile, SCRUM, or DevOps.

The R2D Value Stream consumes the Conceptual Service produced in the S2P Value Stream and through a series of design, development or sourcing, and testing functions enables the development of the Logical Service. The Logical Service is elaborated on until it represents a release that can be commissioned into a production state using standard deployment methods or in an on-demand manner using a user-driven catalog experience. Once deployed into a production state, the Physical Service Model is generated that is comprised of the physical elements that comprise the service.

The key value propositions for adopting the R2D Value Stream are:

Typical activities include:

Figure 6: Requirement to Deploy Activities

3.3.3 Request to Fulfill

The Request to Fulfill (R2F) Value Stream is a framework connecting the various consumers (business users, IT practitioners, or end customers) with goods and services that are used to satisfy productivity and innovation needs. The R2F Value Stream places emphasis on time-to-value, repeatability, and consistency for consumers looking to request and obtain services from IT. The R2F Value Stream helps IT optimize both service consumption and fulfillment experiences for users by delineating functions for an Offer Catalog and Catalog Composition. The R2F Value Stream framework provides a single consumption experience to consumers for seamless subscription to both internal and external services, as well as managing subscriptions and routing fulfillments to different service providers using the R2F Value Stream framework.

The R2F Value Stream plays an important role in helping IT organizations transition to a service broker model. Enterprise customers have been using external suppliers for goods and services for many years. The IT multi-sourcing environment will accelerate as companies adopt cloud computing offerings like Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).

The key value propositions for adopting the R2F Value Stream are:

Typical activities include:

Figure 7: Request to Fulfill Activities

3.3.4 Detect to Correct

The Detect to Correct (D2C) Value Stream provides a framework for integrating the monitoring, management, remediation, and other operational aspects associated with realized services and/or those under construction. It also provides a comprehensive overview of the business of IT operations and the services these teams deliver. Anchored by the Service Model, the D2C Value Stream delivers new levels of insight which help improve understanding of the inter-dependencies among the various operational domains; including Event, Incident, Problem, Change Control, and Configuration Management. It also provides the business context for operational requests and new requirements. The D2C Value Stream is designed to accommodate a variety of sourcing methodologies across services, technologies, and functions. This value stream understands the inter-relationships and inter-dependencies required to fix operational issues. It supports IT business objectives of greater agility, improved uptime, and lower cost per service.

The D2C Value Stream provides a framework for bringing IT service operations functions together to enhance IT results and efficiencies. Data in each operation’s domain is generally not shared with other domains because they do not understand which key data objects to share and do not have a common language for sharing. When projects are created to solve this, it is often too difficult and cumbersome to finish or there is an internal technology or organization shift that invalidates the result.

The D2C Value Stream defines the functional components and the data that needs to flow between components that enhance a business and service-oriented approach to maintenance and facilitates data flow to the other value streams.

The key value propositions for adopting the D2C Value Stream are:

Typical activities include:

Figure 8: Detect to Correct Activities

3.4 IT4IT Reference Architecture

The IT Value Chain is supported by the IT4IT Reference Architecture. The IT4IT Reference Architecture provides a prescriptive framework to support the value chain-based IT organization and service-centric IT management ecosystem. The service-centric IT management ecosystem comprises internal IT functions, external tool vendors, IT management improvement consultancies, external IT service providers (both XaaS and traditional consultancy and outsourcing services), external IT component provides (facilities, hardware, software, data), and training and certification providers. It can be thought of as describing the “IT for IT” (IT4IT) architecture and relationships.

Previous methods for creating an IT4IT Reference Architecture in the IT management domain have been oriented around processes, capabilities, and technology implementations. Unfortunately, processes can be implemented differently for each IT organizational archetype and capabilities are largely influenced by technology implementations. As a result, this architecture approach often results in a complex mesh of products and solutions requiring countless point-to-point integrations to accommodate the variations in process.

Instead, the IT4IT Reference Architecture approach for the IT Value Chain is anchored by four pillars – the Service Model, the Information Model, the Functional Model, and the Integration Model. These areas, when captured and modeled correctly, remain constant regardless of changes to process, technology, and/or capabilities.

3.4.1 Service Model

Without a clear understanding of both the business and technology attributes of a service, there is no way to be certain that the desired outcome can be consistently attained and that the most optimal sourcing strategy will be applied. The Service Model construct in the architecture captures, connects, and maintains these service lifecycle attributes as the service progresses through its lifecycle.

Traditional IT lifecycles are oriented around projects, used to govern technology deployments. Therefore, the plan, build, run lifecycle is the stalwart for most IT organizations and very little data is captured and maintained for a service. The provider/broker model for the new style of IT places its focus on services as the primary IT deliverable and requires a higher degree of flexibility, velocity, and adaptability. A service-centric lifecycle framework is one that supports a continuous cycle of assessing the portfolio, sourcing and integrating components, and offering services to consumers. This requires greater degrees of control over the data associated with a service in its various stages.

In addition, while traditional IT tends to place the majority of emphasis on delivery or implementation of technology resources, the service-centric IT must balance its focus on consumption and fulfillment of services along with the integration and delivery of the technology components and resources.

Figure 9: IT4IT Service Model

The structure that binds the different abstraction levels of the Service Model together is called the “Service Model Backbone” (shown in Figure 9). The Service Model Backbone provides the data entities, attributes, and necessary relationships between them to ensure end-to-end traceability of a service from concept to instantiation and consumption. This means that using this data-driven, model-based approach will ensure that what is required is actually what gets delivered or, in other words, what is offered will produce the outcome that the consumer desires. Further, it allows the IT organization to effectively utilize a service-centric approach in creating and packaging of its deliverables. This requires the creation of services from across resource and capability domains such as infrastructure, application components, database, middleware, monitoring, support, and so on. This enables the organization to improve their speed and consistency through higher re-use of pre-existing services and to embrace new technologies such as containers and micro-services in a more effective manner.

3.4.2 Information Model

The Information Model comprises the set of service lifecycle data objects and their relationships.

Each value stream produces and/or consumes data that together represents all of the information required to control the activities that advance a service through its lifecycle. This data has been referred to as “service lifecycle data objects” (data objects in short form) as of Version 2.0. Some data objects contribute directly to creating and/or advancing the Service Model while others serve as connectors, providing the linkage between functional components and across value streams.

Data objects have the following characteristics:

Service lifecycle data objects in the IT4IT Reference Architecture are grouped into two categories: key and auxiliary.

Data Object Type

Description

Symbol

Key Data Objects

Key data objects describe aspects of “how” services are created, delivered, and consumed; they are essential to managing the service lifecycle. Managing the end-to-end service lifecycle and associated measurement, reporting, and traceability would be virtually impossible without them. The IT4IT Reference Architecture defines 32 key data objects and most are depicted as black circles.

Service models are a stand-alone subclass of key data objects that describe “what” IT delivers to its consumers. They represent the attributes of a service at three levels of abstraction: Conceptual, Logical, and Realized. These data objects are referred to as Service Model Backbone data objects (or service backbone data objects in short form) and depicted using a purple colored circle in the IT4IT Reference Architecture diagrams. Note that the Logical Service Model is subdivided into a Design part, a Release part, and a Consumable part. Similarly, the Realized data object is represented with both a Desired and an Actual model part.

Auxiliary Data Objects

Auxiliary data objects provide context for the “why, when, where, etc.” attributes and, while they are important to the IT function, they do not play a vital role in managing the service lifecycle. The IT4IT Reference Architecture currently describes eight (8) auxiliary data objects and they are depicted using a gray colored circle.

The essential relationships between data objects within and across value streams are defined in the IT4IT Reference Architecture. These relationships function as a prescriptive guide for ensuring the integrity of the Service Model as it progresses through its lifecycle and facilitate traceability across value streams. The IT4IT Reference Architecture provides only the essential relationships and recognizes that there are other relationships that can exist but those are not part of the prescriptive guide. Within the IT4IT Reference Architecture, the relationship between data objects is annotated as follows:

Figure 10 provides an example of the relationship notation. The relationships and notation used here are for illustration purposes only and do not reflect the actual notation used or the relationship between these specific data objects.

Figure 10: Data Objects and Relationships

Notes

  1. Level 3 of the IT4IT Reference Architecture will utilize a full UML multiplicity specification for data object relationships (see Section 4.2).
  2. In the IT4IT Reference Architecture notation, the multiplicity is always written horizontally (e.g., 1:1 in Figure 10). In some cases, the related entities are depicted vertically. When this occurs the general rules of mathematics should be applied to determine the relationship. This means the left position number/letter relates to the entity that is left or upward and the right position number/letter relates to the entity right or downward.

3.4.3 Functional Model

Based on real IT scenarios and use-cases, the IT4IT Reference Architecture identifies and defines one of the essential building blocks – functional components – which create or consume data objects and can be aligned with the appropriate value streams. The Functional Model is the set of functional components and their relationships.

The context for functional components starts with an IT “capability”. A capability is the ability that an organization, person, or system possesses (function or activity it can perform) which produces an outcome of value through the utilization of a combination of people, process, methods, technology resources, and/or tools.

Functional components can be logically associated to IT capabilities for organizational clarity and will be underpinned with processes to drive uniformity and consistency.

While the definition of capabilities is used as a context for defining functional components, they are not the central focus within the IT4IT Reference Architecture. The documentation only refers to capabilities if there is a non-core capability that interacts with the architecture. In that case, using capability reduces the need to provide details for functional components and data objects that are outside the scope of the IT4IT Reference Architecture (for example, IT Financial Management).

Capabilities are supported by “building blocks” called functional components. A functional component is the smallest technology unit that can stand on its own and be useful as a whole to a customer. Functional components must have defined input(s) and output(s) that are data objects and must have impact on a key data object (for example, a state change). Functional components typically control a single data object. A grouping of one or more functional components represents the technology elements of an IT capability.

Capturing the architecture in this manner and constructing the ecosystem using this approach delivers on the agility promise and ensures end-to-end traceability by focusing on data rather than process as the design guide. Processes can change, organizational structures can shift (such as centralized/decentralized), and yet the Information Model remains constant and the architectural integrity of the IT management ecosystem is not compromised.

Functional Component Overview

Within the IT4IT Reference Architecture functional components are grouped into two categories: primary and secondary. In some of the IT4IT documentation primary functional components are also referred to as “key” and secondary as “auxiliary”. The consistency around naming will be improved in future releases.

Functional Component Type

Description

Symbol

Primary
Functional Component

A primary functional component is depicted using a blue colored rectangle and is core to a specific value stream. This means that the functional component plays a key role in the activities of a particular value stream. Without this functional component, the integrity of the data objects and thus the Service Model could not be maintained consistently and efficiently. Most IT4IT documentation will use language such as “a functional component is owned by or is core to a particular value stream” to represent a primary functional component.

Secondary Functional Component

Secondary functional components are depicted using a gray colored rectangle and represent some level of dependency or interaction with a value stream and its data objects. While they interact with a value stream, they are not core to it and are either primary to another value stream or supporting function or represent a capability.

Notes

  1. There are a few conditions when a functional component is core to or co-owned by more than one value stream (e.g., the Change Control functional component). When this occurs, the functional component is depicted using the blue colored rectangle in each value stream.
  2. There is a unique condition in the R2F Value Stream where a relationship exists between functional components that is user experience-driven rather than data-driven. It is expected that this condition will manifest itself in other areas as well. To capture this condition, an informal notation using a gray box with a black outline is utilized, as depicted in Figure 11.

Figure 11: Engagement Experience Portal Functional Component

The relationships and dependencies between data objects controlled by functional components are depicted using a solid line along with cardinality mapping. In addition to the entity relationships, functional components interact and exchange data to form the relationship. The data exchange between functional components is depicted using a dotted-line arrow to represent the direction of the flow.

Figure 12: Data Flows in the IT4IT Reference Architecture

While the IT4IT Reference Architecture depicts data flow and relationships between functional components, it does not advocate or prescribe processes that make this happen. The IT4IT Reference Architecture is process-agnostic in that it provides a prescriptive framework that remains constant regardless of whether an organization utilizes ITIL, COBIT, eTOM, or internally developed processes.

3.4.4 Integration Model

Integration between components in the traditional IT management ecosystem is based on capability and processes. The interfaces needed to accommodate the requirements associated with this approach are largely point-to-point between products to enable automation of inter-dependent workflows. Over time, this results in a complex web of connections that is virtually impossible to manage, making changes to any of the components a daunting task.

Figure 13: Engagement and Insight Information Flow

The IT4IT Reference Architecture defines an integration model composed from the following three types of integrations for simplifying the creation of an IT management ecosystem using functional components:

The Reference Architecture prescribes the essential data model relations needed to create end-to-end traceability across the functional components and value streams. Normally, such integration is accompanied by a system of record data flow.

Note: Often, in order to optimize the information linking systems that implement the functional components of the IT4IT standard, we will maintain more relational links to objects across the IT4IT landscape. In essence, these systems will try to maintain a transitive closure of all the relations that can have relevance to the function. As an example, the Actual Service object maintains a link to the accompanying Desired Service object. If investigating a Configuration Item in the Actual Service model, then in order to find the actual release this came from or what conceptual service it is part of, you need to trace back through the functional components that maintain these links. This can be optimized by keeping this closure stored with the actual service. In the IT4IT standard we do not prescribe this; we deliberately keep the prescriptive relationship model as small as possible. This is equivalent to standard database normalization practice.

3.5 IT Service

An IT service is a performance of an act that applies computing and information management competencies or resources for the benefit of another party. Every IT service has three aspects: the interaction between provider and consumer, the offer that exposes the value proposition to consumers, and the service system which is the people, process, and technology that facilitate the outcome.

Figure 14: IT Service

return to top of page

Copyright © 2017 The Open Group, All Rights Reserved.
IT4IT™ is a trademark of The Open Group
<<< Previous Home Next >>>