Service Utility & Service Warranty mapped to the 12 standard service attributes

Replies to This Discussion

Permalink Reply by Rodrigo Flores on January 13, 2010 at 11:56am

Paul,

Thank you for your thoughtful feedback. This is very useful to think about; and it's exactly what we hoped for from the community.

Clearly, you care about this subject deeply and have strong opinions about service definitions. So let me take the time to explain how the SPACL tech committee is going about the work and the best way to have your ideas be considered and hopefully added to the spec.

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.

For the purpose of this discussion, I'll pick SPACL ServiceOffering as the object.

So let me explain what this means with one of your service attributes, like Service Consumer Count.
First, we need to document what it is in an unambiguous, machine and human readable format. This is the semantic part of the job.

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?

For example, your 04 Service Consumer count, as I read it, might be run-time and not definitional. In other words, the party publishing the ServiceOffering, when they have defined their service may not have a way of knowing the number of registered users. So that aspect would not work for SPACL ServiceOffering. It would work for a future ServiceAgreeement object, which we have decided not to tackle in the first iteration of SPACL.

On the other hand, I can read your definition of Consumer Count in such a way that there are aspects that are definitional and apply to ServiceOffering. It'd be great if you could provide us a definitional version.

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.

I've taken the time to write this lengthy post because I want you and others to contribute to SPACL and the easiest, fastest way is for you to understand how we go about the work.

So it'd be a great contribution if you'd like us to consider your feedback to try to distinguish what are elements, attributes? What data structures and data types we should we be modeling.

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.

• ▶ Reply

Permalink Reply by Rodrigo Flores on January 13, 2010 at 12:20pm

Paul,
See my answer to your first part in the other thread.

• ▶ Reply

Permalink Reply by Paul G. Huppertz on January 14, 2010 at 2:20am

Rodrigo Flores said:

Paul,

Thank you for your thoughtful feedback. This is very useful to think about; and it's exactly what we hoped for from the community.

Clearly, you care about this subject deeply and have strong opinions about service definitions.

[PGH] To be & stay clear from the first and avoid further confusion, I'd like to distinguish between - a definition which is an explanation of the meaning of a term s. http://en.wikipedia.org/wiki/Definition - a specification which is a set of requirements to be satisfied by a good or a service s. http://en.wikipedia.org/wiki/Specification_(technical_standard)_ From my perspective, it's about the definition of the service term at the beginning and then always about specifying particular ICT-based Business Support services and their service contributions. s. http://en.wikipedia.org/wiki/Service_(economics)#Service_definition s. http://en.wikipedia.org/wiki/Service_(economics)#Service_specification [PGH/] So let me take the time to explain how the SPACL tech committee is going about the work and the best way to have your ideas be considered and hopefully added to the spec.

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. [PGH]
From my perspective, it would be about the specification(al) elements as the service (term) is defined once.
[PGH/]

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.

For the purpose of this discussion, I'll pick SPACL ServiceOffering as the object. [PGH]
Each service offering can be clearly, completely & concisely specified by means of the 12 standard service attributes. This specification conforms to the MECE principle (Mutually Exclusive, Collectively Exhaustive).
s. http://en.wikipedia.org/wiki/MECE_principle
[PGH/]


So let me explain what this means with one of your service attributes, like Service Consumer Count.
First, we need to document what it is in an unambiguous, machine and human readable format. This is the semantic part of the job. [PGH]
The Service Consumer Count in standard service attribute 04 is a simple number and unambiguous, machine and human readable insofar.
[PGH/]


Then we run it through a "Core set of Definitional Elements, Attributes, Data Structure and Hierarchy" test. I'll explain.

First, is it core? [PGH]
Regarding that each service triggered by an authorized service consumer must be explicitly rendered to this triggering service consumer, it is paramount to focus on the service consumer. The specification as a whole expresses that the Service Consumer Benefits described in attribut 01 must be rendered to the triggering service consumer at his current Service Delivery Point (attribute 03) within the timeframe specified in attribute 10 'Service Delivering Duration'. For this reason, in the specification, the Service Consumer Count is set to '1' and in the SLA, the value of the Service Consumer Count is set to the number of intended authorized service consumers in the area of the ordering service customer. Furthermore, the names and other identifying data about the authorized service consumers are listed in the appendix of the SLA, so that they can be equipped and authorized accordingly. The particular number of service consumers is an important input for the accountable service provider for calculating the required service deliverying capacity. The service provider has to think about the service triggering rate of the authorized services consumers, so that he can determine the service triggering emergence. E.g. for e-mail services: if the are 100 authorized service consumers specified in the appendix of the SLA (or the correspondent database) and each service consumer triggers 3 e-mail services per hour on average, the service provider must allow for rendering 300 e-mail services per hour.
[PGH/]

Which is a judgement call for sure, but if it's not there is the ServiceOffering still valid?
[PGH]
As each service offering must be made with the service consumers in mind, the service consumer (count) is indispensable and must be included in the service specification. It makes clear that each service consumer is considered with his particular service triggering and it serves as a placeholder for the effective number of authorized service consumers in the signed SLA. By specifying this from the first, no later question or investigation is necessary regaring this basic data.
[PGH/]

If it's not there, does something important break.
[PGH]
If the Service Consumer Count is not there, the required service delivering capacity cannot be calculated appropriately and the sizing of the service-relevant ICT systems might be inappropriate which either leads to many service denials or to wasting money because the system is to large.
[PGH/]

And also the opposite, if this gets added, what compatibility and interchange between systems might get lost.
[PGH]
None & nothing is lost, as the data can be easily transferred and interchanged between any systems.
[PGH/]

What complexity might get introduced?
[PGH]
The complexity of a simple number or count which is indispensable for calculating the required service delivering capacity (which is different from the required system capacities!)
[PGH/]

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.
[PGH]
Understood, and the clear, complete & concise service specification with the 12 standard service attributes the easiest way to specify any service (conribution). As it is generic, this specification can be used for primary business services, for ICT-based Business Support Services (ICTBSS), for service contributions, for services which are based on technology and technical systems. The specification methodology must be learned only once and then can be applied for any type of service and for each & every (type of) service contribution.
[PGH/]

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? For example, your 04 Service Consumer count, as I read it, might be run-time and not definitional. In other words, the party publishing the ServiceOffering, when they have defined their service may not have a way of knowing the number of registered users.
[PGH]
Better written: the Service Consumer Count is specificational and run-time. The value of the service consumer count can be easily transferred to any party. Then, the receiver of the complete specification is able to calculate the required service delivering capacity.
If the Service Offering is specified and published, it cannot be known yet, how man service consumers will be intended by the service consumers who will commission the offer services. Therefore, the Service Consumer Count in attribute 04 is a placeholder - and a kind of check point - for this number which must be precisely determined.
[PGH/]

So that aspect would not work for SPACL ServiceOffering.
[PGH]
I'd suggest to consider the arguments above.
If the service consumer count is not considered and integrated from the first, the question comes up where & when the Service Offering will be substantiated with the number of authorized service consumers. As this count is indispensable for calculating the service delivering capacity, it must be determined in any case - why not at in the course of commissioning the service delivery by means of the SLA which contains the specification of the respective service?
[PGH/]

It would work for a future ServiceAgreeement object, which we have decided not to tackle in the first iteration of SPACL.
[PGH]
... and this is prepared by the attribute 'Service Consumer Count' in the specification as a placeholder and checkpoint for the Service (Level) Agreement.
[PGH/]

On the other hand, I can read your definition of Consumer Count in such a way that there are aspects that are definitional and apply to ServiceOffering. It'd be great if you could provide us a definitional version.
[PGH]
As explained in the Wikipedia entry, the Service Consumer Count specifies the number of intended, identified, named, registered and authorized service consumers which shall be and/or are allowed and enabled to trigger and consume commissioned services for executing and/or supporting their business tasks or private activities.
s. http://en.wikipedia.org/wiki/Service_(economics)#Service_specification
[PGH/]

Third, is this an element or an attribute? An attribute is like a field. It has a value and a data type.
[PGH]
The Service Consumer Count is attribute; it's data type is integer.
[PGH/]

On the other hand price is an element of SPACL definitions and has a complex data structure at that.
[PGH]
As explained in the Wikipedia entry, the Service Delivering Price in attribute 12 has two portions, i.e.
- the service access portion
- the service consumption portion
and there are three basic price models for the service consumption portion
- flat rate based
- volume based
- unit based
The format is currency and it is always referred to one service consumer (as he is the sole focus for any service delivery) and to one month for flatrate based and volume based prices.
s. http://en.wikipedia.org/wiki/Service_(economics)#Service_specification
[PGH/]

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. [PGH]
Applying the clear, complete & concise serivce specifiation with the 12 standard service attributes, there is a limited set of options
- 01. Service Consumer Benefits - formt: free text
- 02. Service-specific Functional Parameters - format: depending on the service, e.g. for e-mail service: MB for the maximum allowable size of one e-mailbox, MB for maximum allowable size of one particualr e-mail including attachments, blocked datafile formats (exe, com, vbs, etc.)
- 03. Service Delivery Point - format: user interface, e.g. MS/Outlook, port type, e.g. TCP port
- 04. Service Consumer Count - format: integer
- 05. Service Readiness Times - format: hh:mm (24 hour format) and time zone
- 06. Service Support Times - format: hh:mm (24 hour format) and time zone
- 07. Service Support Langugages - format: names of mother tongues
- 08. Service Fulfillment Target - format: percentage
- 09. Maximum Impairment Duration - format: hh:mm
- 10. Service Delivering Duration - format: hh:mm
- 11. Service Delivery Unit - format: free text
- 12. Service Delivering Price - format: currency.
[PGH/]

And finally we have hierarchy. Are some elements required by other elements?
[PGH]
As the 12 attribute as mutually exclusive, there is no hierarchy.
[PGH/]

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.
[PGH]
See the explanations regarding the Service Delivering Price above
[PGH/]


I've taken the time to write this lengthy post because I want you and others to contribute to SPACL and the easiest, fastest way is for you to understand how we go about the work.
[PGH]
Many thanks for this. I appreciate it very much as the explanations should propel the discussion and clarifications.
[PGH/]

So it'd be a great contribution if you'd like us to consider your feedback to try to distinguish what are elements, attributes? What data structures and data types we should we be modeling.
[PGH]
There are 12 attributes which have a distinct format, some maybe depending on the service. There maybe a range of or a set of preselected attribute values. As far as I can understand, there are no elements (necessary) in this concern.
[PGH/]

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.
[PGH]
If we are all clearly & consistently distinguishing between (term) definition and (service) specification, we should be able to avoid ambiguity and provide impartiality in both, the definition of the service term and the specification of the offered services.
[PGH/]

• ▶ Reply

▶ Reply to Discussion