Embed Size (px)
Citation preview
Hvad har vi gang i ?
Abstract
– Mange metoder bliver introduceret i IT til at understøtte ting som SAFe, DevOps etc. Typisk ændrer de radikalt måden man arbejder på, og introducerer nye værktøjer for at optimerer resultatet.
– Hvad man har gjort med IT4IT initiativet er en gang for alle definere de komponenter der udgør en ’toolchain’ på tværs af alle IT funktioner.
– I dette indlæg vil vi se på hvordan IT4IT er fokuseret på informationsmodellen på tværs af IT. Der ses på det ’store billede’ og de step der skal til at skabe værdi for IT for at kunne arbejde serviceorienteret i en hybrid verden med mange leverandører
Most IT organizations optimizing around
Process & technology silos
DevelopersBusiness Leader IT Engineer IT Operations UsersEnterprise Architect
Demand
Policy
Business Process Model
Requirement
Defect
Event
Incident, Problem
SubscriptionIT Project
AssetAsset
Physical
Service
Model
RFC
The problem – IT is changing and our customers are struggling
TRADITIONAL IT(Technology provider)
INDUSTRIALIZED IT(Service provider)
IT as a DIGITAL ENTERPRISE ACCELERATOR(Service broker)
• Project lifecycle governs investment• Process model controls workflow
• Project lifecycle governs investment• Process model expanded• Agile concepts introduced
• Service lifecycle governs investment• Formal IT operating model to support
modern workflow (agile, bi-modal, lean… )• Prescriptive IT systems model to power
This shift is triggered by technology disruptions (egcloud, mobility…) and can be realized by transitioning“people, process and technology”. A prescriptive recipe for IT would provide consistency to the journey
This shift is driven by business disruptions (eg digital enterprise) and is forcing a new style of IT. The journey requires transformation - a new culture, structure (operating model) along with the prescriptive design guide for service brokering in a multi-supplier environment
NEW
STYLENEW
TECH
Two foundation components: “Reference Architecture” and “IT Operating Model”
What is IT4IT™ ?
Reference Architecture “prescribes” the technology and information fabric for managing the business of IT
• Prescriptive guide enables end-end visibility of the service lifecycle
• First of its kind in IT industry (data-driven, functional focus)
• Process agnostic – customers can employ ITIL, COBIT …
• Methodology agnostic – customers can use agile, waterfall…
IT Operating Model framework “describes” the structure for managing the business of IT• Based on industry standard business principles (Porter’s Value Chain);
supports Lean, Kanban…
• Resonates with IT leaders, becomes the organizing principle for transforming to New Style of IT
• Fills a void in the industry (no formal IT operating model today)
Related Open Group Forums
IT4IT Activities in The Open Group
• EA Framework
• Harmonization
• Capability PlanningTOGAF
• EA modeling Language
• Adoption within IT4IT
• Capability PlanningArchimate
Joint activities & Sub Groups
• Capability Based Modeling (TOGAF &
Archimate)
• Harmonizing Archimate with UML
• Adopting Archimate in IT4IT
• IT4IT sub-groups:
• Service Lifecycle Management
• Agile integration to IT4IT
• IT Financial Management
• Intelligence and Reporting
• Adoption Workgroup
IT4IT Milestones:
Snapshot 1.3 released October 2014
2.0 in review, ratified by October 2015
People Certification: 10 / 2015; tool Certification: 2016
2.1 about to be ready, and 3.0 work has started
IT4IT™ – How it started Five years ago…
– Insufficiently integrated
toolsets to manage e2e.
– Inability to gain true insight,
hence inability to optimize.
– Lack of collaboration across
all IT competency centers.
– Immaturity to tackle trends
like cloud, mobility, devops.
Problem
Shell/HP partnership
IT4IT™ – How it started Five years ago…
12
– From inside-out focus to
outside-in value thinking.
– Provide solution guidance
to manage the business of
IT.
– Prescribe data integration
and insight via a model.
– Complement process
(what) with data (how to…).
Approach
IT4IT Customer Consortium– Insufficiently integrated
toolsets to manage e2e.
– Inability to gain true insight,
hence inability to optimize.
– Lack of collaboration across
all IT competency centers.
– Immaturity to tackle trends
like cloud, mobility, devops.
Problem
Shell/HP partnership
IT4IT™ – How it started Five years ago…
Requires a standard to drive market adoption
13
– From inside-out focus to
outside-in value thinking.
– Provide solution guidance
to manage the business of
IT.
– Prescribe data integration
and insight via a model.
– Complement process
(what) with data (how to…).
Approach
IT4IT Customer Consortium– Insufficiently integrated
toolsets to manage e2e.
– Inability to gain true insight,
hence inability to optimize.
– Lack of collaboration across
all IT competency centers.
– Immaturity to tackle trends
like cloud, mobility, devops.
Problem
Shell/HP partnership
Optimize the Business of IT
with quality Insight across the
complete Value Chain,
driving intelligent Decisions,
to deliver IT Services
Faster, Better, Cheaper,
and with less Risk
Value
IT4IT™ forum @ The Open Group
IT4IT™ is an official industry standard as
of Oct 20th, 2015
as in a stream of activities delivering value
The IT Value Chain has 4 IT Value Streams
Efficiency
&
AgilityFinance & assets
Intelligence & reporting
Resource & project
Governance, risk and compliance
Sourcing & vendor
IT V
alu
e C
hai
n
Plan Build Deliver Run
Service Model Backbone
Meet the IT value streams
16
Yourobjective
IT4ITprescription
End-to-end integrated Reference Architecture
Proactively detect issues
and take actions to correct them.
Run
Define your strategy to balance and broker your portfolio.
Plan
Prioritize every requirement to build/source the
best services and deploy them.
Build
Handle each request by
streamlining the process
to fulfill it.
Deliver
D2CR2FR2DS2P
Phases for each value stream
17
Service life cycle—on a repeatable, predictable, coherent and future safe reference architecture
Strategy to
Portfolio
– Align strategy
– Rationalize portfolio
– Prioritize backlog
– Manage investment
Requirement
to Deploy
– Plan & design
– Develop
– Test
– Deploy
Request to
Fulfill
– Define & publish
– Subscribe
– Fulfill
– Measure
Detect to
Correct
– Detect
– Diagnose
– Change
– Resolve
D2CR2FR2DS2P
The service model
18
Conceptual
Service Model
– Demand
– Policy
– Portfolio
Logical
Service Model
– IT project
– Requirement
– Release
Physical
Service Model
– Event
– Incident
– Change
The service model – assuring IT service transparency
Detect
to Correct
Request
to Fulfill
Requirement
to Deploy
Strategy
to Portfolio
Business PMO IT EngineerEnterprise Architect
Developers Testers IT Operations Users
D2CR2FR2DS2P
IT4IT™ reference architecture level 1
19
PolicyComponent
RequirementComponent
TestComponent
Offer Consumption Component ProblemComponent
Incident Component
ProposalComponent
Source Control
Component
BuildComponent
Offer ManagementComponent
Request Rationalization
Component
Chargeback/Showback
Component
Service LevelComponent
Event Component
PortfolioDemand
Component
ProjectComponent
Build Package
Component
CatalogCompositionComponent
Change Control
Component
UsageComponent
Diagnostics &RemediationComponent
Service Monitoring
Component
Enterprise Architecture Component
DefectComponent
ServicePortfolio
Component
ServiceDesign
Component
ReleaseCompositionComponent
Configuration Management
Component
Fulfillment Execution
Component
Policy Require-ment
TestCase
Problem/KnownError
Incident
ScopeAgree-ment
SourceCharge-
backContract
Build Offer
Subscrip-tion
ServiceContract
Event
PortfolioBacklog
Item
ITInitiative
BuildPackage
ServiceCatalog
Entry
RFC
UsageRecord
RunBook
ServiceMonitor
ServiceArchitec-
tureDefect
Request
Fulfill-ment
Request
ShoppingCart
Con-ceptualService
LogicalService
Blueprint
ServiceReleaseBlueprint
ActualService
CIs
DesiredServiceModel
ServiceRelease
Con-ceptualService
Blueprint
Strategy toPortfolio
Requirement to Deploy Request to Fulfill Detect to Correct
IT4IT™ is a trademark of The Open Group
Auxiliary data object
Key data object
Service model object
Entity relationship
Key functional component
This diagram is based on material developed by the IT4IT™ Forum of The Open Group – Oct 2015
Strategy to Portfolio phases and activities
20
– 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
Align Strategy Rationalize Portfolio Prioritize Backlog Manage Investment
S2P
Requirement to Deploy phases and activities
21
– IT Project plan
– Logical service model
– Requirements
– Functional & technical
– Standards & policies
– Development: Agile, iterative, waterfall …
– Source & set up development 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
Plan & Design Develop Test Deploy
R2D
Request to Fulfill phases and activities
22
– Merge catalog items from all fulfillment engines
– Set pricing, options and SLA
– Publish services
– Portal engagement
– Personalizedexperience
– Self-service
– Manage subscriptions
– Route fulfillments
– Automate deployment
– Use internal and external providers
– Integrate with asset, configuration and change systems
– Service usage measurement
– Chargeback/showback
– Cost transparency
– Surveys and ratings
Define & Publish Subscribe Fulfill Measure
R2F
Detect to Correct phases and activities
23
– See events, alarms and metrics across 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 run books
– Verify recovery
– Close records
Detect Diagnose Change Resolve
D2C
ReferenceArchitecture Overview
One model described through multiple abstraction levels (like other industry
standards)
What does the RA look like?
• Moves from generic overview to specific details
• Uses informal notation at Layer 1-2
• Uses formal notation (Archimate + UML) at Layer 3
• Useful to non-architect and architect audiences
• Layers 1-3 are defined/controlled by The Open Group
• Layers 4-5 are vendor owned/controlled for implementation and product positioning
Layer 1: End-to-End Overview
Layer 2: Value Stream Documentation
Layer 3: Vendor-independent Architecture
Layer 4: Vendor-specific Refinement Architecture
Layer 5: Solution Architecture
IT4IT RA 2.0: A few basic concepts
Functional Components denotes the essential components of
an IT4IT infrastructure. Functional Components deliver the
essential service that control the contained key data objects:
Relationship between .key data objects
Problem
Component
Incident
Component
Event
Component
Problem/Known Error
Incident
Event
Service Monitor
Service
Monitoring
Comp.
Configuration
Management
Component
Actual Service
CIs
Key Data Object objects that delivers end to end traceability of
what goes on in it: .
Service model Data Object.is special data object that describe
the service delivered by IT to its consumers
Service
Portfolio
Component
Portfolio
Demand
Component
Proposal
Component
Policy
Component
Service
Archite-
cture
Policy
Scope
Agree-
ment
Portfolio
Backlog
Item
Conceptual Service
Blueprint
Concep-
tual
Service
Enterprise
Architecture
Component
IT4IT RA 2.0:
Strategy to Portfolio (S2P)
Align IT portfolio with business
strategy and make sound investments
Strategy to
Portfolio
When IT strategy decides to
make a change in IT, a
scope agreement is
created. The scope
agreement references the
associated opportunity.
Part of strategy is to
maintain a set of policies
that IT must deliver on.
Some of the policies
relate to specific
services.When a business has new needs
(new or changed business
processes), or when performing
portfolio optimization, or operations
has issues that cannot be handled
without development, then an
opportunity needs to be logged with
a strategy as a new backlog item.
The Service Portfolio is
captured as a set of
conceptual service
designs – each with a
set of associated
blueprints that represent
a conceptual roadmap
for the service.
The link between the conceptual
service roadmap and the line of
business that ultimately sets the
goals of IT is the IT architecture for
the services that business needs.
Defect
Component
Requirement
Component
Project
Component
Test
Component
Build
Component
Source Control
Component
Require-
ment
IT
Initiative
Source
Logical
Service
Blueprint
Test
Case
Defect
Service
Release
Build
Service
Design
Component
Release
Composition
Component
Service
Release
Blueprint
Build
Package
Build Package
Component
Requirement
to Deploy
IT4IT RA 2.0: Requirement to Deploy (R2D)
Source what the business needs,
when it wants it
The IT Initiative is picked up by a
development organization and
managed through one or several
delivery/development projects.
Everything in the development
domain is managed through
projects.
Deployment can happen
in one of two ways –
either through a
traditional Change
Management process
where RFCs are
created based on the
content of the release
package or through
publishing the service
blueprints that R2F can
use.
Requirements are captured and, during a development project,
requirements are associated with the project and underlying
opportunity description. Which release will deliver what
requirement is also planned. Note this is also true if the project
is subcontracted or delivered as a COTS or external service.
The source for delivering a new release is controlled as a
source artifact associated with the design documented in the
design package and design templates.
Testing and any associated defect is related to the release under
Test.
A Release package assembles all
of the needed information to make
a release based on specific
deployment topologies and other
constraints.
Projects deliver a set of releases. The Release package is the
assembly of development artifacts that are part of a release.
Change
Control
Comp.
RFC
Usage
Component
Chargeback /
Showback
Comp.
Offer Mgmt.
Component
Offer Consumption Component
Offer
Service
Catalog
Entry
Desired
Service
Model
Usage
Record
Fulfill-
ment
Request
Sub-
scription
Charge-
back
Contract
Request
Catalog
Composition
Component
Shopping
Cart
Fulfillment
Execution
Comp.
Request
Rationalization
Component
Request to
Fulfill
IT4IT RA 2.0: Request to Fulfill (R2F)
Enable seamless consumption and monitor
usage
When a user wants a service from the catalog, a
subscription is created. A subscription has an
associated lifecycle.
Throughout the lifecycle of a service, requests can be
created against the service – initially create a service,
make modifications, and delete later on. The service
requests are defined in the blueprint.
Delivering a service is done through a fulfillment
request which will use the same mechanism as any
other deployment. This implies RFCs and Deployment
packages get in action.
Service catalog entries are
maintained in a service catalog
and represent what can be
ordered from IT. A service entry
is typically constructed from a
Service Blueprint.
Offers can be constructed based on the Service
Catalog entries. The offer adds details on approval
and cost, as well as controls what users can consume
which service.
When services are running, the system generates
usage records which are summarized in
chargeback/showback records associated with the
subscription.
Change
Control
Comp.
Problem
Component
Incident
Component
Event
Component
Diagnostics &
Remediation
Component
Problem/
Known
Error
Incident
Event
Service
Monitor
Run
Book
RFC
Service
Monitoring
Comp.
Configuration
Management
Component
Service Level
Component
Service
Contract
Actual
Service
CIs
Detect to
correct
IT4IT RA 2.0: Detect to Correct (D2C)
Anticipate and resolve business execution
issues
Service monitors are created as part of deploying services and
defines what needs to be monitored in the operations domain.
Incidents are created either by the help desk or event system,
which is the center for fixing issues in operations.
Problems are created by an incident system to indicate issues
that need deeper investigation and potential changes in the
configuration.
Problem or Incident Management might log a defect to later
releases of services, and/or potentially request a new release.
Based on definitions in service monitor, the event system
collects and correlates events from all of the operations.
Events, Incidents, or Problem investigations use run books to
diagnose and remediate issues.
Everything is tied together through the “Actual Service CIs”
information model for what has been deployed.
SLAs are defined, designed
and created vs. the service
along it’s lifecycle and then
captured in D2C.
High level overview of the end-end value chain using informal notation
Level 1
• Audience: non-architects
• Value streams defined
• Functional components named
• Data objects and relationships described
• Service model backbone formed
Functional Component
Data object
Entity relationship
Service model backbone
Detailed rendering of each value stream using informal notation
Level 2
Requirement Component
Requirement to Deploy
1:n
n:1
Portfolio
Backlog
Item
Portfolio Backlog
Item (rationalized/
Prioritized)
Competency
(availability) Assets
(availability)
Policy
Portfolio
Backlog Item
Policy
Requirement
1:n
Conceptual
Service
Blueprint
Portfolio
Backlog
Item
Conceptual
Service
Conceptual
Service
Blueprint
n:m
Project Component
IT Initiative
Scope Agreement
1:n Scope Agreement
Service Design Component
Logical Service
Blueprint1:n
Portfolio Demand
Component
Service Portfolio
Component
n:m
Business Process
Portfolio Backlog Item
n:1Policy
Component
Proposal
Component
Requirement to Deploy
Requirement to Deploy
IT Asset
Management
Business
Strategy
Labor
ManagementProblem Component
Problem, Known ErrorDetect to Correct
Service
Architecture
Enterprise Architecture
Component
n:m
1:1
Portfolio Backlog
Service Model
Data Artifact – Key
Record fabric Integration
Entity relationship
Functional Component - Key
Functional Component - Auxiliary
Data Artifact – Auxiliary
Engagement dataflow
Current practice
This diagram was developed/published by the IT4IT™ Forum of The Open Group™
Supportive Function
Investment Portfolio Comp.
ITFM Supportive Function
IT Budget
n:m
n:1
Cost Modeling Component
ITFM Supportive Function
IT Cost Modeln:1
• Audience: non-architects + architects
• Relationships between data objects defined in greater detail (eg cardinality)
• Functional components defined in detail
• Auxiliary and supporting functional components identified
Example: Strategy to Portfolio
Vendor independent architecture using formal notation (ArchiMate & UML)
Level 3
• Audience: architects
• Scenarios + capabilities
• Essential services
• Attributes of data objects (UML)
[Functional Component] Event [Functional Component] Incident
[Value Stream] Detect to Correct
[Capability Discipline] Event Management [Capability Discipline] Incident Management
[Essential Service]Register Event
[Essential Service]Acknowledge Event
[Essential Service]Register Incident
[Essential Service]Manage IncidentEvent Incident
[Functional Component] Diagnostics & Remediation
Root CauseAnalysis
PerformRemediation
* *
«ItemDefinition»
Incident
- GlobalId :String
- State :IncidentStateEnum
- Name :String
- Description :String
- Solution :String
- CreateTime :DateTime
- LastModifiedTime :DateTime
- ResolutionTime :DateTime
- ClosedTime :DateTime
«enumeration»
IncidentStateEnum
new
created
assigned
wip
resolved
resolution_confirmed
closed
Essential Service
Essential Attributes (for data objects)
Vendor specific architecture
Level 4-5
• Audience: architects, practitioners, vendors
• Owned/controlled by product vendors
• Unique vendor extensions
• Implementable model with product mapping (Reference Implementation)
Project Component
Actual Service CIsDetect to Correct
Configuration
Management
Component
Release
Composition
Component
1:n
Service Release
Blueprint
Desired
Service
Model
Request Rationalization
Component
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
Offer Mgmt.
Component
Request
Knowledge
Item
Incident
Status1:n
Service Catalog Entry
n:m
Fulfillment Execution
Component
RFC
1:1
Detect to Correct
Catalog
Composition
Component
Usage
Component
Chargeback /
Showback
Component
RFCRequest
Change Control
Component
Composite/Compound
Request
IT Supplier
(External to IT)
1:n
Engagement
Experience Portal
1:n
1:1
IT Financial
Management
Service
Monitoring
Component
Fulfillment
Engine & Deploy/
Provision Systems
Detect to Correct
Knowledge &
Collaboration
Supportive Function Detect to Correct
Incident
Component
Offer Consumption Component
Requirement to Deploy
n:m
1:n
Request
1:n
n:1
Service Catalog
Entry (Bound)
Actual
Service
CIs1:nRelease
Package
IT Asset
Management
Supportive Function
Fulfillment
Request
Requirement to Deploy
Supportive Function
Service Level
Comp.
Detect to Correct
Service
Contract
(Template)
Service
Level
Status
Service Contract
1:1Service Contract (Instance)
Service Model
Data Artifact – Key
Record fabric Integration
Entity relationship
Functional Component - Key
Functional Component - Auxiliary
Data Artifact – Auxiliary
Engagement dataflow
Current practice
This diagram was developed/published by the IT4IT™ Forum of The Open Group™
Self Service
SupportKnowledge Collaboration
Conversation
Service Catalog
Shopping Cart
CSA, SM, AM
AM UCMDB BSM Suite
Propel
Propel Portal
SM, SAW
SM, SAW
SM, SAW CSA, SM, SA,
NA, SE, DMA,
OO
Propel SX
Propel Catalog CSA + AM
PPM, ALM, AgM,
SAW
BSM, SM,
SAW
Codar
R2F V.2.0May 14
th 2015
IT4IT is the framework to drive HPE Transformation Areas
Transformto a hybridinfrastructure
Protectyour digitalenterprise
Enableworkplaceproductivity
Empowertheir data-drivenorganization
Transform to a Service Broker
Transform to a Service Integrator
Transform to a Service Supplier
– IT4IT sits at the centre of the 4 HPE plays and is most readily associated with Transform to a Hybrid Infrastructure
– Within this, every IT organization is playing a combination of 3 fundamental roles – Service Broker, Service Integrator and Service Supplier: managed well, these 3 roles deliver true value to their business
– These roles function with the support of the IT4IT Value Chain
HPE Software supports all 3 roles with IT4IT-based solutions
– The key roles map to the Reference Architecture through direct, indirect and associated capabilities across the value streams
– Our software solutions map to the Reference Architecture in such a way as to support end-to-end delivery of value to our customers in exactly the manner that the Value Streams are intended.
– Our Model Offices provide real, demonstrable examples of how the 3 roles are fulfilled through a series of Use Cases to show our customers the value which can be achieved through the adoption of IT4IT, irrespective of their existing technology landscape: http://intranet.hp.com/sw/main/SoftwareField/PS/Portfolio/Pages/page.aspx?q=ModelOffice
Service Broker Service Integrator Service Supplier
IT4IT Transformation Planning OfferingCustomer Journey Flowchart
Executive Briefing e.g. CIO
Brief MgmtTeam/ Senior Stakeholders
Identify Current State & Next
Steps
Map outputs to
Capabilities
Detailed stakeholder interviews
Extend route to value for customer
Workshop Preparation(1-2 wks)
Share Roadmap & Results with Stakeholders
Conduct Transformation
Workshop
Proceed to Transformation
Planning?
Customer expression of interest
Customer Facing Deck (CFD)
Agile Discovery(2-3 hours)
Create Backlog for
Agile Delivery
Extended Agile Discovery(~1wk per
value stream)
Value of IT4IT seen?
Capability Heatmap, & Value
Roadmap
Transformation Roadmap
Solution Delivery
Transformation Workshop
Executive Briefing (free) Transformation Planning, 4-8 weeks, 2 FTE ($)
Discovery option
Workshop Option
IT4IT & Other Standards
IT4IT vs ITILSimple comparison
41
IT4IT ITIL
Prescriptive Descriptive
Architectural origins and focus. Structured consistently with TOGAF
and Archimate. Value stream, capability, data, system views
Primarily narrative
Solution orientation Oriented to practitioner education rather than solution
Fundamental focus on the end to end flow of IT value streams across
IT capabilities. Specified as a conceptual data model for IT4IT and a
set of functional system needed to maintain the data model
Oriented to deep discussion of individual silo functions. Beyond
overall lifecycle, little emphasis on cross capability/function
flows
Mutually exclusive and comprehensive, rigorously avoiding ambiguity
and overlap in its architectural catalogs
Ambiguous and overlapping terminology in places
Precise representation of data and integration patterns in complex IT
management domain
Limited utility to planners and architects attempting to integrate
IT management infrastructure.
Understanding of Agile and DevOps trends. Waterfall, top-down planning orientation.
Agile and iterative, open development process. Long term history of proprietary ownership, not transparent.
Multi-year revision cycle
Goals
Model landscape graphical overview
42
COBIT
IT4
IT R
efe
rence Im
ple
me
nta
tions
(ve
nd
or-
sp
ecific
)
DeliverPlan Build Run
ITIL
TOGAF, PRINCE2, PMI, …
Pro
ce
sse
s
Systems
IT4IT Reference Architecture Level 1 V.2.0
IT4IT™ is a trademark of The Open Group
The Open Group IT4IT™ standard to Run the Business of IT
Technical Standard2011 2012 2013 2014 2015
IT4IT
2.0 Std.
10/2015
RA 2.0
(level 3)
7/2015
RA 1.2
(level 3)
3/2014
RA 0.5
(level 1)
8/2012
Value Chain
9/2011
RA 1.3
(level 3)
10/2014
RA 1.0
(level 2)
1/2013
• ~5000 downloads
• ~800 organizations
• ~74 countries
• Pocket Guide “Hot Seller”
• ~600 downloads
Original Consortium
• Shell
• Hewlett-Packard (IT & SW)
• Achmea
• MunichRe
• Accenture
• Pricewaterhouse Coopers
• University of South Florida
• AT&T
02/2016
What makes IT4IT™ unique?
Data-Driven
• IT standards are predominantly
process (ITIL) or technology
(NIST) focused.
• A data focus provides flexibility to
support a wide variety of process
and technology choices
“Future proof”
• Not designed around products or
process frameworks
• Flexibility to accommodate for
changes in technology, process,
methodology or business models
Practical
• Built through collaboration of IT
professionals and vendors.
• Designed for actual use and to be
prescriptive versus being
theoretical and left open to
interpretation
• Enterprise-scale focus
Vendor Agnostic
• Controlled by an independent
standards organization
(The Open Group)
• Eliminates concern over vendor
lock-in / product agendas
Proven
• Used successfully by/with
customers to help guide
transformation and to resolve
tactical issues in IT execution.
• Customers get it and love it.
Needed
• There are useful standards in
process and technology domains
but none at the operating model
and service lifecycle level which
has limited progress in making IT
an enabler of the digital
enterprise
