I'm pleased to announce that I've become part of NGOSS-Applied, a group of NGOSS experts who can provide real world practical experience in the implementation (and interpretation) of NGOSS, eTOM, and of course SID. This group is being managed through LTC International and a formal announcement will be made on their websites soon.
The objective of the NGOSS-Applied group is to allow a Telco to find one or more experts who have practical hands-on experience of NGOSS and its implementation without bringing down the might (and expense) of one of the big Systems Integrators.
This service is not a replacement of the training and support provided by the TeleManagement Forum, but an adjunct to it and is being put together with their knowledge and blessing.
Should any of you want to know more, then please email me or leave a comment on this blog with your email address and I will send you the brochures and further details.
Incidentally I see I am getting about 10 hits a day on this blog, but very few comments from anyone. Please don't hesitate to ask me a question about the blog or anything related to SID or to suggest something you would like me to write about.
15 October 2008
21 August 2008
How Things Can Go Wrong – a Fantasy
I thought I would try to sum up my last two postings with an example or fantasy to illustrate how “the best laid schemes o' Mice an' Men, gang aft agley”
To set the scene; imagine a start-up Telco that launches with a single ‘all singing all dancing’ software suite that does everything from Customer Care and Order Management through to Billing and Provisioning.
Things work fine for several years and the Telco grows, but eventually, the customer base gets too big for its unified OSS to handle and the new products that marketing want to launch cannot be easily implemented in the system and often require code changes. It is decided it is time to update the OSS, and rather than a ‘big bang’ approach they decided in the low risk strategy of a stepwise replacement of functionality.
First of all they move Billing out to another platform. This will increase throughput and allow more sophisticated pricing plans and discounts.
They select leading Billing package and then spend a lot of time and effort tailoring it to integrate with the legacy system, so the state-of-the-art billing functionality, pricing plans, discounting rules and product definitions are amended to reflect the legacy system’s functionality and product definitions. The official reason for this decision was it would be a waste of time and effort to update the interfaces and functionality in the soon to be replaced legacy system (but as we will discover later there is an additional dark hidden motive driving this decision).
A similar operation is then performed with the Provisioning subsystem, and each of the other parts of the OSS. Each interface is altered so that no change is required within the legacy system and where the legacy system cannot define the complexity of, for example, provisioning some of the new products and services the other systems add information and build special rules and processes to add the level of sophistication required.
Finally the Telco believes it is the right time to completely replace what remains of the legacy system with a market leading Order Management System.
Unfortunately, and inevitably, the project, like its predecessors, quickly runs into problems – the project team finds that they are not allowed to ask the Billing system or the Provisioning system or any other of the OSS components that interface to the Order Management System to change their interfaces or product definitions.
This has been part of the whole strategy for the stepwise OSS replacement; each of the new components is not allowed to ask for a change in any other of the other OSS components.
The Order Management project is now faced with the daunting task of amending the market leading functionality in the selected software package to work with the weird product catalogue, interfaces and constraints adopted by all the other components of the OSS. They are in fact re-implementing the legacy system they are replacing within the new Order Management package. While the new package has the functionality to completely describe the new advanced products within the Order Management system they cannot do this because the interface to the Billing and Provisioning systems are expecting the ‘dumbed down’ legacy system’s definitions and any change would mean that the special rules and procedures developed at great expense would no longer work.
The project deadlines slip, the volume of change requests soar, budgets are broken, doubled and redoubled, but eventually the Order Management system is finally launched.
To everyone’s horror it is quickly discovered that the problems of the old system are still present in the new one. It is impossible to define new products easily as every new product requires major software changes in every major component of the OSS.
The Telco still has the “ghost” of legacy system in their OSS and it will rule their product catalogue and limited their IT Architectural options for years to come.
So how could this imaginary Telco have done things differently? Each step along the way seemed to be sensible and avoided scope creep and spending money on amending soon to be replaced software. Despite this caution (or because of this) they ended up trapped by architectural mistakes made right at the start of the very first migration project. They had tightly coupled the components in their architecture and had never acknowledged that fact nor faced-up to the consequences of sticking with that architecture.
One thing they needed was a loosely coupled architecture – one in which each component (system) is completely unaware of the inner workings of the other component, and only aware of the services the other component support (or require) and the functions (methods) and information required or delivered by the service. A loosely couple architecture allows each component to be independent of every other and can be developed, used, and replaced without impacting any other component.
To achieve this they should have adopted the TMF SID model and mapped the legacy system’s concepts to it. Then each new system should have used the SID definitions, (and not the legacy system’s) to map to (and not implement as) their own internal data structures. There is a lot of effort initially, but one that would have saved them a lot of grief in the long run.
There is also a hidden problem with the architectural approach inherent in the whole process that no one in this imaginary Telco could see.
No one stopped to think about the product catalogue and its definitions. The Telco had ‘grown up’ with the legacy system as initially it ruled every aspect of their business. The way that system defined products and services became part of the corporate culture to the extent that the quirky vocabulary the legacy system used to describe the products end up in the company’s marketing material.
The product catalogue worked fine for the legacy system, but the Billing package has a more advanced and flexible way of working. Rather than adopting that the Telco decides to amend the product definitions in the Billing package to match those in the legacy system. This is, after all, the way the Telco itself thinks about their products and services, so it seemed a very sensible thing to do…
This is actually a form of the Stockholm Syndrome. The Telco feels trapped by the legacy system, but is secretly ‘in love’ with it and has ‘subconsciously’ absorbed its constraints and ways of working even though these are the very reasons for wanting to escape from it.
Again use of the TMF’s SID model could prevent this. There would be considerable pain in the early stages of the whole migration strategy where the Telco has to stop using the legacy vocabulary, map its products into the SID concepts of Product Offering, CFS, and Resource Specification and in the process learn a new system-independent vocabulary. A painful process in deed – especially where a good number of Product Managers, and the users and owners of the legacy systems will see no point in it.
But having taken that pain early on, one of the reasons for moving away from the legacy system – its inability to describe complex products – would then be sealed into that system. It would no longer “infect” each and every other component of the OSS, nor stunt the Telco’s ability to visualise and describe (in a way their customers can understand) new complex Offerings.
Fact or fantasy? – Well, as I said, the scenario is a fantasy, but does this sound like anything you have experienced?
To set the scene; imagine a start-up Telco that launches with a single ‘all singing all dancing’ software suite that does everything from Customer Care and Order Management through to Billing and Provisioning.
Things work fine for several years and the Telco grows, but eventually, the customer base gets too big for its unified OSS to handle and the new products that marketing want to launch cannot be easily implemented in the system and often require code changes. It is decided it is time to update the OSS, and rather than a ‘big bang’ approach they decided in the low risk strategy of a stepwise replacement of functionality.
First of all they move Billing out to another platform. This will increase throughput and allow more sophisticated pricing plans and discounts.
They select leading Billing package and then spend a lot of time and effort tailoring it to integrate with the legacy system, so the state-of-the-art billing functionality, pricing plans, discounting rules and product definitions are amended to reflect the legacy system’s functionality and product definitions. The official reason for this decision was it would be a waste of time and effort to update the interfaces and functionality in the soon to be replaced legacy system (but as we will discover later there is an additional dark hidden motive driving this decision).
A similar operation is then performed with the Provisioning subsystem, and each of the other parts of the OSS. Each interface is altered so that no change is required within the legacy system and where the legacy system cannot define the complexity of, for example, provisioning some of the new products and services the other systems add information and build special rules and processes to add the level of sophistication required.
Finally the Telco believes it is the right time to completely replace what remains of the legacy system with a market leading Order Management System.
Unfortunately, and inevitably, the project, like its predecessors, quickly runs into problems – the project team finds that they are not allowed to ask the Billing system or the Provisioning system or any other of the OSS components that interface to the Order Management System to change their interfaces or product definitions.
This has been part of the whole strategy for the stepwise OSS replacement; each of the new components is not allowed to ask for a change in any other of the other OSS components.
The Order Management project is now faced with the daunting task of amending the market leading functionality in the selected software package to work with the weird product catalogue, interfaces and constraints adopted by all the other components of the OSS. They are in fact re-implementing the legacy system they are replacing within the new Order Management package. While the new package has the functionality to completely describe the new advanced products within the Order Management system they cannot do this because the interface to the Billing and Provisioning systems are expecting the ‘dumbed down’ legacy system’s definitions and any change would mean that the special rules and procedures developed at great expense would no longer work.
The project deadlines slip, the volume of change requests soar, budgets are broken, doubled and redoubled, but eventually the Order Management system is finally launched.
To everyone’s horror it is quickly discovered that the problems of the old system are still present in the new one. It is impossible to define new products easily as every new product requires major software changes in every major component of the OSS.
The Telco still has the “ghost” of legacy system in their OSS and it will rule their product catalogue and limited their IT Architectural options for years to come.
So how could this imaginary Telco have done things differently? Each step along the way seemed to be sensible and avoided scope creep and spending money on amending soon to be replaced software. Despite this caution (or because of this) they ended up trapped by architectural mistakes made right at the start of the very first migration project. They had tightly coupled the components in their architecture and had never acknowledged that fact nor faced-up to the consequences of sticking with that architecture.
One thing they needed was a loosely coupled architecture – one in which each component (system) is completely unaware of the inner workings of the other component, and only aware of the services the other component support (or require) and the functions (methods) and information required or delivered by the service. A loosely couple architecture allows each component to be independent of every other and can be developed, used, and replaced without impacting any other component.
To achieve this they should have adopted the TMF SID model and mapped the legacy system’s concepts to it. Then each new system should have used the SID definitions, (and not the legacy system’s) to map to (and not implement as) their own internal data structures. There is a lot of effort initially, but one that would have saved them a lot of grief in the long run.
There is also a hidden problem with the architectural approach inherent in the whole process that no one in this imaginary Telco could see.
No one stopped to think about the product catalogue and its definitions. The Telco had ‘grown up’ with the legacy system as initially it ruled every aspect of their business. The way that system defined products and services became part of the corporate culture to the extent that the quirky vocabulary the legacy system used to describe the products end up in the company’s marketing material.
The product catalogue worked fine for the legacy system, but the Billing package has a more advanced and flexible way of working. Rather than adopting that the Telco decides to amend the product definitions in the Billing package to match those in the legacy system. This is, after all, the way the Telco itself thinks about their products and services, so it seemed a very sensible thing to do…
This is actually a form of the Stockholm Syndrome. The Telco feels trapped by the legacy system, but is secretly ‘in love’ with it and has ‘subconsciously’ absorbed its constraints and ways of working even though these are the very reasons for wanting to escape from it.
Again use of the TMF’s SID model could prevent this. There would be considerable pain in the early stages of the whole migration strategy where the Telco has to stop using the legacy vocabulary, map its products into the SID concepts of Product Offering, CFS, and Resource Specification and in the process learn a new system-independent vocabulary. A painful process in deed – especially where a good number of Product Managers, and the users and owners of the legacy systems will see no point in it.
But having taken that pain early on, one of the reasons for moving away from the legacy system – its inability to describe complex products – would then be sealed into that system. It would no longer “infect” each and every other component of the OSS, nor stunt the Telco’s ability to visualise and describe (in a way their customers can understand) new complex Offerings.
Fact or fantasy? – Well, as I said, the scenario is a fantasy, but does this sound like anything you have experienced?
20 August 2008
EAI and SID
In the previous post I described how the TMF’s SID provides the language for SOA – in this posting I will discuss its role in an Enterprise Application Integration (EAI) architecture.
When building an interface between two systems there would always be a negotiating between the two architects or designers which boils down to “your data or mine” – would the interface be formatted according to the sender or the receiver or would it be some sort of hybrid of the two.
This is fine if there are only two systems to interface, but when that becomes more like 10 systems, each of which has an interface with the other, the number of interfaces grows to 45, each in its own format and each requires its own ‘translation’ rules at one end of the interface or the other. This is just about manageable but will keep the Telco’s IT department busy, but as soon as one component is replaced some very tough decisions have to be made about each of the interfaces.
What is needed, though it isn’t immediately apparent, is a form of ‘Esperanto’ for the interfaces.
To understand this, instead of systems think of people who speak different languages. If you have just an Englishman and a Frenchman wanting to communicate one or both of them will need to use a French-English dictionary. Introduce a German into the group and you need two more dictionaries (English-German and French-German). Let an Italian join in and the number of dictionaries jumps by three (English-Italian, French-Italian and German-Italian) to six in total. Every new language introduced to the group needs a new set of dictionaries (equal to the number of languages in the group before the newcomer arrived).
On top of that it isn’t possible to predict which party is going to use the dictionary. For example when the Frenchman communicates with the German he may have agreed to with him communicate in German, so he uses the dictionary, while when he talks to the Italian he may have agreed to provide his information in French and let the Italian have the dictionary – and for conversations with the Englishman they have decided to use a compromise “Franglais” – a mixture of English and French.
But what if there was a decision to use Esperanto? Everyone translates what they want to say into Esperanto and all the information they receive is in Esperanto which they must translate back from Esperanto into their mother tongue. The following table compares and contrasts the number of dictionaries required…
Using Esperanto would save 35 dictionaries when there are 10 members, and on top of that the use of the dictionary would be consistent for every member of the group.
So what has this got to do with the SID?
For Telcos the SID can take the role Esperanto It is totally independent of, and unaffected by, the inner workings of any particular component of the OSS but because of its scope and coverage every service delivered by each of the components within the OSS should be able to be expressed in the SID language.
So the SID (or its equivalent) is a prerequisite for an truly open EAI.
I wrote “should” above because there is still the issue of mapping tricky things like the product catalogue into SID and out again in without information loss or distortion (i.e. “Chinese Whispers”, or as it is called in Belgium “le Téléphone Arabe” or “Arabic Telephone”). This isn’t a problem in the SID this is a problem of the “grammar and vocabulary” of the interfacing systems.
But why doesn’t everyone just speak “English”? That surely would give the same result!
No, it would lead to problems because the grammar and vocabulary of one system (probably the oldest or ‘most important’ system) is imposed on each new component of the OSS even when those components had a richer vocabulary and grammar. The new components would/could be “dumbed down” (potentially at great expense) to speak the language of “stupid” legacy system and potentially negate the very reasons the new components were bought in the first place.
What is required, and what SID delivers, is a rich vocabulary and grammar that is tailored for the Next Generation OSS – not the last generation OSS!
When building an interface between two systems there would always be a negotiating between the two architects or designers which boils down to “your data or mine” – would the interface be formatted according to the sender or the receiver or would it be some sort of hybrid of the two.
This is fine if there are only two systems to interface, but when that becomes more like 10 systems, each of which has an interface with the other, the number of interfaces grows to 45, each in its own format and each requires its own ‘translation’ rules at one end of the interface or the other. This is just about manageable but will keep the Telco’s IT department busy, but as soon as one component is replaced some very tough decisions have to be made about each of the interfaces.
What is needed, though it isn’t immediately apparent, is a form of ‘Esperanto’ for the interfaces.
To understand this, instead of systems think of people who speak different languages. If you have just an Englishman and a Frenchman wanting to communicate one or both of them will need to use a French-English dictionary. Introduce a German into the group and you need two more dictionaries (English-German and French-German). Let an Italian join in and the number of dictionaries jumps by three (English-Italian, French-Italian and German-Italian) to six in total. Every new language introduced to the group needs a new set of dictionaries (equal to the number of languages in the group before the newcomer arrived).
On top of that it isn’t possible to predict which party is going to use the dictionary. For example when the Frenchman communicates with the German he may have agreed to with him communicate in German, so he uses the dictionary, while when he talks to the Italian he may have agreed to provide his information in French and let the Italian have the dictionary – and for conversations with the Englishman they have decided to use a compromise “Franglais” – a mixture of English and French.
But what if there was a decision to use Esperanto? Everyone translates what they want to say into Esperanto and all the information they receive is in Esperanto which they must translate back from Esperanto into their mother tongue. The following table compares and contrasts the number of dictionaries required…
| Members | Dictionaries | Esperanto Dictionaries |
|---|---|---|
| 2 | 1 | 2 |
| 3 | 3 | 3 |
| 4 | 6 | 4 |
| 5 | 10 | 5 |
| 6 | 15 | 6 |
| 7 | 21 | 7 |
| 8 | 28 | 8 |
| 9 | 36 | 9 |
| 10 | 45 | 10 |
Using Esperanto would save 35 dictionaries when there are 10 members, and on top of that the use of the dictionary would be consistent for every member of the group.
So what has this got to do with the SID?
For Telcos the SID can take the role Esperanto It is totally independent of, and unaffected by, the inner workings of any particular component of the OSS but because of its scope and coverage every service delivered by each of the components within the OSS should be able to be expressed in the SID language.
So the SID (or its equivalent) is a prerequisite for an truly open EAI.
I wrote “should” above because there is still the issue of mapping tricky things like the product catalogue into SID and out again in without information loss or distortion (i.e. “Chinese Whispers”, or as it is called in Belgium “le Téléphone Arabe” or “Arabic Telephone”). This isn’t a problem in the SID this is a problem of the “grammar and vocabulary” of the interfacing systems.
But why doesn’t everyone just speak “English”? That surely would give the same result!
No, it would lead to problems because the grammar and vocabulary of one system (probably the oldest or ‘most important’ system) is imposed on each new component of the OSS even when those components had a richer vocabulary and grammar. The new components would/could be “dumbed down” (potentially at great expense) to speak the language of “stupid” legacy system and potentially negate the very reasons the new components were bought in the first place.
What is required, and what SID delivers, is a rich vocabulary and grammar that is tailored for the Next Generation OSS – not the last generation OSS!
19 August 2008
SOA and SID
It is not too strong a statement to say that without SOA (or EAI) the SID is little better than an academic exercise. I have spent too many years at Telcos all over the world producing detailed Enterprise Data Models only to see the results filed and forgotten as soon as the project was over. But now that SOA and EAI are well defined and feasible to implement, an Enterprise Data Model, such as SID, becomes much more than a pretty diagram for the CIO to hang on his wall.
In this blog I am going to briefly look at SOA and SID.
A vital ingredient of a successful SOA is a loosely coupled architecture – one in which each component (system) is completely unaware of the inner workings of the other system, and only aware of the services the other systems support (and require) and the information provided or necessary to get the service to work.
A service offered by a component will (unless there is strong architectural governance) offer that service using the data structures and concepts native to that component. Anyone using that service will have to know and understand these structures and concepts – and immediately the goal of a loosely coupled architecture is lost.
For example a service may state that it provides details of the customer’s subscription when provided with the customer account number. But to understand the information provided the service requestor must be aware of the way the service provider defines ‘subscription’ and the definition of each of the products and services listed under that subscription. In other words to use this service you have to adopt its definition of the products or services or alternatively translate that definition into your own definition (which in turn requires knowledge of the service provider’s definitions). Neither approach will result in a ‘loosely coupled’ architecture.
Once this constraint is realised then the Enterprise Architect needs to find a common definition of these business concepts that expresses all the concepts in the enterprise in a complete, unambiguous, agreed and system independent manner – precisely what SID does.
So the SID becomes the language of the SOA providing a vocabulary, grammar and syntax to used by services to provide or receive information. Each service provider is responsible for translating its information into the SID syntax and each service receiver is responsible for translating from SID to its own private syntax. When this is done each service is completely independent of every other one and can be replaced or upgraded without impacting any of the other systems in the enterprise.
Of course it could be that a system decides to adopt SID as its internal syntax, thus saving on the effort of translation – but this is not a requirement of SOA and the use of SID – it is unrealistic to expect Commercial Off the Shelf Technology to adopt SID internally, firstly because some applications within the OSS are not exclusive to Telecoms (e.g. CRM, Finance etc) and secondly the structures within the system will have been tuned to provide the performance and throughput necessary for something like a Billing system.
However one component could have particular benefit of adopting SID as its internal syntax and data model is the Enterprise Data Warehouse as this could significantly reduce ETL effort as all the information providers in the SOA would be providing their information in SID syntax.
In this blog I am going to briefly look at SOA and SID.
A vital ingredient of a successful SOA is a loosely coupled architecture – one in which each component (system) is completely unaware of the inner workings of the other system, and only aware of the services the other systems support (and require) and the information provided or necessary to get the service to work.
A service offered by a component will (unless there is strong architectural governance) offer that service using the data structures and concepts native to that component. Anyone using that service will have to know and understand these structures and concepts – and immediately the goal of a loosely coupled architecture is lost.
For example a service may state that it provides details of the customer’s subscription when provided with the customer account number. But to understand the information provided the service requestor must be aware of the way the service provider defines ‘subscription’ and the definition of each of the products and services listed under that subscription. In other words to use this service you have to adopt its definition of the products or services or alternatively translate that definition into your own definition (which in turn requires knowledge of the service provider’s definitions). Neither approach will result in a ‘loosely coupled’ architecture.
Once this constraint is realised then the Enterprise Architect needs to find a common definition of these business concepts that expresses all the concepts in the enterprise in a complete, unambiguous, agreed and system independent manner – precisely what SID does.
So the SID becomes the language of the SOA providing a vocabulary, grammar and syntax to used by services to provide or receive information. Each service provider is responsible for translating its information into the SID syntax and each service receiver is responsible for translating from SID to its own private syntax. When this is done each service is completely independent of every other one and can be replaced or upgraded without impacting any of the other systems in the enterprise.
Of course it could be that a system decides to adopt SID as its internal syntax, thus saving on the effort of translation – but this is not a requirement of SOA and the use of SID – it is unrealistic to expect Commercial Off the Shelf Technology to adopt SID internally, firstly because some applications within the OSS are not exclusive to Telecoms (e.g. CRM, Finance etc) and secondly the structures within the system will have been tuned to provide the performance and throughput necessary for something like a Billing system.
However one component could have particular benefit of adopting SID as its internal syntax and data model is the Enterprise Data Warehouse as this could significantly reduce ETL effort as all the information providers in the SOA would be providing their information in SID syntax.
14 August 2008
Specification and Instance - an example
One of the readers of this blog got in touch with me and asked me to give him advice on how to represent MSISDN’s and IMEIs with the SID.
To paraphrase his question:
The data model I am working on is related to the Customer MSISDN and IMEI.
You have stated that those are Logical Resources, is it still true when they no longer are in the available company inventory but belong to a customer?
If so, what are the appropriate SID entities I should use to specify the MSISDN, IMEI and where should I put the IDs (i.e. the phone number or IMEI number) and titles (i.e. the names “MSISDN” and “IMEI” ?
My answer to him was as follows:
MSISDN and IMEI are examples of Logical Resource Specifications. All GSM mobile phone numbers conform to the specification "MSISDN" in terms of the number layout and length (see Wikipedia's definition of MSISDN) . There is also a specification for IMEI that defines (specifies) its layout and length (see Wikipedia's definition of IMEI)
A particular MSISDN e.g. "447767811033" is an instance of the MSISDN Logical Resource Specification and is a Logical Resource.
Individual MSISDNs and IMEIs are always Logical Resources - they are still of interest to the Telco when they are no longer the Telco's 'assets' because they have been sold to a customer and have been linked to the “subscription” through the Installed Resource concept.
However if the customer churns (leaves the Telco) and "ports out" the MSISDN then while the IMEI and MSISDN remain logical resources, they are no longer of interest to the Telco and the information on the particular instances of the MSISDN and IMEI can be removed from the Telco's OSS databases.
For example: the Logical Resource 447767811033 which is an instance of the Logical Resource specification "MSISDN" currently belongs to me (it used to belong to Vodafone) and is an Installed Logical Resource in my subscription to O2's Offering "O2 Bill Monthly, 30 minutes free".
So far as Vodafone is concerned the MSISDN is outside their scope of interest and almost certainly no longer can be found anywhere in Vodafone's databases except perhaps in their data warehouse, or as the "B number" on a CDR, because I churned from Vodafone many years ago and took my number with me.
That particular MSISDN is now of interest to O2 (my current mobile telecoms service provider) and will appear in its OSS's databases as a Logical Resource.
Don't get too hung up on the word "Resource" and its English language meaning - it just means an thing or object in the context of the SID (or more precisely exactly what SID defines it to mean). I have often said that I would almost prefer that every concept in the SID had meaningless names like 'XYZQPV' or 'BZHPKD' so that no one would imply a meaning to the concept because of its name (but the concepts would be difficult to remember!)
So finally, here is how I think you should represent MSISDN and IMEI...
To paraphrase his question:
The data model I am working on is related to the Customer MSISDN and IMEI.
You have stated that those are Logical Resources, is it still true when they no longer are in the available company inventory but belong to a customer?
If so, what are the appropriate SID entities I should use to specify the MSISDN, IMEI and where should I put the IDs (i.e. the phone number or IMEI number) and titles (i.e. the names “MSISDN” and “IMEI” ?
My answer to him was as follows:
MSISDN and IMEI are examples of Logical Resource Specifications. All GSM mobile phone numbers conform to the specification "MSISDN" in terms of the number layout and length (see Wikipedia's definition of MSISDN) . There is also a specification for IMEI that defines (specifies) its layout and length (see Wikipedia's definition of IMEI)
A particular MSISDN e.g. "447767811033" is an instance of the MSISDN Logical Resource Specification and is a Logical Resource.
Individual MSISDNs and IMEIs are always Logical Resources - they are still of interest to the Telco when they are no longer the Telco's 'assets' because they have been sold to a customer and have been linked to the “subscription” through the Installed Resource concept.
However if the customer churns (leaves the Telco) and "ports out" the MSISDN then while the IMEI and MSISDN remain logical resources, they are no longer of interest to the Telco and the information on the particular instances of the MSISDN and IMEI can be removed from the Telco's OSS databases.
For example: the Logical Resource 447767811033 which is an instance of the Logical Resource specification "MSISDN" currently belongs to me (it used to belong to Vodafone) and is an Installed Logical Resource in my subscription to O2's Offering "O2 Bill Monthly, 30 minutes free".
So far as Vodafone is concerned the MSISDN is outside their scope of interest and almost certainly no longer can be found anywhere in Vodafone's databases except perhaps in their data warehouse, or as the "B number" on a CDR, because I churned from Vodafone many years ago and took my number with me.
That particular MSISDN is now of interest to O2 (my current mobile telecoms service provider) and will appear in its OSS's databases as a Logical Resource.
Don't get too hung up on the word "Resource" and its English language meaning - it just means an thing or object in the context of the SID (or more precisely exactly what SID defines it to mean). I have often said that I would almost prefer that every concept in the SID had meaningless names like 'XYZQPV' or 'BZHPKD' so that no one would imply a meaning to the concept because of its name (but the concepts would be difficult to remember!)
So finally, here is how I think you should represent MSISDN and IMEI...
- "MSISDN" should be the LogicalResourceSpecAtomic's ID
- "IMEI" should be another LogicalResouceSpecAtomic's ID
- "447767811033" should be stored in the ID of a LogicalDevice which is related to the LogicalResourceSpecAtomic whose LogicalResourceSpecAtomic's ID = "MSISDN"
- "0776 781 1033" could be stored in that LogicalDevice's FriendlyName
21 June 2008
Advanced SID: Logical and Physical Resources
The SID, like many other ways of modelling a Telecoms enterprise or any form of ICT distinguishes between a Logical and a Physical Resource. Anyone in IT thinks that they know what that means… We all know about ‘virtual devices’, virtual memory, virtual machines, and virtual private networks…
So if a Physical Resource is a handset or a switch, then a logical resource is, well, something like a VPN!
Well, “Yes and No” – certainly the concept of Logical Resource could cover the idea of VPN. But there are other things, more useful things to the Telecoms industry that Virtual Resource can cover.
We know that a physical resource has a physical location, has dimensions like weight, height, colour, and even things like smell, and taste (though mobile phones don’t smell or taste of much). These resources, or assets, have a value, are sold and supported by a party and have to be managed in an inventory.
I know some of you are ready with the next answer…
A Logical Resource is something conceptual that has no physical representation, but still is a resource that has to be tracked. Things like MSISDN, IMSI, IMEI and PUKs are all Logical Resources and the SID certainly means those to be included within the definition of Logical Resources.
Yes, that is very true and these things are very important forms of Logical Resources, but still there are others, and to appreciate the full beauty and extensibility of the SID we must look further.
I want to digress for a moment before I expand on the meaning of Logical Resource and what it covers.
Many years ago, I came across the “Duck Test”. It is a simple rule that states something along the lines of
One problem we’ve got as data modellers is that if we come from a physical data modelling background as opposed to an logical data modelling (oh, there’s that word again) then we are always looking for things that make one thing different from another. With the SID, and Enterprise Modelling in general we should always be looking for things that make them similar – or identical to other things – the broad rather than the narrow view, and I find the “Duck Test” very useful in this area.
So what else is like a logical resource? – That looks like a logical resource, walks like a logical resource and quacks like a logical resource?
Come on, I gave a big clue just now when talking about physical and LOGICAL database designs…
What about software? It can’t be measured, weighed, it has no colour, smell or taste, but it still exits. It fulfils the criteria of being a logical resource. We certainly keep inventories of our software, it has a value and has to be purchased and maintained. It can be installed into other Resources (Logical and Physical) and can even have a physical location – my copy of Microsoft Word is installed on my p.c. that is at the moment on a train in France (but that is another story).
Software is a Logical Resource.
So what?
Well there are two really useful things we can do with this idea.
Firstly it starts to help us understand RFSs. After all what does software do, but provide services?
And secondly how is software made? How is it written and designed, and how is that represented in the SID? Something for you to think about!
So if a Physical Resource is a handset or a switch, then a logical resource is, well, something like a VPN!
Well, “Yes and No” – certainly the concept of Logical Resource could cover the idea of VPN. But there are other things, more useful things to the Telecoms industry that Virtual Resource can cover.
We know that a physical resource has a physical location, has dimensions like weight, height, colour, and even things like smell, and taste (though mobile phones don’t smell or taste of much). These resources, or assets, have a value, are sold and supported by a party and have to be managed in an inventory.
I know some of you are ready with the next answer…
A Logical Resource is something conceptual that has no physical representation, but still is a resource that has to be tracked. Things like MSISDN, IMSI, IMEI and PUKs are all Logical Resources and the SID certainly means those to be included within the definition of Logical Resources.
Yes, that is very true and these things are very important forms of Logical Resources, but still there are others, and to appreciate the full beauty and extensibility of the SID we must look further.
I want to digress for a moment before I expand on the meaning of Logical Resource and what it covers.
Many years ago, I came across the “Duck Test”. It is a simple rule that states something along the lines of
“If it looks like a duck,
walks like a duck and
quacks like a duck….
Then it is a duck”
walks like a duck and
quacks like a duck….
Then it is a duck”
One problem we’ve got as data modellers is that if we come from a physical data modelling background as opposed to an logical data modelling (oh, there’s that word again) then we are always looking for things that make one thing different from another. With the SID, and Enterprise Modelling in general we should always be looking for things that make them similar – or identical to other things – the broad rather than the narrow view, and I find the “Duck Test” very useful in this area.
So what else is like a logical resource? – That looks like a logical resource, walks like a logical resource and quacks like a logical resource?
Come on, I gave a big clue just now when talking about physical and LOGICAL database designs…
What about software? It can’t be measured, weighed, it has no colour, smell or taste, but it still exits. It fulfils the criteria of being a logical resource. We certainly keep inventories of our software, it has a value and has to be purchased and maintained. It can be installed into other Resources (Logical and Physical) and can even have a physical location – my copy of Microsoft Word is installed on my p.c. that is at the moment on a train in France (but that is another story).
Software is a Logical Resource.
So what?
Well there are two really useful things we can do with this idea.
Firstly it starts to help us understand RFSs. After all what does software do, but provide services?
And secondly how is software made? How is it written and designed, and how is that represented in the SID? Something for you to think about!
Subscribe to:
Posts (Atom)
