IT4IT Overview (A new standard for IT management)

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 hiswife 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

Building a reference architecture that allows IT to be a business innovation center

Solving problems that every enterprise has

Plan Build Deliver Run

Why create a customer consortium• History of every new initiative reinventing IT foundations • Issues are industry independent

What and next steps• End-to-end business service lifecycle for existing/future paradigms• Open standardization process

How• With broad integrated processes to deliver higher value than silos• Support for industry process models like ITIL and COBIT

Service Portfolio

ManagementConceptualService

ConceptualBlueprint

PolicyManagement

Policy

Requirement Management

Requirement

DefectManagement

Defect

ProblemManagement

Problem

IncidentManagement

Incident

ProposalManagement

(Investment)

IT Contract

Project Delivery

Management

IT Project

TestManagement

Test Case

Catalog Management

Offer

Service Catalog Entry

Subscription Management

Subscription

Billing &Chargeback

Chargeback Record

Diagnostics & Remediation

Runbook

EventManagement

Event

Business Architecture Management

Business Architecture

DemandManagement

Demand

Service Development Management

Source

BuildManagement

Deployment Package

Request &Routing

Management

Fulfillment Request

UsageManagement

Usage Record

ServiceMonitoring

Service Monitor

IT Architecture Management

IT Architecture

Service Design

ManagementDesign Package

Logical Service Blueprint

ChangeManagement

RFC

Configuration Management

Actual Service CIs

ReleaseManagement

Release Package

Service Release

Deployment Management

ServiceReleaseBlueprint

DesiredService CIs

Designed by customers like you over the last 2 years using real world use casesBased on Porter’s value chain and lean manufacturing value streams concepts

Leveraging business value chain success in IT

Value streams

Efficiency

&

AgilityFinance & assets

Intelligence & reporting

Resource & project

Governance, risk and compliance

Sourcing & vendor

Requirement

to Deploy

Detect

to Correct

Strategy

to Portfolio

Request

to Fulfill

IT V

alu

e C

hain

Plan Build Deliver Run

Reference Architecture

Supp

ort a

ctiviti

es

Service Portfolio

ManagementConceptualService

ConceptualBlueprint

PolicyManagement

Policy

Requirement Management

Requirement

DefectManagement

Defect

ProblemManagement

Problem

IncidentManagement

Incident

ProposalManagement

(Investment)

IT Contract

Project Delivery

Management

IT Project

TestManagement

Test Case

Catalog Management

Offer


Subscription Management

Subscription

Billing &Chargeback

Chargeback Record


Runbook

EventManagement

Event

Business Architecture Management

Business Architecture

DemandManagement

Demand

Service Development Management

Source

BuildManagement

Deployment Package

Request &Routing

Management

Fulfillment Request

UsageManagement

Usage Record

ServiceMonitoring

Service Monitor

IT Architecture Management

IT Architecture

Service Design

ManagementDesign Package


ChangeManagement

RFC

Configuration Management

Actual Service CIs

ReleaseManagement

Release Package

Service Release

Deployment Management

ServiceReleaseBlueprint

DesiredService CIs

IT Value Chain integration prescription delivers end-to-end traceability

Realizing a service-centric style of IT

Service lifecycle – on a repeatable, predictable, coherent and future safe reference architecture

Strategy to Portfolio

• Plan• Demand• Policy• Selection

Requirement to Deploy

• Build• Develop• Test• Release

Request to Fulfill

• Deliver• Publish• Subscribe• Fulfill

Detect to Correct

• Run• Monitor• Diagnose• Change

Enterprise Architecture

Service Portfolio

Demand

Proposal

Policy

Fulfillment Execution

DefectRequirement

Project Test

BuildService Development

ReleaseDesignService Design

ChangeControl

CMDB

Service Monitoring

Problem Incident

Event


Knowledge & Collaboration

Usage

Chargeback / Showback

Request Rationalization

Catalog Aggregation & Offer Mgmt.

Shop / Buy / Pay / Manage

Catalog Composition & Design

Service Architecture

Policy Requirement

IT Contract IT Project

Demand Source

Conceptual Service

Blueprint

Conceptual Service

Service Design

Package

Logical Service

Blueprint

Test Case

Defect

Offer

Shopping Cart

Release Package

Service Release

Service Release

Blueprint

Build

Service Catalog

Entry

Desired Service Model

Usage Record

Fulfillment Request

SubscriptionChargeback

Contract

Request

Problem /Known Error

Knowledge Item Incident

Event

Service MonitorRun Book

RFC

Actual Service CIs

Key Functional Components and underpinning Key ArtifactsIT4IT Reference Architecture v1.2

Strategy to Portfolio Requirement to Deploy Request to Fulfill Detect to Correct

Level 3: Vendor independent Architecture

IT4IT Core Metamodel

Functional Component

Value Stream

*

Artifact1

*

1..*

SoR Integration

FC Function

Capability Discipline

Scenario*

*

*

*

**

* *

1

*

Relationship*22

*

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

Attribute

1

*

Essential Service

1..*0..1

1

1

1..*

*

1..*1

Level 3: ArchiMate Notation Guide

Class model for IT4IT Reference Architecture

L3 Element Representation

Value Chain

Value Stream

Capability (Discipline)

Functional Component

[Business Function]Value Chain

[BusinessFunction]Value Stream

[Business Function]Capability Discipline

[ApplicationComponent]Functional

Component

L3 Element Representation

Artifact

Essential Service

SoR Integration

[Data Object]Artifact

[ApplicationService] Essential

Service

[ApplicationCollaboration] SoR

[ApplicationInteraction] SoR

Standard positioning

ITIL positioning in detail ITIL IT4ITPositioning Framework describing functions/capabilities/disciplines. Information model driven reference architecture,

supportive of multiple process frameworks.

Origins “Best” or “good” practice origins intended for broad audience of executives, managers, and individual contributors.

Originated out of needs identified by enterprise architects and IT managers for clearer implementation and integration guidance

Methodology Primarily unstructured narrative. “Process” (similar to what enterprise architects would term function) is the primary unit of analysis.

Structured consistently with TOGAF and Archimate. Value stream, capability, data, system views.

Orientation Oriented to practitioner education rather than solution Solution orientation

Value approach Oriented to deep discussion of individual silo functions/processes. Beyond overall service lifecycle, does not emphasize longer lived value flows.

Focused on the end to end flow of four high level IT value streams (Strategy to Portfolio, Requirement to Deploy, 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 architects attempting to integrate IT management infrastructure.

Precise representation of data and integration patterns in complex IT management domain

Agile Implicit waterfall, top-down planning orientation. Explicit coverage of Agile and DevOps trends. Maintenance process Long term history of proprietary ownership. Multi-year

revision cycle Open development process

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• AT&T• Shell• PwC• Univ. S. Florida• Accenture

• Munich Re• Capgemini• BP• Logicalis• UMBRiO• Atos

IT4IT Content

ValueStream

Context Overview Why it

mattersDeeper

dive KPIs High level flow

ComponentsReference

Architecture Context

Detailed Architecture

Strategy to Portfolio value stream

Creates a blueprint for optimizing the way you manage your IT portfolio and investments to drive business innovation

Value streams Efficiency

&



Resource & project


Sourcing & vendor

Requirem

ent

to Deploy

Detect

to Correct

Strategy

to Portfolio

Request

to Fulfill

IT V

alue

Cha

inPlan Build Deliver Run


Sup

port

activ

ities


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

Drive IT portfolio to business innovation

How a user-centric world impacts IT planning

• Bottom-up tactical monitoring

• Manual data collection and correlation

• Support / enhance core business process

• Resource capacity – big teams, inflexible skills

• 2 year planning windows, quarterly reviews

• Cost reduction and reliability

• 70:30 KTLO to innovation

• Apps focus: business process efficiency

• Ops focus: stability, “change is evil”

• Top-down goals

• KPI monitored via aggregated measures

• Real-time, automated, integrated

• New user end points and edges of process

• Agile teams, multi-sourced, flexible skills

• 4 quarterly rolling planning/ bi-weekly CEO review

• Business innovation and reliability become table stakes

• 20:80 KTLO to innovation

• Sourcing/brokering

• Risk and security

• Customer impact (loyalty, revenue)

Planned economy

Market economy

Common

Next wave


Designed to help with investing in the right services

Why Strategy to Portfolio?

Holistic demand

Across PMO, enterprise architecture, service portfolio and business

Business priorities

Decisions are based on business needs

Data consistency

Reliability and trust based on consistent data across services

Financial visibility

Information on investment activity and value realization

Traceability

Link from business request to what was delivered

Communication

With business stakeholders through service roadmaps

Using Strategy to Portfolio to quantify the value of portfolio planning

Proving value KPIs

% of new investment vs maintenanceInnovation

% planned vs actualCosts

% CapEx vs OpExCapital

By source and typeDemand

% satisfied customers per serviceUsage

Deficiencies in security policies and standardsCompliance

Exploring Strategy to Portfolio


• Define objectives

• Align business and IT roadmaps

• Set up standards and policies

• Enterprise architecture

• Service portfolio rationalization

• Create service blueprint and roadmap

• Consolidate demand

• Analyze priority, urgency, and impact

• Create new or tag existing demand

• Business value, risk, costs, benefits & resources

• What-if-analysis

• Ensure governance

Strategy to Portfolio – major components



Service Portfolio

Demand Proposal

This work is based upon material developed and published by the IT4IT Consortium

V.1.2, Mar 20th 2014


Service Portfolio

Demand

Proposal

Policy


DefectRequirement

Project Test


ReleaseDesign

Service DesignChange Control

CMDB

Service Monitoring

Problem Incident

Event



Usage







Policy Requirement


Demand Source

Conceptual Service

Blueprint

Conceptual Service

Service Design

Package

Logical Service

Blueprint

Test Case

Defect

Offer

Shopping Cart

Release Package

Service Release

Service Release Blueprint

Build

Service Catalog

Entry


Usage Record

Fulfillment Request


Contract

Request

Problem/Known Error

Knowledge Item

Incident

Event

Service Monitor

Run Book

RFC

Actual Service CIs



Service model

Artifact

Entity relationship

Functional component

Requirement to Deploy Request to Fulfill Detect to Correct

Strategy to Portfolio functional model

Requirement


1:n

n:1

Demand

Demand(rationalized)

Competency(availability)

Budget(estimate)

Assets(availability)

Policy

Demand

Policy

Requirement

1:n

Service Blueprint

Demand

Conceptual Service

Conceptual Service

Blueprint

n:m

Project

IT Project

IT Contract

1:n IT Contract

Service DesignLogical Service

Blueprint1:n

n:1

Roadmap

Demand

Service Portfolio

n:m

1:1

Business Process

Demand

1:n Policy

Proposal

V.1.2, Mar 20th 2014

Service Model

Data Artifact – Key

Record fabric Integration

Entity relationship

Functional Component - Key

Functional Component - Auxiliary

Data Artifact – Auxiliary

Engagement dataflow

Current pract ice




Asset Management

BusinessStrategy

IT Financial Management

Labor Management

Problem

Problem, Known Error

Detect to Correct



n:m

Requirement to Deploy value stream

Define, build, test, and deploy the right service, at the right time, at the right cost


&



Resource & project


Sourcing & vendor

Requirem

ent

to Deploy

Detect

to Correct

Strategy

to Portfolio

Request

to Fulfill

IT V

alue

Cha



Sup

port

activ

ities


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

Build what the business wants, when it wants it

How a user-centric world impacts building services

• Manual deployment

• Wastage of assets: performance scripts, known bugs, etc.

• Manual configurations and stubs

• Driven top-down

• Everyone in one building

• Exhaustive definition

• Abstract

• Contractual

• Test only; code=black box

• Lead time for environments

• Treated as ‘last mile’

• Automated deployment

• Asset reuse between Apps and Ops

• Composite and virtualized

• Automatic connections

• Empowered, entrepreneurial and distributed

• Just enough

• Experiential

• Story-based /interpretive

• Insight into code changes

• Auto deploys for dev/test

• Continual testing

4 months

1 week

Common

Next wave


Designed to help in building, sourcing and deploying quality services

Why Requirement to Deploy?

Reuse

Reuse of services and requirements becomes the norm

Time to market

Faster time to market for service realization

Supplier Info

Increased traceability and benchmarking of internal and external suppliers

Financial visibility

Improved inputs to IT Financial Management on full service cost

Predictable

Control point facts about quality, utility, security and cost

Policy compliance

Across security, risk, enterprise architecture & finance

Using Requirement to Deploy to measure investment effectiveness

Proving value KPIs

% of requirements – dev, test, deployRequirements

% of project tasks or cycles on timeOn time

% of automated build, tests, deployAutomation

% of detected vs closed at releaseDefects

% of successful deploymentsDeploy

% of emergency changesChange

Exploring Requirement to Deploy


• IT Project plan

• Logical service model

• Requirements

• Functional & technical

• Standards & policies

• Development: Agile, iterative, waterfall …

• Source & set up dev environment

• Version control

• Developer testing

• Functional: desktop, web, mobile

• Performance: desktop, web, mobile

• Security: static, dynamic

• Release plan

• Change and configuration process

• Knowledge management

• Application and security monitors

Requirement to Deploy – major components


Service Design

Service Development

Requirements

Test

Release Design

Build

Fulfillment


V.1.2, Mar 20th 2014


Service Portfolio

Demand

Proposal

Policy


DefectRequirement

Project Test


ReleaseDesign


CMDB

Service Monitoring

Problem Incident

Event



Usage







Policy Requirement


Demand Source

Conceptual Service

Blueprint

Conceptual Service

Service Design

Package

Logical Service

Blueprint

Test Case

Defect

Offer

Shopping Cart

Release Package

Service Release


Build

Service Catalog

Entry


Usage Record

Fulfillment Request


Contract

Request

Problem/Known Error

Knowledge Item

Incident

Event

Service Monitor

Run Book

RFC

Actual Service CIs



Service model

Artifact

Entity relationship



Requirement to Deploy functional model

Proposal

Service Portfolio

Policy

Demand


Problem Management

Detect to Correct

IT Project


Demand

Requirement

1:n

1:n

Source

1:n

Defect

1:n

RFC (Normal)

1:n

Service Design

Package

Policy

Defect

Defect1:n

n:m

RFC

n:m

1:n

n:m

Requirements

Test Case

Test

Incident Management

Detect to Correct


Conceptual ServiceBlueprint

Project


Change Control

1:n 1:n 1:n

1:1

IT Contract

1:n

1:1


n:m

Service Release

Release Package Desired Service

Model

IT Contract


Defect

Build


1:1

n:1

1:n

1:n

Defect

1:1

Incidnet

IT Project

Requirement

Defect

1:1

Service Design

Service Model



Entity relationship




Engagement dataflow

Current pract ice


V.1.2, Mar 20th 2014


Service Catalog Entry1:n

Request to Fulfill

Request to Fulfill

Fulfillment Request

Release Package

Fulfillment Request

1:n

ReleaseDesign



Service Catalog Entry (Unbound)

1:n

RFC

1:n

Request to Fulfill value stream

Transition to a service broker model using an offer catalog to manage subscriptions and route fulfillments


&



Resource & project


Sourcing & vendor

Requirem

ent

to Deploy

Detect

to Correct

Strategy

to Portfolio

Request

to Fulfill

IT V

alue

Cha



Sup

port

activ

ities

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

Catalog, fulfill, and manage services and track their usage

How a user-centric world impacts delivering services

• Blanket allocations

• Anecdotal service quality reports

• Generic, email/forms-driven

• Fragmented

• Politicized (“who you know”)

• Paper-based

• Built to order

• Multiple hand-offs

• Stranded capacity, “naked” services not monitored in rollout or production

• Pay per use

• Continual user experience measurement and management

• Automated and personalized

• Aggregated (one-stop shop)

• Automated

• Configured to order

• Automated workflow

• Management by exception, instrumented from request to release

• Optimized for consumption

Bureaucratic

Self-serve

Common

Next wave

Define & publish Subscribe Fulfill Measure

Designed to help source and access quality services

Why Request to Fulfill?

Consumption

Consumers easily find and subscribe viaself-service

Single catalog

Single offer catalog with multiple fulfillment providers

Service broker

Transition from request management to broker

Efficiency

Standard subscription process with policies and automation

Traceability

Across subscription, usage and chargeback

Cost optimization

Recover expired and unused subscriptions and licenses

Use Request to Fulfill to quantify the value of self-service catalog subscriptions

Proving value KPIs

Subscriptions per period per serviceDeliver

% self-service requestsCosts

% of orders fulfilled with automationSpeed

% of subscriptions active or expiringBroker

% of successful deploymentsUsage

% of subscriptions requiring an incidentSatisfaction

Exploring Request to Fulfill


• Mash up catalog items from all fulfillment engines

• Set pricing, options and SLA

• Publish services

• Portal engagement

• Personalized experience

• Self-service

• Manage subscriptions

• Route fulfillments

• Automate deployment

• Use internal and external providers

• Integrate with change, asset & config systems

• Service usage measurement

• Chargeback / showback

• Cost transparency

• Surveys and ratings

Request to Fulfill – major components


Catalog Request


Fulfillment Usage



V.1.2, Mar 20th 2014


Service Portfolio

Demand

Proposal

Policy


DefectRequirement

Project Test


ReleaseDesign


CMDB

Service Monitoring

Problem Incident

Event



Usage







Policy Requirement


Demand Source

Conceptual Service

Blueprint

Conceptual Service

Service Design

Package

Logical Service

Blueprint

Test Case

Defect

Offer

Shopping Cart

Release Package

Service Release


Build

Service Catalog

Entry


Usage Record

Fulfillment Request


Contract

Request

Problem/Known Error

Knowledge Item

Incident

Event

Service Monitor

Run Book

RFC

Actual Service CIs



Service model

Artifact

Entity relationship



Request to Fulfill functional model

Project

Service Model



Entity relationship




Engagement dataflow

Current pract ice


Actual Service CIs

Detect to Correct

CMDB

Release Design

1:n




Usage Record

Chargeback Contract

Bill/Invoice

Service Catalog Entry (Unbound)

Usage

Usage

Subscription

1:n

Request

Offer Catalog

n:m

Offer

User Profile

n:m

1:1

Shopping Cart

Chargeback Contract

n:m

Fulfillment Request

1:n

1:n

Subscription

Service Monitor

CatalogAggregation &Offer Mgmt.

Request

Conversation

Knowledge Item


n:m

n:m

Knowledge Item


Incident

Status

1:n


n:m


RFC

1:1

Detect to Correct

Catalog Composition

& Design

Usage


RFC Request

Change Control

Composite/Compound Request

IT Supplier (External to IT)

1:n

Engagement Experience Portal

1:n

1:1

IT Financial Management

Service Monitoring

FulfillmentEngine & Deploy/Provision Systems

Detect to Correct

Problem

Detect to Correct Detect to Correct

Incident

Shop / Buy / Pay / ManageSelf Service

Support


n:m

1:n

Request

1:m

n:1

Service Catalog Entry (Bound)

Release Package

Actual Service

CIs1:nRelease Package

IT Asset Management

Supportive Function

IT ProjectFulfillmentRequest

Service Release

1:n

1:n

1:1


Supportive FunctionSupportive FunctionSupportive Function

V.1.2, Mar 20th 2014

Detect to Correct value stream

Bringing together IT service operations to efficiently detect and correct issues before impacting users


&



Resource & project


Sourcing & vendor

Requirem

ent

to Deploy

Detect

to Correct

Strategy

to Portfolio

Request

to Fulfill

IT V

alue

Cha



Sup

port

activ

ities

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

Anticipate and resolve service issues

How a user-centric world impacts resolving issues

• Patch in prod

• “Snowflake” systems (unique, fragile)

• Tribal knowledge for resolution

• Static infrastructure

• 1:1 resource to service

• Designed to test

• Isolated impact

• Reactive

• Multi-sourcing “blind spots”

• Triage and manual forensics

• Feared

• By-committee

• CAB controls change

• Dev/QA controls regression tests

• Repeatable, automated change

• Social-IT for enterprise collaboration

• Dynamic infrastructure, shared everything

• Designed to operate

• Complex failure modes

• Predictive

• Multi-disciplinary and guided forensics

• Automated triage (“flight data recorders”)

• Expected, continual and automated

• CAB controls change to automation and regression tests

• Dev/Ops collaboration

Local, procedural

Virtual, dynamic

Common

Next wave


Designed to help with investing in the right services

Detect to Correct to Portfolio?

Efficiency

End-to-end visibility to quickly identify and resolve

Collaboration

Common language with consistent data and shared configuration

Traceability

Across event, incident, change and resolution

Cost

Reduce tickets, war rooms and duplicate work

Risk

Defined business impact and reduced clannish knowledge

Improvement

Shorter mean time to repair and more uptime

Using Detect to Correct to quantify the value of IT operations improvements

Proving value KPIs

Decrease mean time to repairVelocity

% of automated event & incident resolutionsCosts

Increase in problems identified & solvedRoot cause

% of events and incidents escalated Effort

% of change related outages Teamwork

% of first call resolutionSatisfaction

Exploring Detect to Correct


• See events, alarms and metrics across the entire infrastructure

• Understand user issues

• Trace the relationship between events

• Enrichment

• Root cause

• Severity and business impact

• Defined escalation path

• Auto-fixed common issues

• Define change request

• Perform problem and risk analysis

• Approve

• Implement change

• Leverage runbooks

• Verify recovery

• Close records

Detect to Correct – major components


Service Monitoring

Event Incident Remediation

Configuration


V.1.2, Mar 20th 2014


Service Portfolio

Demand

Proposal

Policy


DefectRequirement

Project Test


ReleaseDesign


CMDB

Service Monitoring

Problem Incident

Event



Usage







Policy Requirement


Demand Source

Conceptual Service

Blueprint

Conceptual Service

Service Design

Package

Logical Service

Blueprint

Test Case

Defect

Offer

Shopping Cart

Release Package

Service Release


Build

Service Catalog

Entry


Usage Record

Fulfillment Request


Contract

Request

Problem/Known Error

Knowledge Item

Incident

Event

Service Monitor

Run Book

RFC

Actual Service CIs



Service model

Artifact

Entity relationship



Detect to Correct functional modelSelf Service

SupportDefect


Defect

Demand

Strategy toPortfolio

Demand

IncidentEvent

Actual Service CIs

RFC

ServiceMonitor

1:n

1:n n:m

n:m


n:m

n:m

n:m

Event Incident

RFC

RFC

Problem RFC

Incident

Request to Fulfill


Demand

n:m

Usage

1:n

Runbook

Run book

Run book

n:m

Service DiscoveryCI

Defect


Knowledge Item

n:m

1:n

1:n

Request to Fulfill

ServiceMonitor

n:m

Conversation

Knowledge ItemRun book

Interaction

n:m

1:1


1:1

1:1

Usage

Request to Fulfill

Defect

1:11:1

Shop/Buy/Pay/Manage

Request to Fulfill

Status

ServiceMonitoring

Incident Change ControlProblem

Diagnostics & RemediationCMDB

Event

RFC

Service Model



Entity relationship




Engagement dataflow

Current pract ice


1:n

Request to Fulfill

Actual Service

CIsFulfillment Request

V.1.2, Mar 20th 2014

Agile Enablement WorkstreamIT4IT Consortium

Initial charter, scope, and directionDraft 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

• Some suspicion which may reflect on IT4IT– EA perceived as “ivory tower bureaucracy”– 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

Kruchtenhttp://philippe.kruchten.com/2011/02/13/the-elephants-in-the-agile-room/

We don’t need a framework. Looks pretty waterfall.

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

56

Lean Philosophy

Agile: IT applications of Lean

Lean Product Management

DevOps/Continuous Delivery

Agile development practices

Agile operations practices

Kanban

XP Scrum

Continuous Integration Infrastructure as Code

Deployment Automation

DEVOPS TOOLCHAIN

Agile principles

58

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

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

60

application Scenario 1

Build Management Component

Fulfi l lment Execution Component

Service Development Component (SourceControl)

Release Design Component

Test Management Component

Track tests

Execute tests

Static Analysis

Artifact storage &retrieval

Build package

Dependency Management

Artifact reconcil iation

Artifact storage & retrieval

Stores packageDefect Management Component

Prioritization

Tracking

Continuous Deployment

61


Fulfil lment Execution Component

Release Design Component

Artifact storage &retrieval

Deployment ManagementSystems

Install/configure

Report drift

Report configuration

CMDB Component

Target System

Change Control Component

Prioritization

Tracking

Risk Management

Actualpackage

System testing

62


Fulfil lment Execution Component


Install/configure

Report drift

Report configuration

Test Management Component

Track tests

Execute tests

Target System

Defect ManagementComponent

Prioritization

Tracking

Continuous deployment w/rollback

63


Fulfi l lment Execution Component


Target System

Change Control ComponentIncident ManagementComponent

Event ManagementComponent

Aggregation

Business rulemanagement Prioritization

Tracking

Platform SpecificSvcs

Service MonitoringComponent

CMDB Component

Dependency graph

Rollbackauthorized Rollback

invoked

Event

Rollbackrequested

Rollbackexecuted

Condition

Alert

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

• A given team’s Kanban board may encompass Requirements, Changes, Service Requests, Work Orders, and even Incidents and Problems.

Incident

SR

ChangeRelease

TODO DOING DONE

Issue

Work Order

Kanban impact on IT4IT

• We should be able to have unified demand visibility across all queues

• Understanding and managing all “backlog” holistically


Service Portfolio

Demand

Proposal

Policy


DefectRequirement

Project Test


ReleaseDesignService Design

ChangeControl

CMDB

Service Monitoring

Problem Incident

Event



Usage







Policy Requirement


Demand Source

Conceptual Service

Blueprint

Conceptual Service

Service Design

Package

Logical Service

Blueprint

Test Case

Defect

Offer

Shopping Cart

Release Package

Service Release

Service Release

Blueprint

Build

Service Catalog

Entry


Usage Record

Fulfillment Request


Contract

Request

Problem /Known Error

Knowledge Item Incident

Event

Service MonitorRun Book

RFC

Actual Service CIs

Functional Component and Datamodel underpinning ITIL and QueuesITIL and Queues in IT4IT

Strategy to Portfolio Requirement to Deploy Request to Fulfill Detect to Correct

ITIL

Q

ITIL

Q ITIL

Q

ITIL

Q

ITIL

Q

ITIL

Q

Q

Q

Q

Q

Q

Q

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

IT4IT Overview (A new standard for IT management)

Presentations & Public Speaking

higher value

business value chain

porters value chain

it4it strategy board

it4it overviewcharles

enterprise architect

business of itlaunching

runreference architecture