Service Portfolio and Catalog Language
Public review site for SPACL documents.
Can the model do the following?
- Provide a mechanism for categorizing ServiceOfferings. Can a ServiceOffering belong in multiple categories? Is there a limit on how deep categories can be nested? Can a category appear as a sub-category in multiple categories?
- Should a RequestOfferingBundle exist without a ServiceOffering? For example, we may have the ServiceOffering of Email and Desktop Management. New Hire would be a RequestOfferingBundle that contains a "New Email Account" RequestOffering from the Email ServiceOffering and the "New Desktop/Laptop" RequestOffering from the Desktop Management ServiceOffering.
- Provide a mechanism for categorizing RequestOfferings. It may be more optimal to provide Business users a different way of browsing RequestOfferings that's different to the ServiceOffering structure, e.g. structured by commonly used Requests, or by job functions / role, etc.
- May need to think through the ServiceRequestGroup / ServiceRequest structure to model it after the more common OrderHeader / OrderDetail structure. Currently ServiceRequests have customerInfo thus allowing one particular ServiceRequestGroup to span multiple customers. This may cause complexity down the road when SPACL starts modeling approvals (and is inconsistent with other models like OrderHeader / OrderDetail where customerInfo, submissionDate, etc is at the header level)
PS: I'd like to learn how to become a formal member of the consortium.
- Should a RequestOfferingBundle exist without a ServiceOffering? For example, we may have the ServiceOffering of Email and Desktop Management. New Hire would be a RequestOfferingBundle that contains a "New Email Account" RequestOffering from the Email ServiceOffering and the "New Desktop/Laptop" RequestOffering from the Desktop Management ServiceOffering.
- Provide a mechanism for categorizing RequestOfferings. It may be more optimal to provide Business users a different way of browsing RequestOfferings that's different to the ServiceOffering structure, e.g. structured by commonly used Requests, or by job functions / role, etc.
- May need to think through the ServiceRequestGroup / ServiceRequest structure to model it after the more common OrderHeader / OrderDetail structure. Currently ServiceRequests have customerInfo thus allowing one particular ServiceRequestGroup to span multiple customers. This may cause complexity down the road when SPACL starts modeling approvals (and is inconsistent with other models like OrderHeader / OrderDetail where customerInfo, submissionDate, etc is at the header level)
PS: I'd like to learn how to become a formal member of the consortium.
Views: 28
Replies to This Discussion
-
Permalink Reply by Paul G. Huppertz on -
1. Service Offerings and categories
If you take the service specification with the 12 standard service attributes as method & means for specifiying each service, ...
s. http://en.wikipedia.org/wiki/Service_(economics)#Service_specification
... you will have to basic categories of service (offerings)
- ICT-based Business Support Services (ICTBSS) on the highest aggregation level, e.g. Order Management Services, CRM Services, Document Sharing Services, E-Mail Service and the like
- service contribution on the lower aggregation levels, i.e. primary, secondary, tertiary, etc. service contributions, which are used for aggregating higher level service contributions, e.g. Application Hosting Services, Directory Services or LDAP Services, respectively, Storing Services, Server OS Hosting Services, DNS Services, DHCP Services, Server Device Housing Services, etc.
All these ICTBSS and service contributions are independent and clearly distinguished and they can be clearly, completely & concisely specified with their 12 attributes and attribute values. Their are about 30 to 50 standard service contributions as listed above which must be specified only once and then can be used for aggregating many different ICTBSS. This simplifies the entire approach whilst keeping it clear and consistent. As every service contribution is independent as such, there is no overlapp or mixing-up.
2. Service Request Offering and Service Offering
Service Requests and Service Triggers must be clearly distinguished
- Service Requests are concerning some questions regarding triggering, consuming and utilizing ICT-based Business Support Services and the necessary ICT systems with their functions; they are depending on individual conditions and cases
- Service Triggers are standard actions for triggering a service delivery, e.g. by hitting the send button in the e-mail client software which implicitly asks for delivering one e-mail service, i.e. forwarding one copy of the original e-mail to every e-mailbox of the intended addressees.
Service Requests are directed towards the Service Desk and the service contributions of the service desk must be included as a standard tertiary service contribution in every ICT-based Business Support Service (ICTBSS).
Conclusion: Answering any service request is covered by the standard service contribution of service (consumer) support for each independent ICTBSS.
3. Categorization of Service Requests
Based on the explanation above, there is no need of categorizing service requests as each & every service request is assigned to a specific ICTBSS and covered by the standard service contribution of service (consumer) support for the respective ICTBSS. Each service consumer authorized to trigger such an ICTBSS also is authorized to initiate service requests related to this ICTBSS, e.g. asking for more e-mail store capacity related to e-mail services. These service requests are independent from job function, role, etc. as the are related with the specific ICTBSS.
3. Service Request Groups
Based on the explanations above, every service request is related to a specific ICTBSS and every ICTBSS has a specific set of service potential requests which can be determined in advance and assigned to the respective call of an authorized service consumer. All approvals, if any necessary, should be prepared in advance and assigned to the ICTBSS and every authorized service consumer may initiate such a service request.
-
Permalink Reply by Rodrigo Flores on -
Reg,
thanks for the question. We are now back from holidays and we'll be engaging more. You ask some excellent questions. And they require that I set the stage for how we are thinking about in the SPACL work. I just wrote this for Paul Huppertz in a different thread, but it's worth summarizing here.
For SPACL, we need to model a "Core set of Definitional Elements, Attributes, Data Structure and Hierarchy" in one of the three objects we have decided to tackle first. There are other objects, which we may tackle later or never. For example, we decided not to tackle a protocol layer for service request exchanges at this point.
Then we run it through a "Core set of Definitional Elements, Attributes, Data Structure and Hierarchy" test. I'll explain.
First, is it core? Which is a judgement call for sure, but if it's not there is the ServiceOffering still valid? If it's not there, does something important break. And also the opposite, if this gets added, what compatibility and interchange between systems might get lost. What complexity might get introduced?
In the SPACL group we are guided by the history of successful standards, which teaches that the more complex the standard, the less adoption it has. X.400 was the ultimate e-mail standard, but the winner that the internet runs on is Simple Mail Transfer Protocol, and the X.500 model too heavy so it was replaced by Lightweight directory protocol, and so on. So the question of core is a very important one.
Second, is Definitional or is it Run-Time? In other words, can this element or attribute be sent from one party to another without the party having to know about the service operations?
Third, is this an element or an attribute? An attribute is like a field. It has a value and a data type. On the other hand price is an element of SPACL definitions and has a complex data structure at that. For example, the price of "$30 per user per month" is one that has currency time, integer, a unit of measure "per user" which has to be defined somewhere, and a periodicity that also has to be explained ie. a year has 12 months, for example.
In SPACL we know we need to define these things. The question is to what degree? Do we need to create a list of allowable units of measure for IT, such as byte, kilobyte, megabyte, gigabyte, etc? And maintain them? This is a serious endeavor and one that other e-commerce standards eventually had to. For fun, check out the UN site where the global units of measure for international e-commerce are documented.
And finally we have hierarchy. Are some elements required by other elements? For example, price often requires units; it's $5 per hot dog. $5 does not tell you enough. You need the unit of measure hot dog. Thus unit is part of price in this example.
Our goal with SPACL is to take the ambiguity and opinion about service definitions as much as possible and no more. There will always be the need to extend the definition for different industries, uses, etc. In fact SPACL allows for extensions. We see our job as first defining that core set of elements and attributes which all Services need to share.
So to now answer some of your question (I'm lenghty, ain't I). For example your third bullet is very much run-time. The decision of how to display a service is one that a customer can make different from another customer. So SPACL might include category in the definition, but would not include display rules.
Same applies for workflow. We will not deal with workflow in SPACL for two reasons. First, it is a run-time decision that varies by customer. How a customer approves could not be known by the offering party. There's no way that a service provider could create a definition.
I love the questions and your category question and order header is something we'll discuss in the next SPACL meeting.
-
Permalink Reply by Rodrigo Flores on
-
Paul,
thanks again for your contribution. It does a good job of highlighting how many different ways we think about service. Categories are very important part of a service catalog. And if a service offering is akin to a product offering, then in e-commerce category management is a whole discipline.
So the categories you are pointing to are about composing/decomposing a service structure.
The categories Reg refers to have to do how to best display them in portal for different kind of users, how to find them and then how to report against them for service level and financial purposes.
It's a very different usage of the word category. So we need to think of these different usages and potentially come up with a taxonomy of them and decide which should be part of SPACL.
Does that make sense?
Paul G. Huppertz said:1. Service Offerings and categories
If you take the service specification with the 12 standard service attributes as method & means for specifiying each service, ...
s. http://en.wikipedia.org/wiki/Service_(economics)#Service_specification
... you will have to basic categories of service (offerings)
- ICT-based Business Support Services (ICTBSS) on the highest aggregation level, e.g. Order Management Services, CRM Services, Document Sharing Services, E-Mail Service and the like
- service contribution on the lower aggregation levels, i.e. primary, secondary, tertiary, etc. service contributions, which are used for aggregating higher level service contributions, e.g. Application Hosting Services, Directory Services or LDAP Services, respectively, Storing Services, Server OS Hosting Services, DNS Services, DHCP Services, Server Device Housing Services, etc.
All these ICTBSS and service contributions are independent and clearly distinguished and they can be clearly, completely & concisely specified with their 12 attributes and attribute values. Their are about 30 to 50 standard service contributions as listed above which must be specified only once and then can be used for aggregating many different ICTBSS. This simplifies the entire approach whilst keeping it clear and consistent. As every service contribution is independent as such, there is no overlapp or mixing-up.
2. Service Request Offering and Service Offering
Service Requests and Service Triggers must be clearly distinguished
- Service Requests are concerning some questions regarding triggering, consuming and utilizing ICT-based Business Support Services and the necessary ICT systems with their functions; they are depending on individual conditions and cases
- Service Triggers are standard actions for triggering a service delivery, e.g. by hitting the send button in the e-mail client software which implicitly asks for delivering one e-mail service, i.e. forwarding one copy of the original e-mail to every e-mailbox of the intended addressees.
Service Requests are directed towards the Service Desk and the service contributions of the service desk must be included as a standard tertiary service contribution in every ICT-based Business Support Service (ICTBSS).
Conclusion: Answering any service request is covered by the standard service contribution of service (consumer) support for each independent ICTBSS.
3. Categorization of Service Requests
Based on the explanation above, there is no need of categorizing service requests as each & every service request is assigned to a specific ICTBSS and covered by the standard service contribution of service (consumer) support for the respective ICTBSS. Each service consumer authorized to trigger such an ICTBSS also is authorized to initiate service requests related to this ICTBSS, e.g. asking for more e-mail store capacity related to e-mail services. These service requests are independent from job function, role, etc. as the are related with the specific ICTBSS.
3. Service Request Groups
Based on the explanations above, every service request is related to a specific ICTBSS and every ICTBSS has a specific set of service potential requests which can be determined in advance and assigned to the respective call of an authorized service consumer. All approvals, if any necessary, should be prepared in advance and assigned to the ICTBSS and every authorized service consumer may initiate such a service request.
© 2012 Created by Rodrigo Flores.
Powered by 
.
