Service Portfolio and Catalog Language
Public review site for SPACL documents.
What uses cases should SPACL cover?
If you look at the whitepaper, we outline the main use cases the group has chosen to tackle.
The SPACL consortium has reviewed a variety of use cases presented by its members for consideration. This section details the three major use cases that SPACL consortium has decided to address in its first phase.
In these four examples, BigCo is a large company with an internal IT organization. Eric is a Service Catalog Manager at BigCo. SupportCo is an outsourcer who provides IT services to multiple companies. Lisa is a Service Catalog Manager at SupportCo.
The three use cases are in the whitepaper.
We'd love to get feedback on these.
Is there detail we should consider? Are there exceptions we should add? Are assumptions valid or invalid?
Are there other use cases?
The SPACL consortium has reviewed a variety of use cases presented by its members for consideration. This section details the three major use cases that SPACL consortium has decided to address in its first phase.
In these four examples, BigCo is a large company with an internal IT organization. Eric is a Service Catalog Manager at BigCo. SupportCo is an outsourcer who provides IT services to multiple companies. Lisa is a Service Catalog Manager at SupportCo.
The three use cases are in the whitepaper.
We'd love to get feedback on these.
Is there detail we should consider? Are there exceptions we should add? Are assumptions valid or invalid?
Are there other use cases?
Views: 73
Replies to This Discussion
-
Permalink Reply by David Moskowitz on -
Maybe I'm missing something (or nit picking).
re: White Paper section titled: What is a Service Catalogue? ...
The first sentence of the of the 2nd paragraph in the section uses some of the language from the Service Strategy book (specifically: "The Service Catalogue is the subset of the Service Portfolio visible to IT Organizations."). That is a very different meeaning from what is in the Service Stragey book: "The Service Catalogue is the subset of the Service Portfolio visible to customers." The change from "customers" to "IT Organizations" not only changes the audience (effectively limiting the Service Catalog to the part labeled as "technical service catalogue, but appears to exclude the business user.
The 2nd bullet item following this paragraph starts with this:
"Consists of services presently active in the service operations phase and those approved to be readily offered to current prospective IT Organizations."
The Service Strategy book includes this:
"It consists of services presently active in the Service Operation phase and those approved to be readily offered to current or prospective customers."
Again, this would appear to limit the scope of the catalog to technical, not business.
Tell me it's a minor typo and... never mind. However, I think the distinction between IT organizations and customers has to be clearly articulated.
re: use cases
I don't see a use case (unless I missed it) that clearly indicates the Service Catalog is part of the Service Portfolio (or at least integrates with it). While there is mention of "capturing" from the portfolio, there should be a use case to move a service from the Service Pipeline into the Service Catalogue, or the very least a variation or extension to the publish capture UC.
Since the Catalogue contains both service in operation as well as those recently chartered, this notion of transition from pipeline to catalogue should be included -- which leads to another issue I'll get to below.
Similarly there needs to be a use case to retire a service.
How are the business service catalogue (BSC) and technical services catalogue (TSC) connected? In other I words I believe the SPACL needs to support some filtering views of the BSC and TSC which also means there are issues regarding security (authentication and authorization). Use cases appear to be missing in this area.
This leads to another area I alluded to above: Actors need to be defined for each use case -- consistent with appropriate security to use each UC.
What are the success and failure conditions for each use case? How will failures be handled? What about exceptions... (i.e., inconsistent states)
There's more, but this will do for starters.
One last point, maybe I haven't figured it out, yet, but I find the flow of the discussion difficult to follow.
Davud
-
Permalink Reply by Rodrigo Flores on -
Thanks David.
I will take deeper look at your comments next week. I also recommend the object model, which is the meat of the thing.
For now, I'd say... yes, nitpick is allowed and encouraged.
A few answers to just get toing.
- Goal is to be able to model both technical and business services. Good catch!
- Use cases are in the white paper. There are three of them.
There's no use case for moving from service portfolio to a service catalogue. As an interchange format, the definition does not know about that change. On the other hand, the definition should have attributes to carry that information when a system moves it from one status to another.
Filtering views are not covered in SPACL, because they are implementation specific. To give an analogy, we are defining the format and data structure of an e-mail message, but we are not being prescriptive as to what kind of views your inbox should have. What's interesting in what you say, though, would be to define which kind of elements and attributes a user would like to filter.
In e-mail there TO:, FROM:, SUBJECT, etc Do you have a sense of what attributes should be in the spec to enable that filtering?
As I said, more next week.
David Moskowitz said:Maybe I'm missing something (or nit picking).
re: White Paper section titled: What is a Service Catalogue? ...
The first sentence of the of the 2nd paragraph in the section uses some of the language from the Service Strategy book (specifically: "The Service Catalogue is the subset of the Service Portfolio visible to IT Organizations."). That is a very different meeaning from what is in the Service Stragey book: "The Service Catalogue is the subset of the Service Portfolio visible to customers." The change from "customers" to "IT Organizations" not only changes the audience (effectively limiting the Service Catalog to the part labeled as "technical service catalogue, but appears to exclude the business user.
The 2nd bullet item following this paragraph starts with this:
"Consists of services presently active in the service operations phase and those approved to be readily offered to current prospective IT Organizations."
The Service Strategy book includes this:
"It consists of services presently active in the Service Operation phase and those approved to be readily offered to current or prospective customers."
Again, this would appear to limit the scope of the catalog to technical, not business.
Tell me it's a minor typo and... never mind. However, I think the distinction between IT organizations and customers has to be clearly articulated.
re: use cases
I don't see a use case (unless I missed it) that clearly indicates the Service Catalog is part of the Service Portfolio (or at least integrates with it). While there is mention of "capturing" from the portfolio, there should be a use case to move a service from the Service Pipeline into the Service Catalogue, or the very least a variation or extension to the publish capture UC.
Since the Catalogue contains both service in operation as well as those recently chartered, this notion of transition from pipeline to catalogue should be included -- which leads to another issue I'll get to below.
Similarly there needs to be a use case to retire a service.
How are the business service catalogue (BSC) and technical services catalogue (TSC) connected? In other I words I believe the SPACL needs to support some filtering views of the BSC and TSC which also means there are issues regarding security (authentication and authorization). Use cases appear to be missing in this area.
This leads to another area I alluded to above: Actors need to be defined for each use case -- consistent with appropriate security to use each UC.
What are the success and failure conditions for each use case? How will failures be handled? What about exceptions... (i.e., inconsistent states)
There's more, but this will do for starters.
One last point, maybe I haven't figured it out, yet, but I find the flow of the discussion difficult to follow.
Davud
-
Permalink Reply by David Moskowitz on
-
Rodrigo,
Thank you for your response.
My point about filtering was in regard to the TSC and BSC. The introduction of a service into the catalog needs to include attributes that allow the filtered view of either TSC or BSC.
Since the service catalog is part of the portfolio which includes the pipeline (sorrty for the English, it's late and... :-)) the SPACL needs to include APIs (if you will) that allow for the transition from pipeline to the catalog, even if only the catalog "part" is currently available. The same is true about retired services.
I believe the concepts of adding to the catalog should support the transition from pipeline to catalog as a part of chartering a new service (in Service Strategy). Similarly if Service Strategy approves retiring a service, that needs to be supported, too.
In other words, the white paper talks about some aspects of the lifecycle in Service Design, Service Transition, and Service Operation. Apparently missing is explicit integration with Service Strategy -- the source of additions or deletions to/from the catalog -- to get full lifecycle integration.
Unless I'm thinking about this from a different perspective. I'm somewhat less concerned about the data structures of the catalog, per se, than I am about the the meta-language (or APIs) that defines the set of system behaviors required to support operations on the catalog (and by implication, the attributes required in the structure to support the behaviors).
Does this make sense?
I am going through the object model, but that's a slower process! :-)
Again, thank you
David
-
Permalink Reply by Sandra Daly on
-
Use Case:
Company A has a Standard Service Offering with a fixed capacity of X and standard support, however the customer has the option of 'uplifting' both the capacity and support through set options.
example: option 1 x2 capacity, option 2 x4 capacity
example: support Platinum
Once the customer has selected the uplift option, this service agreement becomes a customer specific agreement in the Service catalogue.
Challenges: managing the options, costing/pricing delivering the options, managing the service requests available to the service agreement (not service offering).
-
Permalink Reply by Paul G. Huppertz on -
As every other catalogue, the Service Catalogue must be presented by the accountable Service Provider to the intended group of Service Customers, so that they can pick and commission the Business Servies or better written: the ICT-based Business Support Services (ICTBSS) they want to be rendered to their authorized Service Consumers. Mainly, the Service Catalogue is addressed to the Service Customers and, generally, to the responsible employees of the Service Provider, too.
The technical services, better written: the Service Contributions which are required for aggregating the triggered ICT-based Business Support Services (ICTBSS) must be separately documented, in particular not in the Service Catalogue presented to the Service Customers. They should be documented and maintained in a Service Contribution Register internal to the Service Provider as all these Service Contributions will not be explicitly commissioned by the Service Customers in the business units, but by the accountable Service Provider to his internal or external Service Suppliers. These Service Suppliers must effectuate and contribute the triggered Service Contributions according to their clear, complete & concise specification in the respective Operational Level Agreements (OLA) or Underpinning Contracts (UC).
Conclusion:
- The Service Catalogue must contain the service offerings of the accountable Service Provider, i.e. the clear, complete & concise specifications of the ICT-based Business Support Services (ICTBSS) with their particluar 12 service attributes and distinct attribute values.
- Mainly, the Service Catalogue is addressed to the Service Customers in the Business Units in the enterprise.
- The Service Contributions must be documented in a Service Contribution Register internal to the accountable Service Provider. They must be specified with their particular 12 attributes, too, so that the accountable Service Provider can commission them to the internal or external Service Suppliers.
David Moskowitz said:Maybe I'm missing something (or nit picking).
re: White Paper section titled: What is a Service Catalogue? ...
The first sentence of the of the 2nd paragraph in the section uses some of the language from the Service Strategy book (specifically: "The Service Catalogue is the subset of the Service Portfolio visible to IT Organizations."). That is a very different meeaning from what is in the Service Stragey book: "The Service Catalogue is the subset of the Service Portfolio visible to customers." The change from "customers" to "IT Organizations" not only changes the audience (effectively limiting the Service Catalog to the part labeled as "technical service catalogue, but appears to exclude the business user.
....
Davud
-
Permalink Reply by Paul G. Huppertz on
-
For services, there is only one kind of "use case": An authorized Service Consumer trigger a service which requires the service specific bundle of benefits to be rendered explicitly to this triggering service consumer. This service specific bundle of benefits is specificied in the standard service attribute 01 'Service Consumer Benefits'. The way to effectuate, aggregated and render this bundle of benefits to the triggering Service Consumer is worked out in the respective Service Concept which consists of
- the specification of the ICT-based Business Support Service (ICTBSS) with its 12 attributes
- the Service Map with all Service Contributions required for aggregating this ICTBSS
- the Service Screenplay listing the sequence and combination of service contribution for aggregating this ICTBSS.
Every time, an authorized Service Consumer triggers such an ICT-based Business Support Service (ICTBSS), this ICTBSS must be aggregated from scratch by the required Service Contribution according to the Service Map and the Service Screenplay. The Service Contributions are effectuated by the execution of distinct ICT-systems, e.g. the inital replication service (contribution) of a triggered e-mail serivce is effectuated by the e-mail client system as soon as the service consumer has triggerd an e-mail serivce by hitting the 'Send' button. Following this initial replication service (contribution) must be triggered the further sequence of service contributions according to the Service Screenplay for an e-mail service, so that one copy of the original e-mail is delivered to every e-mailbox of the intended addressees.
David Moskowitz said:
...
re: use cases
I don't see a use case (unless I missed it) that clearly indicates the Service Catalog is part of the Service Portfolio (or at least integrates with it). While there is mention of "capturing" from the portfolio, there should be a use case to move a service from the Service Pipeline into the Service Catalogue, or the very least a variation or extension to the publish capture UC.
Since the Catalogue contains both service in operation as well as those recently chartered, this notion of transition from pipeline to catalogue should be included -- which leads to another issue I'll get to below.
Similarly there needs to be a use case to retire a service.
...
Davud
-
Permalink Reply by Paul G. Huppertz on
-
The Business Service Catalogue contains the list of the clear, complete & concise specifications of all offered ICT-based Business Support Services (ICTBSS) with their particular 12 service attributes and distinct attribute values. From this list, the Service Customers may pick one and commission it to the accountable Service Provider by signing an SLA which contains a copy of this specification. These service specificatons are "connected" to the technical services, better written: (Standard) Service Contributions by means of the Service Concept which contains
- the specification of the ICT-based Business Support Service (ICTBSS)
- the Service Map with all the Service Contributions required for aggregating the ICTBSS
- the Service Screenplay containing the list of conditions & triggers, the sequence & the combination of the Service Contributions for aggregating the ICTBSS.
The Technical Services or Service Contributions are documented and maintained in the Service Contribution Register where they are specified with their self-contained particular 12 service attributes and distinct attribute values.
Conclusion:
- There is no direct connection between the ICT-based Business Support Services (ICTBSS) and the Service Contributions.
- As every ICTBSS is aggregated from scratch in real time of the same Standard Service Contributions, all the required Service Contributions must be effectuated & aggregated not until the ICTBSS is triggered by an authorized Service Consumer.
- A Service Contribution is effectuated by the execution of distinct functions of distinct ICT-systems but neither the service-relevant function nor the service-relevant ICT-system are the Service Contribution itself.
David Moskowitz said:
How are the business service catalogue (BSC) and technical services catalogue (TSC) connected? In other I words I believe the SPACL needs to support some filtering views of the BSC and TSC which also means there are issues regarding security (authentication and authorization). Use cases appear to be missing in this area.
...
Davud
-
Permalink Reply by Rodrigo Flores on
-
Paul,
I think the theoretical framework you advocate, while useful, it's somewhat orthogonal to the SPACL work.
We are working on three definitions. I'd love to get feedback on those elements and attributes.
-
Permalink Reply by Paul G. Huppertz on
-
Hi Rodrigo,
the approach, I have explained is about clearly, completely and concisely specifiying ICT-based services and building a service catalog with service offerings based on the specifications with the 12 standard service attributes. Please find further details and explanations in the attached presentations for further discussions.
- Service Delivering Model
- Service Specifying Methdolody
Best regards
Paul
Rodrigo Flores said:Paul,
I think the theoretical framework you advocate, while useful, it's somewhat orthogonal to the SPACL work.
We are working on three definitions. I'd love to get feedback on those elements and attributes. - Attachments:
© 2012 Created by Rodrigo Flores.
Powered by
