BraindumpDiscussion on BSS Transformation Roadmap and Digital Integration
Summary:
- The BSS transformation project is advanced and requires careful planning for the phase-out of old applications.
- There is a focus on integrating legacy platforms with new systems to facilitate the migration.
- The applications to be decommissioned are being documented in the enterprise architecture tool, Avacus.
- Current discussions revolve around the TMF API standards and integration challenges with Huawei's solutions.
- Two separate programs are being run: the BSS transformation and the digital fast lane for customer journeys.
- Emphasis is placed on creating a consistent user experience across digital channels and backend systems.
Content:
Are being renewed and the old one being deprecated. Yes. Yes. So is there a roadmap somewhere of how the current applications will be phased out and some might change and some might be not only deprecated and totally be terminated? Yeah, I think that's a very good question, and that is something that we need to start writing down in isolation. Andre and I, we've had a look at the BSS migration. This project is obviously advanced, but it's been approached in a very concise, dare I say, manner, the timeline expectations. So the idea that one would have from a digital transformation or a transformation project, we couldn't really foresee how that would fit into the timelines that was dictated up until now, although it should be treated like that.
In isolation, we had a look at, on the integration side, our legacy platforms, how we can integrate the integration with the new BSS to deprecate all the solutions, and we're running into trouble there. But in terms of the program, what the roadmap is of migrating off of the old MDOT-based platform and migrating to Huawei, that is a very specific question. I think we need to plan as part of that project. Selena? So, Gomers, we have an application portfolio that is being sustained in our enterprise architecture tool, Avacus, and on the tool we have a lifecycle stage where we indicate what the next stage of a specific application will be.
And as soon as we have all the components of this BSS transformation verified, they will be indicated there as to which ones will be deprecated, et cetera. As in, do you have an idea when the MDOC will be able to be terminated? That is a difficult question in terms of timing. So that's still to be planned. Yeah, so that is still part of the current planning. It hasn't been planned thoroughly yet. Okay. Okay. And to that extent, for example, when will CMSS disappear as a solution? The answer is probably somewhere within the scope of the BSS transformation.
I don't think we can just have a question. We don't have a timeline, yeah. Correct. Okay. Understood. Yeah, and then Gomers, with regards to the applications that will be decommissioned, so I've placed that on the chat. Again, that is part of the current application inventory that was provided to you. It does say as well on the state that it will be decommissioned, but this is the list of the application from an MDOC perspective that are being used as well. Yes, yes. Okay. Thank you. So what we've realized also since the initial discussion, we started to understand there's a phase 1, there's a phase 2, well, there's a 1.1 and a 1.2.
I didn't see anything further. And it looks like there is a lot to happen between 1.1 and 1.2 in terms of Huawei that needs to provide you with some deliverables to close the gaps on standards. Is that a correct understanding? Are you imposing a lot of your requirements on standards that they must deliver in 1.2? What specifically do you refer to when you talk about standards, Gomers? I see what I saw on some of the stuff is like open APIs, TM forum document references that they gave, and that's all only in a later phase. So we obviously initially stated that that will be our objectives.
Not necessarily all of those are available, and maybe not all of them will be achieved at the end of the transformation, but we will have a set of TMF APIs. So just to give you an idea as a principle, what we are adopting is out-of-the-box APIs, for example, from Huawei, from a BSS that is out-of-the-box SOAP over HTTP, specifically the new services to our third parties. We're going to, to the best of our ability, transform them and expose them as TM forum APIs, although the out-of-the-box is SOAP over HTTP. So we, as a principle, try as much as possible to adopt the TM forum API standard as all the new standards.
So what are the biggest gaps that need to be closed from Huawei that will be aligning to your standards? Gap is a dangerous word. What do you mean by gap? I mean not conforming to the state that TM forum standards that you were asking for. But even that's a loaded question because although the body specifically alluded to TM forum being a preferred principle, they are exposing it, but like I said, the bulk of the out-of-the-box APIs, according to them and the industry, would be SOAP over HTTP. I can't answer the question on their behalf why they are not exposed as TM forum, but given with that, we're literally saying we will transform and expose them ourselves to our clients as TM forum APIs.
But Gombas, fundamentally, what we also need to do, we approach them, we ask them for their solution, and we have stated the 80-20 customization principle that we will only customize up to 20% and no more. So that is the state of the nation as we start this project. Okay, that's very sensible. And I think that's important. Yes, yes, but that's a very important statement to understand what that agreement was. Will you therefore allow Huawei to bypass some of the standards in that 80-20 principle you will allow and you will know which ones you decided to live with?
Yes, as far as they are available and visible to us. Yeah, so Gombas, there's an architecture review forum that takes place weekly, and we also have the governance forum and the design authority. So all architecture topics are discussed with them to make sure alignment and where possible, there's also pushback from our side. And where it's not possible, then that's that deviation or that exception that also gets noted. But these are being discussed on an ongoing basis, and they are formally documented in the decision logs as well for maybe later review where there were gaps identified, but the ones that can be addressed now will be addressed now.
So the design authority will be the decision-making body on what is acceptable and what is not? Yes, it is. And besides that as well, again, we also have a text here as well so that whenever there's things that cannot be resolved or there's no consensus, they then get escalated there as well. Okay, so we will check that the deliveries then conform to what your decisions are. Is that a testing process? Who checks conformance when Huawei finally delivers? So yeah, testing is one of them as well. And also, I guess, from our side, there is that architecture review that we then do in collaboration with our colleagues then, for instance, development, to check those compliance to the standards that we've provided as well.
I mean, if Andre doesn't say I'm getting SOAP HTTP instead of an API, nobody will know that they're not delivering a REST API to you. So far, Andre was saying. Yes, so that's the point. It needs to tell you when it conforms to what you expect. So that's not only a tester, that's also all the teams that needs to integrate to the BSS. One, okay, thank you. That's, I think, that's almost what we had on the list. I want to just have one other question about the scope. As we started to understand the scope, it is clear that the focus of the migration is a big focus on the system of record and a convergence of a lot of the core systems rather than the front-end journeys.
But for every single one, no. Okay, expand on that, please. No, like I said, not every API is a TM forum API. Not every service is TM forum capable. Yes, correct. That's the point I'm making. Okay, but from a migration point of view, what I'm trying to get to is understand the scope from this Amdoc CRM, this OMS, this ABP platform, this service management, and that's going to go into what is the focus of Huawei BSS as a converged platform. What I'm trying to get to is that from that scope that I'm seeing, it's more focused on that core rather than the digital front-end journey.
So my question is, do you have a plan, a separate plan, that will focus on the customer journeys, the digital customer journey that will be enabled by this, or am I talking about something that's going to come with one? So we are actually running two programs at the same time, Corvus. So whilst there is a BSS transformation program, there is a digital fast lane program that is focusing on the digital channels. So the customer journeys are continuously being updated and upgraded and enhanced and changed on there whilst the BSS transformation is happening. And as we start with the unassisted journeys, the self-service journeys together with the BSS transformation, we will establish the integration between the BSS space and those channels.
Is that a separate program that runs, or is that just in the line with CRs or so? The digital fast lane is a separate program, and then the actual integration of the channels with the BSS transformation program will probably happen as components of the program, maybe as projects by themselves. Okay, yeah, we talked about demand management this morning. I saw the digital fast lane there. Yes. Okay. Okay, that was my questions. I said this will be quick. Jako, anything else from your side? Thanks. Okay, I think then we quicken done. Nobody else? Oh, there's a hand up.
Tabu? Yeah, Corvus, if you were to suggest to us, propose a mechanism to check compliance with regards to what was the ask from us that they need to be TM forum compliant and to check that they are actually complying, how would you go about from your end if you were to suggest something? What would be the mechanism to follow to ensure that that compliance and not getting relying on Andre to say, yes, it is compliant there? Well, API is a published mechanism. You can look into an API and run a compare on it. That's not difficult when you have access to it.
It's quite easy to see what is available on an API. I'm just thinking that many times when a vendor delivers, we don't see what is actually delivered unless you talk to the technical person that is consuming that service. Then you really know what is in there. So it's a practical check, but it shouldn't be difficult. Yongama, your hand is up. Thanks, Thomas. I guess you answered. Yes, no, it's fine. You can come to it. Thanks. And yes, Thomas, since the day and maybe even days before, right, and I'm not sure, I joined a bit late, but I think maybe it wasn't that late, about five minutes.
I'm not sure if we had gotten to a point where, because you, I think you every now and then would ask about rumors that we were talking specifically about Dixie, but I think even before that there were other engagements, the questions about what we're doing about the, around the layer above between the digital channels and ESP. And I don't know, and I think we touched briefly on it yesterday to say, you've been asked specifically what the impacts would be based on the BSS transformation. So my question is whether, I don't know what has been shared, but has that been answered now that we are specifically talking to the architecture and integration impacting BSS?
I think so, yes. I think the picture that we have is what Serena called the digital fast lane. What we've covered in detail yesterday was more the focus on Dixie and Kamunda and how that is being used. The other thing I just heard is what she's saying is that I don't think there's a grand plan unless you can correct me, but there are, the process is the digital fast lane in combining with what is happening as BSS. Program is changing. Are there other efforts on the digital side that we need to know about? Do you know about the work on the WhatsApp channels and the digital care side?
Yes, that was mentioned, yes. I don't think we have the detail on that, but I don't think the scope is to go down to a level of function by function. Okay, and maybe just, sorry, Yongama, you were still with a question. Do you want to paint a picture of what is happening in digital care as an architecture focus? I don't think it's necessary at a detailed level, but just in terms of your comment about a grand plan, there actually is a grand plan. The grand plan is we need to get off of our old legacy BSS stacks.
The grand plan is that we need to engage digitally in all aspects, and the grand plan is that we are able to access all information from any channel without any boundaries being set by an application or a suite of applications. The aspect of the plan that is missing is the actual timing when we will be able to do that. So we know now that we are busy with one part to replace the CMSS component of the legacy and next to replace the NGN component of the legacy, and we are now slowly but surely starting to see the timelines for that materialize.
So the program dates will come up as the program evolves, actually? Yes, as we confirm and negotiate with the vendor in terms of the timelines, that will become more solid. Okay. Good. Thank you. Sorry, Yongama, I came in the middle of your question. Did you finish your question? Well, based on Copper's response that it's aligned against CSI, for example, those option ones, two, three, and whatever that we've internally been discussing, and I think there's one we're going for at the moment, I thought those were the kind of things that would have been covered and then to be able to then give some of the questions that people... I haven't seen those options, Yongama.
But do you want to paint a picture of what is happening in digital care as an architecture focus? I don't think it's necessarily at a detailed level, but just in terms of your comment about a grand plan, there actually is a grand plan. The grand plan is we need to get off of our old legacy BSS stacks. The grand plan is that we need to engage digitally in all aspects, and the grand plan is that we are able to access all information from any channel without any boundaries being set by an application or a suite of applications.
The aspect of the plan that is missing is the actual timing when we will be able to do that. So we know now that we are busy with one part to replace the CMSS component of the legacy and next to replace the NGN component of the legacy, and we are now slowly but surely starting to see the timelines for that materialize. So the program dates will come up as the program evolves, actually. Yes, as we confirm and negotiate with the vendor in terms of the timelines, that will become more solid. Good. Thank you. Sorry, Yongama, I came in the middle of your question.
Did you finish your question? Well, based on Copper's response that it's aligned against CSAT, for example, those option ones, two, or three, and whatever that we've internally been discussing, and I think there's one we're going for at the moment, I thought those were the kind of things that would have been covered and then to be able to then give some of the questions that people... I haven't seen those options, Yongama. But do you want to paint a picture of what is happening in digital care? We are currently working on the optimization of the digital engagement space as it's part of a lifecycle, infrastructure lifecycle replacement focus that is started off, and it's expanded, and it now includes looking at the whole space where portal and backends play, particularly Dixie and the ePortal space, and we're looking at the different components there and how to become more lean and mean in that space and not have too many different technologies playing there, different DevSecOps practices, etc. Yes, so that is very important because the whole assessment is a little focus, and we did go quite detailed yesterday about Dixie and the role it's playing, so your future direction there on that is very important.
Okay, so you must just say at what level of information do you want to discuss around that, and then we can set up something. Yeah, so I don't think we need to go maybe diagram level, but we would like to understand what is that future view that you are moving to for the digital channels. We touched yesterday on backends for frontends and whether that's a platform that you're going to implement and whether you're going to attach channels to that or what is that direction that you view you're going to take on the digital frontends. So do you want to discuss it now or do you maybe want to set up a separate session?
Yes, if we can, let's go ahead. We have the time now. Okay, sure. I don't know if everybody from the integration team also wants to stay online, but it's up to you because they may not be interested in that. I would wave you goodbye. Okay, thanks, Andre. Okay, shall I just quickly share a slide with you, a slide or two? So I don't want to go too deep on what we did yesterday on Dixie and then we miss the other picture that you have, so it's better if we can share that. Okay, so let me just make this a little bit.
So we are focusing on the digital layers and we're following a reference architecture that specifically highlights the experience layer as a governing capability that sits horizontally across the digital channel handling layer, the customer engagement layer, decoupling and integration, as well as the backends. And for this particular layer, I'll just maybe expand on, this is not a product or a team, it's a capability and definitely a set of different capabilities that needs to be governed very tightly. It focuses on identity decisioning, the journeys, content and learning as the five primary domains where it focuses on. And it also has a number of specific guidelines that guides and governs how projects that operate in the space should be or what they should adhere to in order for us to achieve a common user experience because one of our key issues is that we're not achieving a common user experience.
And now the problem seems to be that we need to be consolidating, but obviously consolidation only brings you so far because you do need unique channel interactions. Therefore, you do need unique backends to support the specific frontends that perform specific functions for the users. So those backends to support specific frontends, do you see them as separate systems? Are you looking for a form to handle them? No, at the moment we're not looking for a platform to handle those. We have quite a lot of platforms in that space already, depending on your exact definition of a platform, but we have various capabilities, some more mature than others, various very good and very experienced teams that sit in that space.
So our current focus is to look at what is there and create a set of guidelines that will guide the implementation, because, for example, you would look maybe at the Dixie space, and each application developer will deploy caching in their component or their microservice that they are developing, because the guideline and or the deployment at a server level did not actually deploy caching in such a way that the developer does not have to think about that, just as a simple example. So we need to establish the architecture of the service in such a way that everything that is required and everything that needs to be consistent and everything that needs to be immaterial to the developer to put in place, that that is established and is managed.
And that would be the key focus for this space. So initially, the first step will be to actually make sure that we have the necessary infrastructure in place, and then we will be migrating the Dixie capabilities and the portal capabilities into this infrastructure with the established necessary application servers and all of the standards that is being developed in that space so that we can say now we have a future-proof set of portals and backends that sustain a consistent user experience. Okay. Thank you. Anybody else? Yongama, are you happy that we've covered that part? Yes, I'm happy if you are.
Thanks, Kobus. Thanks, Serena. Okay. I think then we are done. Thanks, Serena. That was a good quick call-up. Cool. All right, then I think we're done. Thank you, everybody. Thanks, Blessing, for your arrangement. Thank you, everybody. Bye-bye. Thank you. Bye. Thanks.
- The BSS transformation project is advanced and requires careful planning for the phase-out of old applications.
- There is a focus on integrating legacy platforms with new systems to facilitate the migration.
- The applications to be decommissioned are being documented in the enterprise architecture tool, Avacus.
- Current discussions revolve around the TMF API standards and integration challenges with Huawei's solutions.
- Two separate programs are being run: the BSS transformation and the digital fast lane for customer journeys.
- Emphasis is placed on creating a consistent user experience across digital channels and backend systems.
Content:
Are being renewed and the old one being deprecated. Yes. Yes. So is there a roadmap somewhere of how the current applications will be phased out and some might change and some might be not only deprecated and totally be terminated? Yeah, I think that's a very good question, and that is something that we need to start writing down in isolation. Andre and I, we've had a look at the BSS migration. This project is obviously advanced, but it's been approached in a very concise, dare I say, manner, the timeline expectations. So the idea that one would have from a digital transformation or a transformation project, we couldn't really foresee how that would fit into the timelines that was dictated up until now, although it should be treated like that.
In isolation, we had a look at, on the integration side, our legacy platforms, how we can integrate the integration with the new BSS to deprecate all the solutions, and we're running into trouble there. But in terms of the program, what the roadmap is of migrating off of the old MDOT-based platform and migrating to Huawei, that is a very specific question. I think we need to plan as part of that project. Selena? So, Gomers, we have an application portfolio that is being sustained in our enterprise architecture tool, Avacus, and on the tool we have a lifecycle stage where we indicate what the next stage of a specific application will be.
And as soon as we have all the components of this BSS transformation verified, they will be indicated there as to which ones will be deprecated, et cetera. As in, do you have an idea when the MDOC will be able to be terminated? That is a difficult question in terms of timing. So that's still to be planned. Yeah, so that is still part of the current planning. It hasn't been planned thoroughly yet. Okay. Okay. And to that extent, for example, when will CMSS disappear as a solution? The answer is probably somewhere within the scope of the BSS transformation.
I don't think we can just have a question. We don't have a timeline, yeah. Correct. Okay. Understood. Yeah, and then Gomers, with regards to the applications that will be decommissioned, so I've placed that on the chat. Again, that is part of the current application inventory that was provided to you. It does say as well on the state that it will be decommissioned, but this is the list of the application from an MDOC perspective that are being used as well. Yes, yes. Okay. Thank you. So what we've realized also since the initial discussion, we started to understand there's a phase 1, there's a phase 2, well, there's a 1.1 and a 1.2.
I didn't see anything further. And it looks like there is a lot to happen between 1.1 and 1.2 in terms of Huawei that needs to provide you with some deliverables to close the gaps on standards. Is that a correct understanding? Are you imposing a lot of your requirements on standards that they must deliver in 1.2? What specifically do you refer to when you talk about standards, Gomers? I see what I saw on some of the stuff is like open APIs, TM forum document references that they gave, and that's all only in a later phase. So we obviously initially stated that that will be our objectives.
Not necessarily all of those are available, and maybe not all of them will be achieved at the end of the transformation, but we will have a set of TMF APIs. So just to give you an idea as a principle, what we are adopting is out-of-the-box APIs, for example, from Huawei, from a BSS that is out-of-the-box SOAP over HTTP, specifically the new services to our third parties. We're going to, to the best of our ability, transform them and expose them as TM forum APIs, although the out-of-the-box is SOAP over HTTP. So we, as a principle, try as much as possible to adopt the TM forum API standard as all the new standards.
So what are the biggest gaps that need to be closed from Huawei that will be aligning to your standards? Gap is a dangerous word. What do you mean by gap? I mean not conforming to the state that TM forum standards that you were asking for. But even that's a loaded question because although the body specifically alluded to TM forum being a preferred principle, they are exposing it, but like I said, the bulk of the out-of-the-box APIs, according to them and the industry, would be SOAP over HTTP. I can't answer the question on their behalf why they are not exposed as TM forum, but given with that, we're literally saying we will transform and expose them ourselves to our clients as TM forum APIs.
But Gombas, fundamentally, what we also need to do, we approach them, we ask them for their solution, and we have stated the 80-20 customization principle that we will only customize up to 20% and no more. So that is the state of the nation as we start this project. Okay, that's very sensible. And I think that's important. Yes, yes, but that's a very important statement to understand what that agreement was. Will you therefore allow Huawei to bypass some of the standards in that 80-20 principle you will allow and you will know which ones you decided to live with?
Yes, as far as they are available and visible to us. Yeah, so Gombas, there's an architecture review forum that takes place weekly, and we also have the governance forum and the design authority. So all architecture topics are discussed with them to make sure alignment and where possible, there's also pushback from our side. And where it's not possible, then that's that deviation or that exception that also gets noted. But these are being discussed on an ongoing basis, and they are formally documented in the decision logs as well for maybe later review where there were gaps identified, but the ones that can be addressed now will be addressed now.
So the design authority will be the decision-making body on what is acceptable and what is not? Yes, it is. And besides that as well, again, we also have a text here as well so that whenever there's things that cannot be resolved or there's no consensus, they then get escalated there as well. Okay, so we will check that the deliveries then conform to what your decisions are. Is that a testing process? Who checks conformance when Huawei finally delivers? So yeah, testing is one of them as well. And also, I guess, from our side, there is that architecture review that we then do in collaboration with our colleagues then, for instance, development, to check those compliance to the standards that we've provided as well.
I mean, if Andre doesn't say I'm getting SOAP HTTP instead of an API, nobody will know that they're not delivering a REST API to you. So far, Andre was saying. Yes, so that's the point. It needs to tell you when it conforms to what you expect. So that's not only a tester, that's also all the teams that needs to integrate to the BSS. One, okay, thank you. That's, I think, that's almost what we had on the list. I want to just have one other question about the scope. As we started to understand the scope, it is clear that the focus of the migration is a big focus on the system of record and a convergence of a lot of the core systems rather than the front-end journeys.
But for every single one, no. Okay, expand on that, please. No, like I said, not every API is a TM forum API. Not every service is TM forum capable. Yes, correct. That's the point I'm making. Okay, but from a migration point of view, what I'm trying to get to is understand the scope from this Amdoc CRM, this OMS, this ABP platform, this service management, and that's going to go into what is the focus of Huawei BSS as a converged platform. What I'm trying to get to is that from that scope that I'm seeing, it's more focused on that core rather than the digital front-end journey.
So my question is, do you have a plan, a separate plan, that will focus on the customer journeys, the digital customer journey that will be enabled by this, or am I talking about something that's going to come with one? So we are actually running two programs at the same time, Corvus. So whilst there is a BSS transformation program, there is a digital fast lane program that is focusing on the digital channels. So the customer journeys are continuously being updated and upgraded and enhanced and changed on there whilst the BSS transformation is happening. And as we start with the unassisted journeys, the self-service journeys together with the BSS transformation, we will establish the integration between the BSS space and those channels.
Is that a separate program that runs, or is that just in the line with CRs or so? The digital fast lane is a separate program, and then the actual integration of the channels with the BSS transformation program will probably happen as components of the program, maybe as projects by themselves. Okay, yeah, we talked about demand management this morning. I saw the digital fast lane there. Yes. Okay. Okay, that was my questions. I said this will be quick. Jako, anything else from your side? Thanks. Okay, I think then we quicken done. Nobody else? Oh, there's a hand up.
Tabu? Yeah, Corvus, if you were to suggest to us, propose a mechanism to check compliance with regards to what was the ask from us that they need to be TM forum compliant and to check that they are actually complying, how would you go about from your end if you were to suggest something? What would be the mechanism to follow to ensure that that compliance and not getting relying on Andre to say, yes, it is compliant there? Well, API is a published mechanism. You can look into an API and run a compare on it. That's not difficult when you have access to it.
It's quite easy to see what is available on an API. I'm just thinking that many times when a vendor delivers, we don't see what is actually delivered unless you talk to the technical person that is consuming that service. Then you really know what is in there. So it's a practical check, but it shouldn't be difficult. Yongama, your hand is up. Thanks, Thomas. I guess you answered. Yes, no, it's fine. You can come to it. Thanks. And yes, Thomas, since the day and maybe even days before, right, and I'm not sure, I joined a bit late, but I think maybe it wasn't that late, about five minutes.
I'm not sure if we had gotten to a point where, because you, I think you every now and then would ask about rumors that we were talking specifically about Dixie, but I think even before that there were other engagements, the questions about what we're doing about the, around the layer above between the digital channels and ESP. And I don't know, and I think we touched briefly on it yesterday to say, you've been asked specifically what the impacts would be based on the BSS transformation. So my question is whether, I don't know what has been shared, but has that been answered now that we are specifically talking to the architecture and integration impacting BSS?
I think so, yes. I think the picture that we have is what Serena called the digital fast lane. What we've covered in detail yesterday was more the focus on Dixie and Kamunda and how that is being used. The other thing I just heard is what she's saying is that I don't think there's a grand plan unless you can correct me, but there are, the process is the digital fast lane in combining with what is happening as BSS. Program is changing. Are there other efforts on the digital side that we need to know about? Do you know about the work on the WhatsApp channels and the digital care side?
Yes, that was mentioned, yes. I don't think we have the detail on that, but I don't think the scope is to go down to a level of function by function. Okay, and maybe just, sorry, Yongama, you were still with a question. Do you want to paint a picture of what is happening in digital care as an architecture focus? I don't think it's necessary at a detailed level, but just in terms of your comment about a grand plan, there actually is a grand plan. The grand plan is we need to get off of our old legacy BSS stacks.
The grand plan is that we need to engage digitally in all aspects, and the grand plan is that we are able to access all information from any channel without any boundaries being set by an application or a suite of applications. The aspect of the plan that is missing is the actual timing when we will be able to do that. So we know now that we are busy with one part to replace the CMSS component of the legacy and next to replace the NGN component of the legacy, and we are now slowly but surely starting to see the timelines for that materialize.
So the program dates will come up as the program evolves, actually? Yes, as we confirm and negotiate with the vendor in terms of the timelines, that will become more solid. Okay. Good. Thank you. Sorry, Yongama, I came in the middle of your question. Did you finish your question? Well, based on Copper's response that it's aligned against CSI, for example, those option ones, two, three, and whatever that we've internally been discussing, and I think there's one we're going for at the moment, I thought those were the kind of things that would have been covered and then to be able to then give some of the questions that people... I haven't seen those options, Yongama.
But do you want to paint a picture of what is happening in digital care as an architecture focus? I don't think it's necessarily at a detailed level, but just in terms of your comment about a grand plan, there actually is a grand plan. The grand plan is we need to get off of our old legacy BSS stacks. The grand plan is that we need to engage digitally in all aspects, and the grand plan is that we are able to access all information from any channel without any boundaries being set by an application or a suite of applications.
The aspect of the plan that is missing is the actual timing when we will be able to do that. So we know now that we are busy with one part to replace the CMSS component of the legacy and next to replace the NGN component of the legacy, and we are now slowly but surely starting to see the timelines for that materialize. So the program dates will come up as the program evolves, actually. Yes, as we confirm and negotiate with the vendor in terms of the timelines, that will become more solid. Good. Thank you. Sorry, Yongama, I came in the middle of your question.
Did you finish your question? Well, based on Copper's response that it's aligned against CSAT, for example, those option ones, two, or three, and whatever that we've internally been discussing, and I think there's one we're going for at the moment, I thought those were the kind of things that would have been covered and then to be able to then give some of the questions that people... I haven't seen those options, Yongama. But do you want to paint a picture of what is happening in digital care? We are currently working on the optimization of the digital engagement space as it's part of a lifecycle, infrastructure lifecycle replacement focus that is started off, and it's expanded, and it now includes looking at the whole space where portal and backends play, particularly Dixie and the ePortal space, and we're looking at the different components there and how to become more lean and mean in that space and not have too many different technologies playing there, different DevSecOps practices, etc. Yes, so that is very important because the whole assessment is a little focus, and we did go quite detailed yesterday about Dixie and the role it's playing, so your future direction there on that is very important.
Okay, so you must just say at what level of information do you want to discuss around that, and then we can set up something. Yeah, so I don't think we need to go maybe diagram level, but we would like to understand what is that future view that you are moving to for the digital channels. We touched yesterday on backends for frontends and whether that's a platform that you're going to implement and whether you're going to attach channels to that or what is that direction that you view you're going to take on the digital frontends. So do you want to discuss it now or do you maybe want to set up a separate session?
Yes, if we can, let's go ahead. We have the time now. Okay, sure. I don't know if everybody from the integration team also wants to stay online, but it's up to you because they may not be interested in that. I would wave you goodbye. Okay, thanks, Andre. Okay, shall I just quickly share a slide with you, a slide or two? So I don't want to go too deep on what we did yesterday on Dixie and then we miss the other picture that you have, so it's better if we can share that. Okay, so let me just make this a little bit.
So we are focusing on the digital layers and we're following a reference architecture that specifically highlights the experience layer as a governing capability that sits horizontally across the digital channel handling layer, the customer engagement layer, decoupling and integration, as well as the backends. And for this particular layer, I'll just maybe expand on, this is not a product or a team, it's a capability and definitely a set of different capabilities that needs to be governed very tightly. It focuses on identity decisioning, the journeys, content and learning as the five primary domains where it focuses on. And it also has a number of specific guidelines that guides and governs how projects that operate in the space should be or what they should adhere to in order for us to achieve a common user experience because one of our key issues is that we're not achieving a common user experience.
And now the problem seems to be that we need to be consolidating, but obviously consolidation only brings you so far because you do need unique channel interactions. Therefore, you do need unique backends to support the specific frontends that perform specific functions for the users. So those backends to support specific frontends, do you see them as separate systems? Are you looking for a form to handle them? No, at the moment we're not looking for a platform to handle those. We have quite a lot of platforms in that space already, depending on your exact definition of a platform, but we have various capabilities, some more mature than others, various very good and very experienced teams that sit in that space.
So our current focus is to look at what is there and create a set of guidelines that will guide the implementation, because, for example, you would look maybe at the Dixie space, and each application developer will deploy caching in their component or their microservice that they are developing, because the guideline and or the deployment at a server level did not actually deploy caching in such a way that the developer does not have to think about that, just as a simple example. So we need to establish the architecture of the service in such a way that everything that is required and everything that needs to be consistent and everything that needs to be immaterial to the developer to put in place, that that is established and is managed.
And that would be the key focus for this space. So initially, the first step will be to actually make sure that we have the necessary infrastructure in place, and then we will be migrating the Dixie capabilities and the portal capabilities into this infrastructure with the established necessary application servers and all of the standards that is being developed in that space so that we can say now we have a future-proof set of portals and backends that sustain a consistent user experience. Okay. Thank you. Anybody else? Yongama, are you happy that we've covered that part? Yes, I'm happy if you are.
Thanks, Kobus. Thanks, Serena. Okay. I think then we are done. Thanks, Serena. That was a good quick call-up. Cool. All right, then I think we're done. Thank you, everybody. Thanks, Blessing, for your arrangement. Thank you, everybody. Bye-bye. Thank you. Bye. Thanks.