The common data store trend (part 2)

Last month we posted an article that described using a common data model (CDM) for our OSS / BSS data. It mostly looked at the situation within the context of typical operational data sources (the blue boxes on the left side of the diagram below):

Today’s article pushes the vision a little further. If your CDM is built as part of an enterprise-wide data warehouse, then you may get the opportunity to think beyond the boundaries network and operations data.

We’ve long said that our OSS/BSS impact most other parts of a business, yet we tend to spend very little time proactively seeking value-add opportunities outside network operations, in marketing, products, finance, the C-suite and beyond. 

Traditional OSS/BSS were built around highly structured, relational databases, usually designed by OSS/BSS product vendors. Each data architecture was designed to support the specific, baked-in use-cases offered by each product. It was like a building architect designing a building, let’s say a new wing of a university, from the ground up for a very specific purpose.

You don’t get the same luxury with your CDM. You have to take a multitude of existing platforms, applications and data models and attempt to turn them into a cohesive data set. This is a bit like taking a row of existing houses, extending and combining them to form a university wing. The “existing houses” might represent disparate OSS or BSS or network systems, but they could also be IT / data silos from various other parts of the organisation.

You know the latter “university” design will be compromised – discrepancies in data standards, data flows, siloed data knowledge, disjointed data governance, etc. However, it also comes with a big benefit. You can keep appending new sets of data that were never part of initial considerations, of any of the IT / data silos. It could be weather data, social trending, building approvals or so much more. It could be any data set that you think could unlock new insights.

But to form a coherent and valuable data set, you still need a common blueprint. As Stephanie Shen describes on towardsdatascience.com

“…the following areas need to be considered and planned at this conceptual stage:

– The core data entities and data elements such as those about customers, products, sales.
– The output data needed by the clients and customers.
– The source data to be gathered and transformed or referenced to produce the output data.
– Ownership of each data entity and how it should be consumed and distributed based on business use cases.
– Security policies to be applied to each data entity.
– The relationships between the data entities, such as reference integrity, business rules, execution sequence.
– Standard data classification and taxonomy.
– Standards of data quality, operations, and Service Level Agreements (SLAs).
 
This conceptual level of design consists of the underlying data entities that support each business function.
 
As with all valuable OSS tripods, your value in the CDM chain is being able to connect the silos of business, IT and operations.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.