-
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
IT organizations today experience challenges in planning, sourcing, developing, and delivering applications and services that generate desired business outcomes. 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.
Key objectives to meet in support of giving the business what it needs are to:
• 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. The R2D Value Stream provides a framework that can accommodate everything including:
— Contracts for Software as a Service (SaaS)/Subscription services
— Fast, lightweight application releases such as mobile applications or those built using agile methodologies (for example, SCRUM, extreme programming)
— Traditional applications that utilize more structured project-driven release cycles
— Everything in between
• 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:
• Maximize the pipeline of projects and smaller grained demand requests for faster time-to-market in service realization.
• Predictable outcomes that ensure that the application or service delivered actually performs as requested, leading to higher rates of user acceptance and better business alignment.
• Establish control points to manage the quality, utility, security, and cost of services, independent of development method or delivery source.
• Increased management information for traceability and benchmarking of internal and external service developers and suppliers.
• Ensure that all services are designed in accordance with standards and policies (from sources including Corporate Compliance, Enterprise Architecture, Risk Management, IT Financial Management, and so on).
• Improved inputs to IT Financial Management on service cost.
• Relate applications and services with business value by creating and maintaining the service blueprint.
• Accelerate the sourcing and delivery of applications and services through best practices such as:
— 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 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 Blueprint 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.
Successful execution of the R2D Value Stream is dependent on the following key data objects:
• Scope Agreements, which originate from the S2P Value Stream and provide budget, cost/benefit projects, sizing/scoping of efforts, and other key attributes for proposed work.
• Conceptual Service Blueprints, which are generated and managed in the S2P Value Stream and provide the business view of the desired service or application including processes, architectural data objects, and other information.
• Portfolio Backlog Items, which are stored and managed in the S2P Value Stream and provide details on development needs that have not yet been met.
• Standards & Policies, which originate from the S2P Value Stream where the growing body of guidelines and best practice requirements are captured from IT and the business.
• Problems, which are generated from the D2C Value Stream and create one or many Defects.
The inputs above are assessed, rationalized, and elaborated with more detail and ultimately become content that is consumed and produced in the R2D Value Stream. The following are the key data objects and Service Model entities utilized in the R2D Value Stream:
Build
A Build is the assembly of Source. The term is also used to refer to a Build that is authorized for distribution; for example, software build, server build, or laptop build.
Build Package
A collection of one or more Builds together which will be included as part of a Release Package.
Defect
A flaw in a component or system that can cause the component or system to fail to perform its required function, such as an incorrect statement or data definition. A Defect, if encountered during execution, may cause a failure of the component or system.
IT Initiative
A temporary endeavor with a defined beginning and end undertaken to achieve an objective or outcome at a certain cost. In the context of the IT4IT Reference Architecture, the typical initiative outcome is the delivery of a new service or modification of an existing service or application.
Logical Service Blueprint
Provides the structure and behavior and design for the components that make up a new or changed service and describes how those components relate to one another. The Logical Service Blueprint can be thought of as what is traditionally expressed in IT terms as the design. The Logical Service Blueprint together with the Service Release and Service Release Blueprint make up the Logical Service Model. Along with the service design data objects, the Logical Service Blueprint introduces the “how” details; i.e., technology delivery methods (on-premise versus SaaS), and the technical interfaces necessary to access the service functionality.
Release Package
A collection of one or more Build Packages together with a Service Release Blueprint which describes how the Build Packages can be deployed (as one Build Package may exist for the app server, for the database, and for the front end). A Release Package might also contain other release objects that are not the result of a build process such as training material, Known Errors, or Run Books.
Requirement
A formal statement of what is needed. Such a statement identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a user. A product backlog or program backlog can be derived from requirements.
Service Design Package
Provides the necessary details that describe the design of the IT service, at least sufficient to a given stage in its development. It may be iteratively refined.
Service Release
Describes a specific release of an IT service which could include changes to the service systems and/or service offers for that IT service. One Service Release is defined by complying with a single Logical Service Blueprint. A new Service Release must be established whenever the Logical Service Blueprint for a service changes. A service is released according to a release schedule and cadence (e.g., annual, quarterly, daily) and communicates to external stakeholders of new functionality, improvements, and defect fixes as well as existing problems. A Service Release includes attributes such as a release manifest (that includes underlying technology details), description, dependencies, and one or more Service Release Blueprints (see below).
Service Release Blueprint
Provides the design for the components of an IT service. It contains the description and procedures in order to activate, deploy, and operate a service and its underlying components including applications and technology. Typically, there will be multiple blueprints for each Service Release deployed onto different environments such as development, QA, and production. This distinction is also useful to distinguish between delivery mechanisms, such as on-premise versus cloud.
Source
Represents all kind of sources used within the build process or packaged into a Build to make up an application or service. This may include but is not limited to: build scripts, configuration files, localization files, licenses and entitlements to external services, code in programming languages, code of monitors, HTML, CSS, and JS.
Test Case
One or a set of Test Cases (manual or automated) which contain a set of input values, execution preconditions, expected results, and execution post-conditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement. A Test Case is developed based on a Requirement or a Defect and the same Test Case can be applied across many releases.
The following functional components in the R2D Value Stream support the definition, development, and governance of the data objects and Service Model entities above:
• Build: Create, manage, secure, and track Builds. Implement Build automation. Manage the delivery of Builds to the Build Package component.
• Build Package: Manage and store one or more Builds in a deployable package.
• Defect: Keep track of all Defects, including their origin, status, importance, and relation to Requirements and Known Errors.
• Project: Receive Scope Agreements and coordinate the creation and provide ongoing execution oversight of IT Initiatives aimed at the creation of new or enhancements to existing IT services.
• Release Composition: Keep track of the different Service Releases, define the structure and content of the Service Release and its underlying components, including the instructions of how each component can be deployed.
• Requirement: Manage Requirements through the lifecycle of the service. Maintain traceability of each Requirement to the original request that generated the Portfolio Backlog Item throughout the service lifecycle. Collect, refine, scope, and track progress of Requirements. Provide views into product or program backlogs and team backlogs as a subset of the Requirements.
• Service Design: Create the Logical Service Blueprint for the service(s). Ensure these meet the requirements from the Scope Agreement, IT Initiative, and/or Portfolio Backlog Item and make it perform against the Key Performance Indicators (KPIs), Key Risk Indicators (KRIs), and Service-Level Agreements (SLAs). The output of the Service Design functional component is used by the Source data object to guide source, create, and secure the service.
• Source Control: Ensure that the service is developed in accordance with design specifications, organizational standards and policies, and both functional and non-functional requirements so that the service can be operated successfully and in line with customer expectations and requirements. Produce and manage source and documentation which is stored.
• Test: Plan, store, and execute tests which ensure that the service will support the customer’s requirements at the agreed service levels, including system/integration testing, user acceptance testing, performance testing, and load testing.
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.
Figure 45: 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
• IT Initiative (data object): Details the scope of the work to be performed and created from and associated with the Scope Agreement.
Key Attributes
The IT Initiative data object shall have the following key data attributes:
• ITInitiativeID: Unique identifier of the effort/initiative.
• ITInitiativeName: Full name of the effort/initiative.
• ITInitiativeStatus: Status of the effort/initiative.
• ServiceReleaseID: Identifier of one or more Service Releases.
• RFCID: Identifier of one or more RFCs.
• ScopeAgreementID: Unique identifier of the related Scope Agreement.
Key Data Object Relationships
The IT Initiative data object shall maintain the following relationships:
• Scope Agreement to IT Initiative (1:n): Maintain a linkage between the proposal which authorized one or more IT Initiatives.
• IT Initiative to Service Release (1:n): An IT Initiative will manage the creation of one or more Service Releases required to deliver the IT Initiative.
• IT Initiative to Request for Change (RFC) (1:n): An Initiative will be related to one or many RFC records in order to manage all changes resulting from a single work effort (initiative).
Main Functions
The Project functional component:
• Shall be the system of record (authoritative source) for all IT Initiatives.
• Shall manage the lifecycle of the IT Initiative.
• Shall manage the status of the IT Initiative.
• Shall allow recursive relationships between IT Initiatives.
• Shall associate an IT Initiative to a service.
• May associate an IT Initiative with IT budget in the IT Financial Management supporting function.
If a Change Control functional component exists, the Project functional component:
• Shall associate an IT Initiative to one or more RFCs.
• Can submit one or more RFCs required for the IT Initiative.
If a Fulfillment Execution functional component exists, the Project functional component:
• Can manage the Fulfillment Request data flow to the Fulfillment Execution functional component.
• Can send a request to the Fulfillment Execution functional component when resources are required for the IT Initiative.
If a Proposal functional component exists, the Project functional component:
• Shall associate a Scope Agreement to one or more IT Initiatives.
• Shall be able to receive the Scope Agreement from the Proposal functional component.
If a Service Design functional component exists, the Project functional component:
• Can provide IT Initiative information required for Service Design to the Service Design functional component.
Model
Figure 46: 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
• Requirement (data object): Record which details the needs or conditions to meet for a new or altered service.
Key Attributes
The Requirement data object shall have the following key data attributes:
• RequirementID: Unique identifier of a given Requirement.
• RequirementType: Identifies the category of a Requirement (i.e., epic, theme, feature, user story, non-functional, functional, etc.).
• RequirementSummary: Represents the short description/title/summary of a given Requirement.
• LogicalServiceBlueprintID: Unique identifier of the related Logical Service Blueprint.
• PolicyID: Unique identifier of the related Policy.
• PortfolioBacklogID: Unique identifier of the related Portfolio Backlog Item.
• ServiceReleaseID: Unique identifier of the related Service Release.
• SourceID: Unique identifier of the related Source.
• TestCaseID: Identifier of the related Test Cases.
Key Data Object Relationships
The Requirement data object shall maintain the following relationships:
• Logical Service Blueprint to Requirement (1:n): The Logical Service Blueprint is the Service Design which fulfills one or more Requirements.
• Service Release to Requirement (1:n): The Service Release delivers a service which fulfills one or more Requirements.
• Requirement to Test Case (1:n): A Requirement is traced to one or more Test Cases to ensure stated needs or conditions have been successfully delivered or met.
• Portfolio Backlog Item to Requirement (1:n): A Portfolio Backlog Item is mapped to one or more Requirements which will need to be delivered to successfully fulfill the demand.
• Policy to Requirement (n:m): Requirements may be sourced from policies or may reference policies in order to remain in compliance to previously agreed policies for an organization.
Main Functions
The Requirement functional component:
• Shall be the system of record (authoritative source) for all Requirements.
• Shall manage the lifecycle of the Requirement.
• Shall manage the state of a Requirement.
• Shall allow recursive relationships between Requirements.
• Shall allow hierarchical relationships between Requirements.
• Shall associate a requirement to a service.
If a Portfolio Demand functional component exists, the Requirement functional component:
• Shall associate one or more Requirements to a Portfolio Backlog Item that these Requirements originate from.
If a Service Design functional component exists, the Requirement functional component:
• Can manage the data flow to provide Requirement information to the Service Design functional component.
• Shall associate one or more Requirements to a single Logical Service Model.
If a Release Composition functional component exists, the Requirement functional component:
• Shall associate one or more Requirements to a Service Release that will fulfill these Requirements.
If a Test functional component exists, the Requirement functional component:
• Shall allow a Requirement to be traced to one or more Test Cases designed to test this Requirement.
If a Policy functional component exists, the Requirement functional component:
• Shall allow one or more Requirements to be associated to one or more policies that these Requirements originate from.
If a Source data object exists, the Requirement functional component:
• Shall allow one or more Requirements to be traced to one or more Sources.
Model
Figure 47: 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 Blueprint and Portfolio Backlog Items from the S2P Value Stream along with requirements to produce a Logical Service Blueprint that describes the service structure and behavior considering both the service system and the service offer.
• Creation of various architectural artifacts (data flow diagrams, technical schematics, etc.) that comply with the IT Initiative specifications and boundaries.
• Creation of the service design specification document (Service Design Package).
• Identification of the service delivery model (in-source, outsource, etc.).
• Identification of 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 Service Design Package are compliant with all standards and policies, including security standards and policies.
• Ensure that the architecture and Service Design Package meets 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.
Key Data Objects
• Logical Service Blueprint (data object): Represents the logical design of the service based on the Requirements and Conceptual Service Blueprint.
Key Attributes
The Logical Service Blueprint data object shall have the following key data attributes:
• LogicalServiceBlueprintID: Unique identifier of the Logical Service Blueprint.
• LogicalServiceBlueprintVersion: Version of the Logical Service Blueprint.
• ServiceDesignPackageID: Unique identifier for the Service Design Package.
• ServiceDesignPackageVersion: Version of the Service Design Package.
• ConceptualServiceBlueprintID: Unique identifier of the related Conceptual Service Blueprint.
• RequirementID: Identifier of the related Requirement(s).
• ServiceReleaseID: Identifier of the related Service Release(s).
Key Data Object Relationships
The Logical Service Blueprint data object shall maintain the following relationships:
• Conceptual Service Blueprint to Logical Service Blueprint (1:n): The Conceptual Service Blueprint represents the high-level design of a service or changes to a service and leads to the creation of one or many Logical Service Blueprints.
• Logical Service Blueprint to Requirement (1:n): The Logical Service Blueprint is the service design that fulfills one or more Requirements.
• Logical Service Blueprint to Service Release (1:n): A Logical Service Blueprint can lead to the creation of one or more Service Releases.
Main Functions
The Service Design functional component:
• Shall be the system of record (authoritative source) for all Logical Service Blueprints.
• Shall associate a Logical Service Blueprint to a service.
• Can associate a Logical Service Blueprint to a Service Design Package.
If a Service Portfolio functional component exists, the Service Design functional component:
• Shall associate one or more Logical Service Blueprints to a Conceptual Service Blueprint.
• Can receive the Conceptual Service specification and design several Logical Service Blueprints that represent it.
If a Project functional component exists, the Service Design functional component:
• Can receive IT Initiative information which includes the scope and some content based on which the service is designed.
If a Requirement functional component exists, the Service Design functional component:
• Shall associate one or more Requirements to the Logical Service Blueprint.
• Can receive Requirement information from the Requirement functional component used to design the Logical Service Blueprint and create design specifications.
If a Release Composition functional component exists, the Service Design functional component:
• Shall associate a Logical Service Blueprint to one or more Service Releases which are detailed and designed to deliver the Logical Service Blueprint.
Model
Figure 48: 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.
• Develop automated Source compilation tools and procedures.
• Deliver the Source data object to the Build functional component to generate Builds.
Key Data Objects
• Source (data object): The created or purchased solution to meet the requirements for a particular Service Release.
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:
• SourceID: Unique identifier of the Source.
• SourceVersion: Version of the Source.
• BuildID: Identifier of the related Build(s).
• RequirementID: Identifier of the related Requirement(s).
Key Data Object Relationships
The Source data object shall maintain the following relationships:
• Source to Requirement (n:m): Source will fulfill one or many Requirements, and for a given Service Release, there could be multiple Sources created/modified.
• Source to Build (1:n): Source can create one or many Builds.
Main Functions
The Source Control functional component:
• Shall be the system of record (authoritative source) for all Source.
• Shall manage the lifecycle of the Source.
• Shall allow recursive relationships between Source.
• Shall allow hierarchical relationships between Source.
• Shall associate Source to a service.
If a Requirement functional component exists, the Source Control functional component:
• Shall associate one or many Requirements to one or many Sources which includes the content that fulfills these Requirements.
If a Build functional component exists, the Source Control functional component:
• Shall associate one or many Builds to the related Source.
If a Defect functional component exists, the Source Control functional component:
• Can receive Defect information from the Defect functional component so Defects can be fixed in future versions of that Source.
Model
Figure 49: 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
• Build (data object): Created from Source and versioned.
Key Attributes
The Build data object shall have the following key data attributes:
• BuildID: Unique identifier of the Build.
• BuildVersion: Version of the Build.
• SourceID: Identifier of the related Source.
• TestCaseID: Identifier of the related Test Case(s).
• BuildPackageID: Identifier of the related Build Package.
Key Data Object Relationships
The Build data object shall maintain the following relationships:
• Source to Build (1:n): Source can be built multiple times to create several Build versions.
• Build to Test Case (n:m): One or many Builds can be related to one or many Test Cases used as part of the Build creation.
• Build Package to Build (1:n): A Build Package is comprised of one or many Builds.
Main Functions
The Build functional component:
• Shall be the system of record (authoritative source) for all Builds.
• Shall manage the version of each individual Build.
• Shall associate a Build to a service.
If a Source Control functional component exists, the Build functional component:
• Shall associate Source to one or many Builds.
If a Test functional component exists, the Build functional component:
• Shall associate one or many Builds to one or many Test Cases which are executed as part of the Build creation.
If a Build Package functional component exists, the Build functional component:
• Shall associate one or many Builds to a Build Package.
Model
Figure 50: Build Functional Component Level 2 Model
6.4.6 Build Package Functional Component
Purpose
• Creation of a deployable package made up of one or many Builds.
• Manage the Build Packages and relationships to the Service Release Blueprints.
Key Data Objects
• Build Package (data object): A compilation of one or many Builds in a deployable package.
Key Attributes
The Build Package data object shall have the following key data attributes:
• BuildPackageID: Unique identifier of the Build Package.
• BuildID: Identifier of the related Build(s).
• ServiceReleaseBlueprintID: Identifier of the related Service Release Blueprint(s).
Key Data Object Relationships
The Build Package data object shall maintain the following relationships:
• Build Package to Build (1:n): The Build Package is comprised of one or more Builds.
• Build Package to Service Release Blueprint (n:m): One or more Build Packages can be associated to one or more Service Release Blueprints.
Main Functions
The Build Package functional component:
• Shall be the system of record (authoritative source) for all Build Packages.
• Shall associate a Build Package to a service.
If a Build functional component exists, the Build Package functional component:
• Shall associate one or more Builds to a Build Package.
If a Release Composition functional component exists, the Build Package functional component:
• Shall associate one or more Service Release Blueprints to one or more Build Packages.
Model
Figure 51: 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:
— Requirement functional component: requirements per Release Package
— Source functional component, as well as maintenance scripts: documentation
— Build Package functional component: Build Package
— Test functional component: test results as well as automated tests for validation post deployment
— Defect functional component: Known Errors (issues/defects)
Key Data Objects
• Service Release (data object): Represents the release of a given service.
• Service Release Blueprint (data object): The information and details related to a specific release to a specific environment.
Key Attributes
The Service Release data object shall have the following key data attributes:
• ServiceReleaseID: Unique identifier of the Service Release.
• LogicalServiceBlueprintID: Unique identifier of the related Logical Service Blueprint.
• ITInitiativeID: Unique identifier of the related IT Initiative.
• ServiceReleaseBlueprintID: Identifier of the related Service Release Blueprint(s).
• RequirementID: Identifier of the related Requirement(s).
• TestCaseID: Identifier of the related Test Case(s).
The Service Release Blueprint data object shall have the following key data attributes:
• ServiceReleaseBlueprintID: Unique identifier of the Service Release Blueprint.
• ServiceReleaseBlueprintDescription: Description of the Service Release Blueprint.
• MasterServiceID: Unique identifier of the related service.
• ServiceReleaseID: Unique identifier of the related Service Release.
• BuildPackageID: Unique identifier of the related Build Package.
• DesiredServiceModelID: Unique identifier of the related Desired Service Model(s).
• FulfillmentID: Identifier of the related Fulfillment Request(s).
• ServiceContractID: Identifier of the related Service Contract(s).
• ServiceID: Identifier of the related Service Catalog Entry(ies).
• DefectID: Identifier of the related Defect(s).
Key Data Object Relationships
The Service Release data object shall maintain the following relationships:
• Logical Service Blueprint to Service Release (1:n): A Logical Service Blueprint can lead to the creation of one or more Service Releases.
• IT Initiative to Service Release (1:n): An IT Initiative will manage the creation of one or more Service Releases defined to deliver the content of the IT Initiative.
• Service Release to Service Release Blueprint (1:n): A Service Release can be released to multiple environments based on the associated Service Release Blueprints.
• Service Release to Requirement (1:n): The Service Release delivers a service which fulfills one or more Requirements.
• Service Release to Test Case (1:n): A Service Release can be validated by one or many Test Cases/
The Service Release Blueprint data object shall maintain the following relationships:
• Service Release to Service Release Blueprint (1:n): A Service Release can be released to multiple environments based on the associated Service Release Blueprints.
• Service Release Blueprint to Build Package (n:m): One or more Build Packages can be associated to one or more Service Release Blueprints.
• Service Release Blueprint to Desired Service Model (1:n): One Service Release Blueprint can be translated to one or more Desired Service Models.
• Service Release Blueprint to Fulfillment Request (1:n): One Service Release Blueprint is used for service instantiation by one or many Fulfillment Requests.
• Service Release Blueprint to Service Contract (n:m): One or more Service Release Blueprints contain the template of one or more Service Contracts.
• Service Catalog Entry to Service Release Blueprint (1:n): Each Service Catalog Entry is created based on definitions of a Service Release Blueprint.
• Service Release Blueprint to Defect (n:m): One or more Service Release Blueprints can contain one or may Defects in the form of Problems/Known Errors.
Main Functions
The Release Composition functional component:
• Shall be the system of record (authoritative source) for all Service Releases.
• Shall associate a Service Release to a service.
• Shall allow a recursive relationship between Service Releases.
• Shall associate a Service Release to one or more Service Release Blueprints.
• Shall be the system of record for all Service Release Blueprints.
• Shall associate a Service Release Blueprint to a service.
• Shall associate a Service Release Blueprint to a Release Package.
If a Project functional component exists, the Release Composition functional component:
• Shall associate one IT Initiative to one or more Service Releases which are defined to deliver this IT Initiative.
If a Service Design functional component exists, the Release Composition functional component:
• Shall associate one Logical Service Blueprint to one or more Service Releases which are designed to deliver this Logical Service.
If a Requirement functional component exists, the Release Composition functional component:
• Shall associate one Service Release with one or more Requirements which are fulfilled in this release.
If a Test functional component exists, the Release Composition functional component:
• Shall associate one Service Release with one or more Test Cases.
• Can receive test-related information that should be included in the Release Package from Test Management.
If a Build Package functional component exists, the Release Composition functional component:
• Shall associate one or more Service Release Blueprints to one or more Build Packages.
• Can receive one or more Build Packages that should be included in the Service Release Blueprint.
If a Service Level functional component exists, the Release Composition functional component:
• Can provide service contract information for creating a Service Contract.
• Shall associate one or more Service Release Blueprints to one or more Service Contracts.
If a Fulfillment Execution functional component exists, the Release Composition functional component:
• Can provide information required for service instantiation to the Fulfillment Execution functional component.
• Shall associate a Service Release Blueprint to one or more Desired Service Models.
• Shall associate a Service Release Blueprint to one or more Fulfillment Requests.
If a Catalog Composition functional component exists, the Release Composition functional component:
• Can provide information required for creating a Service Catalog Entry to the Catalog Composition functional component.
• Shall associate a Service Release Blueprint to one or more Service Catalog Entry(ies).
If a Defect functional component exists, the Release Composition functional component:
• Shall associate one or more Service Release Blueprints to one or more Defects.
• Can receive Defect-related information that should be included in the Release Package.
Model
Figure 52: 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 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
• Test Case (data object): The Test Case is used to validate that the Service Release is fit for purpose.
Key Attributes
The Test Case data object shall have the following key data attributes:
• TestCaseID: Unique identifier of the Test Case.
• TestCaseSummary: Summary or short description of the Test Case.
• TestCaseStatus: Status of the Test Case.
• ServiceReleaseID: Unique identifier of the related Service Release.
• BuildID: Identifier of the related Build.
• RequirementID: Identifier of the related Requirement(s).
• DefectID: Identifier of the related Defect(s).
Key Data Object Relationships
The Test Case data object shall maintain the following relationships:
• Requirement to Test Case (1:n): A Requirement is associated to one or more Test Cases that validates this Requirement.
• Service Release to Test Case (1:n): A Service Release is associated to one or more Test Cases which are executed as part of this Service Release.
• Test Case to Build (n:m): One or more Test Cases can be associated with one or more Builds that uses this Test Case as part of the Build creation.
• Test Case to Defect (1:n): One Test Case can be associated to one or more Defects that are reported as a result of this test.
Main Functions
The Test functional component:
• Shall be the system of record (authoritative source) for all Test Cases.
• Shall manage the lifecycle of the Test Case.
• Shall allow recursive relationships between Test Cases.
• Shall associate a Test Case to a service.
If a Build functional component exists, the Test functional component:
• Shall associate one or more Test Cases to one or more Builds that uses this Test Case as part of the Build creation.
If a Requirement functional component exists, the Test functional component:
• Shall associate a Requirement to one or more Test Cases that validates this Requirement.
If a Defect functional component exists, the Test functional component:
• Shall associate a Test Case to one or more Defects that result from this test.
• Shall provide Defect information to the Defect functional component.
Model
Figure 53: 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
• Defect (data object): An issue with the Service Release Blueprint which should be remediated to fulfill the associated Requirements.
Key Attributes
The Defect data object shall have the following key data attributes:
• DefectID: Unique identifier of the Defect.
• DefectDescription: Description of the Defect.
• DefectStatus: Status of the Defect.
• ServiceReleaseBlueprintID: Unique identifier of the related Service Release Blueprint.
• TestCaseID: Identifier of the related Test Case.
• KnownErrorID: Identifier of the related Known Error.
Key Data Object Relationships
The Defect data object shall maintain the following relationships:
• Test Case to Defect (1:n): One Test Case can be associated to one or more Defects that results from the test.
• Defect to Service Release Blueprint (n:m): One or more Service Release Blueprints are associated to one or more Defects which are included in the Release Package as Problems/Known Errors.
• Known Error to Defect (1:1): A Known Error is associated to a Defect when the Known Error is found to be a Defect.
Main Functions
The Defect functional component:
• Shall be the system of record (authoritative source) for all Defects.
• Shall manage the lifecycle of the Defect.
• Shall associate a Defect to a service.
If a Release Composition functional component exists, the Defect functional component:
• Shall associate one or more Service Release Blueprints to one or more Defects which reflects Defects that should be published as Problems/Known Errors.
If a Source Control functional component exists, the Defect functional component:
• Can provide Defect information to the Source Control functional component.
If a Test functional component exists, the Defect functional component:
• Shall receive Defect information from the Test functional component.
• Shall associate a Test Case to one or more Defects.
If a Problem functional component exists, the Defect functional component:
• Shall associate a Known Error to a Defect.
• Shall receive Defect information from a Known Error.
Model
Figure 54: Defect Functional Component Level 2 Model