itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package (SDP) A practical design for a Service Portfolio Peter Brooks (FISM) Economists predict that we will see a massive increase in the number of mergers and acquisitions over the next few years as a natural outcome of the great recession. In financial terms mergers nearly always result in a net loss of value. To minimise this risk and to be successful, the new company needs return to normal operating conditions as soon as possible. The longer the disruption, the greater the loss of value to shareholders and other stakeholders is likely to be. An ability to identify and then adopt, merge or adapt the services from the two operations quickly and effectively would enable the time to a return to normal operation to be kept as short as possible. It is just that ability that the Service Design Package (SDP) provides to businesses. This is a powerful message for any Board of Directors seeking a long-­term preservation of value. The ability to implement a real SDP, as opposed to showing slides of the concept, is something of genuine and lasting value to businesses. The crucial requirement for these organisational re-­structuring, and even for a consistent approach to Services in a large, multi-­divisional company, is that systems are compatible. That is, they can inter-­
operate, and that historical information can be preserved through the merging of different service delivery platforms and mechanisms without extensive and expensive re-­work. This is not possible today, and this will become more visible as a problem as the predicted increase in the rate of mergers develops. The fundamental reason that it is not possible is that there is no common, underlying structure defined for services. Such common underlying structures are known as ‘ontologies’ and are recognised as a desirable end-­point. They have been seen as very difficult to implement. This white paper presents a pragmatic, and practical approach to developing an ontology for Service Management that allows simple, reliable, easy to use, structures (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 2 that can incorporate existing tools. This approach allows for a gradual, staged transition from the current state of tools that can’t easily exchange data with other tools, to one where they can. At first encounter, the SDP appears to be a useful, simplifying notion, drawing together the different phases of the ITIL V3 lifecycle. It is, but the closer you look, the more complex and difficult to implement it appears. This white paper paints a picture of what an effective SDP would look like, and suggests a simple and practical method for implementing one. As usual, it is important to note that what matters is the overall delivery of services and a defined data structure is most certainly not enough for that, it is, however, a powerful facilitator to the design of tools to make the effective and efficient delivery of services much easier to achieve. ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 3 Table of Contents Service Design Package (SDP).............................................................................................................. 1 A practical design for a ............................................................................................................................ 1 Service Portfolio......................................................................................................................................... 1 Introduction............................................................................................................................................ 4 SDP Requirements ............................................................................................................................... 5 Possible Implementation Options ................................................................................................. 6 Existing tools – Word, Excel, Document Management System .................................... 6 Monolithic Service Management Tool .................................................................................... 6 Standard Ontology route (Protégé) ......................................................................................... 6 A practical approach ........................................................................................................................... 8 Top-­‐level design ............................................................................................................................... 8 Using the SDP .................................................................................................................................... 9 Backup and Restore of SDPs .....................................................................................................11 Failsafe, mirroring, immediate recovery.............................................................................11 Capacity Management..................................................................................................................11 Availability Management............................................................................................................11 Customisation..................................................................................................................................11 Updates to the SDP structure ...................................................................................................12 Next Steps ..............................................................................................................................................15 Acknowledgements ...........................................................................................................................16 ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 4 Introduction The Version three release of the IT Infrastructure Library (ITIL) introduced a new idea as part of its lifecycle structure. The Service Design Package (SDP) follows a service through its lifecycle from initial proposal to retirement. It contains all the information required to manage the service. It is defined in the glossary as: “Document(s) defining all aspects of an IT Service and its Requirements through each stage of its Lifecycle. A Service Design Package is produced for each new IT Service, major Change, or IT Service Retirement.” That’s fair enough, at one level, it is clear that in a well run organisation, these documents will exist, so they already have ‘Service Design Packages’. However, the strength of this idea is how it unifies the phases of the lifecycle. You can see that it would develop as a new service moves from being a simply an idea, to a proper definition, and so on, until it describes an operational service. So some sort of structured entity with proper access and version control must be required. A single document might suffice for a tiny service, in a small organisation, but it would become unworkable for anything bigger. Some sort of tool is required. This is where the problem starts. There is no ontology for Service Management, or ITIL, so we can’t take such a definition of how the different parts of an SDP inter-­‐
relate and implement them as a tool. We need to design the SDP itself, in some detail. This white paper explores one approach to designing and implementing a simple SDP structure. The idea is to have something that could be used practically that also affords the opportunity to develop, over time, into a fully-­‐fledged industry standard tool, based on an ontology developed from the proof-­‐of-­‐concept structures described in this document. This is of huge importance to organisations in coming years. IT needs to be agile, but also efficient and effective, the deployment of services relies on many things, but a reliable tool is a fundamental. During mergers, de-­‐mergers, or acquisitions, there is a need to compare services and, quickly (because mergers cost a lot of money) identify which services can be incorporated in the new organisation, which retired and which modified to serve the new structures. An interchangeable SDP format would make this a much less formidable operation than it currently is. ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 5 SDP Requirements The top-­‐level requirements for a Service Design Package are: 1. Easy to use - Many different parts of the organisation have to interface to it
2. Portable
- From one toolset to another
3. Standard
- Based on an ontology agreed by the industry
4. Support the Service Portfolio
5. Available - support distributed servers + robust design
6. Continuous Operation - No down-time required if infrastructure design allows
this
7. Continuous Availability - No outages if infrastructure design allows this
8. Access Control
9. Scalable to many distributed users
10. Reliable Backup/Restore & Service Continuity provisions
11. Allows links to other systems, such as SKMS, service desk tools
12. Allows easy exchange of Service Information between organisations
13. Allows for active and development SDPs of the same service (service versioning)
14. Allows for proper Service Testing
15. Allows for Auditing
16. Facilitates the definition and measurement of standard Metrics
17. Expandable, easy to add vendor or customer specific extensions
©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 6 Possible Implementation Options Existing tools – Word, Excel, Document Management System These tools are all useful for component parts of an SFP. Meeting minutes might be kept in word, metrics might be defined and recorded in excel and design documents for the components that make up a service kept in a document management system so that proper version control is kept over the testing process, say. It soon becomes clear that the requirement for some sort of controlling structure for all the various documents, metrics, tools and so forth is needed. Monolithic Service Management Tool There are many excellent toolsets provided by major vendors that satisfy the requirements of a company working towards ISO20000 or deploying ITIL based processes and functions. There has been some work done to enable the transfer of information between these monolithic tools too by the CMDB Federation (CMDBf). These tools lack an underlying, shared set of data structures and relationships – that an ontology would provide – because, of course, there is no ontology for Service Management. It is also not easy to transfer a service (the SDP, along with associated information, such as incidents, configuration items or test results for the service) from one tool to another, or to compared services on two different tools. These are important requirements in post-­‐merger work to understand existing services in the two organisations so as to make decisions on which to keep, which to discard or which to merge. Standard Ontology route (Protégé) The development of the Semantic Web is based on the use of ontologies that allow computers to understand the meaning (semantics) of information, not just the syntax. There have been many notable successes in moving areas of knowledge into an ontology format. There are now ontologies being used in many areas, mainly those with large amounts of structured information. So the field is well understood, there being a number of models that support ontologies, based on XML, RDF and OWL. The underlying idea of an ontology is very simple. It is based on a triplet showing the relationship between two things. (Thing one, relation, thing two) such as (laptop-­‐34, is-­‐owned-­‐by, Jim). ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 7 The development of a coherent ontology is not that simple. The relationships need to be well understood in terms of how they relate to the real world and to be consistent within the framework as well as actually useful. From the point of view of using the standard approach to developing an ontology for Service Management, there are quite a few hurdles: -­‐ The tool that is most used for developing ontologies, Protégé, is difficult to use, stand-­‐alone, and not particularly robust. -­‐ The assumption is that ontologies are being created either on a green-­‐
field site, or will replace existing systems in a ‘big bang’ release. -­‐ The model is expecting the data to be fairly static and to come from one source. This suits knowledge about biological systems, books, journals, even people, but is not so useful for more dynamic items like invoices, incidents, or service catalogues. It is important that any tool used allows the export of RDF or OWL, but it need not be developed that way. ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 8 A practical approach Top-­‐level design The practical approach, outlined through the rest of this White Paper, is to use the SDP as a file structure, with directories acting as containers for the relevant, files, documents and pointers to URIs referencing that portion of the SDP for the particular Service. In ontology terms, each directory becomes a class that contains the components relevant to it. For data items, such as the status of the SDP, the contact details of the Service Owner, or the version of the SDP itself, an LDAP server is used. For example; A URI in the Service Strategy Directory might link to the minutes of the board meeting that commissioned the service. A URI in the Operations Directory might point to an application that shows a view of all incidents currently outstanding for this service. The top-­‐level file structure supporting the SDP would be as in the diagram below: Figure 1 Services created as directories in Service Portfolio From an ontology point of view, the ‘Template’ is actually the ontology itself whilst all the services listed; such as ‘Invoicing’ are instantiations of the ontology. So instantiating an ontology involves copying the file structure and contents. The template (the ontology) is created by a program that traverses the ontology description in the .dot file building the file-­‐system and the LDAP schema from the graphviz description directly. This powerful mechanism allows a very swift implementation of a testable system from an ontology. ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 9 Using the SDP The interaction between a user (or the web-­‐server that the user views the SDP through) and the SDP is shown in the diagram below: Figure 2 Dynamics of the SDP model The structures involved (preliminary examples of which, appear in this document) are created by Unix command line shell scripts, or applications that call the Unix API to achieve the same result. These scripts are based on an ontology (using the term loosely) developed for this paper in the language dot (described at www.graphviz.com ). The idea is to extend the current proof-­‐of-­‐concept ontology to enable a practical, easily installed and used, open source tool for anybody needing to create a Service Portfolio. ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 10 The beauty of the file system and LDAP approach is that it is independent of any computer language and uses some of the most reliable well-­‐tested software (OS routines). The design of this has been on a Unix system (Apple Macintosh OS/X 10.6.3) so this, or any other Unix-­‐based system would be ideal for first implementations. It might be possible, using the package Unix tools for Windows, to adapt this to the Microsoft Windows platform, but this would have to be tested as a separate exercise. This design means that simple tools can be designed to answer complex questions. One obvious question for implementing something as large as an SDP is how you manage the transition from a tiny bit of information in the structure, to an almost fully filled SDP. The answer, because of this design, is that it is simple. All that is necessary at any time is to do a find (Unix command line ‘find’) in the structure for the number of files in each directory, if that is greater than the number for an empty SDP structure, then that particular section has been modified. This also helps navigation, so that it is easy to see where work has been done. Access and Security This model uses the Access Control Lists (ACLs) supported by the OS. During installation of the first template service, or at subsequent times, the administrator modifies files that allocate access rights to particular groups of users, then runs a script to apply these to the structure of the particular service. These access control files form part of the SDP structure itself (in the Security section), thus making the process self-­‐documenting. So, at the top level, the service itself is activated by moving the directory containing the SDP from the Service Pipeline directory to the Service Catalogue directory. Because of the ACL access control, only Customers authorised to view services can see them, and these customers only have access to the portions of the SDP that have been agreed between the Service Manager and the Customer. Installation and Set-­‐up The sequence of events in creating a Service Portfolio from scratch are: 1. Download the SDP Package 2. Unzip and consult README for instructions and latest changes 3. Run the ‘install_portfolio’ script to create the structures 4. This creates the top-­‐level file system and one SDP called ‘template’ 5. Within this template set up the default ACLs for the organisation based on the Security Policy. 6. Put all standard links into the template. Links to the Service Desk system views and reports, links to Document Management System views of policy documents, meeting minutes, plans, project documents and so forth. ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 11 7. The LDAP structures can be set up on the same server (ensuring that the firewall set to allow an LDAP repository) or on an existing LDAP server. Provision would need to be made for extra information to be kept on that server as well as the LDAP schema. 8. Copy the template to create SDPs for all services e.g.: a. $cp -­‐Rpn ~/Service Portfolio/Service Pipeline/template /Service Portfolio/Service Catalogue/invoicing.sdp 9. Now all the services have been created Service Management staff can start to work with them Backup and Restore of SDPs Simply use the file system commands. Failsafe, mirroring, immediate recovery All these are achieved by tried and tested file system methods – file system routines can run in the background to mirror the Service Portfolio across as many different systems as required. This also enables on-­‐line backup. Crucial parts of the system need to be written to ensure that they have atomic transaction support. If anything is being used when a particular system crashes, the mirrored system will contain the previous version of the file. Capacity Management Increase in the capacity needs or access demands to the Service Portfolio can be met by increasing the number or power of the servers supporting it. There are no single server or single thread requirements from this design. Applications that access the SDP entries need only ensure that the correct data is put in the right place and the mirroring system will take care of the rest. Availability Management File Sytems can be kept available through standard methods such as mirroring (see above). For the components within the SDP to be highly available, it would be sensible to develop them in a reliable language such as Ada. Customisation It is easy enough to add directories, but there is a danger of incompatibility later releases. ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 12 Updates to the SDP structure It is often difficult to move from one version to another of a software product. The design of the SDP should allow a reasonably straightforward upgrade path. When a new version of the SDP ontological structure is released, an update program is provided. This would update all the services by adding new directory entries. Where an entry is moved, a physical move to another part of the tree can take place. Where an item is renamed, this can happen directly. When an item is deleted, it is flagged as ‘no longer valid’ and a list of these is provided to the administrator for individual action. ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 13 The SDP Structure The SDP follows the structure of the ITIL v3 books. That is there is a core structure, which describes items relevant to all stages of a service, then one structure for each of the books. To give a flavour of the definition language: { "User Profiles" -­‐> "Customer PBA" "Demand Management" -­‐> "Demand Pattern" "Strategy" -­‐> "Standard Supporting Package" "Strategy" -­‐> "Core Service Package" "Strategy" -­‐> "Service Level Package" "Service Level Package" -­‐> "Service Level Agreements" -­‐> "Customer" -­‐>"Warranty" "Warranty" -­‐> "Availability" "Warranty" -­‐> "Capacity" } The above group of statements show how these various components relate. In the case of the SDP, most of the ‘-­‐>’ will actually mean ‘contains’ this is at the class level. When the structure gets down to the item or component level (kept in LDAP or obtained by a query to another application, database or document repository) other relations can be defined. Where the data comes from is described by the URI. This allows for gradual transition. incidents_for_this_service
incident-datetime
incident
incident-number
uri
incident-category
customer
initial-category
description
incident database
remote incident database
Service Desk Tool API
Figure 3 Transition initially accessed through URI, later through ontology definition Initially incidents can be retrieved through a URI that links to an application description that returns the details of the incident required from a database, a Service Desk tool or from any other data source. Later, as part of migrating to the ontology structure, this same query would be answered by the upgraded application, which would give data conformant to the ontology definition. This allows step-­‐by-­‐step replacement of any part of the SDP over time, without the need for a big-­‐bang release of an entire ontology. There’s a simple look-­‐up algorithm. At any level of the SDP, a URI is selected if it is there. If there is no URI, then the class structure is used with the appropriate application for that level. ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 14 It is not particularly useful in this form, but the diagram below gives a feeling of what the SDP ontology looks like – this is a preliminary, partial proof-­‐of-­‐concept diagram for the purposes of this white paper: Risk
Assessments
SDP
Access
Rights
SDP
Authorisations
RACI
Matrix
CriticalSDP
Success
Factors
*Service Owner
*Retired
*Operational
*Released
*Test
*Built
Business
Last
Requirements
Change
Next
SDPOrigination
Review
SDP
Service
applicability
Actual
*Developed
Currently
Planned
English
Original
Service
Lifecycle
Plan
Date Structure
*Designed
Organisational
Readiness
Assessment
Dates
3rd Party
Contracts
Service Contacts
SLA
*Chartered
OLA
Processes
*Approved
Core Metrics
*Analysed
Core Change Log
*SDP Version
*Defined
Language
Service Status
Core Structure
*Requirements
Service Portfolio Reports
Customer Reports
User Reports
Financial Reports
Operations Reports
Service Desk Reports
Service Owner Reports
Security Reports
Capacity Reports
Availability Reports
Continuity Reports
Change Reports Reports
Release Reports
Demand Reports
Development Reports
Supplier Reports
Description
Views
Supplier View
Development View
Demand View
CSI
Release View
Change View
Continuity View
Availability View
Capacity View
Security View
Service Owner View
CSI Version
Service Desk View
Projects
Operations View
CSI Status
Financial View
Next Planned Improvements
User View
CSI Issue Log
CSI RAG
Customer View
CSI Next Review Date
Service Portfolio View
CSI Metrics
V0.1
Operation Change Log
CSI Change Log
Operation Version
Operation Metrics
SDP
Operation Next Review Date
Operation
Transition Version
Operation RAG
Operation Issue Log
ITSCM Plan
Design Version
Current ACL permissions
Access Control
Organisation
Transition Operation
Status
Strategy Version
Communication Plan
Training Plan
Transition Change Log
Transition Metrics
Test Plan Service Continuity
Transition Next Review Date
Design
Transition RAG
Service Recovery Information
Transition Issue Log
Transition Status
Audit Plan
Strategy Status
Design Change Log
Design Metrics
Audit Result
Strategy
Design Next Review Date
Design RAG
Design Issue Log
Design
Status
Strategy Change
Log
Warranty
Development
Plan
Availability
Strategy
Metrics
Strategy Archetype
Strategy
Next
Review
Date
Strategy
RAG
Strategy
Issue
Log
Capacity
Service
LevelPackage
Package
Core
Service
Standard
Supporting
Package
Customer Assets
Continuity
a1
Demand
Management
Inventories
Business
Case
Value
Proposition
Risk
Financial
Analysis
ROI
Tracking
Management
Resource
Authorisation
Priority
Approval
Security
a2
a3
a4
a5
Service Level Agreements
Service Archetype
a6
DemandProfiles
Pattern
a7
Customer
User Profiles
a8
a9
u1
u2
u3
Customer
u4
u5 u6
u7 u8
Customer
PBA
u9
Customer
User
PBA Type
User
Type
Utility
Figure 4 Graph of proof-­of-­concept SDP ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 15 Next Steps The SDP implementation structure described in this white paper currently is a proof-­‐of-­‐concept. If the ideas in this white paper were to meet with general acceptance the next steps would be: -­‐ Extend this white paper to a book (ideally published with the itSMF) -­‐ Audit, improve and extend the SDP description -­‐ Seek sponsorship and ownership. The itSMF, Service Management Tool Vendors, end user Customers and other interested parties might form a partnership to support this -­‐ Carry out a pilot exercise -­‐ Publish results -­‐ Package the SDP description as an Open Source item (free for individual use, a license fee to developers or companies) -­‐ Start work to transform this into a full Ontology -­‐ Set up support structures for the product ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission
itSMF International
Whitepaper Competition 2010
Finalist
Service Design Package – A practical design for a Service Portfolio Page 16 Acknowledgements The Author is indebted to material quoted under Copyright ‘fair use’ from the following publications: Majid Iqbal and Michael Nieves (2007). ITIL Service Strategy. The Stationery Office. ISBN 9780113310456. Vernon Lloyd and Colin Rudd (2007). ITIL Service Design. The Stationery Office. ISBN 9780113310470. Shirley Lacy and Ivor Macfarlane (2007). ITIL Service Transition. The Stationery Office. ISBN 9780113310487. David Cannon and David Wheeldon (2007). ITIL Service Operation. The Stationery Office. ISBN 9780113310463. George Spalding and Gary Case (2007). ITIL Continual Service Improvement. The Stationery Office. ISBN 9780113310494. ©2010 Peter Brooks [email protected] (c) itSMF International - no part of this paper may be reproduced without permission