I think it's important to define very well the concepts of product, service and resource. In fact I don't see very well the difference between a service and a resource in this context (perhaps you can help me in this aspect).

Here I expose some ideas for discussion:

Some definions:

A service: any capacity or functionality exposed as a service (so a consumer can invoke it with an API), owned by a service provider, an application provider, a content provider, and advertiser, a Telco operator...

The owner of a service can share it to allow its reutilisation by others to create more complex services (for example a BPEL flow)

In other hand the owner of a service can sell it to final customers or allow other service providers to sell the service.

A product  is a commercial concept and may be a complex commercial package (a set of aggregated services) or a simple one (only one commercial service.)

So, a service is something available to providers while a product is something available to final customers.

About meta-data:

I think a service should have two kind of meta-data/specifications related:

• Service Technical Specifications (STE): They describe the service functionalities, the pre-conditions and post-conditions to be invoked, how to invoke it and this kind of things.
• Service Business Specifications for providers (SBE): Talk about the conditions (business conditions) in order to allow other providers (not the owner) to reuse it to create a more complex service or to package/sell it.

As well a product should have two kind of meta-data/specifications related:

• Product Technical Specifications (PTE): They describe to final customers the service functionalities, how to use it etc.
• Product Business Specifications (PBE) in order to be sold to final customers, this business specifications tells the customer the commercial conditions to contract/use the service. The business specification also describe the business model and the value chain related to the service (revenue sharing conditions between providers etc.)

About LM:

I think it would be a good idea to try to separate the technical and the commercial management of services, understanding:

• Technical LM: related to processes/tools that will allow to discover the available services owned by different providers and their technical specifications and that will allow participants to publish the technical specifications of their own services, and also to develop and publish new products resulting from the composition and orchestration of existing ones (STE and PTE management)
• Commercial/Business LM: related to processes/tools that will allow to share services between providers (SBE management) and the management of products for final customers (PBE management).

SagrioA wrote: I think it's important to define very well the concepts of product, service and resource. In fact I don't see very well the difference between a service and a resource in this context (perhaps you can help me in this aspect).

One cornerstone of your article is “a service is something available to providers while a product is something available to final customers.” With that definition in mind, you certainly need both business specifications and technical specifications for products as well as for services. But instead of coming up with a completely new interpretation of the terms product and service which I feel is opposed to the spirit of SID, I suggest to follow the SID as closely as possible and to identify the topics that need to be added or changed. Nevertheless, I do agree that we need a technical lifecycle management in addition to a business lifecycle management.

In SID, both the product and the service are made available to a customer by a service provider. The product ABE (aggregate business entity) is the commercial wrapper and relates to the proposed idea of “business specifications”. The service ABE relates to the technical functionality in a way similar to the proposed “technical specifications”.  In a value chain, service provider SP1 is a customer of service provider SP2:  SP1 selects a product offering from SP2’s product catalog, SP2 procures a corresponding product (the instance) to SP1 as a handle for the CRM process domain and makes the technical functionality available as a service.

Below I included a summary that I wrote some time ago. It interprets some key concepts of the SID Phase VII with regard to lifecycle management, and I hope it will help in understanding the relationship of the various concepts.

Kind regards,

Martin Gutzki

SID Product / Service / Resource Summary

A product catalog is a list of product offerings that customers can buy or lease from a service provider. A product offering is comprised of one or more product specifications which detail the characteristics exposed and the value delivered to a user, and which can exist in different versions according to their product specification version. A product offering is valued by its product offering price, targeted to specific market segments and made available to the market through defined sales channels. Marketing campaigns promote selected product offerings that are listed in a product catalog.

A product offering is instantiated by the service provider as an individual product during fulfillment. The product represents the customer’s particular instance of a product offering, therefore the interactions between customer and service provider concerning billing, customer trouble and termination relate to the product, not the product offering.

A service represents logical functionality that is packaged as part of a product. A service is the means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. SID differentiates between resource- and customer-facing services.

A resource-facing service is a mechanism to enable access to a set of one or more capabilities (e.g. communications, information processing), where the access is provided using a well-defined interface. The resource-facing service represents the technical aspects of a service and is bound to the underlying physical and logical resources. A resource facing service can be accessed by clients through a protocol at a defined device interface that is identified by a network address (such as an URL). A customer-facing service aggregates resource-facing services, it represents the delivered value of the service to a user while hiding the technical details. Product (market aspects) and its underlying resource-facing services (technical aspects) are never linked directly, but through customer-facing services as intermediary.

A service represents the functionality (e.g. of a particular communication system or computing system) that is instantiated and made available for use by clients. A service usage is an occurrence of employing a service for its intended purpose, with the consequence of the realization of one or more real world effects. In a network centric environment, service usage can be monitored by observing the exchange of messages between a device interface and a client.

A service catalog (not a SID class in SID VII) is a list of customer-facing service specifications and resource-facing service specifications. Each specification reflects the invariant characteristics of a service, and can exist in different versions according to its customer- or resource-facing specification version. Product specifications are built from customer-facing service specifications which in turn aggregate resource-facing service specifications. Customer-facing service specifications are convenient as shared knowledge between market-oriented product management functions and technology oriented factory functions.

Resource-facing services are implemented by logical resources which are contained in and are supported by physical resources. Physical resources are tangible entities of a computing and communications infrastructure (e.g. physical devices, chassis, slots, cards, ports, disks, memory, processing units, cables and connectors). Logical resources are immaterial entities that reside within physical resources (e.g. software, operating systems, logical devices, device interfaces, network addresses and protocols). 

A resource catalog (not a SID class in SID VII) is a list of resource specifications. Each resource specification reflects the invariant characteristics of a resource, and can exist in different versions according to its resource specification version. A resource-facing service specification links to its underlying resource specifications. Sometimes hardware is sold or leased as a visible part of a product, this can be modeled by means of an association between product specification and resource specification.

Differences between services and resources.

In my opinion here is how they relate. [Please note however my comments below about the notions of services].

Resource can have two definitions:

l  Either anything that may exist in a service provider environment and may be interacted with other elements in the SP domain. That would include OSS, BSS components, network elements as well as any application.

l  Or the elements in eth SP domain that support SDF services or functions available to SDF services but are not modeled in SDF. That would include: OSS or BSS functions or Network elements.

We need to decide which one we want to select.

Note that while not at all an expert I believe that resources may also have a different meaning in some OSS or BSS models (e.g. from TMF). So we may have to use the term “SDF resource”...

Services

I think these notions are indeed recipes for some confusion. It should be noted that n many environments, these definition have completely different meanings. We need to first decide what is intended behind the notion of service. In the spaces I am coming from these notions have at least several diametrically different notions:

l  Applications that run in environment

l  The definition you provide above and variations from a SOA / SCA point of view

l  BSS notion of service built on available products...

We must make room for these concepts with terms not too far from the expectation of people.

I personally think that the two first bullet are similar are what we mean b y SDF service.

The third one should be denoted differently either as BSS service, or service only...

Product:

I think you notions of product overlap and confuse the notions of BSS product and BSS services which are also prevalent in industry.

In my understanding a product is more something that can be sold to a customer. A service a la BSS is a package of products that can be sold to customers. The difference between the two is interesting only from a BSS point of view in the sense that products may be made available as part of a product catalog that marketing can further customize, bundle, promote etc as part of a service sold to the customers.

Meta-data

Before understanding meta-data, we must understand the notions of dependencies.

As new applications are built using possibly other components they have tangible dependencies (i.e. I am calling other components or I am composed by other components) and intangible ones (I need to have a particular bandwidth available to have this running or expect also that I have subscription to another service or have a certain type of client or phone...).

The tangible dependencies are IMHO contained in the implementation and packaging of the new service. This is squarely an issue of the SCE and execution environment packaging story.

The intangible dependencies are much more complicated. This where we will need to have metadata to model and accompany the life cycle management interfaces. The business requirements are really; how to I describe and convey intangible dependencies when I handle, re-program or compose a component so that we can check that these dependencies are satisfied when a service / product is created in CRM, when a customer order sit, when fulfillment needs to take place or when we have to resolve troubles etc...

This is IMHO what the SDF meta-data must capture: the intangible dependencies.

With respect to the proposal so far, I certainly would not consider that what is called PTE is meta-data. That seems more the interface description to me, i.e. something like a WSDL or other representation of the interface to put in a software repository like UDDI. For the matter of the SDF it is really all what matters.

I understand that the PTE proposal also seems to include what I would almost call as product data sheets and or other type of manuals / documentations. I would agree that it is of certain value to track that. However I have difficulties to understand how it is really relevant to the SDF aspects. Indeed, as say software is re-programmed or composed, the evolution of the documentation is not really something that can be modeled and most often it becomes immediately obsolete (note what is not obsolete is really the underlying intangible dependencies that I mentioned above, IMHO).

Similarly I do see the value to discuss PBE somewhere, but I believe these are pure BSS considerations, again not related to SDF / life cycle management. Manuals, SLAs, etc are aspects that the business terms must capture in the collateral tracked by support, CRM or even ERP or fulfillment (for packaging etc...). SLAs etc may result into what needs to be activated, provisioned, fulfilled and charged but this is because the BSS or OSS manage the lifecycle of the run time and SDF services according to this data.

Manuals are part of the products. SLAs, contracts, etc are part of the OSS/BSS: service catalog information (e.g. available plans), subscriber subscription (what I have subscribed to, under what terms), assets, rates etc that are “set” via lifecycle management of resources / SDF services. It is that aspect that matters for SDF. The data characterization data is part of OSS/BSS data models, not extra metadata IMHO.

Distinction between Technical and business life cycle management

I am not understanding that analysis / discussion.

In my view, we are modeling the life cycle management across OSS and BSS not the life cycle aspects of SW creation in general nor the eTOM cycle on the OSS/BSS side.

I feel that there may be a confusion on the aspects at least that we must clarify.

Reading about the description of technical LM: I think that producing collateral for products is really not what LCM is about. It should rather be about how OSS/BSS and run time interact to allow things like creating a new software (from scratch, by composing others or by reprogramming one), making it available as a product or elements that can be part of a service and sold/promoted, bundled, then allowing its deployment, activation, provisioning to be available to fulfill customer orders and have them fulfilled, allow execution, charging, activity monitoring, troubleshooting, upgrade and retirement. Etc.

In that context aspects like generating collaterals (business or technical) are at best part of some SDF service or product creation phases. Metadata is IMHO a relevant step for us to model if we identify it instead as the intangible. But the tangible dependencies are produced by the SW tools (probably not for us to model) and the documentation is produced as part of the SW development practice, again something I am not sure we want to model.

I do not understand at all what you mean by commercial/business LM based on your definition. Again in my view once the SDF services + metadata are mapped on the OSS/BSS catalogs and inventories, I would expect that the cycles to generate bundles, promotions, sales, campaigns etc are part of the BSS / OSS... As such I do not believe we model in SDF, we reuse eTom and related processes...