0% found this document useful (0 votes)
90 views

IT4IT Reference Card2

The document outlines a framework called R2D (Requirement to Deploy) that provides a process for prioritizing, creating, modifying or sourcing services in order to improve reuse, time-to-market, supplier information, financial visibility, and predictability. Key activities in the R2D framework include planning and designing services, developing them using agile, iterative or waterfall methodologies, and controlling changes and deployments. The goal of R2D is to deliver the best services by defining quality, utility, schedule and cost.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
90 views

IT4IT Reference Card2

The document outlines a framework called R2D (Requirement to Deploy) that provides a process for prioritizing, creating, modifying or sourcing services in order to improve reuse, time-to-market, supplier information, financial visibility, and predictability. Key activities in the R2D framework include planning and designing services, developing them using agile, iterative or waterfall methodologies, and controlling changes and deployments. The goal of R2D is to deliver the best services by defining quality, utility, schedule and cost.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

R2D: Requirement to Deploy

Value Drivers Key Activities

Reuse
Plan &
Re-use of services and requirements
Design
Prioritize Every Requirement to Build the Best Services and Deploy Them becomes the norm.
• Provides a framework for creating, modifying, or sourcing a service Time-to-Market
• Supports agile and traditional development methodologies IT project plan
~
• Enables visibility of the quality, utility, schedule, and cost of the services you deliver Faster time-to-market for service Logical service model
• Defines continuous integration and deployment control points realization. ~
Requirements
~
Supplier Info. Functional & technical
Fulfillment Request ~
Standards &
Increased traceability across internal and policies
Defect external suppliers.
RFC (Normal)
Financial Visibility
1:n Develop
Scope Agreement
Project Component Source Control Build Component Change Control
Component Component
Improved inputs to IT Financial
Proposal Component Management on full service cost.
Development: agile,
Scope Agreement 1:n
IT Initiative
n:m
Source
1:n
Build RFC
Predictability iterative, waterfall, …
~
Strategy to Portfolio Source & set up
n:m
Service Contract (Template)
n:1
Service Level Component Control point facts for quality, utility, dev. environment
~
IT Inititative
1:n Service
security, and cost. Version control
Contract
Service Portfolio Service Design Release Build ~
Component Component
Release
Composition
Package Package Detect to Connect
RFC Policy Compliance Developer testing
Component Fulfillment Execution
Service
Design
1:1
Build Package Desired
ComponentFulfillment
Package Service Release
Blueprint Component Service Model Request Across security, risk, enterprise
Conceptual
Service Blueprint 1:n 1:n 1:n 1:n
1:n 1:1
architecture, and finance. Test
Logical Service Service
Blueprint Release
Strategy to Portfolio Release Package

1:n
Request to Fulfill
Proof Points
1:n n:m
n:1 1:n
Requirement Service Catalog Entry (Unbound) Functional: desktop,
Catalog Composition
Component web, mobile
Service ~
Policy Requirement Test Component Defect Defect Catalog Entry Performance: desktop,
Component Component Component
web, mobile
Policy
n:m
Requirement
1:n
Test Case
1:n
Defect
1:1
Request to Fulfill
Requirements Defects ~
% of requirements – % of detected versus Security: static,
Strategy to Portfolio
dev, test, deploy closed at release dynamic
Functional Component - Key
Portfolio Demand Defect Functional Component - Auxiliary
Component
Defect Service Model
Portfolio 1:n
Backlog Item
Problem Incident Data Object - Key Deploy
Strategy to Portfolio Component Component
Data Object - Auxiliary
Automation Deploy
Problem
known error
Incident % of automated % of successful
Entity Relationship build, tests, deploy deployments
Record Fabric Integration
Detect to Connect Detect to Connect Release plan
Engagement Data Flow ~
Current Practice Change and
configuration process
Source: Open Group - http://www.opengroup.org/IT4IT ~
On Time Change Knowledge
% of project tasks or % of emergency management
cycles on time changes ~
Application and
security monitors

www.orbussoftware.com

You might also like