Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

IT4IT Overview (A new standard for IT management)

30,761 views

Published on

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

IT4IT Overview (A new standard for IT management)

  1. 1. IT4IT Overview Charles Betz
  2. 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. 3. What we will cover • Overview and positioning of IT4IT • IT4IT governance • IT4IT content • IT4IT Agile workstream • Getting involved 3
  4. 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. 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. 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. 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. 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. 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. 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. 11. Standard positioning
  12. 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. 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. 14. IT4IT Consortium members (Sep 2014) • HP • AT&T • Shell • PwC • Univ. S. Florida • Accenture • Munich Re • Capgemini • BP • Logicalis • UMBRiO • Atos
  15. 15. IT4IT Content Value Stream Context Overview Why it matters Deeper dive KPIs High level flow Components Reference Architecture Context Detailed Architecture
  16. 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. 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. 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. 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. 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. 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. 22. Strategy to Portfolio – major components Strategy Service Portfolio Demand Selection Enterprise Architecture Service Portfolio Demand Proposal
  23. 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. 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. 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. 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. 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. 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. 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. 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. 31. Requirement to Deploy – major components Plan & design Develop Test Deploy Service Design Service Development Requirements Test Build Release Design Fulfillment
  32. 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. 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. 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. 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. 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. 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. 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. 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. 40. Request to Fulfill – major components Publish Subscribe Fulfill Measure Catalog Request Fulfillment Usage Chargeback / Showback Shop / Buy / Pay / Manage
  41. 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. 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. 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. 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. 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. 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. 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. 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. 49. Detect to Correct – major components Detect Diagnose Change Resolve Service Monitoring Event Incident Remediation Configuration
  50. 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. 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. 52. Agile Enablement Workstream IT4IT Consortium Initial charter, scope, and direction Draft 0.3 7/21/2014
  53. 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. 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. 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. 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. 57. DEVOPS TOOLCHAIN
  58. 58. Agile principles 58 • Correctly apply economics • Avoid waste • Maximize information • Manage for flow under uncertainty • Build effective culture • Build effective software pipeline
  59. 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. 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. 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. 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. 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. 64. KANBAN & QUEUING
  65. 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. 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. 67. Kanban impact on IT4IT • We should be able to have unified demand visibility across all queues • Understanding and managing all “backlog” holistically
  68. 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. 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. 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. 71. Questions/discussion 71

×