TM Forum Community

In a TELCO, we have to migrate  several inventories  (more than 8 OSS sources) to 2 OSS destinations (internal and external plant inventories). They support the fulfilment and assurance processes of the company (fixed services).
At the same time we have to migrate the BSS, and we'll have a coliving period (old BSS uses the old inventories systems, new BSS  uses the new inventories). The BSS migration strategy must be supported  by the inventory migration strategy.
In your experience, i would like to know:
- difficulties to migrate the inventories
- strategies to migrate inventories and manage coliving
- any recommendation considering the scenery.

If you can share your experiences, I will be grateful.
Thanks

------------------------------
Cecilia
Telefonica
------------------------------

​One design pattern that you can consider for system migration where new and old system must run is parallel is to introduce a new, temporary, switch or 'shim' function. -
 Let O be the old inventory system, N be the new system and C be any system which makes system calls API to the inventory.
 Now create a new, temporary switch or 'shim' layer called S. Design S such that it has a policy for handling calls from C which can be one of three possibilities: O only, N only or both O and N. Start with a policy of all O, then run just a few calls to both O and N; test N behaves as expected. Gradually increase the use of N until you are confident then set policy to N only.
Your application will determine how much synchronization is needed between data in O and N to satisfy all possible API requests on either system.

------------------------------
Paul Jordan
The views expressed here are not necessarily those of my employer
------------------------------

​Paul thanks for rapid and clear response.

Paul's response is a specific application of a more general set of principles of moving to 'platforms' exposed by open APIs to allow for legacy migration.
One of Paul's colleagues - George Glass  gave a couple of interesting similar worked examples in his platform presentation at AW Week Vancouver Sept 2016. The material were publicly available at Agenda | TM Forum Action Week attached as difficult to locate the originals.
One Manage Product Availability shows the migration strategy that Paul explained but using open APIs
We do have a Inventory APIs in the TMF Forum with updates coming for R17 coming in July 2017 which could be used as the Shim for inventory as describe by Paul . 

As a member you can get an early view if you join/register  the API Collaboration team at
Current Projects - TM Forum 
then you will be able to view the inventory APIs that your could use at:
Resource Inventory API


------------------------------
Dave Milham
TM Forum Chief Architect ZOOM SP engagement
------------------------------

Original Message:
Sent: 06-19-2017 02:53
From: Paul Jordan
Subject: Inventories and BSS Migration Strategy

​One design pattern that you can consider for system migration where new and old system must run is parallel is to introduce a new, temporary, switch or 'shim' function. -
 Let O be the old inventory system, N be the new system and C be any system which makes system calls API to the inventory.
 Now create a new, temporary switch or 'shim' layer called S. Design S such that it has a policy for handling calls from C which can be one of three possibilities: O only, N only or both O and N. Start with a policy of all O, then run just a few calls to both O and N; test N behaves as expected. Gradually increase the use of N until you are confident then set policy to N only.
Your application will determine how much synchronization is needed between data in O and N to satisfy all possible API requests on either system.

------------------------------
Paul Jordan
The views expressed here are not necessarily those of my employer
------------------------------

------Original Message------

In a TELCO, we have to migrate  several inventories  (more than 8 OSS sources) to 2 OSS destinations (internal and external plant inventories). They support the fulfilment and assurance processes of the company (fixed services).
At the same time we have to migrate the BSS, and we'll have a coliving period (old BSS uses the old inventories systems, new BSS  uses the new inventories). The BSS migration strategy must be supported  by the inventory migration strategy.
In your experience, i would like to know:
- difficulties to migrate the inventories
- strategies to migrate inventories and manage coliving
- any recommendation considering the scenery.

If you can share your experiences, I will be grateful.
Thanks

------------------------------
Cecilia
Telefonica
------------------------------

Hi Cecilia,

I worked on a quite similar situation a few years ago for a Tier One operator in France. The context was :
- Build of a new BSS system, in replacement of a legacy mainframe. Both cohabitated several years until all customer were migrated.
- Replacement of legacy OSS inventory, which was closely coupled to the legacy BSS.

Here is the strategy whe had recommanded and applied :
1) Base principles :
     - No impact on legacy BSS/OSS stack
     - Progressive switch between the old inventories and the new ones
2) Implentation of a routing mechanism on the new BSS, for each kind of resource
     - Routing on resource allocation, based on the kind of offer, to handle a progressive switch to the new inventory
     - Routing on resource modification, based on the location of the primary allocated resource
3) Implementation of a three step migration between old and new inventories
    - Step 1 : the old inventory remains the master. The new inventory automatically pulls its resources modification to the old one through either real time flows where available, either night batch flows.
    - Step 2 : the new inventory becomes the master, when most of the resources are managed through it. All flows from the new BSS have been routed to the new inventory. We accepted a batch synchronisation flow from the new inventory to the old one, since the volume of modification on the old one had become quite small. 
   - Step 3 : after the complete migration of customers to the new BSS system, the old inventories can be decommissioned.

In addition, a partitioning of resources has been set up between the old and  new inventories, where possible, to avoid inconsistency (for example : MSISDN range, SIM cards stocks).

Please let me know if you need further details.

Regards,

Matthieu Lemoine
Sopra Steria

------------------------------
Matthieu LEMOINE
Senior Enterprise Architect
Sopra Steria - Telecom, Media & Entertainment
------------------------------

Thanks for your answers! They are very useful for me.

------------------------------
Cecilia Galindo
Telefonica Moviles SA
------------------------------

Hi Cecilia,

In addition to Matthieu Lemoine post, I will just comment that the same migration strategy was also used to migrate the whole customer base (more than 20 millions) from the old Intelligent Networks (IN) systems to the new ones, from a different supplier (it was not only a version upgrade project).

This strategy was possible thanks to a real time routing system at network level to define where the resources of the customers where managed, in the old stack or the new one. The migration operations lasted about 18 months and the whole project, with initialization and post migration cleaning phases, about 24 months.

I hope it is useful for you.

Regards,


------------------------------
Herve Souvignet
Managing Director
Sopra Steria Consulting TME
------------------------------

Original Message:
Sent: 06-22-2017 00:13
From: Cecilia Galindo
Subject: Inventories and BSS Migration Strategy

Thanks for your answers! They are very useful for me.

------------------------------
Cecilia Galindo
Telefonica Moviles SA
------------------------------

Hi Cecilia, 

Due complexity of legacies architecture, specially in a scenary involving customers with "fixed inside/outside plant access infraestructure" - a non ubiquity access enviroment,  some keys towards the transformation success:

1. To Guarantee  "zero impact" in your AS-IS customer services provisioning eviroment - Legacy. Special care in their roadmap.
2. Coliving architecture. It's to guarantee convergence with TO-BE scenary in order to switch-off your legacies.
3. Coliving strategy. Armonization & convergence in all your operational procedures.
4. Migration strategy. Necessary internal consensus to define the best option: based on network topology, based on services, etc.
5. TO-BE inventories migration rules. To guarantee "Traceability" is mandatory to define all procedures and mecanisms related with: data conciliation, correlation, update and rollback activities.
6. Strategy to manage in a convergence way the new network operational  & customer support procedures.

Hope this info helps you.
Regards.






------------------------------
Victor BERNALES
NGOSS Systems Manager
Indra Sistemas
------------------------------

Original Message:
Sent: 06-22-2017 00:13
From: Cecilia Galindo
Subject: Inventories and BSS Migration Strategy

Thanks for your answers! They are very useful for me.

------------------------------
Cecilia Galindo
Telefonica Moviles SA
------------------------------

​Hi to all,

the topic is very interesting.
Are there international/official guidelines or principles for migration strategy to be shared ?

Thanks in advance
Stefano

------------------------------
Stefano Gufi
Accenture
------------------------------

Original Message:
Sent: 06-23-2017 04:06
From: Victor BERNALES
Subject: Inventories and BSS Migration Strategy

Hi Cecilia,

Due complexity of legacies architecture, specially in a scenary involving customers with "fixed inside/outside plant access infraestructure" - a non ubiquity access enviroment,  some keys towards the transformation success:

1. To Guarantee  "zero impact" in your AS-IS customer services provisioning eviroment - Legacy. Special care in their roadmap.
2. Coliving architecture. It's to guarantee convergence with TO-BE scenary in order to switch-off your legacies.
3. Coliving strategy. Armonization & convergence in all your operational procedures.
4. Migration strategy. Necessary internal consensus to define the best option: based on network topology, based on services, etc.
5. TO-BE inventories migration rules. To guarantee "Traceability" is mandatory to define all procedures and mecanisms related with: data conciliation, correlation, update and rollback activities.
6. Strategy to manage in a convergence way the new network operational  & customer support procedures.

Hope this info helps you.
Regards.






------------------------------
Victor BERNALES
NGOSS Systems Manager
Indra Sistemas
------------------------------


Original Message:
Sent: 06-22-2017 00:13
From: Cecilia Galindo
Subject: Inventories and BSS Migration Strategy

Thanks for your answers! They are very useful for me.

------------------------------
Cecilia Galindo
Telefonica Moviles SA
------------------------------

Cecilia,
Would love to discuss this topic f2f.
In one of my 3 steps I am approach I am discussing an option to encapsulate the legacy.

CASE STUDY: Achieving an End-to-End Digital OSS/BSS Chain

• How to become and remain a B2B digital Telco champion (+900K€ revenue per FTE, +45 NPS)
• Delivering a superior customer experience by implementing cutting-edge industry cloud software from Vlocity and Salesforce
• Reinvent your BSS/OSS digital ecosystem in 3 steps
  • Step 1: Business market ecosystem
  • Step 2: Embracement and encapsulation of legacy
  • Step 3: A culture of Agile entrepreneurs

------------------------------
Steven Klockaerts
Telfort
------------------------------