Premise of Layering & De-layering in Telecom IT Architecture

Early Days

From the mid-80s to early to mid-90s when wireless/mobile & wired networks started to scale around the world and more and more service providers around the world started feeling the need to have a formal IT stack in some shape and form to be able to serve their customer needs at scale .

Most of the initial versions of these technology stacks more represented a black box which served all the functions something on the below lines .

Some of the earliest version of these tech stack/s suffered from the below issues :

• Tight Coupling
• No clear data ownership between various modules and sub-modules
• Manual processes leading to operational overheads

Due to the monolithic nature of the IT stack , the scalability of these systems were always questionable and due to which arose the need of a layered telecom IT architecture which eventually gave rise to modern day BSS, OSS systems .

Evolution

The key objectives of this layered IT architecture were some of the below :

1. Separation of concerns .
2. Clear process , function and data ownership.
3. Scalability and Extensibility

Over a period of time there were other industry forums and frameworks like TMF , MEF etc which further worked on standardizing this architecture which always comes in as a useful guidance .

Layering v/s De-layering

While the evolution of Telecom IT Architecture into a more layered and standardized view has definitely solved a lot of problems around scalability , extensibility , process, function and data ownership off late it seems like the overall ecosystem is going overboard with creating further functional layers.

There is absolutely no doubt that every time the intent of further layering an IT ecosystem comes with an agenda of simplicity , scalability and also it means newer selling and building opportunities for the vendors(system integrators and technology companies) but the key question here remains is it really serving any purpose for the service providers(CSPs/RSPs) themselves .

Below are few of the key examples I will quote to elaborate the thought .

1. A light weight CRM only providing basic native/OOTB functions around customer , lead and opportunity management , everything else around the overall sales ecosystem of CPQ , contract management , product catalog has to be either custom built or additional COTS solutions bought .
2. The separation of sales CRM and services CRM leading to multiple install base (product inventory) data stores , while multiple data stores for the same data is still OK as long as there is clear principle applied around master and slave but the problem starts happening when to address different functional flows organizations start using different data sources which means duplicate data sources and also additional overhead to always keep them in sync .
3. Service management platforms providing overlapping functionalities pertaining to a service inventory data store which will provide the data feed to cater to service and customer impact analysis from a service assurance standpoint .
4. Telecom order management platform natively having the provision to store install base(product inventory)

The above list can go on & on however it will be only wise to cover a few examples to elaborate the problem at hand .

Also the problem with layering doesn't end here , the quantum of the problem is multi-folded when applied to the CSP's IT ecosystem without much thought/s and considerations put around the below :

1. Solid Architecture Governance - Not backed by the fundamental notions of architecture standards , principles and decisions (needless to the say the extincting breed of industry architects and the value they provide versus the continuous influx of technical architects in key architectural roles)
2. Siloed Transformation Initiatives - Transformation programs being executed in silos with only a view of meeting the objectives for a particular domain , function , platform without anyone owning or evaluating the e2e impact a transformation initiative will have , this also allows the vendors to upsell duplicate functions to the CSPs fairly easily.
3. Very Little Ownership From Tech Companies - Even in today's date tech companies primary intention is to sell the platform , beyond the initial sale and POV their ownership and willingness to make the initiative a success is an eye wash

A Balanced Approach

There is certainly a need to have a balanced approach applied to this debate of layering v/s delayering the functions in a CSPs IT ecosystem to ensure any layered function is providing the intended benefits for the CSP, rather than just being a case of a quick upsell by the vendor , which can be only be achieved by :

1. CSPs understanding the need to invest in solid architecture practice which is backed by proper architecture governance practices.
2. Holistic ownership of any transformation initiative within the CSP , rather than a case of a siloed execution .
3. Finally tech companies focus shift to working as a partner either through their services function or via partner/s to ensure they influence the transformation journey and the eventual outcome.