Guy Daniels, TelecomTV (00:15):
Our next session looks at the move from cloud native to AI native and let's invite our speaker to the lectern and it's Vivek. Vivek Chadha is SVP and Global Head of Telco Cloud for Rakuten Symphony.

Vivek Chadha, Rakuten Symphony MEA (00:34):
I'm going to try and have a little bit of a dialogue if that's okay, and some of what I shared today is actually in three parts. One I'd like to start with, and this is where it was very interesting, the way you created the narrative in the panel that we had from cloud native to AI native. So the first part of the discussion that I'd like to have is just her perspective and I repeat it's her perspective, it's not their perspective. What I think is cloud native and what I think AI native probably should be.

(01:12):
And that ties in some ways to the beginning of the panel that we had earlier before lunch. Moving on from that, I'd like to touch a little bit about what Rakuten Symphony is doing in one small part of that transformation. Again, one very small part, it's a very extensive, multilayered multi partner kind of space in the AI domain. No one person does it all and in the end I will try to summarize a little bit about one real world use case where a telco customer was on their way to doing something in the ai and it's not necessarily related to networks. We do have permission from the operator. We'll share with you what might look like a very simple need, but became an involved exercise and how they spent several months trying to understand the best way to do what they are now doing and how for the last two years they've been using some elements from Rakuten Symphony in doing a little bit on their AI journey. Hopefully that gives you a little bit of feel for how some customers are looking at the move from cloud native to AI native, what it means, what Symphony is doing in a small way in that journey, and an example for how a customer has been able to use some of that.

(02:49):
Is there a clicker for this thing there? It's so I think we had the conversation earlier in the panel about, and this is where I picked up the tagline, shifting the focus from how we deploy to how we decide. I'd actually like to add more to the how we decide. It's also in the long-term going to be what we decide. There were panelists in the morning who actually talked about the known unknowns and the unknown unknowns. What we decide today is what we know. What if there are areas that we've not even understood lie hidden in the data that we have. What if AI is able to surface these insights and pose questions which are today not part of our thinking? I believe DT has taken a very pragmatic view of trying to understand did I take the right decision and if I did not take the right decision, does it have a real consequence or am I okay for that error rate to go ahead?

(03:59):
Some of that will become what AI hopefully allows us to do in a much more seamless and transparent manner. Today it's hard today it's analytical at best what we decide, how we decide, and the last element, how much of it we control on an ongoing basis. I'm not suggesting we lose all control because ultimately it is software things go wrong regardless of best intent sometimes due to bad actors. So that one tagline I think is a metaphor for what should to my mind be the shift of if you believe you were cloud native and you think you or your partners or your customers are now going to embrace AI native, what you decide, how you decide and how you control it, that is going to determine where you are on that journey. And this is regardless of whether you're a telecom operator or a bank or a retailer, getting a little bit more specific, right?

(05:02):
And again, this is oversimplification for the sake of the session, but you've got a few different pillars which are common across in terms of teams across both cloud native and AI native. You've got infrastructure, technology, organization, culture and thinking, which includes skills and you've got objectives. And the key thing here is to see what the shift is. Infrastructure is an easy example. It's very easy to relate to. You can touch it, you can feel it. There's a balance sheet that has a dollar figure to it. Depreciates, Cloudnative allowed us a way to say you can build applications and the application can pretend it has in finite resources, but if you've truly done cloud native, your cloud native platform and environment and operating model will protect against in finite scale and elasticity. That's where the governance comes in. Why is that important? It allows you to take the power the best of what was public cloud and bring it in a controlled environment for your use cases.

(06:11):
That was one essence of infrastructure in cloud native. But how will that change when you go to AI native on the infrastructure there? You're not thinking in terms of scale and elasticity. That's a problem that's been solved. You are thinking, and this was a term discussed very actively in our session in the panel data and am I AI centric from the get-go? So it's not a Bolton. There is a bit of debate in the industry about are people who are chasing use cases in a better position to have a lead in AI or are the ones who are actually building fundamental or foundational change in a better place. I personally don't have a view on this. I think both camps probably have merit depending on who you are, where you are in your peer group. Same applies for technology, operating model cultures and thinking and goals. So that shift, while your pillars remain common, what you think about what you focus on those pillars is going to undergo a change.

(07:17):
Most of you may have already picked this up. Technology is just one of the elements to the common man. When we talk about AI or even in our industry when we loosely use the term ai, the general mental recall is of AI as technology first, but that's just one aspect of it. So I'm almost tempted to say all will be revealed, but how I wish that was true. I did say, and I'm stepping into it now in a self-confessed manner guys, I did say most of us are engineers. We love some sort of framework or a roadmap or a blueprint to help us understand where we are, where we want to go, what could be a route to go there. So I had a bit of debate with some of my colleagues about this topic, and again, this is not a prescription, it is one potential way to look at where you or your partner or your customers or your teams are or the AI continuum on the AI native continuum. There is some creative liberty here. So I'm happy to be challenged, happy to hear a different point of view because after all, this is all about evolving together.

(08:38):
So the first column talks about the stages and some of you might be able to draw parallels to the autonomous network journey, but this is not about networks. This is about the principle design of your business regardless of who you are. The use cases I've taken at telco specific, just to make it a little bit easier to relate to the second column talks about architectural reality, which is a combination of several pillars you saw in the previous slide, whether it's infrastructure, technology, operations, et cetera. The third, which is the most critical one, is decision making.

(09:16):
The fourth is about the shift in business model, which impacts processes, skills, how you would want to start interoperating. And the last one is a little bit about risk, but we are looking about the future. So let's not worry about risk, let's worry about not even worry, let's focus about what is it that is needed to shift from cloud native pre ai. And I use that word very loosely. I'm sure AI has existed actively in several of the organizations who have sat in this room for many, many years before Open AI Chat GPT made it popular at a consumer scale. So please take that with a pinch of salt. But cloud native as we knew it, even in these forums still three years ago or four years ago, I think this is the first AI native panel, isn't it? Or the sessions. Yeah, so I use that as a metaphor rather than an actual historical basis for AI being invented a few years ago.

(10:12):
So cloud native architectural reality was around elasticity, compute paradigm building applications by borrowing the best of public cloud, but none of the excesses of public cloud and being able to control that. And there was an operating model chain, there was a skillset change and all of the good things that came with it and you focused on efficiency and agility. So the scale elasticity of public cloud, but in my control, and it didn't stop you or prevent you from also using public cloud. It leveraged the best of both worlds depending on what your use cases were.

(10:50):
And what does that tell you? If you're cloud native, well, you're modern, but you're reacting to an established set of business needs, but you're reacting to it in a much better manner than you would have say 10 years ago, right? A lot of people have had some exposure as business to AI now over the last couple of years. And at the very least we can confidently say that these companies can associate themselves as being AI assisted. I was having simple examples. I dunno if Nico is in the room about how some of us are now using AI models, whether it's a private on-prem, internally protected chat GPT version or a homegrown version, which is like chat GPT to review contracts. Now this is AI on the side. It is not a fundamental part of my business or your business, but it's a good tool which improves efficiency in some function of your business. And the examples that we can look from a network point of view are cost or ops optimization, right? So even service assurance, et cetera. But this is an add-on. You don't fundamentally change your business, you improve an aspect of it. I pointed out in the beginning of the slide that the most important column on this slide is the decision making column.

(12:18):
You are still relying on a human to make a conscious choice of when and how to use that AI on the side number, number one. Number two, you are also relying on that human being to choose what to do with the output of that ai. Take all of it, take some of it, discard it, completely rerun it, but it's still a lot better than doing things the legacy way. If you go further down in the evolution journey, you have AI enabled, this is where it starts getting a little bit more intrinsic to your business. Now you've got AI in the loop, which means you are not explicitly going and activating or triggering something in whatever part of the business process. You've used ai, but it is autonomously taking over some part of execution regardless of function or department.

(13:19):
You move from humans making decision in AI assisted to AI executes, but the human still approves the final outcome. So you're no longer having to press the button, but you are analyzing the outcome and deciding whether to let it go ahead, roll back, change it so it's a little bit better that there are no manual intervention required to start the process or have it kick in. So what does this give you when you go to AI enabled where it's a significant load better than saying you don't just live in fancy dashboards, you are able to do operational efficiencies. If you remember the discussion we had, I alluded to CQT, either cost quality time or all of them or some of them are improving as an outcome, but it is not fundamentally changing the macro business because it's happening in piece meals and parts. And some of it might be by design because you could be somebody who's venturing into this AI continuum and you want to start with baby steps, understand what it means for you, see the impacts on your business, get your organization comfortable with the fact that yes, you can read the news no, but it's not going to take your job away tomorrow.

(14:30):
It's actually going to empower you to do more of what you're doing or do it better.

(14:35):
And then we moved into probably where it starts getting a lot more integrated and involved in the core parts of your business, which is AI driven. Some companies have started saying that our operating principle is now our default is ai. It's very hard to unpack that statement to be honest. I've made an attempt here and my view of that is that AI leads the execution and the outcome and the human supervision is only at the business metric level, not at every process or execution level. And this may explain why there is this sequence of evolution on the AI native continuum because by the time you go from AI assisted to AI driven, you would have had the opportunity to fine tune test put in place guardrails and policies that you can start relegating some aspects of the business to an AI driven, not just AI in the loop, but AI controlling execution. And this goes back to the example again of you will probably still not get a hundred percent success rate, but you would've had enough opportunity to understand that either in time rollback or rectification is possible if there is an erroneous output or the cost of that failure is in the larger consequence of the business immaterial, which means it is worth making those failures because the gains far outweigh the rectification you might have to do in case of a fallout. This is where at AI driven, you start getting very close to industrial grade.

(16:25):
And the last probably the most evolved, and I use the word autonomous again to link it in a way to the level five journey of the networks, is when you have the economy of your business, I use the word network because we are in largely a telco or a service provider environment, but this could be any industry where your economy of your business organization is largely autonomous largely. And the difference in the decision-making pyramid here is that human defines intent and AI adapts continuously. I think Bijoy mentioned something on what they are implementing in terms of intent-based orchestration and modeling, and that was a technical example, but it leads to a business outcome where you can even negotiate an intent that wasn't thought of earlier. And that is where eventually I think businesses will go to. Because if I am able to think of 10 scenarios or a hundred use cases, of course I can build sophisticated and efficient processes to deliver against those.

(17:29):
But maybe there's 120 and I am not aware of the other 20. Maybe I have a unique customer demand that comes in and if I'm able to service that demand in reasonable time, it opens up a new revenue stream for me. But today, in order to do that, we end up doing solution design and ROI calculation a bit of POC, et cetera. All of that's not going to disappear overnight. Some of the business that this industry is in is still hardwired and you can't pretend that it's all going to go away because you are somewhere on a chart, but some of it can actually move to a more autonomous layer. So I thought I'd just do a level set before I get into a little bit of what we've done in a very tiny space in this area and just offer a perspective of what is in my view, the metaphorical shift from cloud native to AI native. And if you do believe that AI native is a continuum, it's not a binary jump from zero to one, there are stages in that journey. And this is true for any business, not just a network or a RAN or a core use case.

(18:38):
So I'm going to talk a little bit about two things that were discussed in different parts in the first half of the day, not just in our panel, but other panels as well. AI without data is kind of meaningless. You've got an engine with massive horsepower, but you have no fuel to put into it. Data is the fuel. Your AI capabilities and sophisticated infrastructure is the engine, which is good, but what does that mean? What are the actual business problems? Some organizations that we have spoken to are facing when they're embarking at least in the initial phases on their AI ML journey because they want to learn, they want to discover insights, they want to trial a few things, and whether they relate to a model or a chart like this or a journey like this or they have their own, they will start somewhere and evolve into a much more mature organization.

(19:35):
So four things came out. A lot of the organizations are reluctant to have some of their core data go to public cloud. While it is experimental, multiple reasons for it, which aren't really important, but we've had over the last almost two years, multiple very categoric interactions where ultimately this has become an us saying, I know I can do this at scale. At initially very high speed and elasticity without getting into complex procurement cycle, but there's a part of my network data that I really do want to mine, but I not right now comfortable putting it on public cloud. And some of it is historic data, some of it's commercial data, so you understand why they would be locked in to do it. There's another segment of the customers who are saying, we've been playing with something either as a large language model or a small language model.

(20:30):
We believe we built something unique, we'd like it to stay within our boundaries. Fair enough. So we realized very quickly that a lot of customers are asking for a modern on-prem private cloud, but not just an abstraction layer cloud a cloud which specifically does something to address the cradle to grave of building an AI ML infrastructure. Data sovereignty is a big part of it. Obviously cost is important because some of this is experimental opex and CapEx going in. Nobody has a guaranteed view of ROI right now, so they would like to start small, but they'd also like to do it in a reasonable way. The second was data centric and this ended up becoming actually the biggest obstacle. And this was going to be one of my answers to the last question you had on the panel guy. What are some of the factors that are holding back accelerated investment or growth or adoption of AI native in telcos?

(21:31):
When I say data, it is neither lack of data, nor is it in the most part the quality of data. It is actually the fragmentation of data. It is the different kinds of data. It is the different sets of data, and that becomes a data management IT overhead on day zero when organizations truly start trying to do something at a macro scale. If you're doing it in a limited function, it's probably not that complicated. It's still a little bit of hard work, but you can get around it. But if you want to say that I want to do a data lake for every single network domain I have every single e om domain I have across strategy, marketing, product commercial, my order logs for the last seven years, and I want to understand what my business was, how is it changing? What is it likely to mean for me in the future?

(22:34):
Suddenly you are talking about not just a ridiculously large amount of data. You're talking about probably dozens if not hundreds of different databases built over time in different technologies, different versions living in different parts of the world if not the country. So if you ignore this challenge and you have the world's best cloud software, you have the best GPUs from whoever you've built the best engine, you're going to choke it off fuel because you don't have an elegant, cost-effective, highly automated way to get the fuel into the engine. So the second thing we relied was any solution that is going to act as an enabler to jumpstart the AI journey for a customer has to have data upfront as a recognized input factor. If you don't design and build with that philosophy in mind, you're going to hit that roadblock sooner or later. There is statistics.

(23:35):
Somebody mentioned a lot of POCs failed. One of the reasons they failed is ultimately customers give up saying it's too hard to get the right data at the right place in the right time. And we've learned this over feedback over a while. The third thing we realized was performance and robust, but I'm not going to spend time on that. That's almost a given. The reason that it is still here is a call out to the fact that a lot of very valent attempts were made. Actually some of them were made in the financial services sector, some in the us, some in other parts of the world about four to five years ago when they built homegrown stacks to try and do some of what is getting converged into more of a standards based approach now. And eventually the technical debt was too high. And also I think Danielle alluded to it and somebody else that MCP comes out changes things.

(24:26):
A few months later, kit comes out from OpenAI changes things, and that time it was even worse because there wasn't even an established source of truth from where you would understand which ways AI is headed. So the performance and robust has come about because some of those learnings have percolated in the industry and people want something that is easy to work with, cost effective, but if it works, they just want to be able to scale it without having to restart that whole process. That's why performant and robust. And the last one is actually a combination of many things.

(25:05):
It's very easy to understand, unified and highly automated in an abstract sense, but if you don't have prebuilt adapters, for example, to do ETL, so extraction transformation and loading of data from discrete, disparate, heterogeneous data sources. And if you don't have somebody supporting and maintaining this because your vendor ecosystem is evolving, right? Whether they're going from a VM based solution to a containerized solution, whether they're releasing a new version of the product, your IT teams are not going to put a freeze on everything Just because you're doing an AI ML initiative, they're going to evolve their business because it's a running business. So you need a solution that recognizes this, change, this continuum, and allows you to create automation to keep up with this change without putting extra overhead of what I call digital plumbing or it overhead on your data science team. The second is human in nature.

(26:03):
If your initial pilots and POCs succeed, and if you're a large operator, you will start scaling this out. You can't do a linear increase of your technology staff for these initiatives, multiple reasons. One is you don't have the skillset sets in the market as the biggest shortfall in the human resource index in technology field right now is data scientists and a ML experts or AI ops experts. It used to be cloud nine years ago, but it's data science now. Second, it's an expensive skillset. So it's a race to the compensation battle, probably nobody's going to win it against if they decide to go down that route. And the third is it kind of defeats the purpose of the autonomous journey. If you are going to linearly scale your human capital count with a growth in your technology rollout, you've actually taken away some of the business benefits.

(27:01):
So that's why the automation has to be across day zero, day one and day two across the entire crad to grave lifecycle of the platform of the product. So these were four pillars that we realized needed to be addressed because in different priorities, different shapes and form, we kept hearing the same thing again and again. So what we did was, and for those of you who probably don't have introduction to Rakuten Symphony, Rakuten is a conglomerate with about 70 businesses, 16 billion in revenue. It owns Rakuten Mobile in Japan, which is the world's first fully cloud native open ran network. And it also owns a company called Rakuten Symphony, which is where I sit, which offers a portfolio of open standards based open, ran, open cloud, and OSS solutions. And today what I'm going to talk to you about is the bit that's highlighted at the bottom, which is the Rakuten data and AI cloud platform.

(28:03):
This was built over the last three and a half years, starting with an internal project then taken on by a customer as the initial version. And in the last two years, this has accelerated significantly for two reasons. The initial pilot customers started sending new requirements to us and we realized we had to keep up, otherwise they would drift away. But at the same time, other customers started getting traction with us for the exact same set of requirements, which is great news for our product organization. You want to build one thing and repeat it all the time, not the other way around. The second reason was this has started being used within Rakuten as well. So Rakuten has a group, like I said, has 60, 70 different businesses ranging from e-commerce to digital banking, to payment solutions to healthcare, to advertising. A lot of those businesses are shifting and adopting the same product.

(29:02):
So we had two direct sources of market input now on how to create commonality and repeatability in what we thought would be needed in the market. So what is it actually? So what we've actually built is on Rakuten Cloud, which is a very high performance pure Kubernetes on-prem private cloud offering. It used to be a startup in California called robin.io. I was a Robin IO employee and Rakuten acquired robin.io, and that is the Rakuten Cloud offering that we offer to our customers. Now it comes with one of the fastest software defined storage drivers for Kubernetes in the world. It also comes and the storage is available standalone, so we can support any Kubernetes distribution, not just our own. And it also comes with a cloud native orchestrator to do webscale orchestration of Kubernetes clusters globally or across countries or across regions. But this was just the cloud layer, the data AI platform that I'm talking to you about was what we did on top of it.

(30:12):
So we tried to answer pain points for three stakeholders. We came top down. We try to solve things for developers who typically face challenges in the cradle to give journey when they are being asked to deploy, setup and run AI ML pipelines. We try to make life a little bit easier for data scientists and obviously we also try to keep data engineers in mind. And what we've built is a complete AI ML pipeline based on the most popular open source industry applications, which are typically used by most organizations. Again, it's not prescriptive, but this is a stack that we believed meets the majority of the customer market that we've been interacting with. And in addition to that, we built data governance. We built data discovery. We built ETL adapters to link to multiple data sources. We built a query engine. We've created some preexisting models so you can get started with a ML, and we built some guardrails around policy for AIOps as well. This is available as a complete offering from Rakuten Symphony pre-integrated with our on-prem cloud with all the application layers and the pipeline available pre-built. So the work required when a customer wants to accelerate their journey is to integrate to their data sources, help their data scientists design, and then there off. So we've been able to reduce setup time in excess of 50% and the database administration time has gone down by more than 70% for the customers.

(31:53):
I'm going to skip some of the slides. This is just giving you a workflow view of the four pillars I showed you in the beginning how we went about solving them from ingest, processing, transformation, prototyping and deployment to serving models. All of that is available on an ops governed framework, which runs on the Rakuten cloud on-prem private cloud solution. It's compatible with pretty much every mainstream X 86 compute available in the world. Dell, hp, SMC, Quanta, Lenovo X Fusion am now going to talk a little bit about what we did with Orange Ivory Coast. So they actually have commercially deployed this solution. It's been running for a of years. They have a data democracy program in Orange, and they were piloting multiple alternatives. When we had an opportunity to talk to them and present, it sounded too good to be true on the demo. So they actually made us do several month long POC on their infrastructure life, and the test was very bizarre at that time.

(33:00):
They said, as long as our end users tell us that their user experience is no different from bare metal, we will go ahead with this. I'll be very honest, that scared us a little bit because it is a cloud platform running with a few layers on top. But we've been running commercially for over two years now because thankfully their end users came out saying, we see no difference in using the platform provided by Rakuten compared to what we are doing. Bare metal. There is probably a difference at the physics level, but it is not noticeable to an end user. But the time that they saved in automation, this is what they have to say about the impact that it made on their AI journey. So we chose Rakuten Telco cloud native platform for our data democracy program to improve our time to market and flexibility.

(33:50):
This was achieved by significantly reducing provisioning time and automating manual operation. The solution has exceeded our expectation, streamlining processes, reducing errors, and allowing us to focus on business outcomes. So that's a little bit about real world, very simple. It's not changing the world, it's not running the network on its own, but it's a starting point and it's a starting point that recognizes realities of the software engineering world, of the physical network world, of what data really needs to, or how data needs to be managed for you to actually have efficiency in your AI journey. That's it for me folks.

Guy Daniels, TelecomTV (34:34):
Fantastic. Thank you. Thank you very much indeed. Come and sit down here for a second Vivek. Round of applause please. Lots to digest there, and we will digest that later. I realize it's break time coming up, but I'm sure we have a question and let's get somebody to part the room. There's one of the far side by looks of it. Can we get the microphone right to the doors? You must get a question in because there was an awful lot in there to digest. Here we go.

Anas Alloush, Deutsche Telekom (35:02):
Cloud native, when started, it started on very clear basis starting from how the application is written, the 12 add factor and so on and so on. And then with a very clear goal to break the ice between dev and ops.

Vivek Chadha, Rakuten Symphony MEA (35:22):
Correct?

Anas Alloush, Deutsche Telekom (35:23):
What are the fundamentals of AI native when you state it like this, from that to this, from application view to what kind of eyes or things? What is the problem that it attacks directly other than just using the models and the AI tools and the agents in a better way? That's understood. But when you say AI native, what is the fundamentals for that?

Vivek Chadha, Rakuten Symphony MEA (35:52):
I think that's a great question. Let me think a second. Two things come to mind. One thing is around, and I'm just referring to you said application. So I'm going to limit the response mainly to the application layer for now. Applications are deterministic today. They're built for a targeted outcome for a set of input rules. If there's computer science folks in the room, it's a state machine effectively, right? You transform from one state to another based on a set of rules. So it's deterministic, which is important because you want predictability in the outcome. Whether it's a positive or a negative, you want to be able to know, my view is genuine. AI native eventually will allow you to have intent, primary objective, determined, but unforeseen or unpredictable use cases also be handled. And by handled, I don't mean delivered all the time because is it is mathematics.

(37:07):
You cannot have in inite probability computed by a piece of software. At least today, I don't know if AGI happens, maybe that will be possible. But compared to where we are today, if that piece of software is able to address an unknown series of circumstances and do one of three things fail gracefully, which is important. A lot of people probably don't think failing gracefully is important, blue screen of death, but that's the technology world. But it has far worse consequences. We've recently seen two major outages. One in the telco world, one in the cloud world. Maybe there'll be a time where this failure is managed a lot more gracefully. So that's one objective I would look for. The second, which is a lot more better for all of us, is for a subset of those unforeseen, unpredictable use cases, it manages to provide a reasonable outcome, not the best outcome, a reasonable outcome.

(38:04):
A reasonable outcome is something that can be solved in time, gives enough value to the recipient of that outcome, even if the recipient comes back after two days or a week or months saying, this is okay, but can I get something better? Because you've solved that immediate need at that time. And the third objective is it knows it can't fail gracefully. Or even if it fails gracefully, there is a sub case there. It definitely could not do the second, it could not provide a reasonable outcome. It then triggers off autonomous process that says, I have detected an anomaly, which I am not able to handle, get ready for it in the future. Whether that means code that is self annealing or morphing, whether it means it creates an agent, which it triggers next time, it faces a similar circumstance. I don't know about that, but to me, add the application layer. And now you can say, I've not used the word infrastructure even once. I've not used DevOps even once. The world is out there, no battle contact, no plan survives, battle contact, no piece of code survives. The real market in finite ai hopefully allows us to do a little bit better in handling the unknowns. I think that's the best way I can answer it for today.

Guy Daniels, TelecomTV (39:27):
Great. Great question. And a well thought out answer. Thank you very much, Vivek. We must leave it there. We need to take a short break, a 25 minute break, and we'll be back here what, 25 minutes time at 4:00 PM sharp for our final sessions. But before we go, a round of applause for Vivek, please. Thank you very much, Vivek. Great.