As promised this is the second part of the Extending the SID.
Actually it might be better entitled "Implementing the SID".
I've noticed that deploying the SID in any organisation is a lot more complicated than many people assume. There seems to be a general belief that the SID can be deployed straight "out of the box" and that any problems encountered must be because of the deploying organisation and its legacy.
I don't think this is the case. I believe that there has to be some sort of deployment project when SID is implemented in any organisation. I am working on a SID deployment methodology which covers a range of topics including
a) tailoring the SID for business alignment
b) mapping the product catalogue
c) identification the domain to deploy first
d) education
This methodology is mainly in my mind rather than on paper and probably could do with some workshop discussion with one or more organisations in the process of deploying SID.
Any takers?
17 August 2009
23 July 2009
Extending SID - Part 1
Over the last six months I've given SID training and consultancy in a number of different countries and the one question I keep being asked is "How do I add stuff to the SID?".
Given SID's size, complexity and provenance it is not surprising that people are nervous about fiddling with it, but it is a "work in progress", so it is inevitable that extensions will be required. Having said that I would always challenge the assumption that the SID needs to be changed - more on that later; after I've explained how to make changes I will discuss why these changes may not be necessary.
I've identified a simple set of modelling rules that should keep you out of trouble when you modify SID as the changes you make if you uses these rules should be the same as the rules used by the SID developers themselves, so that when you get the new release which covers the extensions you made you should find the structures are the same, even if the names are (hopefully) slightly different.
As you get to know SID you will start to recognise a number of "patterns" or conventions repeated throughout its structure. All these rules do is list these patterns and explain how to use them.
Rule 1: Specification and instance
Everywhere in SID you see the word "Specification" - I discussed this in a previous blog. When you extend the SID to cover a new concept then you must consider if it could be implemented as a Specification/Instance pair. The Specification describes the properties that apply to all instances of the "thing" and defines their "type" while the Instance defines the life of a particular "thing". I must admit I find it hard to think of an example that is (a) not already in the SID and (b) not trivial...
Rule 2: Role
The recent versions of the SID have extended the use of the Role concept from Party Role (see my previous blog on this) where it uses a Role to separate the objective (real-world) Party from the subjective view of the Party such as Customer. Now SID has extended this approach to include, for example the roles played by Customer Accounts and Resources in a Product (subscription) through the ProductInvolvementRole concept.
This is a highly generic and very powerful approach that if used properly can make the SID very powerful. I must admit that I didn't use this approach when I first started using the SID and modelled explicitly the specific role played by a Resource, Account and Resource in a Product - while this made the model easier to understand through "concrete" instances it could make it less flexible in the future when new roles for accounts, parties and resources are developed as technology and the business evolves. So when modelling in a new area, such as in the Supplier/Partner Domain you will inevitably come up with the concrete roles played by your suppliers and partners. Having done that you must then think if these concrete roles could be made more generic through a role structure.
Rule 3: Composite/Atomic
Not so much an intellectual technique, more of a modelling convention. Recursive relationships/associations are fairly common both in Telecoms in general and in the SID in particular. In some places the SID has a simple "Pigs Ear" relationship from an entity back to itself to show a hierarchy, but elsewhere it subtypes a concept, such as ProductSpecification into AtomicProductSpecification and CompositeProductSpecification and then had the association from the Composite back to the parent giving the hierarchy. This looks a bit weird, and could be considered to be an idiosyncrasy of the SID, but it is widely used (and it does at least allow you to explicitly identify the "leaf" nodes in a hierarchy) and to maintain consistency with the SID you should adopt this approach.
Rule 4: Attributes vs Characteristics
All the above rules cover adding new concepts or entities to the SID. However quite often all that is required is an extra attribute or two. Even here you must be cautious. The SID has a set of extensive, highly generic structures Characteristic and Characteristic value, for example ProductSpecCharacteristic /ProductSpecCharacteristicValue, ServiceSpecCharacteristic/ServiceSpecCharacteristicValue and ResourceSpecCharacteristic/ResourceSpecCharacteristic which can be used to add information about Products, Services and Resources without changing the model.
It is difficult to define a "hard and fast" rule that defines when these structures should be used instead of adding explicit attributes to the associated entities, but as a rule if the attribute is
(a) of significance to the business - i.e. everyone in the business wants to know the weight of a Resource (unlikely) then add it as an attribute, otherwise use a characteristic and
(b) applicable to each and every one of the instances of the Spec, i.e. every Resource has a weight (unlikely again) then add it as an attribute.
If the attribute is particular to a particular type of Product/Service/Resource then it should be a characteristic, if however it is required as a result of a particular business practice or law in your country, then it should (probably) be an attribute.
If you stick to these rules you should be able to ensure upward compatibility with the SID (providing they stick to them too ;-) ).
Now after giving you the rules/tools to change SID I must add the "health warning"...
Ask yourself "Why am I extending the SID?". If the answer is because the SID hasn't yet defined that domain (e.g. the Supplier/Partner Domain) then go ahead. If it is because the SID doesn't reflect the conventions and laws of my country, then go ahead too (have a look at how Australian addresses have been added to the SID), but if it is because "I can't find it in the SID" and "it" is a common business practice, then STOP! Do not extend the SID! It is probably because you don't understand how "it" has been implemented in SID - Ask an expert (like me) before making any changes.
I will discuss a bit more about tailoring the SID in the next blog...
Given SID's size, complexity and provenance it is not surprising that people are nervous about fiddling with it, but it is a "work in progress", so it is inevitable that extensions will be required. Having said that I would always challenge the assumption that the SID needs to be changed - more on that later; after I've explained how to make changes I will discuss why these changes may not be necessary.
I've identified a simple set of modelling rules that should keep you out of trouble when you modify SID as the changes you make if you uses these rules should be the same as the rules used by the SID developers themselves, so that when you get the new release which covers the extensions you made you should find the structures are the same, even if the names are (hopefully) slightly different.
As you get to know SID you will start to recognise a number of "patterns" or conventions repeated throughout its structure. All these rules do is list these patterns and explain how to use them.
Rule 1: Specification and instance
Everywhere in SID you see the word "Specification" - I discussed this in a previous blog. When you extend the SID to cover a new concept then you must consider if it could be implemented as a Specification/Instance pair. The Specification describes the properties that apply to all instances of the "thing" and defines their "type" while the Instance defines the life of a particular "thing". I must admit I find it hard to think of an example that is (a) not already in the SID and (b) not trivial...
Rule 2: Role
The recent versions of the SID have extended the use of the Role concept from Party Role (see my previous blog on this) where it uses a Role to separate the objective (real-world) Party from the subjective view of the Party such as Customer. Now SID has extended this approach to include, for example the roles played by Customer Accounts and Resources in a Product (subscription) through the ProductInvolvementRole concept.
This is a highly generic and very powerful approach that if used properly can make the SID very powerful. I must admit that I didn't use this approach when I first started using the SID and modelled explicitly the specific role played by a Resource, Account and Resource in a Product - while this made the model easier to understand through "concrete" instances it could make it less flexible in the future when new roles for accounts, parties and resources are developed as technology and the business evolves. So when modelling in a new area, such as in the Supplier/Partner Domain you will inevitably come up with the concrete roles played by your suppliers and partners. Having done that you must then think if these concrete roles could be made more generic through a role structure.
Rule 3: Composite/Atomic
Not so much an intellectual technique, more of a modelling convention. Recursive relationships/associations are fairly common both in Telecoms in general and in the SID in particular. In some places the SID has a simple "Pigs Ear" relationship from an entity back to itself to show a hierarchy, but elsewhere it subtypes a concept, such as ProductSpecification into AtomicProductSpecification and CompositeProductSpecification and then had the association from the Composite back to the parent giving the hierarchy. This looks a bit weird, and could be considered to be an idiosyncrasy of the SID, but it is widely used (and it does at least allow you to explicitly identify the "leaf" nodes in a hierarchy) and to maintain consistency with the SID you should adopt this approach.
Rule 4: Attributes vs Characteristics
All the above rules cover adding new concepts or entities to the SID. However quite often all that is required is an extra attribute or two. Even here you must be cautious. The SID has a set of extensive, highly generic structures Characteristic and Characteristic value, for example ProductSpecCharacteristic /ProductSpecCharacteristicValue, ServiceSpecCharacteristic/ServiceSpecCharacteristicValue and ResourceSpecCharacteristic/ResourceSpecCharacteristic which can be used to add information about Products, Services and Resources without changing the model.
It is difficult to define a "hard and fast" rule that defines when these structures should be used instead of adding explicit attributes to the associated entities, but as a rule if the attribute is
(a) of significance to the business - i.e. everyone in the business wants to know the weight of a Resource (unlikely) then add it as an attribute, otherwise use a characteristic and
(b) applicable to each and every one of the instances of the Spec, i.e. every Resource has a weight (unlikely again) then add it as an attribute.
If the attribute is particular to a particular type of Product/Service/Resource then it should be a characteristic, if however it is required as a result of a particular business practice or law in your country, then it should (probably) be an attribute.
If you stick to these rules you should be able to ensure upward compatibility with the SID (providing they stick to them too ;-) ).
Now after giving you the rules/tools to change SID I must add the "health warning"...
Ask yourself "Why am I extending the SID?". If the answer is because the SID hasn't yet defined that domain (e.g. the Supplier/Partner Domain) then go ahead. If it is because the SID doesn't reflect the conventions and laws of my country, then go ahead too (have a look at how Australian addresses have been added to the SID), but if it is because "I can't find it in the SID" and "it" is a common business practice, then STOP! Do not extend the SID! It is probably because you don't understand how "it" has been implemented in SID - Ask an expert (like me) before making any changes.
I will discuss a bit more about tailoring the SID in the next blog...
22 January 2009
SID Training
There are a series of training courses offered by the TM Forum (see http://www.tmforum.org/TrainingWebinars/TMForumTraining/5912/Home.html) that can lead to NGOSS "Knowledge Certification".
These courses are, I believe, excellent, and if combined with a visit to the TM Forum Management World conference can be highly rewarding and instructive experience.
However if you are looking for a 'lighter' and potentially cheaper alternative you may be interested in a 2 training course I am developing in which I introduce the major concepts within the SID and provide practical guidance on the use of the SID based on my real world experience.
This course is not based on the TM Forum courses and uses none of their material, nor will it lead to any sort of certification and is certainly not offered as an alternative to the TM Forum training. Rather I am trying to develop it into something that you might want all your architects to attend, and from their experience and what they learnt on the course you might then select a few to go forward for the full TM Forum training and certification.
This course is still a "work in progress" but if you are interested in more information on pricing and content then please do not hesitate to contact me (email: mcfadyen.andrew @ gmail.com).
These courses are, I believe, excellent, and if combined with a visit to the TM Forum Management World conference can be highly rewarding and instructive experience.
However if you are looking for a 'lighter' and potentially cheaper alternative you may be interested in a 2 training course I am developing in which I introduce the major concepts within the SID and provide practical guidance on the use of the SID based on my real world experience.
This course is not based on the TM Forum courses and uses none of their material, nor will it lead to any sort of certification and is certainly not offered as an alternative to the TM Forum training. Rather I am trying to develop it into something that you might want all your architects to attend, and from their experience and what they learnt on the course you might then select a few to go forward for the full TM Forum training and certification.
This course is still a "work in progress" but if you are interested in more information on pricing and content then please do not hesitate to contact me (email: mcfadyen.andrew @ gmail.com).
CFSs revisited
I see from the hits on my blog that most people find there way to it from Google where they have searched for “Customer Facing Service” (I am flattered and amazed to see that my blog is the first one returned by Google for that particular term”. I have also been asked for my list of CFSs... I am not sure that
a) I could give it out to you as it belongs to the organisation that I created it for
b) It would be particularly useful to you anyway...
However I would say a couple of things on this subject that may guide people struggling with the concept of CFS
1. The SID is a means to an end and not an end in itself. It is highly generic and can be used to solve almost any problem. As a result it is highly complex. It offers you the ability for example to endlessly nest CFSs and to build a complex hierarchy of products and product specifications and offerings. What you need to do is to focus on what you are trying to achieve with your CFS definition.
2. Each organisations list of CFSs is likely to some degree or another be unique to that organisation.
3. Keeping the first point in mind; In Proximus my colleague Eric Borremans and I were trying to simplify a complex mess of services and products that had evolved over the years. We decided to limit ourself to a single level of CFS rather than a hierarchy. We wanted something that
a) the customer (or end user) experiences and recognises
b) is complete and free-standing enough to be packaged up into an Product Offering alone without any other CFSs being necessary to support it.
c) is manageable through a single 'on/off switch' within the Network Management system.
For example we considered Voice Mail. Now when a customer uses Voice Mail he is able to perceive a range of services including deleting messages, listening to messages, recording greetings etc. This would indicate that there are several CFSs that make up the Voice Mail service. However it isn't useful to separate them.
One would never package up a Voice Mail Product Offering containing only the service to delete messages but not listening to them. We therefore decided that we would only have a single CFS service as Proximus had an "all or nothing" approach to Voice Mail and any enhanced services were bundled into the PABX offerings as Office Automation type services. So for Proximus Voice Mail was a single service.
On the other hand we had 2G access and 3G access as separate CFSs. This was despite the customer being potentially unaware which service he was using during a call. The reason for this was that it was mooted that the Telco might want to sell 2G only services to an MVNO and there were 2 "switches" in the network, one to switch on/off 2G and one to switch on/off 3G.
There is no “right” answer to CFS - but if you can define a set of criteria as we did for Proximus that does not contravene the spirit of the SID and NGOSS and makes logical sense for what you are trying to achieve in using SID then you can use these criteria as an “Occam's Razor” to sort out what is a Product Offering, what is a CFS and what is a RFS.
Simply put if a "candidate CFS" was found to be made up of or contains two or more CFSs then it, according to the rules we created in Proximus, is a Product Offering, if it isn't a Product Offering and fails one or more of the CFS criteria (listed above) it must be a RFS.
The list and the rules we created in Proximus reflected our desire to simplify Service Management and to an extent CRM. If our objective had been different then perhaps the CFS rules set and the resulting CFS list would have been different.
By the way the rules we developed allowed a long list of over 400 candidate services gathered from various departments throughout the organisation to be “boiled down” to only some 65 to 70 CFSs. This allowed would have allowed us to (in theory) to load the product definitions and CFSs into the CRM system to aid with problem reporting and ticket creation.
The lesson to be learnt about the SID is that “all things are possible” with it. You can create really complex Products, Product Offerings, CFSs and RFSs - which is fine, if that is really what you want to do. If however you don't need the complexity that SID offers then ignore it!
a) I could give it out to you as it belongs to the organisation that I created it for
b) It would be particularly useful to you anyway...
However I would say a couple of things on this subject that may guide people struggling with the concept of CFS
1. The SID is a means to an end and not an end in itself. It is highly generic and can be used to solve almost any problem. As a result it is highly complex. It offers you the ability for example to endlessly nest CFSs and to build a complex hierarchy of products and product specifications and offerings. What you need to do is to focus on what you are trying to achieve with your CFS definition.
2. Each organisations list of CFSs is likely to some degree or another be unique to that organisation.
3. Keeping the first point in mind; In Proximus my colleague Eric Borremans and I were trying to simplify a complex mess of services and products that had evolved over the years. We decided to limit ourself to a single level of CFS rather than a hierarchy. We wanted something that
a) the customer (or end user) experiences and recognises
b) is complete and free-standing enough to be packaged up into an Product Offering alone without any other CFSs being necessary to support it.
c) is manageable through a single 'on/off switch' within the Network Management system.
For example we considered Voice Mail. Now when a customer uses Voice Mail he is able to perceive a range of services including deleting messages, listening to messages, recording greetings etc. This would indicate that there are several CFSs that make up the Voice Mail service. However it isn't useful to separate them.
One would never package up a Voice Mail Product Offering containing only the service to delete messages but not listening to them. We therefore decided that we would only have a single CFS service as Proximus had an "all or nothing" approach to Voice Mail and any enhanced services were bundled into the PABX offerings as Office Automation type services. So for Proximus Voice Mail was a single service.
On the other hand we had 2G access and 3G access as separate CFSs. This was despite the customer being potentially unaware which service he was using during a call. The reason for this was that it was mooted that the Telco might want to sell 2G only services to an MVNO and there were 2 "switches" in the network, one to switch on/off 2G and one to switch on/off 3G.
There is no “right” answer to CFS - but if you can define a set of criteria as we did for Proximus that does not contravene the spirit of the SID and NGOSS and makes logical sense for what you are trying to achieve in using SID then you can use these criteria as an “Occam's Razor” to sort out what is a Product Offering, what is a CFS and what is a RFS.
Simply put if a "candidate CFS" was found to be made up of or contains two or more CFSs then it, according to the rules we created in Proximus, is a Product Offering, if it isn't a Product Offering and fails one or more of the CFS criteria (listed above) it must be a RFS.
The list and the rules we created in Proximus reflected our desire to simplify Service Management and to an extent CRM. If our objective had been different then perhaps the CFS rules set and the resulting CFS list would have been different.
By the way the rules we developed allowed a long list of over 400 candidate services gathered from various departments throughout the organisation to be “boiled down” to only some 65 to 70 CFSs. This allowed would have allowed us to (in theory) to load the product definitions and CFSs into the CRM system to aid with problem reporting and ticket creation.
The lesson to be learnt about the SID is that “all things are possible” with it. You can create really complex Products, Product Offerings, CFSs and RFSs - which is fine, if that is really what you want to do. If however you don't need the complexity that SID offers then ignore it!
15 October 2008
NGOSS-Applied
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.
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.
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!
Subscribe to:
Posts (Atom)
