Copyright © 2015 The Open Group
| < Previous | ▲ Home | Next > |
|
IT4IT Reference Architecture, Version 2.0 Technical Standard Copyright © 2015 The Open Group |
|
This chapter introduces the IT Value Chain and IT4IT Reference Architecture. Together these provide the foundation for an IT operating model where IT is the service broker to the lines of business.
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:
• Primary activities, which are concerned with the production or delivery of goods or services for which a business function, like IT, is directly accountable.
• Supporting activities, which facilitate the efficiency and effectiveness of the primary activities.[3]
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:
• Strategy to Portfolio
• Requirement to Deploy
• Request to Fulfill
• Detect to Correct
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:
• Governance Risk & Compliance
• Sourcing & Vendor
• Intelligence & Reporting
• Finance & Assets
• Resource & Project
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:
• Be flexible enough to support frequent changes in business models while sturdy enough to track compliance and cost controls.
• Be defined in practical terms for immediate application in “real-world” IT environments.
• Be able to be implemented in a phased approach that avoids any requirement for “rip and replace”.
• Be technology and vendor-agnostic.
• Be accessible to anyone who wishes to make use of it. This provides the opportunity for IT departments to work towards the same standard and to benchmark performance data against a body of data from all participants.
• Be, wherever possible, complementary to current industry standard best practices.
The IT Value Chain is the series of activities that IT performs to add value to a business service or IT 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:
• The Strategy to Portfolio (S2P) Value Stream receives strategic demands for new or improved services from the business or IT itself and develops the Conceptual Service Blueprint to represent the new or enhanced business/IT service that is requested. The Conceptual Service Blueprint is the bridge between business and IT in that it provides the business context for the service along with the high-level architectural attributes.
• The Requirement to Deploy (R2D) Value Stream receives the Conceptual Service Blueprint and designs and develops the Logical Service Model with more detailed requirements that describe how the newly requested business/IT service and its components shall be designed. The Logical Service Model can be thought of as what is traditionally expressed in IT terms as the “system design”. The Logical Service Model together with the Service Release make up the Logical Service Blueprint. The R2D Value Stream builds, tests, and delivers the deployable service (Service Release Blueprint) to the R2F Value Stream.
• The Request to Fulfill (R2F) Value Stream receives the Logical Service Blueprint after it has gone through development, test, and release approval. For repeatedly consumable services, the R2F Value Stream is responsible for the tasks to transition the service into production and make it consumable by the business including creating the Service Catalog Entry.
• 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.
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.
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
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:
• Establish a holistic IT portfolio view across the IT PMO, and the Enterprise Architecture and Service Portfolio functional components so IT portfolio decisions are based on business priorities.
• Use well-defined system of records between the key areas that contribute to the IT Portfolio Management function to support consistent data for accurate visibility into business and IT demand.
• Endorse a Service Model that provides full service lifecycle tracking through conceptual, logical, and physical domains so it is possible to trace whether what was requested actually got delivered.
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.
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 Blueprint produced in the S2P Value Stream and through a series of design, development, and testing functions enables the development of the Logical Service Model for the service. The Logical Service Model 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:
• Ensure that the Service Release meets business expectations (quality, utility).
• Make service delivery predictable, even across globally dispersed teams and suppliers, and multiple development methodologies while preserving innovation.
• Standardize service development and delivery to the point where re-use of service components is the norm.
• Build a culture of collaboration between IT operations and development to improve Service Release success.
Typical activities include:
Figure 6: Requirement to Deploy Activities
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:
• Provide a portal and catalog blueprint for facilitating a service consumption experience that allows consumers to easily find and subscribe to services through self-service, regardless of sourcing approach.
• Establish the model for moving from traditional IT request management to service brokerage.
• Increase fulfillment efficiency through standard change deployment and automation.
• Leverage the common Service Model to reduce custom service request fulfillments and design automated fulfillments.
• Facilitate a holistic view and traceability across service subscription, service usage, and service chargeback as applicable.
Typical activities include:
Figure 7: Request to Fulfill Activities
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:
• Timely identification and prioritization of an issue.
• Improved data sharing to accelerate ability to understand the business impact.
• Automation both within domains and across domains.
• Ensuring an operating model, capabilities, and processes that can handle the complexity of service delivery across multiple internal and external domains.
• Effective linkage of Events to Incidents to Problems to Defects in the R2D Value Stream.
Typical activities include:
Figure 8: Detect to Correct Activities
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 operating model 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.
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.
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.
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 in prior releases of the IT4IT Reference Architecture as “service lifecycle artifacts”; however, as of Version 2.0 the term “service lifecycle data objects” (data objects in short form) has been adopted. Throughout the documentation there may still be some use of the term artifact, but when this occurs it should be interpreted as data object. 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:
• They describe an aspect of an IT service.
• They are inputs or outputs associated with an IT4IT functional component or a service lifecycle phase.
• They are uniquely identified, and have a lifecycle of their own.
• They maintain structured information that allows for relationship tracking and automation.
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. |
|
|
|
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:
• 1 to 1 (1:1): implies that if there is a relationship, it is between two data objects. It does not imply that there will always be a relationship. For example, Events without Incidents or Incidents without Events are legitimate scenarios.
• 1 to many (1:n): implies that one data object relates (A) to one or more other data objects (B...) in scenarios where there is a relationship.
• Many to many (n:m): implies that both and A and B above can relate to zero, one, or many of the connected data objects.
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.
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 |
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 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 uniqe 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.
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:
• System of record integrations (data-centric integration, SoR in short form): These entity relationship definitions 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 to maintain the integrity of the Service Model. They are represented by a dotted black line like the one in Figure 13.
• System of engagement integrations (experience-centric integration, SoE in short form): These are user interface integrations derived from value stream use-cases and user stories. These integrations deliver the technology underpinning for a capability by combining several functional components into a single user experience to facilitate human interaction with data objects. In the IT4IT Reference Architecture system of engagement integrations are represented by the blue arrow in Figure 13. In the actual notation, system of engagement integrations are depicted using a dotted blue line.
• System of insight integrations (intelligence, analytics, and KPI-centric integrations, SoI in short form): These are data-centric integrations driven by the need to provide traceability, end-to-end visibility, transparency, and to capture measurements related to services (for example, performance) or the service lifecycle (for example, fulfillment time). Further, these integrations can accommodate the exchange of both structured and unstructured data that is created across the value chain. System of insight integrations are represented by the gray arrow in Figure 13. The actual notation for system of insight integrations has not yet been defined as the architecture to support them will be developed in future releases. Therefore, while this integration is mentioned here, they do not appear in the current version documentation.
| < Previous | ▲ Home | Next > |
