Amdocs Integration Services

Very pleased to say we've got another very interesting case study now. We're going to look at how you can go from a monolithic legacy system to a cloud based digital platform and we're going use the example of a transformation that happened when both of our next two guests were working at Sprint. So please welcome Meg Nouth from T Mobile USA and Joshua Koenig from Amdocs. Hello. Morning, Thank you for joining. I'm really excited about our fireside chat here. Too bad I have a little bit of a fiery background, but this is the work. So we've been through a full transformation together, and we are going through another one now at T Mobile. So we've got quite a history between my group and your groups. And so I just have a few questions to kind of set the base and let people understand kind of what we've been through. So let's think back three years ago when we started and we were coming into the transformation that was recently completed. What were kind of the main concepts in your opinion of that transformation? What was trying to be achieved there? What were the main concepts behind that? I'll get to that in one second, but first, I would be remiss if I didn't offer you congratulations on Sloan's birth. So Josh became a four time dad on Friday, and it's really important to acknowledge that for a couple of reasons. First of all, it's a great accomplishment. But second of all, Josh talked about the fact we've worked together for a number of years. And one of the things that we'll get to in terms of what are some of the key success factors is, comes down to relationships and really knowing people as people. It's a relationship you need to have with your supplier like Amdocs. It's also the relationship you need to have with your business partners because this is not for the faint of heart. And if we don't know people as people and really invest ourselves in each other, it makes the work just that much harder to do. Would you agree, Josh? Oh, absolutely. Being there in the box and in the battle, so to speak, you know, it really does make it it makes it easier to work together when you're really, you know, in it for the same reasons and you have the same, you know, end goal. It's amazing how well you can start to build that relationship and everybody's marching the same tune. And it goes quickly beyond the professional into the more personal and, you know, just like today, you know, first thing you mentioned is the fact that I had a baby. That's definitely not professional. That's personal. And But that's just kind of a very good example of the way the relationships have formed between our companies and our groups. Exactly. And so to get to your previous question, those relationships are instrumental in achieving the goals. I doubt there's a speaker at this conference that's not going to talk about wanting an amazing customer experience, faster speeds to market, and lower costs. I'd be shocked if that doesn't come up in every single presentation, but as we all know, getting there is really tricky because you're juggling a lot of different goals and objectives, and what's important is really to understand where each person or group is coming from so that you can work together to create win win solutions, and using iPASS, which Josh and I are going to talk about a lot here, is one of those ways that instead of forcing trade offs between great customer experiences and change in the back end, we use this product to act as an isolation layer and a translation layer to enable us to both achieve great experiences at the same time that we did quite a transformation behind the scenes. Kept that invisible from our customers so that we could achieve more and jointly meet our goals. Yeah, I think, you know, that's that's one of the things is, you know, when you come into these transformations, you have, you know, the new stack, you have the legacy stack, and they still have to work together. And that's where really the, you know, something like an iPass can really be of value. And we learned a lot from our side as we, you know, basically learned what we learned, you know, working with you. And we started to build that into our product roadmap and things that were gaps are no longer gaps because over three years, we were able to develop this roadmap to cover those gaps. And a lot of that is the way we work back and forth. And you guys helped us understand the gaps. And then we were able to go and try to remediate those and that, you know, that this helped improve things along the way. So, you know, one of the things was, you know, let's talk about that integration in general. What we're, you know, obviously when you're going into a transformation, there's a lot to worry about from the business aspect, you know, how they're going to react and their processes and things like that and how the legacy in the back end are going to be able in the new stack, I mean, are going to be able to work together. What were some of your main concerns coming into it? And how do you think we were able to overcome some of those? Great question, Josh. The biggest concern that our partners faced and that we faced was, Oh my goodness, are we looking at a flash cut? Are we looking at swallowing the whole elephant at once? And that's overwhelming to anyone. So one of the first things that we sat down and worked with you and others on is, how can we phase things in and how can we make the impact smaller so that we can all focus in on subsets of whether it be customers or transactions, and then evolve it as we go so that we can build a base, but we're not trying to solve World Home Girl at the same time. And I think that's a big part of what we did with this product, was internally we nicknamed it the switch, which I don't know if you like that nickname or not, Josh, but what the switch enabled us to do was it enabled us to take subsets of customers and subsets of transactions and move just that subset over to the target state platform at a time, and that had a lot of benefits, not only to the business in terms of being able to minimize the overarching impact and to be really refined in operational processes around that smaller subset, but it also has huge testing benefits. When you can isolate what your change is, You can focus your testing efforts and and focus your, deployment efforts in that space, and respond just that much faster to to anything that, that bubbles up. Yeah, absolutely. And one of things, so I want to jump back to talk about the partnership and stuff like that. And so one of the things that we did that was different for us, and I'm not sure if it was different for you at the time, but we went to a co development setup, you know, and that was something that we learned a lot from the Amdoc side. I talked earlier about how we kept evolving our platform and our service around integration. But that co development helped us a tremendous amount and how to better work directly with a client. Love to get your perspective on co development. And I know we're going to, you know, my guess is you like it because we're going to start we're talking about that now in mobile and how we're working together very closely again. So I'd love to get your perspective on co development, what you think well with that and if there's any drawbacks to it as well that you can see. I think Ralph even alluded to it a little bit in the presentation before us, where when you can really break down all those silos and let everyone be on small teams together and work literally elbow to elbow and not just hand requirements, you know, over the wall or over the ocean as it might be, but really actually co develop the requirements, develop the designs, and then the solutions can move so much faster. And you can also take even more advantage of folks working around the globe, all the different time zone changes, etc. The efficiency factor just goes up tremendously. Yeah. From our side, what we've seen in the past where it's, you know, here's your requirement, go do it. And then you didn't get that right. And it can create that animosity almost where it's hard to become that true partnership where everybody's together. We found that that was definitely averted with this type of codevelopment where we're in it together. We're always in sync. I think that's a key piece is that being in sync. And if something's not quite right, from what we understand, it's not like we have to go back to a formal process. It's literally look to the guy to my right or my left, say, hey, here's what we think is going on. So we recommend what you guys' thoughts, what do you recommend? And it was amazing how that really created that partnership. And I thought that was amazing. I think that's a great model to work in general from our side. And I think it's, you know, seems, you know, same from your side. You guys see the same type of benefits. So yeah, I think that was really great. And I think that's something that I think will be coming more and more popular in our industry in general for stuff like this, because it just allows you to get away from that. Here's your requirement. Go do it. No, you don't do it right. There's gaps and finger pointing, you know, that really can start eliminating some of that. And that's probably some of the biggest pain points in a transformation, at least ones I've been involved in the past that were avoided here. And so I think that's a I really like that model in general. I completely agree with Josh. Thing to add to that real quick is by doing codevelopment, not only were we not handing requirements over the wall, but we were also explaining the why. I found that really powerful. When the entire team understood the why we were doing something, it was amazing how many more creative solutions came, were broached and discussed as a joint team. Yeah. Yeah. I mean, that really it, you know, when we're getting explained the why and we're in it, you know, it basically enables us now to become that partner instead of just that vendor. And I think, yeah, that goes pretty awesome. So so let's let's fast forward a little bit. Right? So we we made it through a transformation. It went well. We still like each other, you know, so that's a good piece of this whole thing, right? So now let's jump forward. So we're in T Mobile now and we're doing, you know, there's a merger happening and there's a whole IT transformation happening there. And we have iPass there again. So what do you see as the integration platform we bring to bear when we're considering the merger and acquisition between T Mobile, Sprint and the new stack coming in? What do you see that the real value that will be of iPass coming into this new world? Great question. We're still evaluating some of the options and alternatives, but what I would initially tell you, I can identify as potential value blocks is, first of all, using the translation capabilities that iPass brings, or as AAML, as I still love to call it, and I know it drives you bonkers, can't get with the new branding yet. Definitely, we'll be using that translation layer capability so that we can talk from one data model to the other data model, And we'll also be leveraging, again, that switch capability I referred to earlier, because we don't want to do a big bang with conversion either. The more we can isolate what's going on in the IT shop and all that change from our customers and our business partners, the happier everyone is, frankly, because it enables IT then to position themselves to be more agile and to move more rapidly with change, but yet not put all the burden of that change back on the business and on the customers to absorb. Yep, yep, absolutely. You know, just talking, you know, the business aspect of the IT transformation, right? So a lot of times we see that the business aspect gets missed. And that's something we try to account for with iPass is, you know, follow-up management, things like that. You know, what are some, you know, in your history here, what are some of the things that you have seen as a major impact for business that's not normally accounted for when an IT transformation happens? And, you know, what are kind of the plan to start accounting for those in the future? I think one of the biggest things that we kind of tend to fall in a rut of collectively is we try to optimize what we already have. And it's really important to have that great business partnership so that you know where the business is wanting to be three and five and ten years out so that you're building your infrastructure and your processes and capabilities toward the future so that, as technology partners, we're already capability rich and ready before the business comes forth with projects. So it's a part of kind of restructuring how visioning happens and how road mapping happens such that we don't burden the business with constantly asking for projects for onesie, twosie, or point solutions, but rather becoming a very feature rich shop that's tied in with their future visions. Yeah, yeah, definitely. You know, in kind of my experience, we're starting to see this new setup where you have your partners are in the same room. Sometimes it's multiple partners, not just one partner. And then you have your IT teams, you have your business teams, you have your liaison teams, you have your marketing teams. We're starting to see that slowly come together where people are all in the same room when it comes to transformation. Are you seeing that from your side? Are you guys starting to maybe take on some of those that philosophy of bringing everybody to the table upfront? Or is it still kind of start the process and then bring them in eventually? Or how are guys doing it now at T Mobile? Well, starts with the visioning process. So we're doing a lot of road mapping, and we're spending a lot of time on where do we want to be, excuse me, I've got quite a thunderstorm behind me, three and five years out. And then when it comes to the actual work efforts itself, as we begin to go through the development cycle, Then we're bringing the teams, to your point, the business teams to the table with us to make sure that what we're hearing is correct, and probably most importantly, that we're taking into account all the operational aspects of an effort right up front. Often, we'll get together with product or marketing, but we may not bring care and sales and billing to the table. We're starting to see a big change in that where the operational teams bringing those requirements in upfront and they're shifting left with us just as, you know, IT shops are bringing ops to the table and shifting left as well. So it's a joint shift left, if you will. Yep. Well, you know, we've definitely, you know, just kind of wrapping up a little bit. We definitely, you know, the journey that we went through and, you know, the way, you know, we've we as the integration team at Amdocs worked with your team so closely, you know, it was a it was a great learning experience. I'm glad we got a chance to go through it. I'm glad we're still going through it. And I think it's think we're just going to keep learning more and becoming a better and better partner. But, you know, I think it'd be you know, now would be a great time, I think, for us maybe kick it over to see if we've any questions of anybody listening in. Yeah, hi, can you hear me? Yeah, that's okay. Just checking on what's coming on. Hi Josh and Meg, good to see you. Thank you very much for that. There's a question coming in, which is actually one that was on my mind as well. It's about the whole human aspect of this sort of transformation whenever you're bringing organisations together and let me just see if I can get the name. Ayesha asks, you know, what do you do with that whole human aspect of it, particularly people who are maybe working on the legacy systems and they're thinking, where does my job go? What's going to happen when move? How do you deal with that whole sort of uncertainty side of things with this sort of transformation? What we found, and I'd love to hear Josh's feedback too, is address it upfront and be open and candid and honest. Where you're potentially moving someone's cheese or you're changing their responsibilities, talk about the fact you're moving their cheese. Don't try to cover it up or hide it or ignore it because it's an elephant in the room, and the sooner you have open dialogue about it and let those folks that are being impacted be a part of the change and a part of the solution, the happier everyone is and the faster the whole organization moves through the change curve. The other thing to emphasize is the importance of operational stability through a transformation. It's really important for folks to understand that that doesn't suddenly become secondary. If anything, it's even more important when you're going through a transformation that ops is completely stable and those legacy systems are completely stable because the business is very dependent on that stability in order to free up resource and time to be able to spend on the transformation. So both are very critical and it's really important for people to understand the importance and the why and the what they're supporting. Yeah, you know, from our side, you know, we're more of a, you know, I'm on the other side of that table. But, you know, what we see is, you know, yes, the transparency is very, very important. And one thing that we push forward in Amdocs is the upscaling, right? So we know the change is coming. We're putting it out there ahead of time and we're giving a path or, okay, we're changing how we operate. For instance, Amdocs, we're very much going cloud based now. So we're changing how we operate and we're saying, here's what we need to train everybody So we were providing classes, providing different methods for people to be upskilled. So when cheese, as Meg put, gets moved, we can go over and grab it very easily at the next phase, whether that's way up in the cloud or it's down on the prem somewhere, can go get that cheese as part of the new structure after, you know, post transformation. Another question coming up, it's to do with the, you talked about finding the gaps. Whenever you're bringing two stacks together or two companies together. The big question I always feel as gaps and overlaps, you're trying to find we've got two things to do the same job or you're trying to find where you've got a gap and nobody's doing that job. One of the things I've certainly find over years of various mergers and acquisitions and so on is the importance of getting some sort of common ground, some sort of standard where you can bring two organisations together and if they've both defined their architecture in a similar way, does that help? From a personal experience, I find actually going back a few years now, TM Forum standards to be very useful for this. I'm just wondering, did you have that experience? Were there any common standards that really helped you work out where the gaps were and very importantly, the overlaps were? I think one of the best things T Mobile did was to find the North Star very quickly. So there wasn't months of sessions on making assessments. It was, No, this is the target stack we are all going toward. Now the mission for everyone is how do we get there in the fastest possible way with the best customer experience. So, by defining that North Star, that enabled us to move very rapidly. Wasn't so important that our current stacks be identical. The importance was knowing where we're going and then building the roadmaps together to get there. Yep. Yeah, exactly. I mean, once you know where you're headed, it's very the path gets illuminated as to what needs to be there and what does not need to be there. You start to see that very quickly. And so understanding where you're headed, and that's something I think T Mobile did great. Our previous integration deal, you know, did great is what is the info we have to get to? And then let's work back and let's figure out how that all pieces together. And then that really kind of the overlap and kind of just sheds off to the side and you have your your packets illuminated. There's always gonna be little things, but you know, the main things are going to be pushed out of the way. Yeah, and that leads on probably very much to the next question is going to ask about sort of very clear governance. I think what you say there Meg about the North Star is absolutely essential. If you get that clarity and everybody can get behind it and everybody knows what they're going to do, It is so helpful at getting the success and we've probably all had experiences where we haven't had that clarity and it can be a bit of a train crash where you're just going down the line, everybody's fighting their own corners and so on. Another thing that I find, maybe that North Star is the same answer to this one, but did you find any sort of experience of what I would always call turf wars, where people had their own area and they liked the way they worked, they liked the way they did things and they didn't want to change? Was that a problem, and was that a difficult one to overcome, or maybe the North Star solved it? So I got to go through a turf war when Sprint and Xcel came together, and candidly did not enjoy that experience. T Mobile has done just an absolutely beautiful job of eliminating turf wars. Again, going back to the North Star and then just being completely transparent, it's all about what's your work back plan, what is it going to take to get to that North Star, and being completely transparent across every single lane so that the lanes can work together seamlessly, define our dependencies, and solve for risks together. You know, I'm very proud of T Mobile for laying it out in this manner. It's the best I've ever seen. Yeah. Yeah. From our side of the house, you know, looking at it from a different lens, right? And, you know, if we if you don't have if we have a client that doesn't have that leadership buy in from the top and then on down it, that's where your turf wars can originate. So I think, know, that, you know, as we said, defining the North Star and making sure everybody from the top all the way down understands that, that can eliminate some turf wars. But if you don't do that, and we have definitely seen this, the turf wars will get violent and they will definitely slow down any transformation. So yeah, the alignment thing and transparency is so critical to making sure that everybody works together and you get through a transformation with minimal amount of pain. Yeah, well, think we're just about out of time there, so I think we're going to have to close that down. Thanks for the questions from the Q and A and Meg and Josh, thank you very much for your discussion and your answers. I believe you're going to be staying around after the session finishes for the Zoom, for the live Q and A as well. So we can hopefully get into a few more things there, for now, thank you very much. Thank you, Ian. Thanks, Josh. Ian, Josh, Meg, thank you all very much.