Hi there. My name is Charlotte Patrick, and I'm an industry analyst looking at data intelligence and automation for telcos. Good to speak to you today, Ehren. Could I first just ask you to introduce yourself to those of who are listening? Sure, Charlotte. Nice speaking with you. My name is Aaron Katz. I'm BI consultant and data architecture lead at Amdocs responsible for our ALDM practice. I have been working on EDW and and operational data store design and implementations for the last twenty years, working closely with customers across the globe, including Vodafone, T Mobile, Veon, Deutsche Bank, and other organizations as well, both from telecom and financial domains. Oh, fantastic. So you've been around in this space for some time. In our discussions for this webinar, we were talking about what Amdocs is seeing when they're on the ground with their telco customers. My observation would be that the larger ones seem to really have a significant focus now on being data driven. This really came home to me. You know, I've just been speaking with both Orange and Vodafone last week, about their activities for some research that I'm doing. And, you know, they now have teams in the hundreds of headcount kind of focused on working towards the goal of being data driven. However, I know that you are on the ground working day to day with the complexities of moving the supertanker that is a telco, what do your customers most need from their data management systems currently? Right. We know that businesses, our customers currently have far more than just the classic classical data management requirements. By classical data management requirements, I mean the ability of data management solutions to support business strategic and planning decisions. Today, in addition to that, they also need the ability to analyze not transformed information from BSS or SS. For example, for revenue assurance needs, for fraud detection, and for machine learning as well. Businesses also, want their data management solutions to support daily operational tasks by running operational reports, usually near real time, and providing integrated information to third party systems as well. And they voted the structure to support future remote enrichments as well. Example, implementation for additional line of businesses. Plus, these expectations are even more prominent when there there is some compelling event for data management transformation or modernization. For example, the sales transformation of mergers and acquisitions. And do you see good decisions being made around data management? Obviously, it's still quite a quite a fast moving world in terms of new solutions, and some are currently kind of barely mature. And then there's also already, of course, issues of technical debt where some solutions have been tried and they've fallen a bit short. Thinking of the first round of data lakes is a good example. A telco is doing a good job of building for the future. That is interesting question, Charlotte. To answer today's business needs, IT is building new data management components on top of analytical or data warehouse solutions. This included no transform data lakes with minimum data transformation and the customer operational data stores or ODS usually at any real time NFTs. Most of our customers have already very rich analytical solutions, many with extensive machine learning capabilities. It is true that in many cases, they need to modernize their solutions due to BSS or assess modernization, five g implementation, and other reasons. It is very challenging process, but it could be done using multiple known data warehouse solutions and traditional industry standard data models. But the real challenge today is actually the implementation of operational data store or ODS. Absolutely. And, obviously, we're discussing data stores today. And I'm just wondering if you start by just talking to us briefly about this kind operational data store. What is its function? What needs to go inside of it? What capabilities need to build around them to enable them to work, correctly? Alright. Well and operational data store or ODS for short has several very key characteristics. Firstly, it is a data layer that organize the data in a way that it could be easily consumed for operational needs. Secondly, it fills the gap between a raw data lake from one end and file highly structured and transformed data warehouse from other end. Thirdly, it is a data that kept in very detailed grain of the assess and OSS systems, but still this data is integrated and unified for easy consumption. And finally, ODS is used for operational reports, down downstream interfaces, and machine learning as well. Okay. So we're talking here about the detail of what's stored in the BSS and OSS. You know, I just I know that that's precious information, and that it's only probably understood by a proper handful of people in the telco. So this is just really about codifying that knowledge. Interesting interesting and useful stuff. What do you see happening today? Are telcos having an easy time building what they need? Right. Building successful operational data store is certainly a challenge. It demands the right balance between transformation needs to prepare data at near real time, flexibility requirements, and consumption needs as well. Plus, there is also a challenge of implementing traditional industry standard data models for operational data store as, typically, these models provide solution for analytical needs only. Means they don't really have answers for operational reporting or downstream interfaces. Additional challenge is to load the data at near real time. We know that both technology and then data model as well should support near real time load and consumption. And the third issue is that these traditional data models are not optimized for modern technologies. So as a result, we have seen some customers using their no transform data lakes for their operational reporting and downstream interfaces. It is possible, but the issue is that usually this leads to consistency issues since the same integration logic of data is duplicated at every report and every interface, plus high maintenance costs and increased time to market for new reports and new downstream interfaces. Yeah. Interesting. I mean, those those kind of problems that you're highlighting there are things that I've heard talked about before, so I'm interested that you're seeing them as well. And then what happens when you also have to create a data model for the store as well? Is is this proving easy? No. That is a real pain point for their solutions. Most of our customers fully understand the need of model for this. No need to convince them. But as they cannot base their solution on the traditional industry standard data models, they're creating their own data model. And, usually, this works pretty well for the first release or first PI since it is based on specific set of business requirements. But once there are new set of business requirements, for example, implementation of new line of business, new products, the solution usually, unable to support these new requirements, creating the need not only for additional components, but for full change of existing solutions that it is in production already. And this is a really painful process. As a result, we see actually many customers end up with multiple operation data store systems for every line of business and line of business or for every product and every product. That is that is pretty that is pretty terrible. I see a lot of interest from and a lot of activity from the telcos to DIY things, and this sort of issue is just the sorts of things that you know? And it's not like this is the first time we've seen this. So very interesting that Amdocs is kind of working on on a more standardized solution. So so we have multiple siloed data with no standardized data model. And I know that Amdocs has been knee deep in this issue for quite some time. Could you could you talk to us a little bit about what you're doing? Right. So, actually, around twelve years ago, Amdocs recognizes challenges and took the strategic decision to build its own industry standard data model for telecommunications and beyond, example, media and finance. And what are actually design principles for this new industry standard data model by Amdocs? First, we need one integrated data model to support both b to c and b to b across organization lines of businesses, including mobile, fixed line, media, and so on. Secondly, we need one data model with different layers for both operational and analytical needs. Thirdly, it has to be business analysis oriented model. This data model should be very intuitive to business. It should use intuitive business language. And, additionally, it has to be pre mapped already to Amdocs platforms and to other common BSS and OSS systems as well. So this led to what we called ALDM, armed toxicological data model. And today, ALDM is matured, team of certified data model with more than twenty successful implementations at the tier one and tier two service providers. Excellent. So one of my interests as an analyst is on the use cases which come from these types of architectural initiative. I'm always interested to know exactly, you know, where the money is coming from, especially especially in these early days of implementation. Could you talk about what exactly the model provides for data scientists and those sitting in the telco in need of clean data? Right. I could say that both ODS and analytical layers provide critical value to the different types of business users. ODS layer of LDM supports, business processes and operational flow. Example, analysis of bottlenecks on the ordering flow or downstream interfaces that require integrated data, example, to commissioning systems. The analytical layer supports business strategy and planning. Example, AI driven customer profiles, supporting NBA or NBO. Five g use cases such as dynamic bandwidth allocation. Another example is customer experience analysis via paid media such as Facebook or Twitter. Understand. Are you seeing in terms of value for your customers when they're implementing ALD? It's up and running. What what are you seeing? You know, let's take a look on the recent implementations that we did for one of the tier one service providers. Service providers selected aldea for its new data management solution to improve the customer experience, data democratization, and operational efficiency. As a result of aldeam adaptation, the number of self-service business users grew by forty percent in the first year, while time to market for the new report implementation decreased by seventy percent. It's also allowed to add new analysis areas and data products without the need to make significant changes in the solutions are already in production. Plus, data user satisfaction also increased, even creating more data ideas and requirements. And finally, maintenance cost was decreased by thirty percent comparing to the latest BI. Thirty percent is a lot of money. So what's the future of AIDIMM? How is it likely to develop and integrate with other Amdocs products and and beyond that? Alright. We are seeing that complexity of data and analytics will continue to grow both for technology and functional perspectives. So to be ahead in the game, we'll continue expanding LDM both vertically and horizontally. Means on one end, we will cover we will cover more use cases related to new businesses, for example, related to five g, data marketplace, or multi vendor offerings. And on other end, we'll continue integrating LDM with new Amdocs and not Amdocs products as well. Interesting. Yeah. So sounds like a significant bit of work for you over the coming years, so good luck with that. And I would I was thinking about how I'd might like to come come into land with this discussion today, and I I thought it would be just be useful to summarize a quick overview of some of the thinking that I've been doing about all of the mid and long term requirements for ALDM, and how it might underpin the data management requirements that are going to develop in an increasingly kinda interesting world for telcos. So the sorts of trends that I'm expected to see impacting in the midterm include, first of all, we need to deliver on some of the promises of bottom line of improvements for data that we've been discussing for, what, the last ten years. This hasn't always been easy, and lack of quality data has been a major part of that. And then secondly, the arrival of more intelligence and automation, we've obviously seen some, but other more sophisticated requirements needs kind of specific new things like orchestration in the network or in operational systems, which will be arriving as five g s a gets rolled out. But, you know, it will suddenly become more feasible to run more complex algorithms that that we've been talking about, and this is gonna need, you know, more quality data for training than is currently available. And then three, we've already seen some increase in internal and also external users of telco data, and these users will need a mix of new data management architecture to support their needs. And then on the quality of data side, they're also gonna need other things. And then we've got, you know, governance and security as well on top of that. So in the midterm, that's quite a big ask. And then into the longer term, things get really interesting. I think telcos are gonna face a series of complex new challenges and many caused by the rise in new intelligences and automation. So for example, the speed of which we do business is going to accelerate, and competition are gonna find it easier to replicate certain capabilities, which have been kind of specific telco specialists in the past, things like network management, and that's gonna change. Plus, not only more competition in in telco space, but telcos may see opportunities outside of their traditional domains becoming more viable. So telcos are gonna want to do something. And in this environment, you know, the speedy and agile use of data will be key, and telcos will need, to put significant energy into creating a data strategy and data management architecture that can cope with these new requirements, that are being placed on it. So and and, obviously, an operational data store is just just one part of that, but, all of these things are gonna be so important, and it's just gonna be really, really interesting to watch what happens. So I hope that those have been who've been listening today have found this a useful discussion. And if you wish to explore more in detail, I've written a white paper with Ehran, which should be available alongside this webinar. So thank you so much, Iran, for your time today. Thank you, Charlotte.