BLOG POST
Data Mesh – Connecting Personas to Roles and on to Automation
Data Mesh is a new conception of how to handle and process data, but it can easily be aligned with the ways in which we have delivered service assurance and analytics. It builds on familiar ground to provide a new way to supporting data processing and handling through common principles – and also fuels enhanced automation.
In our recent webinar, we showed why Data Mesh is, in our opinion, the right approach to creating a unified data architecture and unlocking new levels of insight. This isn’t really the place to define what we mean by Data Mesh – that deserves a longer article – but, briefly, let’s summarize for those new to the term.
Introducing Data Mesh
A brief summary of the key concepts
Data Mesh was conceived and coined by Zhamak Dehghani in 2019 and is really based on four simple concepts:
- Domain ownership – taking responsibility for data
- Data as a product – consumers need data, and they may be outside the base domain
- Self-service – a platform enables access to the data
- Federated governance – data is standardized, and data products are interoperable
In essence, we’re talking about a way of bringing data together (so eliminating silos) and enabling access to the data by anyone (or anything) that needs it, whether inside the domain from which it originates, or outside.
So, CSPs, like many other organizations, are now seeking to leverage these principles to create a new data processing and access architecture and we will write about specific steps towards achieving this goal – or ‘nirvana’ as we put it – in future posts. Here, we want to focus on a term that was frequently used during the session: personas.
We use the word persona in many different ways. Marketers will talk about the personas of their target audiences, for example. In terms of Data Mesh, however, what we mean by personas are the different stakeholders across the data supply chain – and, to use another term, the analytics lifecycle.
These can described differently, but we’re essentially talking about data consumers and producers. These can be categorized into many different categories, but these all represent variants of these core personas. These can include data scientists – but it’s important to note that we are not restricted to that persona, and this is important for CSPs seeking to adopt these principles.
Data collection and delivery
Aligning personas with roles in the CSP organization to leverage Data Mesh
What matters is that the underlying architecture and framework allows data to be collected and processed – and then served or delivered to any given persona. In the telecoms network domain, we can usefully consider mapping consumer personas to roles in the CSP organization. It’s this step that helps simplify adoption, because while data scientists are important, we already have consumer roles in our team who need data to be available from the mesh.
A clue to this was provided in the webinar. At the outset, we highlighted different functions that can, ultimately, be labelled as one persona or another. We did this by considering some common functions within familiar CSP domain. These include things like:
- Customer experience
- Cell experience
- Device analytics
- Network analytics
- Performance management
- Service assurance
And so on. So, the personas we’re concerned with basically begin with roles that are familiar in the CSP domain. This point was reinforced by reviewing some questions that might be asked, such as:
- How do I segment my customers?
- How can I detect fraud and protect revenue?
- How can I reduce call-center traffic?
These questions could be asked by people from different teams – and you can imagine how, for example, a device analyst might wish to know something like the rate of penetration of a specific new device in the network. Or, a marketer to understand how a new service is being adopted.
Removing confusion surrounding Data Mesh
New terminology, but it is completely aligned with existing practices, building on CSP analytics and assurance principles
The point is that, while Data Mesh gives us a new lexicon, in truth, it can easily be mapped to our existing understanding of CSP analytics and assurance. This is of huge importance. Why?
It’s because the benefits of a unified approach to data – with no silos and with data as a product, available through a (secure) self-service platform – are so significant in terms of enabling future operations and insights that we must not conceal them with the jargon associated with yet another new set of terminology and descriptive language.
Sure, we have to use that, so we’re aligned with the principles behind Data Mesh, but underneath that, what we have is a framework that will enhance the ability of our existing roles (aka personas) and people to answer key questions and to generate new insights. But Data Mesh can be misinterpreted, so to be sure that we’re on safe (and familiar) ground, it helps to remove any confusion by relating it directly to the operational roles in our organizations. There may be new ones, but we already have the key stakeholders in place.
Data consumers for automation
Consumers can be processes, enabling automation to be realized from the data product and platform
There’s another reason, though – which is just as important for future aspirations. A data consumer could also be a process that enables automation. Data Mesh helps us to conceptualize this by liberating the person or thing that uses a specific set of data from the mechanism by which it is obtained.
So, the radio operations engineers can use the same data as a new process that might automate cell capacity management. The data is the same, but the users are different. What this does is to both empower our traditional users of data and to fuel automation that can reduce our operational costs and enhance efficiency.
To be sure, Data Mesh is relatively new – but it does have well-established principles and frameworks. These can easily be correlated with the traditional world of CSP service assurance, but they can also quickly translate into new automation opportunities. And, it also exposes very clearly the ways in which new sources of data can augment what we already have (Control & User Plane, OSS, BSS and so on) – but that’s another story.
What matters is that we now have both a conceptual AND a practical framework to help reach that nirvana.
