You are on page 1of 71

IT4IT Overview

Charles Betz
Speaker bio
• Charlie Betz is Director of Strategy and Innovation (aka Chief Architect) for a major US telecom and ecommerce
hosting provider, currently assigned to large enterprises in the retail and healthcare sectors.
• Representative to the IT4IT Strategy Board, a new Open Group standard for the “business of IT”
• Previously he was Research Director for IT Portfolio Managmeent at Enterprise Management Associates. He spent 6
years at Wells Fargo as VP and Enterprise Architect for IT Portfolio Management and Systems Management. He has
held architect and application manager positions for Best Buy, Target, and Accenture, specializing in IT
management.
• He is sole author of Architecture and Patterns for IT and co-author of several works with Lean collaborators and for
ISACA’s COBIT.

• Charlie lives in Minneapolis, Minnesota with his


wife Sue and son Keane.
What we will cover

• Overview and positioning of IT4IT


• IT4IT governance
• IT4IT content
• IT4IT Agile workstream
• Getting involved

3
IT4IT overview

• Industry standard for the “business of IT”


launching this October at Open Group
conference in London
• Started out of discussions between Shell,
HP and other customers
• Intended to be more prescriptive and
architectural than ITIL or COBIT
• Emphasis on end to end IT value streams
and conceptual data model
• Similar in scope and intent to reference
architectures such as eTOM and ARTS

4
Solving problems that every enterprise has
Building a reference architecture that allows IT to be a business innovation center
Why create a customer consortium
• History of every new initiative reinventing IT foundations
• Issues are industry independent
Policy Requirement Defect Problem Incident
Management Management Management Management Management

Policy Requirement Defect Problem Incident

Proposal
Management
(Investment)

IT Contract
Project
Delivery
Management
IT Project
Test
Management

Test Case
Catalog
Management
Offer

Service Catalog
Subscription
Management

Subscription
Billing &
Chargeback

Chargeback
Record
Diagnostics &
Remediation

Runbook
Event
Management

Event
What and next steps
Entry

Business
Architecture
Management
Business
Architecture
Demand
Management

Demand
Service
Development
Management
Source
Build
Management

Deployment
Package
Request &
Routing
Management
Fulfillment
Request
Usage
Management

Usage Record
Service
Monitoring

Service
Monitor
• End-to-end business service lifecycle for existing/future paradigms
IT
Architecture
Management
Service
Portfolio
Management
Service
Design
Management
Design Package
Release
Management
Release Package
Deployment
Management
Service
Change
Management
Configuration
Management
• Open standardization process
Release Desired
Conceptual Conceptual Service CIs
Service Blueprint Logical Service Blueprint RFC
IT Architecture Blueprint Service Release Actual Service CIs

Plan Build Deliver Run How


• With broad integrated processes to deliver higher value than silos
• Support for industry process models like ITIL and COBIT
Leveraging business value chain success in IT
Designed by customers like you over the last 2 years using real world use cases
Based on Porter’s value chain and lean manufacturing value streams concepts

IT Value Chain

Plan Build Deliver Run Efficiency


Reference Architecture &
Finance & assets Agility
Sourcing & vendor
Intelligence & reporting
Resource & project
Governance, risk and compliance
Realizing a service-centric style of IT
IT Value Chain integration prescription delivers end-to-end traceability
Service lifecycle – on a repeatable, predictable, coherent and future safe reference architecture

Strategy to Requirement Request to Detect to


Portfolio to Deploy Fulfill Correct
• Plan • Build • Deliver • Run
• Demand • Develop • Publish • Monitor
• Policy • Test • Subscribe • Diagnose
• Selection • Release • Fulfill • Change
Pol icy Requirement Def ect Probl em Incident
Management Management Management Management Management

Pol icy Requi rement Def ect Pr obl em Inci dent

Proposal Project Test Cat al og Subscript ion Bil l ing & Di agnost ics & Event
Management Del i very Management Management Management Chargeback R emedi at ion Management
(Invest ment ) Management Of f er

IT Cont ract IT Pr oject Test Case Subscr ipt i on Char geback Runbook Event
Servi ce Cat al og Record
Ent ry

Business Demand Ser vice Buil d Request & U sage Ser vice
Archi t ect ure Management Devel opment Management Rout ing Management Moni t oring
Management Management Management
Busi ness Demand Sour ce Depl oyment Ful f il l ment Usage Record Servi ce
Ar chit ect ure Pack age Request M onit or

IT Ser vice Ser vice Rel ease Depl oyment Change Conf igurat ion
Archi t ect ure Por t f ol io D esi gn Management Management Management Management
Management Management Management
Design Package Rel ease Package Servi ce
Rel ease Desir ed
Concept ual Concept ual Servi ce CIs
Servi ce Bl uepr int Logi cal S er vice Bl uepr int RFC
IT Ar chit ect ure Bl uepr int Servi ce Rel ease Act ual Ser vice CIs
Service
Architecture
Enterprise
Architecture
IT4IT Reference Architecture v1.2
Key Functional Components and underpinning Key Artifacts
Knowledge &
Policy Requirement Defect Shop / Buy / Pay / Manage Problem Incident
Collaboration
Shopping
Cart
Knowledge Problem /
Policy Requirement Defect Incident
Item Known Error

Catalog Request Chargeback /


Proposal Project Test Rationalization Event
Aggregation Request Showback
& Offer Mgmt.
Chargeback
IT Contract IT Project Test Case Offer Subscription Event
Contract

Usage Diagnostics & Service


Demand Service Build
Development Remediation Monitoring

Usage Service
Demand Source Build Run Book
Record Monitor

Release Catalog Composition Change CMDB


Service Service Design Control
Portfolio Design Release & Design Fulfillment
RFC
Package Request
Service Service
Design Catalog
Package Entry

Conceptual Logical Service Desired


Conceptual Service Actual
Service Service Release Service
Service Release Service CIs
Blueprint Blueprint Blueprint Fulfillment Model
Execution

Strategy to
Requirement to Deploy Request to Fulfill Detect to Correct
Portfolio
IT4IT Core Metamodel
Level 3: Vendor independent Architecture
*
Value Stream
*
* Attribute
* * 1
Capability * * 1 1..*
Functional Component Artifact
Discipline
2 2
1 1 *
1
1..* Relationship

1
FC Function

1..*
* * *
1..*
* 0..1
* Essential * * SoR
Scenario
Service Integration

Use cases identified and together with SoR Integrations drive identification of Service Endpoints / Essential services for IT
Attributes needed for SoR integrations and Use cases are indentified
The Class model is mapped to ArchiMate concepts and the IT4IT specification is capture in ArchiMate
Class model for IT4IT Reference Architecture
Level 3: ArchiMate Notation Guide
L3 Element Representation L3 Element Representation

Value Chain Artifact [Data Object]


Artifact
[Business Function]
Value Chain

Value Stream Essential Service


[BusinessFunction] [Application
Value Stream Service] Essential
Service

Capability SoR Integration


[Business Function] [Application
(Discipline) Capability Discipline
Interaction] SoR

Functional [Application [Application


Component Component]
Functional
Collaboration] SoR

Component
Standard positioning
ITIL positioning in detail
ITIL IT4IT
Positioning Framework describing functions/capabilities/disciplines. Information model driven reference architecture,
supportive of multiple process frameworks.
Origins “Best” or “good” practice origins intended for broad Originated out of needs identified by enterprise architects
audience of executives, managers, and individual and IT managers for clearer implementation and
contributors. integration guidance
Methodology Primarily unstructured narrative. “Process” (similar to Structured consistently with TOGAF and Archimate. Value
what enterprise architects would term function) is the stream, capability, data, system views.
primary unit of analysis.
Orientation Oriented to practitioner education rather than solution Solution orientation
Value approach Oriented to deep discussion of individual silo Focused on the end to end flow of four high level IT value
functions/processes. Beyond overall service lifecycle, does streams (Strategy to Portfolio, Requirement to Deploy,
not emphasize longer lived value flows. Request to Fulfill, Detect to Correct) across IT capabilities.
Internal consistency Ambiguous and overlapping terminology in places Mutually exclusive and comprehensive, rigorously
avoiding ambiguity and overlap in its architectural
catalogs
Level of detail Not sufficiently detailed to be of utility to planners and Precise representation of data and integration patterns in
architects attempting to integrate IT management complex IT management domain
infrastructure.
Agile Implicit waterfall, top-down planning orientation. Explicit coverage of Agile and DevOps trends.
Maintenance process Long term history of proprietary ownership. Multi-year Open development process
revision cycle
IT4IT Governance

• First open reference model dedicated


to the “business of IT”
• Clear, community process for
maintenance
• Consortium model is the most proven
model for sustaining this kind of
architectural work with accountability
• IT4IT will follow Open Group’s mature
standards development practices
IT4IT Consortium members (Sep 2014)

• HP • Munich Re
• AT&T • Capgemini
• Shell • BP
• PwC • Logicalis
• Univ. S. Florida • UMBRiO
• Accenture • Atos
IT4IT Content

Value Reference
Why it Deeper High level Detailed
Stream Overview KPIs Components Architecture
matters dive flow Architecture
Context Context
Strategy to Portfolio value stream

IT Value Chain
Plan Build Deliver Run Efficiency
Reference Architecture &
Finance & assets Agility
Sourcing & vendor
Intelligence & reporting
Resource & project
Governance, risk and compliance

Creates a blueprint for optimizing the way you


manage your IT portfolio and investments to drive
business innovation
Strategy to Portfolio

Strategy Service Portfolio Demand Selection

Provides the strategy to use to balance and broker your portfolio


Unified viewpoint across PMO, enterprise architecture & service portfolio
Improves data quality for decision making
KPIs and roadmaps to improve business communication
How a user-centric world impacts IT planning
Drive IT portfolio to business innovation
Strategy Service Portfolio Demand Selection

Common Planned economy


• 2 year planning • Support / enhance core • 70:30 KTLO to • Bottom-up tactical
windows, quarterly business process innovation monitoring
reviews • Resource capacity – big • Apps focus: business • Manual data collection
• Cost reduction and teams, inflexible skills process efficiency and correlation
reliability • Ops focus: stability,
“change is evil”
Next wave Market economy
• 4 quarterly rolling • New user end points • 20:80 KTLO to • Top-down goals
planning/ bi-weekly and edges of process innovation • KPI monitored via
CEO review
• Agile teams, multi- • Sourcing/brokering aggregated measures
• Business innovation and sourced, flexible skills • Risk and security • Real-time, automated,
reliability become table integrated
stakes • Customer impact
(loyalty, revenue)
Why Strategy to Portfolio?
Designed to help with investing in the right services
Business
Holistic demand Data consistency
priorities
Across PMO, enterprise Decisions are based on Reliability and trust based
architecture, service business needs on consistent data across
portfolio and business services

Financial visibility Traceability Communication


Information on Link from business With business
investment activity and request to what was stakeholders through
value realization delivered service roadmaps
Proving value KPIs
Using Strategy to Portfolio to quantify the value of portfolio planning

% of new investment
Innovation vs maintenance
Demand By source and type

% satisfied customers
Capital % CapEx vs OpEx Usage per service

Deficiencies in security
Costs % planned vs actual Compliance policies and standards
Exploring Strategy to Portfolio

Strategy Service Portfolio Demand Selection

• Define objectives • Enterprise • Consolidate • Business value,


• Align business and architecture demand risk, costs, benefits
IT roadmaps • Service portfolio • Analyze priority, & resources
• Set up standards rationalization urgency, and • What-if-analysis
and policies • Create service impact • Ensure governance
blueprint and • Create new or tag
roadmap existing demand
Strategy to Portfolio – major components

Strategy Service Portfolio Demand Selection

Enterprise Service
Demand Proposal
Architecture Portfolio
Reference Architecture
Strategy to Portfolio Requirement to Deploy Request to Fulfill Detect to Correct
Enterprise
Architecture

Ser vice
Architectur e

Knowledge &
Policy Requirement Defect Shop / Buy / Pay / Manage Problem Incident
Shopping
Collaboration
Functional
Cart
Poli cy Requirement Defect
Kno wle dge
Item
Pro blem/
Kno wn Err or
Inci dent component

Catalog Request Chargeback /


Proposal Project Test Rationalization Event
Aggregation Reque st Showback
& Offer Mgmt.
IT Contract IT Proje ct Test Ca se Offe r Sub scription
Charge back
Contract
Event
Artifact

Usage Diagnostics & Service


Demand Service Build
Remediation Monitoring
Development

Demand Sou rce Buil d


Usa ge
Run Book
Ser vice Entity
Record Monitor
relationship
Release Catalog Composition Change CMDB
Service Service Design Control
Portfolio Design Release & Design Fulfillment
RFC
Package Reque st
Ser vice Ser vice
Design Catalog
Package Entry
Service
Conceptual
Ser vice
Conceptual
Ser vice
Log ica l
Ser vice
Ser vice
Release
Ser vice
Release
Desired
Ser vice
Actu al
Ser vice CIs
model
Blue print Blue print Blue print Fulfillment Model
Execution

V.1.2, Mar 20th 2014


This wor k is based upon material
developed and publ ished by t he
IT4IT Consort ium
Strategy to Portfolio functional model Service Design
Logical Service
Service Portfolio 1:n Blueprint
Requirement to Deploy
Roadmap Conceptual
Service Service
Enterprise Architecture Blueprint Blueprint
1:n Policy
Policy
n:1 Requirement
Service n:m n:m Requirement
n:m
Architecture
Conceptual
Service Policy Requirement to Deploy

Demand 1:n 1:n


Business Process

Demand Demand Proposal


Business (rationalized) IT Contract Project
Demand
Strategy IT Contract
Demand n:1 1:n IT Project
Requirement to Deploy

Competency Budget Assets


Demand 1:1 (availability) (estimate) (availability)
V.1.2, Mar 20th 2014
This wor k is based upon material
Problem Labor Asset developed and publ ished by t he
IT4IT Consort ium
Management Management
Problem, Functional Component - Key
Known Error
Detect to Correct Functional Component - Auxiliary
IT Financial Service Model
Management
Data Artifact – Key
Data Artifact – Auxiliary

Entity relationship
Record fabric Integration
Engagement dataflow
Current practice
Requirement to Deploy value stream

IT Value Chain
Plan Build Deliver Run Efficiency
Reference Architecture &
Finance & assets Agility
Sourcing & vendor
Intelligence & reporting
Resource & project
Governance, risk and compliance

Define, build, test, and deploy the right


service, at the right time, at the right cost
Requirement to Deploy

Plan & design Develop Test Deploy

Framework for creating, modifying or sourcing a service


Supports agile and traditional development methodologies
Visibility to the quality, utility, schedule, and cost of the services you deliver
Defines continuous integration and continuous deployment control points
How a user-centric world impacts building services
Build what the business wants, when it wants it

Plan & design Develop Test Deploy


Common 4 months
• Exhaustive definition • Manual configurations • Test only; • Manual deployment
and stubs code=black box
• Abstract • Wastage of assets:
• Driven top-down • Lead time for performance scripts,
• Contractual
environments known bugs, etc.
• Everyone in one
building • Treated as ‘last mile’
Next wave 1 week
• Just enough • Composite and • Insight into code • Automated deployment
• Experiential virtualized changes • Asset reuse between
• Automatic connections • Auto deploys for Apps and Ops
• Story-based /
dev/test
interpretive • Empowered,
entrepreneurial and • Continual testing
distributed
Why Requirement to Deploy?
Designed to help in building, sourcing and deploying quality services

Reuse Time to market Supplier Info


Reuse of services and Faster time to market for Increased traceability and
requirements becomes service realization benchmarking of internal
the norm and external suppliers

Financial visibility Predictable Policy compliance


Improved inputs to IT Control point facts about Across security, risk,
Financial Management quality, utility, security enterprise architecture &
on full service cost and cost finance
Proving value KPIs
Using Requirement to Deploy to measure investment effectiveness

% of requirements – dev, % of detected vs closed


Requirements test, deploy Defects at release

% of automated build, % of successful


Automation tests, deploy Deploy deployments

% of project tasks or
On time cycles on time Change % of emergency changes
Exploring Requirement to Deploy

Plan & design Develop Test Deploy


• IT Project plan • Development: • Functional: • Release plan
• Logical service Agile, iterative, desktop, web, • Change and
model waterfall … mobile configuration
• Requirements • Source & set up • Performance: process
dev environment desktop, web, • Knowledge
• Functional &
• Version control mobile management
technical
• Developer testing • Security: static, • Application and
• Standards &
dynamic security monitors
policies
Requirement to Deploy – major components

Plan & design Develop Test Deploy

Service Service
Test Fulfillment
Design Development

Build
Requirements
Release Design
Reference Architecture
Strategy to Portfolio Requirement to Deploy Request to Fulfill Detect to Correct
Enterprise
Architecture

Ser vice
Architectur e

Knowledge &
Policy Requirement Defect Shop / Buy / Pay / Manage Problem Incident
Shopping
Collaboration
Functional
Cart
Poli cy Requirement Defect
Kno wle dge
Item
Pro blem/
Kno wn Err or
Inci dent component

Catalog Request Chargeback /


Proposal Project Test Rationalization Event
Aggregation Reque st Showback
& Offer Mgmt.
IT Contract IT Proje ct Test Ca se Offe r Sub scription
Charge back
Contract
Event
Artifact

Usage Diagnostics & Service


Demand Service Build
Remediation Monitoring
Development

Demand Sou rce Buil d


Usa ge
Run Book
Ser vice Entity
Record Monitor
relationship
Release Catalog Composition Change CMDB
Service Service Design Control
Portfolio Design Release & Design Fulfillment
RFC
Package Reque st
Ser vice Ser vice
Design Catalog
Package Entry
Service
Conceptual
Ser vice
Conceptual
Ser vice
Log ica l
Ser vice
Ser vice
Release
Ser vice
Release
Desired
Ser vice
Actu al
Ser vice CIs
model
Blue print Blue print Blue print Fulfillment Model
Execution

V.1.2, Mar 20th 2014


This wor k is based upon material
developed and publ ished by t he
IT4IT Consort ium
Requirement to Deploy functional model Fulfillment Request
Defect
RFC (Normal)
1:n
IT Contract
Project Service Development Build Change Control
Proposal

IT Project
IT Contract Source Build RFC
1:n 1:n
Strategy to Portfolio

1:n n:m
IT Project n:m

RFC
Release Package
Service Design 1:n
Release
Fulfillment Execution
Service Portfolio Service Release Fulfillment
Package Desired Service 1:1
Design 1:1 1:1 Model Request
Conceptual Service Package Design
Blueprint
1:n 1:n 1:n 1:n 1:n
Logical Service Service Service
Strategy to Portfolio Blueprint Release Release Blueprint Request to Fulfill

1:n

1:n Catalog Composition &


1:n n:1 Service Catalog Entry (Unbound)
Design
Requirement 1:n Service Catalog Entry

n:m
Request to Fulfill
Requirements Test Defect
Defect
Policy
Policy n:m 1:n 1:n 1:1
Requirement Test Case Defect
Strategy to Portfolio V.1.2, Mar 20 th 2014
This wor k is based upon material
developed and publ ished by t he
1:1
Demand IT4IT Consort ium

Problem Defect Defect Incident Functional Component - Key


Demand 1:n Management Management Functional Component - Auxiliary
Strategy to Portfolio Problem, Incidnet Service Model
Known Error
Data Artifact – Key
Detect to Correct Detect to Correct
Data Artifact – Auxiliary

Entity relationship
Record fabric Integration
Engagement dataflow
Current practice
Request to Fulfill value stream

IT Value Chain
Plan Build Deliver Run Efficiency
Reference Architecture &
Finance & assets Agility
Sourcing & vendor
Intelligence & reporting
Resource & project
Governance, risk and compliance

Transition to a service broker model using an offer


catalog to manage subscriptions and route
fulfillments
Request to Fulfill

Publish Subscribe Fulfill Measure

Helps your IT organization:


• Transition to a service broker model
• Present a single catalog with items from multiple supplier catalogs
• Efficiently manage subscriptions and total cost of service
• Manage and measure fulfillments across multiple suppliers
How a user-centric world impacts delivering services
Catalog, fulfill, and manage services and track their usage

Define & publish Subscribe Fulfill Measure


Common Bureaucratic
• Paper-based • Generic, email/forms- • Multiple hand-offs • Blanket allocations
driven
• Built to order • Stranded capacity, • Anecdotal service
• Fragmented “naked” services not quality reports
monitored in rollout or
• Politicized
production
(“who you know”)
Next wave Self-serve
• Automated • Automated and • Automated workflow • Pay per use
personalized
• Configured to order • Management by • Continual user
• Aggregated exception, instrumented experience
(one-stop shop) from request to release measurement and
management
• Optimized for
consumption
Why Request to Fulfill?
Designed to help source and access quality services

Consumption Single catalog Service broker


Consumers easily find Single offer catalog with Transition from request
and subscribe via multiple fulfillment management to broker
self-service providers

Efficiency Traceability Cost optimization


Standard subscription Across subscription, Recover expired and
process with policies and usage and chargeback unused subscriptions and
automation licenses
Proving value KPIs
Use Request to Fulfill to quantify the value of self-service catalog subscriptions

Subscriptions per % of subscriptions


Deliver period per service
Broker active or expiring

% of orders fulfilled % of successful


Speed with automation
Usage deployments

% self-service % of subscriptions
Costs requests
Satisfaction requiring an incident
Exploring Request to Fulfill

Publish Subscribe Fulfill Measure


• Mash up catalog • Portal engagement • Route fulfillments • Service usage
items from all • Personalized • Automate measurement
fulfillment engines experience deployment • Chargeback /
• Set pricing, options • Self-service • Use internal and showback
and SLA external providers • Cost transparency
• Manage
• Publish services subscriptions • Integrate with • Surveys and
change, asset & ratings
config systems
Request to Fulfill – major components

Publish Subscribe Fulfill Measure


Shop / Buy / Pay / Manage

Catalog Request Fulfillment Usage

Chargeback /
Showback
Reference Architecture
Strategy to Portfolio Requirement to Deploy Request to Fulfill Detect to Correct
Enterprise
Architecture

Ser vice
Architectur e

Knowledge &
Policy Requirement Defect Shop / Buy / Pay / Manage Problem Incident
Shopping
Collaboration
Functional
Cart
Poli cy Requirement Defect
Kno wle dge
Item
Pro blem/
Kno wn Err or
Inci dent component

Catalog Request Chargeback /


Proposal Project Test Rationalization Event
Aggregation Reque st Showback
& Offer Mgmt.
IT Contract IT Proje ct Test Ca se Offe r Sub scription
Charge back
Contract
Event
Artifact

Usage Diagnostics & Service


Demand Service Build
Remediation Monitoring
Development

Demand Sou rce Buil d


Usa ge
Run Book
Ser vice Entity
Record Monitor
relationship
Release Catalog Composition Change CMDB
Service Service Design Control
Portfolio Design Release & Design Fulfillment
RFC
Package Reque st
Ser vice Ser vice
Design Catalog
Package Entry
Service
Conceptual
Ser vice
Conceptual
Ser vice
Log ica l
Ser vice
Ser vice
Release
Ser vice
Release
Desired
Ser vice
Actu al
Ser vice CIs
model
Blue print Blue print Blue print Fulfillment Model
Execution

V.1.2, Mar 20th 2014


This wor k is based upon material
developed and publ ished by t he
IT4IT Consort ium
Request to Fulfill functional model
n:m
1:1 User Profile Engagement Experience Portal

Knowledge &
Self Service
Shopping Cart Collaboration Knowledge
Shop / Buy / Pay / Manage Item Support
n:m
1:n
Conversation
Composite/Compound
n:m 1:n Request

Catalog Request Rationalization Chargeback / Knowledge


Item
Aggregation & Subscription Showback Status
Subscription
Offer Mgmt. 1:n
n:m 1:n
Offer n:m
Request Chargeback Contract
Catalog Offer n:m

Project n:m 1:m


Service Catalog Chargeback
Fulfillment 1:n Usage
Entry (Bound) Contract
ITProject Request
1:n
Requirement to Deploy
Catalog Fulfillment Execution Usage
Composition Desired
& Design Fulfillment Service
Request Model
n:1 Usage Record
Service Catalog Entry

Service Catalog
V.1.2, Mar 20th 2014
Entry (Unbound) This wor k is based upon material
developed and publ ished by t he
Release IT4IT Consort ium
Package 1:1 Service
1:1 Functional Component - Key
Actual Monitor
1:n Release Design Service Functional Component - Auxiliary
1:n Release Request Usage Incident
1:n RFC CIs Service Model
Service Package
Service Release Data Artifact – Key
Release Blueprint Data Artifact – Auxiliary
1:n Bill/Invoice
Requirement to Deploy Entity relationship
1:n Record fabric Integration
Engagement dataflow
Request
Current practice

Request 1:1

IT Asset Change CMDB Fulfillment IT Financial Service Problem Incident


IT Supplier
Management Control Engine & Deploy/ Management Monitoring
(External to IT) Actual Problem,
RFC Service CIs Provision Systems Known Error
Supportive Function Supportive Function Detect to Correct Detect to Correct Supportive Function Supportive Function Detect to Correct Detect to Correct Detect to Correct
Detect to Correct value stream

IT Value Chain
Plan Build Deliver Run Efficiency
Reference Architecture &
Finance & assets Agility
Sourcing & vendor
Intelligence & reporting
Resource & project
Governance, risk and compliance

Bringing together IT service operations to


efficiently detect and correct issues before
impacting users
Detect to Correct

Detect Diagnose Change Resolve

Brings together IT service operations to enhance results and efficiency


End-to-end visibility using a shared configuration model
Identify issues before they affect users
Reduce the mean time to repair
How a user-centric world impacts resolving issues
Anticipate and resolve service issues

Detect Diagnose Change Resolve


Common Local, procedural
• Reactive • Static infrastructure • Feared • Patch in prod
• Multi-sourcing “blind • 1:1 resource to service • By-committee • “Snowflake” systems
spots” (unique, fragile)
• Designed to test • CAB controls change
• Triage and manual • Tribal knowledge for
• Isolated impact • Dev/QA controls
forensics resolution
regression tests
Next wave Virtual, dynamic
• Predictive • Dynamic infrastructure, • Expected, continual and • Repeatable, automated
shared everything automated change
• Multi-disciplinary and
guided forensics • Designed to operate • CAB controls change to • Social-IT for enterprise
• Automated triage (“flight • Complex failure modes automation and collaboration
regression tests
data recorders”)
• Dev/Ops collaboration
Detect to Correct to Portfolio?
Designed to help with investing in the right services

Efficiency Collaboration Traceability


End-to-end visibility to Common language with Across event, incident,
quickly identify and consistent data and change and resolution
resolve shared configuration

Cost Risk Improvement


Reduce tickets, war Defined business impact Shorter mean time to
rooms and duplicate work and reduced clannish repair and more uptime
knowledge
Proving value KPIs
Using Detect to Correct to quantify the value of IT operations improvements

Decrease mean time % of events and


Velocity to repair
Effort incidents escalated

Increase in problems % of change related


Root cause identified & solved
Teamwork outages

% of automated event
Costs & incident resolutions
Satisfaction % of first call resolution
Exploring Detect to Correct

Detect Diagnose Change Resolve


• See events, alarms • Enrichment • Define change • Implement change
and metrics across • Root cause request • Leverage runbooks
the entire • Perform problem
• Severity and • Verify recovery
infrastructure and risk analysis
business impact • Close records
• Understand user • Approve
• Defined escalation
issues
path
• Trace the
• Auto-fixed common
relationship
issues
between events
Detect to Correct – major components

Detect Diagnose Change Resolve

Service
Event Incident Remediation
Monitoring

Configuration
Reference Architecture
Strategy to Portfolio Requirement to Deploy Request to Fulfill Detect to Correct
Enterprise
Architecture

Ser vice
Architectur e

Knowledge &
Policy Requirement Defect Shop / Buy / Pay / Manage Problem Incident
Shopping
Collaboration
Functional
Cart
Poli cy Requirement Defect
Kno wle dge
Item
Pro blem/
Kno wn Err or
Inci dent component

Catalog Request Chargeback /


Proposal Project Test Rationalization Event
Aggregation Reque st Showback
& Offer Mgmt.
IT Contract IT Proje ct Test Ca se Offe r Sub scription
Charge back
Contract
Event
Artifact

Usage Diagnostics & Service


Demand Service Build
Remediation Monitoring
Development

Demand Sou rce Buil d


Usa ge
Run Book
Ser vice Entity
Record Monitor
relationship
Release Catalog Composition Change CMDB
Service Service Design Control
Portfolio Design Release & Design Fulfillment
RFC
Package Reque st
Ser vice Ser vice
Design Catalog
Package Entry
Service
Conceptual
Ser vice
Conceptual
Ser vice
Log ica l
Ser vice
Ser vice
Release
Ser vice
Release
Desired
Ser vice
Actu al
Ser vice CIs
model
Blue print Blue print Blue print Fulfillment Model
Execution

V.1.2, Mar 20th 2014


This wor k is based upon material
developed and publ ished by t he
IT4IT Consort ium
Detect to Correct functional model RFC
RFC

Self Service Defect Demand


Shop/Buy/Pay/ Usage Support
Incident Defect Defect Defect Demand Demand
Manage
Requirement Strategy to
Request to Fulfill to Deploy Portfolio
Request to Fulfill Request to Fulfill
1:1
1:1 1:1

Status Usage 1:n


1:n

Service
Event Event Incident Incident Problem Problem RFC Change Control
Monitoring
Interaction
Problem,
Service n:m Incident Known Error
Monitor Event
1:n n:m n:m 1:n RFC

n:m
1:n Run book
Service n:m
Monitor Service Discovery Knowledge Item
CI Run book Run book
V.1.2, Mar 20th 2014
n:m This wor k is based upon material
Actual developed and publ ished by t he
Fulfillment Execution
Desired Service Diagnostics & Knowledge & Collaboration IT4IT Consort ium
Fulfillment Service CIs CMDB Remediation Functional Component - Key
Request Model n:m Functional Component - Auxiliary
1:n 1:1 n:m Runbook
Knowledge Conversation Service Model
Actual Service CIs Item Data Artifact – Key
Request to Fulfill Request to Fulfill Data Artifact – Auxiliary

n:m Entity relationship


Record fabric Integration
Engagement dataflow
n:m
Current practice
1:1
RFC
Agile Enablement Workstream
IT4IT Consortium

Initial charter, scope, and direction


Draft 0.3 7/21/2014
Mission

• Chartered at Spring 2014 meeting (Amsterdam)


• Scope
– Develop patterns, scenarios and perspectives demonstrating utility of
IT4IT Reference Architecture for Lean and Agile delivery, including
DevOps
– Identify specific changes to the IT4IT Reference Architecture as
needed to better support Agile delivery
– Contribute to positioning IT4IT specifically with reference to SAFe, also
Kanban, Scrum, and other Agile methods.
About Enterprise Architecture
and Agile
We don’t need a • Some suspicion which may reflect on IT4IT
framework. Looks – EA perceived as “ivory tower bureaucracy”
pretty waterfall. – Frameworks such as ITIL, COBIT, CMMI perceived
as non value add
– Inherent difficulties in representing iteration in a
framework
• Consider:
– EA as Orienting phase of OODA
– “Picture worth a thousand words” – visual syntax
is important
– Recommended: “The Elephants in the Agile
Room” by Kruchten
http://philippe.kruchten.com/2011/02/13/the-elephants-in-
the-agile-room/
Positioning

• IT4IT is not a methodology.


• It is closer to design patterns.
• It is a “framework” and
“prescriptive” in the sense of it
being a reference model
• There is validity to the Agile
concern that “process can be
nothing more than organizational
scar tissue.”
– But process is not ONLY that.
Lean & Agile ecosystem

Agile: IT applications of Lean

DevOps/Continuous Delivery

Agile development Agile operations practices


practices
Lean Product Deployment
XP Scrum Automation
Management
Continuous
Integration Infrastructure as Code

Kanban

Lean Philosophy

56
DEVOPS TOOLCHAIN
Agile principles

• Correctly apply economics


• Avoid waste
• Maximize information
• Manage for flow under uncertainty
• Build effective culture
• Build effective software pipeline

58
Agile objectives for IT4IT

• Centrality of version control for both text and binary artifacts


• Automation of build, test, and deployment processes

• Support forward transparency & shared visual mental models


• Support limited Work in Progress; understand and manage all queues
• Show patterns for fast feedback
– Event – Incident – Defect – Story - Change
– Automated rollback
• Identify the industry consensus end to end components across core Dev
and Ops
Continuous Integration
application Scenario 1

Fulfillment Execution Component

Service Development Component (Source Build Management Component Release Design Component
Control)

Dependency Management Artifact storage &


Artifact storage & retrieval retrieval

Build package
Artifact reconciliation

Stores package
Defect Management Component
Test Management Component

Prioritization Static Analysis Track tests

Tracking Execute tests

60
Continuous Deployment
application Scenario 2

Fulfillment Execution Component

Release Design Component


Change Control Component
Deployment Management
Systems
Prioritization
Artifact storage &
retrieval Install/configure
Tracking
Target System

Risk Management Report configuration

Actual Report drift


package

CMDB Component

61
System testing
application Scenario 3

Fulfillment Execution Component

Deployment Management
Systems Defect Management
Test Management Component Component
Install/configure
Prioritization
Track tests
Report configuration
Execute tests Tracking

Report drift

Target System

62
Continuous deployment w/rollback
application Scenario 4

Fulfillment Execution Component

Rollback Rollback
Rollback
requested authorized
invoked

Event Management
Incident Management Change Control Component
Component Deployment Management
Component
Systems
Business rule
Alert Prioritization
management

Aggregation Tracking

Platform Specific
Svcs

Event

Service Monitoring CMDB Component


Component
Rollback
executed

Condition Dependency graph

Target System

63
KANBAN & QUEUING
WHAT is Kanban?

• In manufacturing, a visible
signal (e.g. return of an
empty parts bin) that a
work area needs to pull
more work.

• In IT services development
and operations, an
adaptable, shared visual
model that makes demand
and supply explicit
The challenge
Incident
• A given team’s Kanban board SR
may encompass Requirements, Work Order
Changes, Service Requests,
TODO DOING DONE
Work Orders, and even
Incidents and Problems.

Issue
Change
Release
Kanban impact on IT4IT

• We should be able to have


unified demand visibility across
all queues
• Understanding and managing
all “backlog” holistically
Service
Architecture
Enterprise
Architecture
ITIL and Queues in IT4IT
Functional Component and Datamodel underpinning ITIL and Queues
Knowledge &
Policy Requirement Defect Shop / Buy / Pay / Manage Problem Incident Q
Collaboration
Q Shopping
Cart ITIL
Knowledge Problem /
ITIL
Policy Requirement Defect Incident
Item Known Error
Q Q

Catalog Request Chargeback /


Proposal Project Test Rationalization Event Q
Aggregation Request Showback
ITIL Q & Offer Mgmt. ITIL
Chargeback
IT Contract IT Project Test Case Offer Subscription Event
Contract
Q

Usage Diagnostics & Service


Demand Service Build
Development Remediation Monitoring

Usage Service
Demand Source Build Run Book
Record Monitor
Q Q

Release Catalog Composition Change CMDB


Service Service Design Control
Portfolio Design Release & Design Fulfillment
RFC
Package Request ITIL
Q
Service
Design
Q Service
Catalog
Package Entry ITIL
Q
Conceptual Logical Service Desired
Conceptual Service Actual
Service Service Release Service
Service Release Service CIs
Blueprint Blueprint Blueprint Fulfillment Model
Execution

Strategy to
Requirement to Deploy Request to Fulfill Detect to Correct
Portfolio
How do I get involved?

• Open Group is a consortium model


• Your company needs to join the Open Group
and in particular the IT4IT Forum for full
participation in content development
• There is a LinkedIn group where questions
are discussed with the community and
suggestions can be raised
• This is the same as the Archimate and
TOGAF models
69
Benefits to standards participation

• It’s not just for product companies


• The knowledge sharing that comes is
beneficial for practitioners
– Meet peers struggling with the same issues
• Consider it as a form of staff development
– Intense, challenging, collaborative work
– Great for senior people bored with conferences
& classroom training
• Cost (including membership) is comparable
or cheaper than traditional training and
conferences

70
Questions/discussion

71

You might also like