Presentation on IT4IT standard delivered to Twin Cities Association of Enterprise Architects on September 12th, 2014

1. IT4IT Overview
Charles Betz

2. 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.

3. What we will cover
• Overview and positioning of IT4IT
• IT4IT governance
• IT4IT content
• IT4IT Agile workstream
• Getting involved
3

4. 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

5. Solving problems that every enterprise has
Building a reference architecture that allows IT to be a business innovation center
Policy
Management
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
Management
Conceptual
Service
Conceptual
Blueprint
Policy
Requirement
Management
Requirement
Defect
Management
Defect
Problem
Management
Problem
Incident
Management
Incident
Proposal
Management
(Investment)
IT Cont ract
Project
Delivery
Management
IT Project
Test
Management
Test Case
Catalog
Management
Of fer
Service Catalog
Ent ry
Subscription
Management
Subscription
Billing &
Chargeback
Chargeback
Record
Diagnostics &
Remediation
Runbook
Event
Management
Event
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
IT
Architecture
Management
IT Architecture
Service
Design
Management
Design Package
Logical Service
Blueprint
Change
Management
RFC
Configurat ion
Management
Actual Service CIs
Release
Management
Release Package
Service Release
Deployment
Management
Service
Release
Blueprint
Desired
Service CIs

6. 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
Efficiency
&
Finance & assets Agility
Sourcing & vendor
Intelligence & reporting
Resource & project
Governance, risk and compliance
IT Value Chain
Plan Build Deliver Run
Reference Architecture

7. 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
Pol icy
Management
Service
Portfolio
Management
Conceptual
Service
Conceptual
Blueprint
Policy
Requirement
Management
Requirement
Defect
Management
Defect
Problem
Management
Problem
Incident
Management
Incident
Proposal
Management
(Investment)
IT Cont ract
Project
Delivery
Management
IT Project
Test
Management
Test Case
Catalog
Management
Of fer
Service Catalog
Ent ry
Subscription
Management
Subscription
Bill ing &
Chargeback
Chargeback
Record
Diagnostics &
Remediation
Runbook
Event
Management
Event
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
IT
Architecture
Management
IT Architecture
Service
Design
Management
Design Package
Logical Service
Blueprint
Change
Management
RFC
Configurat ion
Management
Actual Service CIs
Release
Management
Release Package
Service Release
Deployment
Management
Service
Release
Blueprint
Desired
Service CIs
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

8. Enterprise
Architecture
Policy
Proposal
Demand
Service
Portfolio
IT4IT Reference Architecture v1.2
Fulfillment
Execution
Requirement Defect
Defect
Project Test
Service Build
Development
Release
Design
Service Design
Problem Incident
Change
Control
Event
Service
Monitoring
CMDB
Diagnostics &
Remediation
Knowledge &
Collaboration
Chargeback /
Showback
Usage
Request
Rationalization
Shop / Buy / Pay / Manage
Catalog
Aggregation
& Offer Mgmt.
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
Offer
Shopping
Cart
Release
Package
Service
Release
Service
Release
Blueprint
Build
Service
Catalog
Entry
Desired
Service
Model
Usage
Record
Fulfillment
Request
Subscription
Chargeback
Contract
Request
Problem /
Known Error
Knowledge
Item
Incident
Event
Service
Monitor
Run Book
RFC
Actual
Service CIs
Key Functional Components and underpinning Key Artifacts
Strategy to
Portfolio
Requirement to Deploy Request to Fulfill Detect to Correct

9. IT4IT Core Metamodel
Level 3: Vendor independent Architecture
Value Stream
*
Functional Component
Artifact 1
*
1..*
SoR
Integration
FC Function
Capability
Discipline
Scenario
*
*
*
*
* *
* *
1
*
Relationship
*
2 2
*
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

10. Class model for IT4IT Reference Architecture
Level 3: ArchiMate Notation Guide
L3 Element Representation
Value Chain
Value Stream
Capability
(Discipline)
Functional
Component
[Business Function]
Value Chain
[BusinessFunction]
Value Stream
[Business Function]
Capability Discipline
[Appl ication
Component]
Functional
Component
L3 Element Representation
Artifact
Essential Service
SoR Integration
[Data Object]
Artifact
[Application
Service] Essential
Service
[Application
Interaction] SoR
[Application
Collaboration] SoR

11. Standard positioning

12. 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
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

13. 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

14. IT4IT Consortium members (Sep 2014)
• HP
• AT&T
• Shell
• PwC
• Univ. S. Florida
• Accenture
• Munich Re
• Capgemini
• BP
• Logicalis
• UMBRiO
• Atos

15. IT4IT Content
Value
Stream
Context
Overview
Why it
matters
Deeper
dive
KPIs
High level
flow
Components
Reference
Architecture
Context
Detailed
Architecture

16. Strategy to Portfolio value stream
Sourcing & vendor
Creates a blueprint for optimizing the way you
manage your IT portfolio and investments to drive
business innovation
Efficiency
&
Finance & assets Agility
Intelligence & reporting
Resource & project
Governance, risk and compliance
IT Value Chain
Plan Build Deliver Run
Reference Architecture

17. 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

18. How a user-centric world impacts IT planning
Drive IT portfolio to business innovation
Strategy Service Portfolio Demand Selection
• 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

19. Why Strategy to Portfolio?
Designed to help with investing in the right services
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

20. Proving value KPIs
Using Strategy to Portfolio to quantify the value of portfolio planning
% of new investment
vs maintenance
Innovation
Capital % CapEx vs OpEx
Costs % planned vs actual
Demand By source and type
% satisfied customers
per service
Usage
Deficiencies in security
policies and standards
Compliance

21. Exploring Strategy to Portfolio
Strategy Service Portfolio Demand Selection
• 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

22. Strategy to Portfolio – major components
Strategy Service Portfolio Demand Selection
Enterprise
Architecture
Service
Portfolio
Demand Proposal

23. Problem Incident
Event
Service
Monitoring
V.1.2, Mar 20th 2014
This work is based upon material
developed and publ ished by t he
IT4IT Consort ium
Reference Architecture
Enterprise
Architecture
Policy
Proposal
Demand
Service
Portfolio
Fulfillment
Execution
Requirement Defect
Defect
Project Test
Service Build
Development
Release
Design
Service Design
Change
Control
CMDB
Diagnostics &
Remediation
Knowledge &
Collaboration
Chargeback /
Showback
Usage
Request
Rationalization
Shop / Buy / Pay / Manage
Catalog
Aggregation
& Offer Mgmt.
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
Offer
Shopping
Cart
Release
Package
Service
Release
Service
Release
Blueprint
Build
Service
Catalog
Entry
Desired
Service
Model
Usage
Record
Fulfillment
Request
Subscription
Chargeback
Contract
Request
Problem/
Known Error
Knowledge
Item
Incident
Event
Service
Monitor
Run Book
RFC
Actual
Service CIs
Strategy to Portfolio
Functional
component
Artifact
Entity
relationship
Service
model
Requirement to Deploy Request to Fulfill Detect to Correct

24. Strategy to Portfolio functional model
Requirement to Deploy
Requirement
Requirement to Deploy
Conceptual
Service
Blueprint
1:n
n:1
Service Portfolio
Demand
Demand
(rationalized)
Competency
(availability)
Budget
(estimate)
Assets
(availability)
Policy
Demand
Policy
Requirement
1:n
Service
Blueprint
Demand
Conceptual
Service
n:m
Project
IT Project
IT Contract
1:n
IT Contract
Service Design
Logical Service
1:n Blueprint
n:1
Roadmap
Demand
n:m
1:1
Enterprise Architecture
Business Process
Demand
1:n Policy
Proposal
V.1.2, Mar 20th 2014
This work is based upon material
developed and published by t he
IT4IT Consort ium
Functional Component - Key
Functional Component - Auxiliary
Service Model
Data Artifact – Key
Data Artifact – Auxiliary
Entity relationship
Record fabric Integration
Engagement dataflow
Current practice
Requirement to Deploy
Asset
Management
Business
Strategy
IT Financial
Management
Labor
Management
Problem
Problem,
Known Error
Detect to Correct
Service
Architecture
n:m

25. Requirement to Deploy value stream
Sourcing & vendor
Define, build, test, and deploy the right
service, at the right time, at the right cost
Efficiency
&
Finance & assets Agility
Intelligence & reporting
Resource & project
Governance, risk and compliance
IT Value Chain
Plan Build Deliver Run
Reference Architecture

26. 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

27. How a user-centric world impacts building services
Build what the business wants, when it wants it
Plan & design Develop Test Deploy
• 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

28. Why Requirement to Deploy?
Designed to help in building, sourcing and deploying quality services
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

29. Proving value KPIs
Using Requirement to Deploy to measure investment effectiveness
% of requirements – dev,
test, deploy Requirements
% of automated build,
tests, deploy Automation
% of project tasks or
cycles on time On time
% of detected vs closed
at release Defects
% of successful
deployments Deploy
Change % of emergency changes

30. Exploring Requirement to Deploy
Plan & design Develop Test 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

31. Requirement to Deploy – major components
Plan & design Develop Test Deploy
Service
Design
Service
Development
Requirements
Test
Build
Release Design
Fulfillment

32. Problem Incident
Event
Service
Monitoring
V.1.2, Mar 20th 2014
This work is based upon material
developed and publ ished by t he
IT4IT Consort ium
Reference Architecture
Enterprise
Architecture
Policy
Proposal
Demand
Service
Portfolio
Fulfillment
Execution
Requirement Defect
Defect
Project Test
Service Build
Development
Release
Design
Service Design
Change
Control
CMDB
Diagnostics &
Remediation
Knowledge &
Collaboration
Chargeback /
Showback
Usage
Request
Rationalization
Shop / Buy / Pay / Manage
Catalog
Aggregation
& Offer Mgmt.
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
Offer
Shopping
Cart
Release
Package
Service
Release
Service
Release
Blueprint
Build
Service
Catalog
Entry
Desired
Service
Model
Usage
Record
Fulfillment
Request
Subscription
Chargeback
Contract
Request
Problem/
Known Error
Knowledge
Item
Incident
Event
Service
Monitor
Run Book
RFC
Actual
Service CIs
Strategy to Portfolio
Functional
component
Artifact
Entity
relationship
Service
model
Requirement to Deploy Request to Fulfill Detect to Correct

33. Requirement to Deploy functional model
Proposal
Service Portfolio
Conceptual Service
Blueprint
Policy
Demand
Service Development Build
Problem
Management
Detect to Correct
IT Project
Demand
Strategy to Portfolio
1:1
Requirement
1:n
1:n
Source
1:n
Defect
1:n
RFC (Normal)
Service
Design
Package
1:n
Policy
1:n
1:n Service Catalog Entry
Defect
Defect
1:n
n:m
RFC
n:m
1:n
n:m
Requirements
Test
Test Case
Incident
Management
Detect to Correct
Strategy to Portfolio
Project
Build
Fulfillment Execution
Change Control
1:n 1:n 1:n
IT Contract
1:n
1:1
Logical Service
Blueprint
n:m
Service
Release
Release
Package Desired Service
Model
IT Contract
Strategy to Portfolio
Defect
Problem,
Known Error
1:1
n:1
1:n
1:n
1:1
Defect
Incidnet
IT Project
Requirement
Defect
1:1
Service Design
Catalog Composition &
Design
Request to Fulfill
V.1.2, Mar 20th 2014
This work is based upon material
developed and publ ished by t he
IT4IT Consort ium
Functional Component - Key
Functional Component - Auxiliary
Service Model
Data Artifact – Key
Data Artifact – Auxiliary
Entity relationship
Record fabric Integration
Engagement dataflow
Current practice
Request to Fulfill
Fulfillment Request
Release Package
Fulfillment
Request
1:n
Release
Design
Service
Release Blueprint
Strategy to Portfolio
Service Catalog Entry (Unbound)
RFC
1:n

34. Request to Fulfill value stream
Efficiency
Sourcing & vendor
Transition to a service broker model using an offer
catalog to manage subscriptions and route
fulfillments
&
Finance & assets Agility
Intelligence & reporting
Resource & project
Governance, risk and compliance
IT Value Chain
Plan Build Deliver Run
Reference Architecture

35. 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

36. How a user-centric world impacts delivering services
Catalog, fulfill, and manage services and track their usage
Define & publish Subscribe Fulfill Measure
• 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

37. Why Request to Fulfill?
Designed to help source and access quality services
Consumption
Consumers easily find
and subscribe via
self-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

38. Proving value KPIs
Use Request to Fulfill to quantify the value of self-service catalog subscriptions
Subscriptions per
period per service
Deliver
% self-service
requests
Costs
% of orders fulfilled
with automation
Speed
% of subscriptions
active or expiring
Broker
% of successful
deployments
Usage
% of subscriptions
requiring an incident
Satisfaction

39. Exploring Request to Fulfill
Publish Subscribe Fulfill Measure
• 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

40. Request to Fulfill – major components
Publish Subscribe Fulfill Measure
Catalog Request
Fulfillment Usage
Chargeback /
Showback
Shop / Buy / Pay / Manage

41. Problem Incident
Event
Service
Monitoring
V.1.2, Mar 20th 2014
This work is based upon material
developed and publ ished by t he
IT4IT Consort ium
Reference Architecture
Enterprise
Architecture
Policy
Proposal
Demand
Service
Portfolio
Fulfillment
Execution
Requirement Defect
Defect
Project Test
Service Build
Development
Release
Design
Service Design
Change
Control
CMDB
Diagnostics &
Remediation
Knowledge &
Collaboration
Chargeback /
Showback
Usage
Request
Rationalization
Shop / Buy / Pay / Manage
Catalog
Aggregation
& Offer Mgmt.
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
Offer
Shopping
Cart
Release
Package
Service
Release
Service
Release
Blueprint
Build
Service
Catalog
Entry
Desired
Service
Model
Usage
Record
Fulfillment
Request
Subscription
Chargeback
Contract
Request
Problem/
Known Error
Knowledge
Item
Incident
Event
Service
Monitor
Run Book
RFC
Actual
Service CIs
Strategy to Portfolio
Functional
component
Artifact
Entity
relationship
Service
model
Requirement to Deploy Request to Fulfill Detect to Correct

42. Request to Fulfill functional model
Project
This work is based upon material
developed and published by t he
IT4IT Consort ium
Functional Component - Key
Functional Component - Auxiliary
Service Model
Data Artifact – Key
Data Artifact – Auxiliary
Entity relationship
Record fabric Integration
Engagement dataflow
Current practice
Composite/Compound
Request Rationalization
CMDB
Actual
Service CIs
Detect to Correct
Release Design
Service Catalog
Entry (Bound)
1:n
Service
Release
Blueprint
Desired
Service
Model
Chargeback /
Showback
Chargeback Contract
Usage
Usage Record
Bill/Invoice
n:m
Service Catalog
Entry (Unbound)
Usage
Subscription
1:n
Request
Offer
Catalog
n:m
Offer
User Profile
n:m
1:1
Shopping Cart
Chargeback
Contract
n:m
1:n
Fulfillment
Request
1:n
Subscription
Service
Monitor
Catalog
Aggregation &
Offer Mgmt.
Request
Conversation
Knowledge
Item
Problem,
Known Error
n:m
n:m
Knowledge
Item
Knowledge &
Collaboration
Incident
Status
1:n
Service Catalog Entry
Fulfillment Execution
RFC
1:1
Detect to Correct
Catalog
Composition
& Design
Usage
RFC Request
Change
Control
Request
IT Supplier
(External to IT)
1:n
Engagement Experience Portal
1:n
1:1
IT Financial
Management
Service
Monitoring
Fulfillment
Engine & Deploy/
Provision Systems
Detect to Correct
Problem
Incident
Detect to Correct Detect to Correct
Shop / Buy / Pay / Manage
Self Service
Support
Requirement to Deploy
n:m
1:n
Request
1:m
n:1
Release
Package
Actual
Service
1:n CIs
Release
Package
IT Asset
Management
Supportive Function
IT Project
Fulfillment
Request
Service
Release
1:n
1:n
1:1
Requirement to Deploy
Supportive Function Supportive Function Supportive Function
V.1.2, Mar 20th 2014

43. Detect to Correct value stream
Sourcing & vendor
Bringing together IT service operations to
efficiently detect and correct issues before
impacting users
Efficiency
&
Finance & assets Agility
Intelligence & reporting
Resource & project
Governance, risk and compliance
IT Value Chain
Plan Build Deliver Run
Reference Architecture

44. 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

45. How a user-centric world impacts resolving issues
Anticipate and resolve service issues
Detect Diagnose Change Resolve
• 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

46. Detect to Correct to Portfolio?
Designed to help with investing in the right services
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

47. Proving value KPIs
Using Detect to Correct to quantify the value of IT operations improvements
Decrease mean time
to repair
Velocity
% of automated event
& incident resolutions
Costs
Increase in problems
identified & solved
Root cause
% of events and
incidents escalated
Effort
% of change related
outages
Teamwork
Satisfaction % of first call resolution

48. Exploring Detect to Correct
Detect Diagnose Change Resolve
• 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

49. Detect to Correct – major components
Detect Diagnose Change Resolve
Service
Monitoring
Event Incident Remediation
Configuration

50. Problem Incident
Event
Service
Monitoring
V.1.2, Mar 20th 2014
This work is based upon material
developed and publ ished by t he
IT4IT Consort ium
Reference Architecture
Enterprise
Architecture
Policy
Proposal
Demand
Service
Portfolio
Fulfillment
Execution
Requirement Defect
Defect
Project Test
Service Build
Development
Release
Design
Service Design
Change
Control
CMDB
Diagnostics &
Remediation
Knowledge &
Collaboration
Chargeback /
Showback
Usage
Request
Rationalization
Shop / Buy / Pay / Manage
Catalog
Aggregation
& Offer Mgmt.
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
Offer
Shopping
Cart
Release
Package
Service
Release
Service
Release
Blueprint
Build
Service
Catalog
Entry
Desired
Service
Model
Usage
Record
Fulfillment
Request
Subscription
Chargeback
Contract
Request
Problem/
Known Error
Knowledge
Item
Incident
Event
Service
Monitor
Run Book
RFC
Actual
Service CIs
Strategy to Portfolio
Functional
component
Artifact
Entity
relationship
Service
model
Requirement to Deploy Request to Fulfill Detect to Correct

51. Detect to Correct functional model
Self Service
Support
Defect
Defect
Requirement
to Deploy
Demand
Strategy to
Portfolio
Demand
Event
Event Incident
Event Incident
1:n n:m
Actual Service CIs
RFC
Service
Monitor
1:n
n:m
Problem,
Known Error
n:m
n:m
n:m
RFC
RFC
Problem RFC
Incident
Request to Fulfill
Fulfillment Execution
Demand
n:m
Usage
1:n
Run book
Run book
Runbook
n:m
Service Discovery
CI
Defect
Knowledge & Collaboration
Knowledge
Item
n:m
1:n
1:n
Request to Fulfill
Service
Monitor
n:m
Conversation
Knowledge Item
Run book
Interaction
n:m
1:1
Desired
Service
Model
1:1
1:1
Usage
Request to Fulfill
Defect
1:1
1:1
Shop/Buy/Pay/
Manage
Request to Fulfill
Status
Service
Monitoring
Incident Problem Change Control
Diagnostics &
CMDB Remediation
RFC
This work is based upon material
developed and published by t he
IT4IT Consort ium
Functional Component - Key
Functional Component - Auxiliary
Service Model
Data Artifact – Key
Data Artifact – Auxiliary
Entity relationship
Record fabric Integration
Engagement dataflow
Current practice
1:n
Request to Fulfill
Actual
Service
Fulfillment CIs
Request
V.1.2, Mar 20th 2014

52. Agile Enablement Workstream
IT4IT Consortium
Initial charter, scope, and direction
Draft 0.3 7/21/2014

53. 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.

54. 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 Kruchten
http://philippe.kruchten.com/2011/02/13/the-elephants-in-the-
agile-room/
We don’t need a
framework. Looks
pretty waterfall.

55. 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.

56. Lean & Agile ecosystem
56
Agile: IT applications of Lean
XP Scrum
Continuous
Integration Infrastructure as Code
Lean Philosophy
Lean Product
Management
DevOps/Continuous Delivery
Agile development
practices
Agile operations practices
Kanban
Deployment
Automation

57. DEVOPS TOOLCHAIN

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

59. 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

60. Continuous Integration
60
application Scenario 1
Fulfillment Execution Component
Build Management Component
Service Development Component (Source
Control)
Release Design Component
Dependency Management
Test Management Component
Track tests
Static Analysis
Execute tests
Artifact storage &
retrieval
Build package
Artifact storage & retrieval
Artifact reconciliation
Stores package
Defect Management Component
Prioritization
Tracking

61. Continuous Deployment
61
application Scenario 2
Fulfillment Execution Component
Release Design Component
Artifact storage &
retrieval
Deployment Management
Systems
Install/configure
Report configuration
Report drift
CMDB Component
Target System
Change Control Component
Prioritization
Tracking
Risk Management
Actual
package

62. System testing
62
application Scenario 3
Fulfillment Execution Component
Deployment Management
Systems
Install/configure
Report configuration
Report drift
Test Management Component
Track tests
Execute tests
Target System
Defect Management
Component
Prioritization
Tracking

63. Continuous deployment w/rollback
63
application Scenario 4
Fulfillment Execution Component
Deployment Management
Systems
Change Incident Management Control Component
Business rule
management Prioritization
Target System
Component
Event Management
Component
Aggregation
Tracking
Platform Specific
Svcs
Service Monitoring
Component
CMDB Component
Dependency graph
Rollback
authorized
Rollback
invoked
Event
Rollback
requested
Rollback
executed
Condition
Alert

64. KANBAN & QUEUING

65. 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

66. The challenge
• A given team’s Kanban board
may encompass Requirements,
Changes, Service Requests,
Work Orders, and even
Incidents and Problems.
Incident
SR
TODO DOING DONE
Change
Release
Issue
Work Order

67. Kanban impact on IT4IT
• We should be able to have
unified demand visibility across
all queues
• Understanding and managing
all “backlog” holistically

68. Enterprise
Architecture
Policy
Proposal
Demand
Service
Portfolio
ITIL and Queues in IT4IT
Fulfillment
Execution
Requirement Defect
Defect
Project Test
Service Build
Development
Release
Design
Service Design
Problem Incident
ITIL
Q
Q
Change
Control
Event
Service
Monitoring
CMDB
Diagnostics &
Remediation
Knowledge &
Collaboration
Chargeback /
Showback
Usage
Request
Rationalization
Shop / Buy / Pay / Manage
Catalog
Aggregation
& Offer Mgmt.
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
Offer
Shopping
Cart
Release
Package
Service
Release
Service
Release
Blueprint
Build
Service
Catalog
Entry
Desired
Service
Model
Usage
Record
Fulfillment
Request
Subscription
Chargeback
Contract
Request
Problem /
Known Error
Knowledge
Item
Incident
Event
Service
Monitor
Run Book
RFC
Q ITIL
Actual
Service CIs
Functional Component and Datamodel underpinning ITIL and Queues
Strategy to
Portfolio
Requirement to Deploy Request to Fulfill Detect to Correct
ITIL
Q
ITIL
Q
ITIL
Q
ITIL
Q
Q
Q
Q
Q
Q

69. 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

70. 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

71. Questions/discussion
71