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

6 Requirement to Deploy (R2D) Value Stream

This chapter provides an overview of the Requirement to Deploy (R2D) Value Stream – one of four IT Value Streams that comprise the IT Value Chain. It describes the business context, objectives, and details behind the R2D Value Stream.

6.1 Objectives

The R2D Value Stream is designed to ensure predictable, cost-effective, high quality results to the business while also promoting high levels of re-use, flexibility, speed, and collaboration across IT to support traditional and new methods for service creation and sourcing.

Make service delivery predictable, even across geographically dispersed teams, multiple suppliers, and multiple development methodologies. Applications and services today are sourced or developed in cooperation with many different parties. All parties are working with their own processes and tooling. IT must be able to provide a good overview of the planned activities, should speak a common language with all parties involved, and should provide a methodology for how to achieve the highest quality results. Cloud sourcing, agile development, and other innovations have created the need for IT to be able to manage development and delivery of services in a hybrid or multi-sourced environment.

Ensure that each Service Release is high quality, fit-for-purpose, and meets customer expectations. IT still experiences too many incidents immediately after release of an application or service into production. IT must establish control over the quality of a service regardless of the number of vendors involved in development and/or delivery.

Understand the evolving relationship between planning and building. Historically, estimation has been framed as a trade-off, balancing a prior “planning” phase versus a later “building” phase. However, it is increasingly understood that planning in complex domains requires information only available through iterative attempts to fulfill requirements. In a sense, both planning and building must take place simultaneously in many cases.

Standardize service development and delivery to the point where re-use of service components is the norm. IT operations and development must ensure increased quality and speed of service delivery while also lowering costs. In support of these efficiency and quality goals, IT must have a framework in which to drive the re-use of existing service components at multiple stages of the development lifecycle across multiple applications and services. IT must work successfully with multiple internal and external contributors and be able to integrate the data, process, and tools required to work with geographically dispersed teams, outsourcers, and traditional and cloud-based suppliers. Furthermore, IT must maintain control of the governance of the R2D Value Stream and be able to track and measure internal and vendor performance, costs, quality, and on-time delivery. The ability to re-use requirements, source code, documentation, test scripts, service monitors, and other data objects of the service development lifecycle is a key contributor to managing cost, increasing quality and predictability, and accelerating release cycles.

Build a culture of collaboration between IT operations and IT development to support Service Release success. IT operations and development must improve collaboration between departments. Development organizations build and test services in a silo and “surprise” IT operations by “throwing release packages over the fence” for immediate delivery. IT operations may not be able to accommodate new technologies and environments fast enough to meet the requirements of developers. Inefficient manual processes are typical, and in high maturity shops are increasingly replaced by fully automated continuous delivery pipelines.

Put rigorous information management controls in place to lessen the impact of the IT reality – high staff turnover. High turnover in IT means knowledge is lost and schedules are impacted. Particularly in low-cost labor markets where employers are suffering high employee turnover rates. The R2D Value Stream helps capture the knowledge that would otherwise be lost and cause schedules to be delayed.

Drive predictable outcomes without driving out innovation. Innovation and process efficiency are two pillars of competitive advantage that IT departments bring to the business, yet these two pillars often have trouble co-existing. The emphasis on on-time project delivery tends to stifle innovation, creating a conflict between these two priorities. IT must continuously improve its ability to execute in such a way that on-time innovation is the norm. The R2D Value Stream identifies the core automation enablers and the key data exchanges required to accomplish this goal. For example, focusing efforts on automation of test, release, and deployment provides more time and resource for innovation in service design and development.

6.2 Business Value Proposition

The R2D Value Stream describes a prescriptive framework of required functional components and data objects so IT organizations can better control the quality, utility, schedule, and cost of services regardless of the delivery model.

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

—  Re-use – manage, maintain, and leverage re-usable IT components and services.

—  Automation – identify the core functional components and data required to streamline the R2D Value Stream.

—  Collaboration – use data to institutionalize collaboration of teams involved in the development lifecycle to expedite releases, and reduce incidents and rework that might otherwise result. This lays the foundation for new paradigms such as DevOps.

6.3 Key Performance Indicators

The R2D Value Stream critical success factors and Key Performance Indicators (KPIs) are as follows:

Critical Success Factors

Key Performance Indicators (KPIs)

Improve Quality

Number of escaped defects

% of actual versus planned executed tests

% of critical defects found early in unit testing versus UAT

Improve Project and Feature Execution

% of projects (project tasks, stories, other demand requests) on time

% of healthy projects (projects without unresolved urgent issues)

Deviation of planned to actual work hours

Number of identified issues

Number of opened risks

Amount of backlog/work-in-process

Arrival and departure rate for work

Improve Stewardship of IT Investment

% of actual versus planned project cost

% of change in project cost

% of budget at risk

Increase Automation Adoption

% of automated tests

Achieve Development Process Excellence

% of requirements tested, authorized, completed

% of requirements traced to tests

% of reviewed requirements

% of successful builds

% of changes resulting in Incidents

Ratio of detected to closed defects at release

Improve Early Life Success of Releases

% of Incidents during warranty period

% of successful/unsuccessful deployments for the project

% of emergency changes

Pass rates on UAT/validated requirements

Operations and Development Collaboration

Trend on early life support/UAT success metrics

% rework

Improve Financial Visibility

Planned cost versus actual cost

Maintain a Linkage between Business Services and IT Initiatives

Aggregate (roll up) service development costs by business service

High Quality Service Design Specifications at the Outset

% reduction in the rework required for new or changed service solutions in subsequent lifecycle stages

Integration Test Success

Trend on the number of installation errors in all the packages in the integration environment

Number of applications or services that require exceptions outside of the existing infrastructure portfolio

Design-Review to Ensure Application Design Complies with all Policies, including Security

Number of application designs that pass a security policy review

Early Testing of Applications for Security Vulnerabilities

% of severity 1 security defects fixed before application is released

6.4 Value Stream Definition

The Requirement to Deploy (R2D) Value Stream contains primary and secondary functional components. Primary functional components are core to the value stream and are essential for managing the service at this stage of its lifecycle. Secondary functional components are not dedicated to R2D but provide relevant data objects to primary functional components. The following functional components in the R2D Value Stream support the definition, development, and governance of the data objects and Service Model entities above:

The R2D Value Stream is process-agnostic in that while methods and processes may change (i.e., ITIL, COBIT, agile, waterfall, etc.), the functional components and data objects that comprise the value stream remain constant. The R2D Value Stream provides the framework for creating and sourcing a new or modifying an existing application or service. The R2D Value Stream is triggered if it receives a demand signal from a consumer or from other components such as Problem Management. This may take the form of an approved Scope Agreement and Conceptual Service from the S2P Value Stream, or may be a smaller grained signal such as an individual development story, user story, defect, problem, usage data, or scenario for a specific application or service. The R2D Value Stream ends when the requested service or modification is packaged for immediate or future deployment through an R2F Value Stream Fulfillment Execution functional component.

Figure 46: Requirement to Deploy Level 2 Value Stream Diagram

6.4.1 Project Functional Component

Purpose

Coordinate the creation and provide ongoing execution oversight of IT Initiatives aimed at the creation of new or enhancements to existing services. Create IT Initiatives based on the specifications outlined in the Scope Agreement, including cost, time, scope, and quality. Aggregate, track, and report status, resources consumed against project plan, or project burn down, and communicate these to stakeholders via auxiliary functional components such as Resource Management, Supplier Management, and IT Financial Management. Govern, coordinate, influence, and direct initiative execution. Ensure financial goals and boundary conditions are adhered to. Maintain the connection between initiatives and associated applications and service(s) being developed. Maintain the linkage/traceability between Scope Agreements, IT Initiatives, and Service Releases. Produce various request artifacts associated with financial, human, and technology resources (that is, feedback to the S2P Value Stream when variances cross thresholds). Coordinate the acquisition of resources (hardware, software, and people) required to source/create a service in a particular project.

Key Data Objects

Key Attributes

The IT Initiative data object shall have the following key data attributes:

Key Data Object Relationships

The IT Initiative data object shall maintain the following relationships:

Functional Criteria

The Project functional component:

Data Architecture Criteria

The Project functional component:

Model

Figure 47: Project Functional Component Level 2 Model

6.4.2 Requirement Functional Component

Purpose

Manage Requirements through the lifecycle of a service. Service-level requirements are captured as Requirements. Collect, refine, scope, and track progress of Requirements even before and after an IT Initiative has concluded. Maintain traceability of each Requirement to the original source (demand, IT or business standard or policy, and/or requestor) and to appropriate Source and/or Test Cases throughout the service lifecycle. Derive product or program backlogs which will ultimately serve as queues for enhancing IT services.

Key Data Objects

Key Attributes

The Requirement data object shall have the following key data attributes:

Key Data Object Relationships

The Requirement data object shall maintain the following relationships:

Functional Criteria

The Requirement functional component:

Data Architecture Criteria

The Requirement functional component:

Model

Figure 48: Requirement Functional Component Level 2 Model

6.4.3 Service Design Functional Component

Purpose

Identify the new or existing services required to meet the needs of the Scope Agreement and IT Initiative, including both service systems and service offers. Leverage the Conceptual Service and Portfolio Backlog Items from the S2P Value Stream along with requirements to produce a Logical Service that describes the service structure and behavior considering both the service system and the service offer. Create various architectural artifacts (data flow diagrams, technical schematics, etc.) that comply with the IT Initiative specifications and boundaries. Create the service design specification document (Logical Service Blueprint). Identify the service delivery model (in-source, outsource, etc.). Identify service suppliers to meet the requirements within the chosen delivery model. Enable interaction with IT operations to develop support plan/requirements for an IT service. Ensure that the architecture and Logical Service Blueprint are compliant with all standards and policies, including security standards and policies. Ensure that the architecture and Logical Service Blueprint meet all requirements including security requirements to ensure the confidentiality, integrity, and availability of the service. Put instrumentation in place so that IT can capture empirical data about how IT services are performing rather than relying only on anecdotal input from the user community. Ensure that the service is architected to meet the KPIs and SLAs. The output of the Service Design functional component is used by the Source data object to source, create, and secure the service. The traceability is done through the Requirement functional component.

Key Data Objects

Auxiliary Data Objects

Key Attributes

The Logical Service data object shall have the following key data attributes:

The Logical Service Blueprint data object shall have the following key data attributes:

Key Data Object Relationships

The Logical Service data object shall maintain the following relationships:

Functional Criteria

The Service Design functional component:

Data Architecture Criteria

The Service Design functional component:

Model

Figure 49: Service Design Functional Component Level 2 Model

6.4.4 Source Control Functional Component

Purpose

Develop source code or infrastructure based on the Logical Service Blueprint, Service Design Package, and IT Initiative priorities. Ensure that the source code meets the design specifications, organizational policies, standards, and non-functional requirements so that the service can be operated successfully and meets customer expectations. Manage the development backlog of Requirements and Defects in accordance with the Service Design Package and Service Release. Receive Defects and input from the Defect functional component to enable the development of fixes or documented workarounds. Create automated test scripts including unit testing and scripts for static application security testing that follow a formal software security assurance methodology. On existing services being changed, run security tests on core code to identify existing security issues at the start of the development cycle so that assessment of scope/requirements set/schedule can be negotiated early. Manage source code images and store them in a Source data object repository.

Key Data Objects

Note: Source does not always equal “source code”. Consider all use-cases such as “source code” for services produced on-premise, to contracts or entitlements for services simply subscribed to, to the purchase and implementation of a Commercial Off-The-Shelf (COTS) application.

Key Attributes

The Source data object shall have the following key data attributes:

Key Data Object Relationships

The Source data object shall maintain the following relationships:

Functional Criteria

The Source Control functional component:

Data Architecture Criteria

The Source Control functional component:

Model

Figure 50: Source Control Functional Component Level 2 Model

6.4.5 Build Functional Component

Purpose

Receive the Source data object from the Source Control functional component and manage the creation, implementation, automation, and security and storage of all Builds. Create Build from the Source data object for a particular service component. Automate the Build process to support the Build schedule and build frequency requirements in order to support daily Build and smoke test plans or continuous integration plans. Run dynamic application security testing no later than when the final Build data object is received and before the RFCs are created for moving the new or changed service into production. Manage Builds and versioning in a Definitive Media Library (DML). Develop automated Build storage procedures and automated compilation techniques and tools. Monitor and report on the results of each integration Build. Initiate or automate the delivery of Builds to the Build Package functional component for validation by the acceptance testing team as candidate release builds.

Key Data Objects

Key Attributes

The Build data object shall have the following key data attributes:

Key Data Object Relationships

The Build data object shall maintain the following relationships:

Functional Criteria

The Build functional component:

Data Architecture Criteria

The Build functional component:

Model

Figure 51: Build Functional Component Level 2 Model

6.4.6 Build Package Functional Component

Purpose

Create a deployable package made up of one or many Builds. Manage the Build Packages and relationships to the Service Release Blueprints.

Key Data Objects

Key Attributes

The Build Package data object shall have the following key data attributes:

Key Data Object Relationships

The Build Package data object shall maintain the following relationships:

Functional Criteria

The Build Package functional component:

Data Architecture Criteria

The Build Package functional component:

Model

Figure 52: Build Package Functional Component Level 2 Model

6.4.7 Release Composition Functional Component

Purpose

Manage the Release Package, Service Release, Service Release Blueprints, and overall Service Release for developing and delivering new or changed services to the R2F Value Stream Fulfillment Execution functional component to facilitate a smooth transition to IT operations. Create the Service Release, Service Release Blueprint, and Release Packages that will be utilized by the Test functional component and later the Fulfillment Execution functional component (R2F Value Stream) to create a specific deployment for a specific IT service instance (including service system and/or service offer). Begin the creation of monitors, batch processing, backup/restore, etc. for the service, to ensure supportability as part of IT operations enablement.

Manage the release artifacts within the Release Package by centralizing all elements of the Service Release Blueprint from the various functional components:

Key Data Objects

Key Attributes

The Service Release data object shall have the following key data attributes:

The Service Release Blueprint data object shall have the following key data attributes:

Key Data Object Relationships

The Service Release data object shall maintain the following relationships:

The Service Release Blueprint data object shall maintain the following relationships:

Functional Criteria

The Release Composition functional component:

Data Architecture Criteria

The Release Composition functional component:

Model

Figure 53: Release Composition Functional Component Level 2 Model

6.4.8 Test Functional Component

Purpose

Trace to Requirements. Plan and execute tests that ensure the IT service will support the customer’s requirements at the agreed service levels. Create Defect data objects that are consumed by the Defect functional component. Plan and design tests, including automated test scripts for both code images and monitors, using input from service development. Prepare the test environment. Execute tests, including functionality, usability, acceptance, risk-based security (dynamic application security and infrastructure security testing), performance, and stress testing. Create Defects found during testing which are consumed by the Defect functional component. Manage test data, drive automation, and re-use test automation and test scripts where appropriate. Provide test execution reports for the tested Requirements. Ensure that the operations tooling works as expected (monitors, etc.).

Key Data Objects

Key Attributes

The Test Case data object shall have the following key data attributes:

Key Data Object Relationships

The Test Case data object shall maintain the following relationships:

Functional Criteria

The Test functional component:

—  Functionality tests

—  Usability tests

—  Acceptance tests

—  Risk-based security tests (dynamic application security and infrastructure security testing)

—  Performance tests

—  Stress tests

Data Architecture Criteria

The Test functional component:

Model

Figure 54: Test Functional Component Level 2 Model

6.4.9 Defect Functional Component

Purpose

Keep track of all Defects; including their origin, status, importance, and relation to Requirements and Known Errors. Register Defects of all types (including security-related) with all relevant details such as description, severity, application version, related requirement, etc. Analyze Defects and find resolution. Associate Defects with Requirements. Document issues that should be communicated to the Release Composition functional component. Consume Defects from the D2C Value Stream Problem functional component as well as the Test functional component that are in turn consumed by the Source Control functional component for review and resolution. Update Defect details. Decide on target release. Report Defect status and provide Defect reports. Convert Defects not resolved by service development to Known Errors for Problem Management (D2C Value Stream) to document or develop work-around and report in knowledge management articles.

Key Data Objects

Key Attributes

The Defect data object shall have the following key data attributes:

Key Data Object Relationships

The Defect data object shall maintain the following relationships:

Functional Criteria

The Defect functional component:

Data Architecture Criteria

The Defect functional component:

Model

Figure 55: Defect Functional Component Level 2 Model

return to top of page

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