Enterprise Product Management

About Catherine

Catherine MichelCatherine Michel
Chief Technical Officer
Tribold Limited

Catherine Michel is CTO and cofounder of Tribold Limited. She is the principle architect of the company’s product and solutions portfolio. Her extensive experience in CSP transformational strategy and systems development has made her a recognized authority in the industry. Prior to co-founding Tribold, Catherine was a senior executive in Accenture’s Communications & High Tech practice, devising and delivering strategy and large-scale BSS / OSS projects. Catherine also sits on TM Forum Executive Committee.

View Catherine's TM Forum Profile

Syndication

TM Forum Blogs


Martin Creaner's Blog
President & Chief Operations Officer 
TM Forum

The Insider The Insider
by Tony Poulos
TM Forum

TM Forum Training
by John Reilly
Subject Matter Expert and Distinguished Fellow TM Forum
&
Andrew Chalmers
Director of Training
TM Forum


Enabling New Services
Stephen Fleece
Director, New Services Collaboration 
TM Forum

Leadership Blog Leadership Blog
TM Forum

Centralized vs. Federated – is there a right answer?

Share |

After a brief hiatus, I’m back to blogging!  And having just spent the last couple of months deep in the bowels of a CSP advising on their product data architecture, I’m more passionate than ever about what needs cleaning up around the Telco product landscape. 

So carrying on from my previous blog’s notion that sorting out the data challenge (PDM) of products takes supremacy over the process (PLM) challenge, let’s talk about the question that inevitably arises for managing the data...centralized or federated???

Where centralized asserts a common view and predominant master over all (or most) product data, federated supports a common view but is still slave to multiple masters.

On first telling, federated is the concept with which many people are most comfortable.  On the surface it means less disruption to existing architectures and processes, whilst still achieving the single view of the product.  Contrast that with centralized, which involves consolidation of data, changes in the direction and integration of data and changes to operations.  With those optics, who would choose anything but federated?

Well, the answer lies deeper than glossy architecture.  It is somewhere in the effect that the approach should have on the ability to manage data and the cost and time of doing so. 

The reason federated seems so undisruptive is because it is undisruptive.  It provides very little basis for change.  A lot of work still needs to be done to create that single view, but everything else remains the same.  Federated still requires multiple points of entry when creating or updating products / prices.  Federated does not rationalize the view of products into something logical with which both the business and IT can relate and work together.  Federated does not shift the organization into thinking in holistic product terms, rather than the traditional rate plan or network capability terms.   Little change in this case does mean little benefit.

Centralized, on the other hand, gives the organization the opportunity to consolidate products into a standard, comprehensive and very useable view that is focused on component reuse and service enablement.  Centralized gives the organization the ability to make changes in one place and disseminate those changes in an automated, error-resilient fashion.  Unfortunately, one of the myths about centralized is that it would require major changes to existing systems and the repopulation of data.  In fact, if done properly, the changes are limited to the new catalog and to the integration.  Finally, and most importantly, centralized asserts real control over the thousands of pieces of data that sit dispersed across the BSS/OSS.  This type of control effects real change in the organization and ties together the operations from the best possible perspective – getting the right products out to suit customers’ desires and needs in less time and at lower cost.

So, yes, there is definitely a right answer to the question of Centralized vs Federated.


Posted 10-19-2009 5:43 AM by Catherine Michel

Comments

Martin Creaner wrote re: Centralized vs. Federated – is there a right answer?
on 10-20-2009 6:13 AM

Catherine, very interesting.  Are there implications in this debate for what we do with the SID.  Logic would say that the SID is equally suitable for either a centralized or federated world, but are the subtle differences that make it more suited to one than the other?

John Reilly wrote re: Centralized vs. Federated – is there a right answer?
on 10-20-2009 11:52 AM

Right, Martin...the SID can be used in both cases.  Often the SID is used to federate as a first step towards centralization/convergence.

And, sometimes the decision is dependent on applications currently in place.  Here is an example where federation may be desirable.  There are two inventory applications in place, one for fixed networks and one for mobile networks.  Each of the two applications contains functionality specialized to the type of network.  And, one cannot be used in place of the other, but a consolidated (federated) view of the networks is desired.

Bottom line is that the current environment and future goals need to be considered when making a choice.

Raja Sekhar Ravi wrote re: Centralized vs. Federated – is there a right answer?
on 10-25-2009 8:46 AM

It is nice to see a post on federated vs. centralized product data management. The author has detailed the advantages and disadvantages of these two approaches.

My point of view is to have a centralised federated product data management. As author rightly mentioned a centralised data management provides a holistic and consolidated view of business to the IT world. With this IT world also can easily understand what needs to be done to bring these products quickly to the market. I prefer this centralised data management to be confined to logical models and business language. This facilitates a single truth of source to the federated product configuration and development in the respective B/OSS applications. This way it provides control over the implementation view to the business view and ensures that IT applications are not deviating from the business view.

Jagadish Baddukonda wrote re: Centralized vs. Federated – is there a right answer?
on 05-31-2011 6:59 AM

Hi,

Both , Centralised Data management and Federated Data Management especially when it comes to product data Modelling and management and Customer Data management have thier advantages. From a purely theritical perspective, the Centralised approach appears to be better. However the world is not perfect and there is always the problem of legacy and change management and hence the Federated approach looks good.

Let us look at the aim of data management  /

Central Product Catalog

- It should be an Information repository with persistent data.

Federated Data management fails here

- Should be Multi Domain.

Both the approaches work here but in the Federated approach it depends on how the data governance is established in the mother application i.e. how the CRM models the Sales view and the same is modelled in the Billing. So the dependancy on the CRM / Billing / TechnicalProduct catalog is high

- Process centric approach

Federated approach fails here

Data Synchronization

Again not available in Federated approach

Essentailly when product harmonization and product data master is the need of the hour, sadly the federated approach fails, since it essentially is a Access Only apporach and does nto fix the problem of data harmonization and data governance.

Doug Newdick wrote re: Centralized vs. Federated – is there a right answer?
on 05-31-2011 8:08 PM

There are actually two different dimensions to the federated vs centralised debate here. The first (and IMO the most important) is the business dimension - are product decisions, product architectures, re-use managed separately by different parts of the business, or are they managed centrally? The second dimension is the technology dimension - is product data, data architecture etc. managed by a single central IT system, or is it managed separately by different IT systems, and only a consolidated view obtained? I think that we can have any combination of central vs federated for business and technology (though the most efficient will be when they are aligned).  Even if you have centralised technology, you will still not achieve the sorts of re-use and efficiency that you are after if each separate part of the business can create their products without paying attention to concerns around re-use and standardisation.

Which approach is better will be determined by the way that your organisation operates: do separate business units compete by offering localised and nimble product offerings, or does your organisation compete by seeking economies of scale and efficiencies through standardisation?

Jagadish Baddukonda wrote re: Centralized vs. Federated – is there a right answer?
on 07-06-2011 6:16 AM

Could not agree more Doug.

And one more practical aspect, I would like to add is that, the definition of Master Data in the identified data domains is specific to the way in which the business operates and the business drivers of the organisation at that point of time.

For e.g. the time that a Customer Logs in (Time and Data stamp) into the Self Care portal is normally seen as transactional data. However if there is a mandate to reduce / increase the number of such log ins for whatever purpose, then that becomes master data under the Customer Data domain and needs to ne analysed upon. What is important is that the different applications which maintain the context of each log in (done via the portal) need to be able to provide the required info or rather the "master" / centralized or if I may use the word "Harmonized" application should be able to draw the necesary information from each of the transactional applications and use that data.

Same goes with Product Usage Analytics. However for the purpose of Product Catalog (Introduction and maintain products and services), then a centralized Product master looks a viable option. Ofcourse the product reference data between application needs to be made available

Hence now it is not only  Centralized VS Federated but also a HARMONIZED approach that is also in the fray.

We welcome your feedback! To comment on this blog post please either Log-In or Register to the TM Forum Community

Paid Advertisement
About TM Forum
Introduction, History, Board, Management Team...
Membership
How to Join, Benefits, Member List...
Community
Community Home, Groups & Teams, Blogs...
Conferences
Event Calendar, Management World, Supported Events...
Training & Webcasts
Upcoming Training Courses, Upcoming Webinars, Podcasts, On-Demand Webcasts...
Initiatives
Cable, Enabling Cloud Services, Government and Defense...
Best Practices & Standards
Frameworx, Business Process Framework (eTOM), Information Framework (SID)...
Resources
Document Library, Case Studies, White Papers
Research & Publications
Business Benchmarking, Newsletters, Insights Research...
Copyright © 1988-2012, TeleManagement Forum. All Rights Reserved
Contact Us
Careers with TM Forum
News Room
Privacy Policy
Terms of Use
Sitemap