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.

Integrating architecture and itil

5,912 views

Published on

When a company invests in ITIL, very often Architecture is not much involved: this is a mistake because there is much overlap, and Architecture can end up side-lined by the ITIL juggernaut. But there are a lot of benefits Architecture can bring to an ITIL-oriented organization.

This slide deck goes a step or two further than the white-papers out there I've found to date in providing some concrete guidance on how to actually integrate Architecture activities into ITIL. The deck uses TOGAF as the reference framework, but the concepts can be applied to any modern Architecture practice, since the discussion focuses on the types of deliverables and activities, which analogously exist in most frameworks.

Published in: Technology

Integrating architecture and itil

  1. 1. Integrating Architecture and ITIL Best Practices, Part 1 Warren Weinmeyer Aug. 2014
  2. 2. Table of Contents • Executive Summary ………………………………………………Slides 05-09 • The Case for Integration ………………………………………Slides 12-14 • TOGAF & ITIL as Deming Cycles …………………………Slides 16-19 • Foundational IT Lifecycle & IT Levels ……………………Slides 21-26 • Architecture & IT Roles at Different IT Levels………Slides 28-30 • TOGAF Integration by ITIL Stage & Process…………Slides 32-58 • Other Important Aspects of Integration ………………Slides 60-62 2
  3. 3. 3 Introduction • This slide deck attempts to offer some concrete guidance on how Architectural activities and outputs can be integrated into the ITIL framework • The focus is on integrating into ITIL processes
  4. 4. A brief summary for Managers (and for you TL;DR types)… 4
  5. 5. There’s LOTS of overlap between the focus areas of Architecture and ITIL High Low 5 Maturity of Best Practices Operational Tactical Strategic Activity Type Architecture Med ITIL Architecture has further reach and more sophisticated guidance for strategic activities, while ITIL better covers daily operational activities
  6. 6. TOGAF and ITIL are examples of a Deming Cycle. When colour-coded against the Deming Cycle steps and plotted over the generic IT lifecycle, you can see they have a good synergy (at a high level). Continual Service Improvement Service Operation 6 Prelim
  7. 7. Architecture & ITIL operate at multiple levels of IT (their areas of focus as well as their activities are different at different levels). At each layer, Architecture and ITIL require coordination and integration. 7
  8. 8. Here is a 1-page look at integrating Architecture outputs into ITIL
  9. 9. You need to consider Process, Data and Governance to get a complete picture of the integration. • Process (to a certain level of detail) is covered in this deck 9
  10. 10. 10
  11. 11. This is the beginning of the main slide deck. Let’s start off with some general background… 11
  12. 12. ITIL and Architecture: The Case for Integration • Historically, EA has not been active in ITIL initiatives • A Forrester paper says that even today most ITIL programs still have little involvement from EA • The belief seems to be that these are different worlds and different concerns • However, both ITIL and Architecture have expanded their frameworks over time and now have significant overlap 12
  13. 13. ITIL and Architecture: The Case for Integration • You may have seen this diagram in some whitepapers that discuss integrating TOGAF with ITIL • This view illustrates how TOGAF can complement ITIL’s weakness in Strategic matters and vice-versa for Operational matters • Two challenges with this diagram: • The way it’s laid out leaves an initial impression that Architecture and ITIL are nice complementary halves of the whole, not heavily-overlapping frameworks • This only looks at Enterprise Architecture: what about the Architecture practice as a whole? 13 Strategic ITIL Tactical Operational EA
  14. 14. ITIL and Architecture: The Case for Integration • This diagram perhaps more realistically illustrates the type of overlap between the two frameworks • In the Operational area, ITIL provides SLA concepts that Architecture doesn’t talk about. • In the Strategic area, ITIL does not address anything above the level of portfolio of Services • There’s a lot of area in between where integration is required • Note: This may not reflect your specific company: • Many companies do not try to implement all of ITIL • Many companies do not have a modern and/or comprehensive Architecture practice High Low 14 Maturity of Best Practices Operational Tactical Strategic Activity Type Architecture Med ITIL
  15. 15. Synchronization of processes is an important part of integration, so let’s take a moment to compare the TOGAF and ITIL lifecycles… 15
  16. 16. TOGAF and ITIL Are Modified Deming Cycles • The Deming Cycle is an iterative process (originating in the manufacturing sector) for quality management and continuous improvement. • It consists of 4 steps: • Plan: Establish objectives • Do: Implement the plan • Check: Study the results • Act: Adjust to bring results in line with objectives • TOGAF and ITIL are all about quality control and continuous improvement 16 Are we doing the right things? Plan Act Deming Cycle netting the expected Check Do Are we doing things right? Are the results benefits? Are we getting the expected results?
  17. 17. TOGAF as a Modified Deming Cycle 17 • Here is a diagram of TOGAF’s ADM (architecture development method). Colour-coding is used to map TOGAF stages to Deming Cycle steps. • Quality control and continuous improvement entails: • iterating and going back to previous steps when necessary • constant cross-references between Requirements as they evolve versus the architecture specifications as they evolve. • assessing gaps, redundancies and performance of delivered architectures • defining future states with capability maturity models and roadmaps, • transitional architectures to guide progress to the future state.
  18. 18. ITIL as a Modified Deming Cycle 18 • Here is a diagram of ITIL’s lifecycle. Colour-coding is used to map ITIL phases to Deming Cycle steps. • Quality control involves defining expected levels of service and metrics to assess whether levels are met. • Continuous improvement involves a formal 7-step quality improvement process. • Note: The size of the pie slices are not meant to indicate the relative time or focus dedicated to any particular phase
  19. 19. TOGAF and ITIL Overlaid as a Deming Cycle 19 • Overlaying ITIL with TOGAF shows that, at a high level, the two frameworks sync up pretty well in terms of the main Deming-type focus of each of their respective steps. • When we dive a little deeper into the activities of each step in these frameworks, we see the picture is a little more complicated, because several TOGAF phases actually bridge ITIL phases • We will go through that later on in this deck
  20. 20. Now let’s see how Architecture and ITIL relate to different levels of IT… 20
  21. 21. The Foundational Annual IT Lifecycle 21 • Even companies that have implemented ITIL tend to keep to a traditional, fundamental annual rhythm that has 3 basic phases: • Planning for the upcoming year • Executing Delivery projects that were identified in the planning stage • Maintaining delivered solutions as part of corporate operations • Includes the monitoring, operating and supporting of systems
  22. 22. ITIL in the Foundational IT Lifecycle Service Operation 22 • If we plot ITIL stages onto the basic IT lifecycle, we see a pretty close alignment with the basic IT organization lifecycle. • Service Transition straddles Delivery and Operations because that phase begins with the final phases of a delivery project and continues through the warranty period of the delivered solution operating in Production Continual Service Improvement
  23. 23. TOGAF and ITIL in the Foundational IT Lifecycle Continual Service Improvement Service Operation 23 Prelim • Overlaying ITIL with TOGAF shows us how TOGAF phases relate to the ITIL lifecycle • Phase B is shown as straddling the Strategy and Design stages because TOGAF allows for the scenario where the is little or no pre-existing Business Architecture and so work needs to be done to get buy-in for the key Business objectives, to build Business Strategy and Vision if there isn’t one, etc. • Phase F bites into Service Transition because the transition plan is finalized in Phase F, and is one of the first things completed in Service Transition • Phase G straddles Design and Transition because TOGAF specifies that IT projects happen during that phase • Phase H has aspects of Continual Service Improvement: that is where operational monitoring as well as monitoring for changes in the environment occurs. Changes in the Business environment can result in changes to the service strategy and architecture vision.
  24. 24. The Basic Lifecycle Exists at Multiple Levels of IT 24 • The top level is at the level of IT as an organization • The second level is typically a portfolio of some kind, which can be based on a Capability, on related technologies, on the Business Unit customer, etc. Portfolios typically consist of multiple systems or services. • The third level is typically a Service or system • These levels are “typical” – your org may be different
  25. 25. The Basic Lifecycle Exists at Multiple Levels of IT 25 • At the IT Level: • Involves strategically prioritizing and sequencing Business demand • Governance of delivery and change management • Centralized Help Desk function • At the Portfolio Level: • Involves identifying and planning strategic capability enhancements • Management and synchronization of projects impacting the portfolio technical landscape • Identifying capability gaps and redundancies in the technical landscape of the portfolio • Managing the portfolio information landscape • At the Service Level: • Involves identifying and planning service improvements • Managing delivery projects • Managing the introduction of new solutions into the technical landscape • Operating, monitoring, supporting and maintaining solutions
  26. 26. Architecture & ITIL Exists at Multiple Levels of IT 26 • IT Organization level: • ITIL is concerned with building a service catalog, assigning service ownership roles and responsibilities, and coordinating and standardizing Service Design approaches • Architecture is focused on EA concerns, such as the business priorities, investment prioritization, architectural governance (standards, arch. patterns and compliance) and future-state visioning/planning • Portfolio/segment level: • Architecture is concerned with portfolio management and capability planning. • IT Service level: • ITIL lifecycle and practices are applied to each Service • Architecture complements ITIL with specific best practices applied across the ITIL lifecycle and is concerned with the application of Solution Architecture practices within service delivery projects
  27. 27. Let’s get a little bit more specific regarding what Architecture and ITIL contribute at the different IT levels. 27
  28. 28. Architecture & ITIL Roles – IT Organization Level 28 • Architecture supports with: • Best practices: • Strategic Planning • Models: • Strategy/Motivation • Capability/Value Chain • Analytics: • Demand/Opportunity strategic value interdependencies, redundancies and synergies assessments • Governance: • Standards and Patterns • Strategic Alignment • ITIL supports with: • Processes: • Change Management • Help Desk/Support • Governance: • Organizational structures • Functional Role Definitions • Service Portfolio • Standardized Processes • Models: • CMDB
  29. 29. Architecture & ITIL Roles – IT Portfolio Level 29 • Architecture supports the IT portfolio lifecycle with: • Best practices: • Strategic Planning • Master Data Management • Models: • Maturity • Strategy/Motivation • Capability Development Roadmaps • Analytics: • Portfolio capability gaps and redundancies • Program/Project interdependencies, redundancies and synergies • ITIL does not address the IT portfolio level
  30. 30. Architecture & ITIL Roles – IT Service Level 30 • Architecture supports with: • Best practices: • Strategic Planning • Business Process Modeling/Improvement • SOA • Models: • Strategy/Motivation • Process • Solution Architectures • Analytics: • System interdependencies/interactions • Governance: • Technology Standards • ITIL supports with: • Processes: • Service Lifecycle Management • Change Management • Continuous Improvement • Capacity Planning • Governance: • Service/Process Owners and Stewards • Service Level Agreements
  31. 31. Now let’s zoom in for a look at some concrete ways of integrating TOGAF into the ITIL lifecycle. 31
  32. 32. TOGAF Integration by ITIL Stage and Process • Here’s a basic view of TOGAF and ITIL without any of the lifecycle flow arrows • Using this view, we are going to build a mid-level mapping of Architecture activities and deliverables against each ITIL process • We will also indicate which TOGAF phase will govern the interaction with the ITIL process
  33. 33. TOGAF Integration by ITIL Lifecycle Stage • Strategy Mgmt. involves determining how to manage IT Services to optimize their value to the organization • At the IT level, this means the IT Service strategy as a portfolio of services • At the Service level, this means doing strategic planning for a service • The TOGAF Preliminary phase provides basic guiding context at both the IT level and for individual services • Verify the opportunity, the buy-in, the level of organizational capability and maturity, and the organizational model • Phase A supports the identification of the relevant Stakeholders, Vision, Principles and Strategy, and assessing strategic alignment and readiness for Business Transformation • Phase B supplies Business context: Value Chains & Processes, Requirements, and Operating Models
  34. 34. TOGAF Integration by ITIL Lifecycle Stage • Business Relationship Management (BRM) involves identifying customer needs and ensuring that an IT service provider can meet these needs, now and as customers' needs change over time • The Preliminary phase can accommodate preparation for building relationships and for doing strategic planning • Create understanding of the stakeholders, their expectations, build the organizational model, and assess the business capability maturity • Phase A provides strategies & roadmaps from Business and IT, and supports the modeling of Stakeholders’ Concerns and the Vision, Principles and Strategy. As well, assessing organizational readiness for Business Transformation • Phase B supports creation of Business and Process models, and the capture of Requirements & Drivers
  35. 35. TOGAF Integration by ITIL Lifecycle Stage • Financial Management involves ensuring the management of a service is undertaken with due consideration of the value, risks, benefits, and costs of the service • Phase A provides relevant strategies & roadmaps from Business and IT, as well as strategic alignment/value assessments of services and supporting elements • Phase B provides insights regarding the relevant Business requirements, along with risk/impact assessments of relevant Business Cases
  36. 36. TOGAF Integration by ITIL Lifecycle Stage • Demand Management involves interpreting and influencing customer demand for services, as well as providing capacity to meet those demands • Creating PBAs (Pattern of Business Activity) and UPs (User Profile) to make demand patterns more predictable • Creating SLPs (Service Level Package) to satisfy the PBAs • The Preliminary Phase provides the Stakeholder Framework, which describes the Stakeholder types, their roles and responsibilities and their standard Concerns • Phase A provides specific stakeholders’ Concerns, as well as roadmaps from Business and IT, to inform on potential future demand. • Phase B provides Business processes, requirements & drivers, to inform on potential future demand and required service levels
  37. 37. TOGAF Integration by ITIL Lifecycle Stage • Service Portfolio Mgmt. involves determining which IT services to include and how those services will be tracked throughout their lifecycles • At the IT level, this means governing and managing the Service Portfolio, and identifying new needed services • At the Service level, this means launching a new service or identifying required changes to one • The Preliminary phase provides the opportunity, buy-in and approval, the Capability landscape and Service taxonomy, and the organizational model needed to support a new service and the Portfolio • Phase A provides strategic alignment and readiness assessments for services • Phase B supplies Value Chains and Processes, and Requirements needed for establishing the Business Case for a new service • Phase H shows changes in the enterprise that trigger new or changed services
  38. 38. TOGAF Integration by ITIL Lifecycle Stage SS Stage Summary • As indicated in the high-level view, the Preliminary Phase, Phase A and parts of Phase B provide integral inputs to ITIL’s Service Strategy stage • Also as per the high-level view, Phase H provides a continuous improvement feedback loop into the Service Strategy stage
  39. 39. TOGAF Integration by ITIL Lifecycle Stage • Design Coordination involves ensuring quality and consistent design practices and documents and coordinating design activities across projects • At the IT level, this means EA and PPM types of governance • At the Service level, this means launching and governing IT projects and SA governance • Phase A provides the strategic alignment and value assessments for project proposals (PPM), and Business/IT strategies and roadmaps (EA). At the SA level, it supports the definition of project Vision, Principles and Objectives, & Risk/Impact Assessments. • Phase B supports the discovery of functional Requirements, as well as the identification of roles, activities, organizational units and capabilities involved in the solution. • Phases C & D provide… (next slide)…
  40. 40. TOGAF Integration by ITIL Lifecycle Stage • Phases C & D provide Data and Technical standards and patterns (EA), support the discovery of non-functional and security Requirements, and elaboration of the logical information and technical characteristics of the required solution (SA). • Phase E supports the RFx and solution selection and assessment processes within IT projects and the specification of the physical architecture of the solution • Phase F supports the valuation and coordination of proposed capability enhancements across services (EA), as well as supports the creation of solution implementation and migration plans (SA) • Phase G supports the construction of deployment environments as well as the creation of oversight architecture documents for solution deployment and validation
  41. 41. TOGAF Integration by ITIL Lifecycle Stage • Service Level Management involves negotiating SLAs and ensuring that they are adhered to through monitoring, reporting and soliciting customer feedback • Phase B provides Business strategy and service functional Requirements and supports mapping these to the existing capabilities of the service. • Phases C & D provide the security and non-functional Requirements, and support mapping these to the existing capabilities of the service. • Phase H supports monitoring of the operational solutions supporting the service, and assessing their compliance with functional, non-functional and security Requirements
  42. 42. TOGAF Integration by ITIL Lifecycle Stage • Service Catalog Mgmt. involves ensuring that there is a central, accurate, and consistent source of data about all operational services and about all services being transitioned to the live environment • Phase B provides solution stakeholder maps to help identify Business-facing services and their customers • Phases C & D provide information and technical models and landscapes to feed and validate CIs in the CMDB and service catalog.
  43. 43. TOGAF Integration by ITIL Lifecycle Stage • Availability Mgmt. involves measurement, monitoring, analysis, and reporting of the availability, reliability and maintainability of the service • Phase A provides enterprise strategy, principles and policies regarding high-availability and disaster recovery to guide proactive planning of service availability requirements • Phase D provides reference architectures, patterns and standards for reliably attaining required availability levels from solutions supporting the service.
  44. 44. TOGAF Integration by ITIL Lifecycle Stage • Capacity Mgmt. involves ensuring that the maintenance and growth of IT resource capacity (compute, bandwidth, storage,) is aligned to the requirements of service customers and the preservation of required service levels • Phase B provides Business capacity Requirements from across the enterprise (EA) • Phase D provides current capacity for components of the shared infrastructure (EA) and specific solutions (SA) • Phase F provides timelines for projected additional capacity and capacity requirements from architectural roadmaps (EA)
  45. 45. TOGAF Integration by ITIL Lifecycle Stage • Supplier Mgmt. involves ensuring that suppliers meet the terms, conditions, and targets of their contracts and agreements & optimizing the value from the supplier services • Phase C provides information principles and master data management policies (EA), as well as information management and privacy requirements for the data processed or hosted by the supplier (SA) • Phase D provides security principles and guidelines (EA), as well as non-functional and security requirements for the solutions developed or hosted by the supplier
  46. 46. TOGAF Integration by ITIL Lifecycle Stage • Info Security Mgmt. involves ensuring that availability, confidentiality, integrity and authenticity of information and systems is maintained by managing risks and monitoring for compliance • Phase A provides info-sec and information mgmt. strategy, principles and policies (EA) • Phase B provides user roles, role access privileges, and use-cases • Phase C provides info-sec, information mgmt., and privacy patterns and standards, as well as data flow profiles across solutions (EA) • Phase D provides security patterns, standards (EA) as well as solution deployments specifications of interface points and security mechanisms (SA) • Phase G provides security architecture compliance assessments of solution specifications (EA) • Phase H provides changes in business environment
  47. 47. TOGAF Integration by ITIL Lifecycle Stage • Service Continuity Mgmt. involves ensuring that required IT technical and service facilities can recommence within required timescales by maintaining continuity and recovery plans in compliance with SLAs, perform Business Impact and Risk assessments and DR testing • Phase A provides DR/BC strategy & principles (EA) • Phase B provides Business Impact assessments, Risk Assessments, as well as Return to Operations (RTO), Recovery Point Objectives (RPO) specs and other BC requirements (SA) • Phase C provides data restore processes (SA) • Phase D provides DR patterns & standards (EA) & solution deployments • Phase G provides solution DR/BC compliance assessments (SA) • Phase H provides changes in the business environment (EA)
  48. 48. TOGAF Integration by ITIL Lifecycle Stage SD Stage Summary • As one would expect, there are numerous points of integration between TOGAF and ITIL at the Service Design stage • The nature of the various points of integration includes both EA and SA activities • The Design Coordination high-level process is umbrella beneath which IT development projects are spun up and executed, but Design Coordination does not actually manage or execute the projects. • This is analogous to the relationship between IT projects and TOGAF’s Phase G.
  49. 49. TOGAF Integration by ITIL Lifecycle Stage • Release and Deployment Mgmt. involves guiding the planning, scheduling, building, testing, and deployment of releases • Phase F assists in the coordination of the solution deployment with other governance bodies and processes, provides an Implementation and Migration plan to assist in the development of a Release and Deployment plan, and provides critical success factors defining the successful deployment of the solution (SA) • Phase G provides a description of required resources and skills for a successful deployment, a Deployment Risk/Impact assessment, oversight of the construction of the Production and QA environments, as well as oversees the retirement and disposition of obsolete and redundant solution and data components (SA)
  50. 50. TOGAF Integration by ITIL Lifecycle Stage • Knowledge Management involves ensuring that perspectives, data, ideas, experience & information, are retained and readily available • Phase F provides for the completion & confirmation of the various EA and SA architectural documents and artifacts for the current iteration of the architecture cycle
  51. 51. TOGAF Integration by ITIL Lifecycle Stage • Service Asset and Configuration Mgmt (SACM) ensures that the assets required to deliver IT services are properly controlled, and that accurate and reliable information about those assets is readily available • Phase F provides for the completion & confirmation of the various EA and SA architectural documents and artifacts for the current iteration of the architecture cycle
  52. 52. TOGAF Integration by ITIL Lifecycle Stage • Transition Planning and Support involves overall planning for Service Transition processes and coordinates the resources that they require • Phase F provides for identifying and resolving conflicts and inter-dependencies between implementation projects, & coordination/sequencing of the projects for optimal benefits realization (EA) • Phase G provides the identification of required skills and resources for a successful deployment (as well as governance over the solution construction and deployment (SA)
  53. 53. TOGAF Integration by ITIL Lifecycle Stage • Service Validation and Testing provides quality assurance, and verifies that a new or changed IT service is fit for purpose and fit for use. • Phase G provides validation of architectural compliance of the solution to architectural standards (EA), and assists in validating the service through providing fit/gap assessments for the non-functional, security and functional characteristics of the solution compared to Requirements (SA)
  54. 54. TOGAF Integration by ITIL Lifecycle Stage • Change Management involves the enablement of beneficial changes with minimal disruption to IT services through risk management, ensuring changes are documented, controlled and prioritized for value and strategic alignment • Phase A provides strategic alignment and value assessments for work packages that have submitted change requests. (EA) • Phase F provides for identifying and resolving conflict/interdependencies between implementation projects, sequencing of the projects for optimal benefits realization (EA), and deployment and roll-back plans (SA) • Phase G provides validation of architectural compliance of the solution to architectural standards (EA), and assists in validating the service through providing non-functional and functional fit/gap assessments to listed Requirements (SA)
  55. 55. TOGAF Integration by ITIL Lifecycle Stage • Change Evaluation involves a consistent and standardized means to assess the performance or value of a proposed IT service change, to facilitate a decision about whether to authorize the change • Phase A provides strategic alignment and value assessments for work packages that have submitted change requests. (EA) • Phase F provides for identifying and resolving conflict/interdependencies between implementation projects (EA) • Phase G provides a Deployment Risk/Impact assessment (SA) and also provides a host phase for ARB approval for the change (EA)
  56. 56. TOGAF Integration by ITIL Lifecycle Stage ST Stage Summary • There are a surprising number of both EA and SA integration points between TOGAF and ITIL at the Service Transition stage • The Release & Deployment Management process is where the work gets done to move solutions into Production. • This is analogous to the relationship between IT projects and TOGAF’s Phase G.
  57. 57. TOGAF Integration by ITIL Lifecycle Stage • For operational services, the role of Architecture is focused around ensuring the services continue to provide the required benefits and to identify when changes are needed • Providing insight into changes in the Business environment that might change the operating conditions or expectations for services • Checking that service levels meet Requirements • Providing guidance on system/data access and usage
  58. 58. TOGAF Integration by ITIL Lifecycle Stage • Here’s everything summarized on 1 page
  59. 59. Wait! We’re not done yet! There is more to talk about Process, and also Data and Governance • each of these is worth a slide deck on their own, but we’ll close off with a few slides to paint an overview 59
  60. 60. Other Considerations - Process • The previous analysis of TOGAF Integration by ITIL Stage is a pretty instructive and prescriptive look at integration from a Process perspective, but it doesn’t tell the whole story. This view: • does not show that many ITIL processes span multiple ITIL stages, and also does not peer inside the processes, so the timing of the Architectural inputs into the processes is not clear in this view • only shows a 1-way relationship of Architecture inputs to ITIL, but not ITIL inputs to Architecture
  61. 61. Other Considerations - Data • ITIL has a few different categories of Service: 1. Business Service: A service delivered to business customers by business units. Note that this is demarcated from any technology - since ITIL is IT-scoped, the internal workings of a Business Service are really outside the scope of ITIL, though of course we need to understand the inputs, outputs and controls so that IT can support these activities. 2. IT Service: A service provided by IT. These are really what ITIL Services are all about. There are two types of IT Service, Customer-facing and Supporting: A) Customer-facing Service: These are the IT Services that are directly interacted with by the Customer. The Customer means internal customer (i.e. the Business): not the public and not other IT groups. Why not the public? Because the Business Services are the interface to the public, not IT Services. Why not other IT groups? Because if other IT groups can be customers then all IT Services will be Customer-Facing, making the service catalog pretty useless for one of its primary goals: making it easy for the Business to find and engage services. B) Supporting Service: These are the IT services that support Customer-facing Services. The customers of these services are other IT groups. So, that's the ITIL service types: they are differentiated by the type of end customer, but they are what you would call "organizational" services. They all are mapped to an org unit that delivers them, they all include management, planning, monitoring, and support resources (people, budget, equipment, etc.). TOGAF (if you include the extensions to the meta-model) has the following service types: Business, Information System, and Platform. TOGAF service types map to different layers: Business Service ---> Organizational: between people as part of business processes Info System Service ---> SOA: between systems as part of processes Platform Service ---> Technology: interfaces between technology and/or software Now look back at ITIL: those services are all at the Organizational layer. So, you actually have a 3:1 overloading of ITIL Service to TOGAF Business Service. • Other important ITIL concepts must also be mapped in a manner that preserves integrity for both TOGAF and ITIL. Sometimes this is straight-forward, sometimes it isn’t! 61
  62. 62. Other Considerations - Governance 62 • The ITIL books do offer some discussion regarding interacting with other governance bodies, but its recognition of Architecture governance is mostly restricted to specifying standards. • ITIL does not mention common Architecture governance bodies, such as ARB, nor does it talk about the scope of mandate an ARB may have.
  63. 63. 63

×