TM Forum Community

Expand all | Collapse all

B/OSS migration

  • 1.  B/OSS migration

    TM Forum Member
    Posted Dec 19, 2018 08:50
    Dear Community,
    I'm involved in a B/OSS migration project as End to End Solution Architect and I need some guidelines and "smart ideas" :) to achieve this mission.
    WHat do you think of this steps ?
    -  Identify the business processes and applications .
    -  Collect Requirements from different  System Users.
    -  Define  Target Business Architecture  based  on scope/requirements
    -  Define Roadmap to reach Business Architecture.
    -  Define an Implementation strategy
    Best regards

    Issam BOUDANE
    NHB MS
    DT Asia

  • 2.  RE: B/OSS migration

    TM Forum Member
    Posted Dec 21, 2018 02:11
    A lot depends on the scope and scale of the migration project.

    The longer the current solution has been it place, the harder it will be to discover all the components.  You'll probably find one or two key systems after implementation begins.  Such as a cron process, reliability working behind the scenes, doing something important, and literally forgotten by the staff.  Usually it's running on a PC under someones desk.

    Like the complex root systems of an old growth forest, B/OSS can be a complex root system for the business and it's operation.  Moving a forest, one tree at a time, involves untangling the roots.  Sometimes it might just take the slash and burn approach, replanting as you go.  No matter what approach is taken, it will probably take longer than planned and will require more effort than expected for the new root system to develop.

    Feathers will be ruffled, some users will not like the change.  It's human nature and you're not going to be able to keep everyone happy.  But you MUST involve ALL of the stakeholders.  Find yourself a champion, someone to promote the new B/OSS solution.  Check out Scaling Up Excellence: Getting to More Without Settling for Less, there are some smart ideas for handling disruptive change to a businesses processes.

    In summary, here are some things to consider:
    • You will miss some business processes, applications, and requirements
    • It will take longer than expected
    • Technology is only part of an end-to-end solution, don't forget there are people involved

    Brian LaVallee
    INVITE Communications Co. Ltd

    DT Asia

  • 3.  RE: B/OSS migration

    TM Forum Member
    Posted Dec 21, 2018 09:44
    Thank @Brian LaVallee for you response and valuable advises and recommendations.
    Indeed, I have identified some area where risks can be high :
    missing(and misunderstanding of )  key requirements ,
    resistance to change,
    Quality of Data,
    Incomplete Baseline architecture,
    and probably many others risks  I can't see now :).
    Best regards

    Issam BOUDANE
    NHB Management Services SARL

    DT Asia

  • 4.  RE: B/OSS migration

    TM Forum Member
    Posted Dec 24, 2018 02:20
    Hi Issam,
    What is you focus:
    • to get the solution up an running according to functional spec., or
    • or securing a defined business impact - business capabilities.

    If you focus is the former, go the traditional way. This tend to, from implementation view, commence with (Business) processes to satisfy functionality. Functionality are usually defined by staff who are doing a job today and supportive activities. Remember that, most likely going to be replaced tomorrow ->robotics.

    if it is the latter, commencing with (business)processes to satisfy functionality has a high probability to re-invent what you already have, just changing technology.
    I would recommend:

    1.  identify and get business capability targets documented
    2. Document the BUSINESS RULES (not traditionally operational process (business) rules
    3. Design processes with an horizontal and cross departmental and systems view 
    4. Identify re-usability on data model level (SID) to enable process re-usability - major cost saver
    5. If not already trapped, OPEN APIs (rest), paramount for ecosystem play.
    My penny worth.

    Cato Rasmussen

    DT Asia

  • 5.  RE: B/OSS migration

    TM Forum Member
    Posted Dec 26, 2018 04:27
    Hi Issam,

    You must schedule and define Data Migration strategy. It's the biggest technical challenge involved in transformation projects.
    - Analysis
    - Data Transformation
    - Migration

    At the step 3 (Define Target Business Architecture based on scope/requirements), you must align and design to easily convergent with future transformation scopes (eg., cloud native arch).

    Raman Kumar
    Whale Cloud Technology Co., Ltd

    DT Asia

  • 6.  RE: B/OSS migration

    TM Forum Member
    Posted Jan 02, 2019 02:05
    Hi Issam,

    I've seen quite a few interesting responses to your question and I agree to most of the opinions.
    Having handled quite a few E2E BSS migrations (or say transformations), I would love to add a few more steps:

    1. Understand the need for transformation before you plan out the end-to-end architecture - 
    The operator/customer already knows (in most cases) the pain-points with their existing systems. Some may have a lot of issues with turn-around-times; others may have problems related to process efficiency or TTM (time-to-market) or some want an upgrade just because their competitors are upgrading and the stakeholders are getting anxious.
    As a vendor, you need to hit the sweet spot by tackling their most important problem. E.g. If the issue is time-to-market, you need to ensure efficiencies in all your business process designs. 
    Almost all operators/customers are skeptical at the start of a transformation - this exercise will actually make them believe that they are on the right track.

    2. Understand the vision of the customer - 
    Whenever an operator undergoes a transformation, there is always a vision attached to it. Unfortunately, these visions just get featured in public articles and stay among the top management and serve as a confidence builder for key stakeholders. There are cases where the operator's IT team is itself unaware of why they are undergoing such a huge change. 
    Quite evidently, there will be cases where the IT team themselves get distracted from their vision. 
    Citing a very recent example for an operator where their major pain-point was revenue-assurance and reconciliation. The IT team still kept on sharing requirements with no mention of ways to reconcile revenue. As a trusted vendor, it should be us who should bring them back on track keeping their core mission in mind.

    Also, as correctly pointed out by Raman, data migration strategy should be dealt a bit earlier in the project phase than it normally is. Data migration issues are the most common reasons for delay in any complex project. With the invent of stronger EU GDPR rules (or similar ones in other parts of the world), there should an elaborate strategy for data migration which must include security implementation, data transfer techniques, data retention scheme and data privacy policies.

    Keep yourself updated with the latest policies like ASC 606, IFSC 15, etc (these are just examples of recent updates in revenue reconciliation in the US) and its implication on your transformation. Even if it might entail additional cost and time, it might be worthwhile to bring these topics during any phase of the project.

    Let me know if you want to know more about this topic.


    Shashank Singh
    Cerillion Technologies Limited

    DT Asia

  • 7.  RE: B/OSS migration

    TM Forum Member
    Posted Jan 03, 2019 03:06
    Dear all,
    Thank you for your contributions and valuables inputs .
    Indeed  (DATA) Migration Strategy is a key point in this kind of Endeavor.  There should be also a focus on requirements , scope and vision in order to define a good strategy for migration.
    Thank you all   for your  valuable contributions.

    Issam BOUDANE
    NHB MS

    DT Asia

  • 8.  RE: B/OSS migration

    TM Forum Member
    Posted Jan 03, 2019 05:36
    While it would definitely and theoritically be possible to migrate from one BSS system to another, however key questions to be answered:
    a)How long
    b)At what cost
    c)Extent of customization to be allowed at target side to mimic source systems (process and data)

    If we try to fit every data and process elements, exception scenario of source to target BSS, it will be a gigantic effort and also will limit the target BSS's capability.

    My 2 cents will be to engage Business team to simplify Target state business process, look for optimum migration need and handle exceptions as business process rather than technical solution if possible (you probably don't want to create a mini-bss on your migration platform just to handle all exception scenario).

    Chinmohan Biswas
    IBM Corporation

    DT Asia

  • 9.  RE: B/OSS migration

    Posted Jan 08, 2019 04:10
    The steps you listed are very important to deliver an acceptable solution architecture for your project. I will however want to add that it is important to pay very close attention to the reason why the enterprise is embarking on this project, understanding this help in shaping your design approach and methodology.

    Because it is an E2E Solution Architecture project which will involve many touch points in the Enterprise, you will need to device a strategy to manage all your stakeholders (technical and non-technical) in order to secure their cooperation and buy-in this will bring them on the same page with you hence simplifying your architecting process.

    This project sound like a big one which could bring about some disruption in some business process, you should therefore be ready for some push back and plan your change management around the expected resistance you may face in the course of your design.

    I wish you all the best.

    Olusegun Sanyaolu
    B/OSS Planning and Design Manager
    Airtel Africa

    DT Asia