2nd Generation I.T. Service Catalogues

1,536 views

Published on

IT service engineering – our term for the systematic approach to developing IT services – is fast becoming a core competence of IT service providers. The reason is simple enough: professionally engineered service products are the only ones which stand a chance on the market and can win the acceptance of consumers. The challenge of IT service engineering is to specify IT services such that consumers and providers all have a clear understanding of what the services actually comprise.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,536
On SlideShare
0
From Embeds
0
Number of Embeds
224
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

2nd Generation I.T. Service Catalogues

  1. 1. Intention | Structure | Bundle | Model | Process | Application 2 nd Generation I.T. Service Catalogues Workshop September 9 th , 2005
  2. 2. The five stages of evolution in the Service Provider Maturity Model (SPMM) Intention | Structure | Bundle | Model | Process | Application
  3. 3. Service Catalogue in the customer relation: A sales tool Intention | Structure | Bundle | Model | Process | Application Service Value Chain Suppliers Service Provider Customers For internal use : The Service Catalogue is the service provider's product data management . Employees know how to provide a service , what is included and the quality thresholds . Processes can be automated and/ or monitored . Optimized resource utilization . In the supplier relationship : Well specified services allow the service provider to plan and calculate with the suppliers offerings and resources . In the customer relationship : The functionality , quality and provisioning times of services can be communicated . It is assured that services are deliverable in the specified way. Customers know how they can configure the services .
  4. 4. Service Catalogue for internal use: The Product Data Management (PDM) Intention | Structure | Bundle | Model | Process | Application
  5. 5. Key Finding 1: Product Data Management A second-generation service catalogue takes the description of services one step further, complementing the customer-centric presentation of services with an internal provider view. What the catalogue does is create a knowledge base about the service, and assemble the available information in a single source. The service catalogue is the IT service provider’s PDM – Product Data Management. Intention | Structure | Bundle | Model | Process | Application
  6. 6. Service Catalogue in the supplier relation: Enable for the service integrator model Intention | Structure | Bundle | Model | Process | Application IP VPN LAN Data Center LAN Branch Office Customer Desktop SP LAN SP WAN SP LAN SP Application SP Service Integrator Service Broker publish UDDI SOAP XML order query order service delivery Management Interface <ul><li>SOAP, XML
  7. 7. WSDL
  8. 8. BPEL </li></ul>
  9. 9. Plattform Strategies have been implemented successfully in the automotive industry Intention | Structure | Bundle | Model | Process | Application
  10. 10. Key Finding 2: Products and components Component-based service architectures mandate a differentiation between service products and service components. Accordingly, there are two catalogues: a product catalogue and a component catalogue. Intention | Structure | Bundle | Model | Process | Application
  11. 11. Decomposing IT services is the equivalent of breaking down goods into constituent parts Intention | Structure | Bundle | Model | Process | Application
  12. 12. Example illustrating how the IT service “workspace” is decomposed Intention | Structure | Bundle | Model | Process | Application
  13. 13. Key Finding 3: Characteristics of service components Service components should have as limited a scope as possible to keep them easily manageable. They can be iteratively decomposed (broken down) or composed (built). Finer granularity increases the likelihood of component reusability. IT service providers typically have several hundred service components. Intention | Structure | Bundle | Model | Process | Application
  14. 14. Decompose existing products Intention | Structure | Bundle | Model | Process | Application Product 1 Component Candidate Product 2 Component Candidate Service Component 1
  15. 15. Eliminate doubles, define variants and associate components to precombined classes Intention | Structure | Bundle | Model | Process | Application Product 1 Component Candidate Product 2 Component Candidate Service Component 1 Service Component Service Component Service Component 2
  16. 16. Abstract superclasses to refine taxonomy Intention | Structure | Bundle | Model | Process | Application Product 1 Component Candidate Product 2 Component Candidate Service Component 1 Service Component Service Component Service Component 2 Service Component Service Component 3 Service Component Service Component Service Component Service Component Service Component
  17. 17. Service taxonomy Intention | Structure | Bundle | Model | Process | Application
  18. 18. Key Finding 4: Service taxonomy Service components can be arranged in a hierarchy of classes, in accordance with the principles of object orientation. A service taxonomy of this nature promotes standardisation and simplifies modelling through its inheritance mechanisms. It also acts as vehicle for semantic knowledge. Intention | Structure | Bundle | Model | Process | Application
  19. 19. The iterative composition of the “Workspace” service product Intention | Structure | Bundle | Model | Process | Application
  20. 20. Key Finding 5: Characteristics of service products Service products are sold to clients; they are comprehensive, valuable service packages. The number of service products should be limited so as not to overburden the customer with choice. Service products should permit or comprise variations so as to address individual demand profiles. Service providers can also differentiate from other market players by their design of service products. Intention | Structure | Bundle | Model | Process | Application
  21. 21. Dimensions explored when modelling IT service components Intention | Structure | Bundle | Model | Process | Application
  22. 22. Service Engineering vs. Configuration Management Intention | Structure | Bundle | Model | Process | Application Service Engineering is the process by which the provider develops marketable services, thus defining his or her own potential. This data is also known as “potential data”. Configuration Management, on the other hand, is about managing the assets – inventory, or customer relationships – which currently exist and constitute a value. This data is termed the “asset data”.
  23. 23. IT service providers are only now beginning to specify their potential in service catalogues Intention | Structure | Bundle | Model | Process | Application
  24. 24. The two differentiations create a matrix that defines four object types Intention | Structure | Bundle | Model | Process | Application Service Product Service Component Specification Instance Service Product Specification Service Order Service Component Specification Service Instance
  25. 25. Key Finding 6: Specifications and instances It is necessary to differentiate between a specification and an instance of this specification on both the product and component levels. A single instance of the specification of a service product is an order (or rather service configuration); a single instance of the specification of a service component is known as a service instance. Intention | Structure | Bundle | Model | Process | Application
  26. 26. Key Finding 7: Specification details to map Service products and service components are described in detail in specifications. The specifications contain: <ul><li>Product model: specification of functionality, quality, cost, etc.
  27. 27. Process model: life cycle, states, workflows (the basis for automation)
  28. 28. Resource model: required service components (build rules), personnel (roles), infrastructure
  29. 29. Marketing: customer interaction model, presentation </li></ul>Intention | Structure | Bundle | Model | Process | Application
  30. 30. Reasons for process definition and automation <ul><li>Easing workload from routine tasks
  31. 31. Speed-up processes e.g. in provisioning
  32. 32. Eliminate error flashpoints
  33. 33. Monitor Processes </li></ul>Intention | Structure | Bundle | Model | Process | Application
  34. 34. Specifications have these life cycle states Intention | Structure | Bundle | Model | Process | Application
  35. 35. State transitions of specifications Intention | Structure | Bundle | Model | Process | Application Life cycle Version 1.1.17 DV Version 1.2.3 AC Version 1.2.5 EL Version 2.0.8 AC Version 1.6.1 PO Version 1.5.5 DV Version 1.99.45 DV Version 1.2.4 PO Version 1.6.0 AC
  36. 36. State model of instances Intention | Structure | Bundle | Model | Process | Application
  37. 37. State model of instances Intention | Structure | Bundle | Model | Process | Application Initial Configured Ready Available Cancelled Degrading Degraded Unavailable Workspace Service Product Desktop Computer Office Communications User Support Email Telephone Network Email Telephone Network Work Order Desktop Computer Office Communications User Support Workspace Service Product
  38. 38. Reference application architecture for IT service providers Intention | Structure | Bundle | Model | Process | Application

×