Hello, everyone. Welcome back to today's latest episode of the 'Down The Wire' podcast. Some of you will know from previous podcasts, my name is Craig Northveth, CTO of The Network Collective and I'll be your host today for the next 20 minutes. I'm very pleased to be joined again by Clare Tyndall, one of our Principal Consultants. Clare, would you like to give a quick intro of yourself?
Yeah, thanks, Craig. Yeah, as you say, I'm a Principal Consultant at TNC. I've been at TNC over a decade, working with lots of our biggest customers on Transformation projects. So looking forward to talking to you today.
Lovely Clare, thank you. So before we before we get started, I just want to quickly remind our listeners a little bit about TNC and our credentials, and talk about this a bit today. TNC - we are the UK's largest independent telecom professional services consultancy. We support over 280 major UK multinational organisations with their strategy, sourcing, development, and in-life managed services, particularly around network and telecoms, services and technologies. And today's topic primarily, we're going to be looking at network transformation and the planning of network transformation. So we're going to start really, with a bit of a discussion around why we're looking at this as a topic, and particularly why this has changed over the last few years. So yeah, I'm delighted to have Clare on board with me today. She's been involved in a lot of these processes, as have I myself. So we're going to try and navigate through the treacherous world of network and telecoms in terms of getting from Point A to Point B, and try to explain all the kind of tips and tricks that we employ, and then look to deliver as part of our network transformation process. So let's start, Clare, with the kind of key topics: What has changed in over the last few years?; What is different?; Why has it become more difficult to get from a traditional legacy type of network environment to something that's more modern?; and what do we tend to see as a result of our procurement processes?
I think there's lots of reasons, Craig, I think the first one that springs to mind is the fact that the technology itself has gone through a real revolution, over the past 18 months to two years. We now have all different types of technology: SD-WAN, SASE, an entirely different approach to networks and security. Obviously, we also know we've got entirely different ways of working, people have had to really rethink the way they work - organisations have had to think how they're going to change and transform the network to support those needs, particularly in flexibility of working, but also in flexibility of how they serve end-customers who might be who might be using services - and then beyond that, I think the environment within IT has become increasingly complex recently, particularly the demands on the network for unified comms. And the demands on the IT team are more complex than ever, and trying to get to grips with all those different moving pieces, in order to effect a transformation that's really going to bring benefits in all those areas, is a huge piece of work to undertake, when perhaps your workforce has been... well, it's smaller, and it's struggling and facing its own challenges with multiple projects itself. It's a very familiar tale that we hear from customers.
So I think there's a couple of really, important points there that you've talked about, which we maybe should focus on during this session. I think you talked about the convergence of network and security services? I guess you know, when we were doing these processes, from a procurement point of view, and transformation point of view, maybe five or ten years ago, we were primarily looking at buying MPLS networks, and there wasn't much of a security angle to that? Definitely what we are seeing now is that with network procurements, we're sourcing secure networks; security is very, very core key component of this. But that introduces maybe some complexity, doesn't it in terms of the people who we need to engage, understanding of what the security requirements are, understanding how that effectively fits around the whole network to develop that secure network process? So yeah, it's a really good point there. I think the other point I thought was really interesting, was around the operating model for networks going forward. I know you've got some specific experience of this from various different projects we've been working on, so maybe it's worth exploring that in a little bit more detail as well...
Yeah, absolutely. I think picking up on the first point there around MPLS and maybe buying MPLS networks and security separately, and that convergence - I think when the answer was sort of always MPLS, (which it was for a number of years), it was hard enough anyway, if you had a complex business environment, to gather the requirements from the different stakeholders. And actually to get your baseline under some control, to actually understand what sites you had out there; what bandwidths you had out there; what devices that there were on the network; whether they were legacy, end of life, etc, - that took an awful lot to get to grips with. You talk about the tips we would give our customers we would always say, 'That should be your first port of call, the baseline and understanding that'. That's now far more difficult, you need to be paying attention to far more different elements within that baseline as you approach that, so you need to understand the security baseline, you need to understand your application environment, as well as the network, as well as your unified comms needs... it all needs to come together if you're thinking about undertaking something like this now. And in terms of the operator model, with MPLS networks, it was the case that it was just very often a managed service model, but there's far more flexibility within that now. And like you say, bringing together the different service towers like Security, alt-WAN, etc, you might want to approach the management of that in a completely different way. Again, you're going to have to understand your baseline for your current resources and what they're going to be capable of, and how much they cost you, and things like that. So understanding the baseline, both from a technological, but also from an operator model point of view, needs to be your starting point whenever you want to undertake this kind of project.
Yeah, I think that's definitely one of our biggest learnings in this last 12 - 18 months as we've been doing more and more of these strategic procurements and looking at different types of technologies: understanding the importance of that baseline, how that effectively will drive the process; understanding where the return on investment is going to come from; understanding where the operating model might need to change; understanding the difference sort of commercial models as well. So I guess, you know, one of the other areas we're starting to see now, is much more subscription-based models, or consumption-based models, where in the past it's been pretty fixed, pretty static, one-off costs, recurring rentals. So yeah, understanding the difference in the change, I guess, is again, a key thing and something that needs to be understood earlier in the process. Is that a true reflection?
Yes, it is a very accurate reflection. So from the baseline, you need to be understanding your existing operating model, what the strengths and weaknesses of that are - you need to be understanding your technical baseline, and where precisely that is. You also need to be understanding your commercial and contractual baseline - whether you need to do any short term extensions to contracts for instance, in order to align ready to undertake the transformation project, then once you've got all that together, you need to be seeking out "what are the requirements?" So "what are the commercial requirements?" "Is it for subscription?" "Is it for an annual capital investment type of type of project?" "How do you want to see that structured?" "How would you want to see - as we've just been talking about - the resource and operating model and the management of the network operating going forward", "What needs and requirements are driving that?" "How are you structuring your applications?" "What projects are starting to become fundamental to your business?" "Are those changing particularly in the in the light of the vastly changing economic and global situation?" "How have those changed over the past year to 18 months?" "What might be happening in the future, you might not know how do you build in that flexibility?" "What is the flexibility in the requirements that you're going to need?" So there's an awful lot to consider when you first start that baselining. And then there is the requirements gathering for the business across all the different areas. And you need to be very diligent in how you do that.
I guess one of the positives of doing that early in a kind of transformation process, is that there is opportunity to identify some quick wins isn't there? So you know, a lot of people think that they're going to do a network transformation, and so they're not really going to deliver benefit until a year or two years down the line. But actually, that kind of auditing the baseline, and understanding exactly what's there - you're highly likely to find some things that you maybe don't need anymore, or they could be re-contracted at a lower cost or you could do some tactical changes to effectively deliver some cost savings. So I think we are starting to see more on that as being a value add effectively from that that audit process at the front end.
Yeah, very much so. The sort of clean up of the commercials, contracts... Maybe you're paying for things that you actually should have cancelled, or did cancel! We are seeing that sort of thing all the time. So I think, yeah, maybe there's a tendency to get very excited about all the new technologies that are coming within the market - and I think we're about to come on to talking about that, but in the first instance, you need to make sure you've dotted all your 'i's and crossed all your 't's and got a good clean base to work from.
Yeah, absolutely, that's really good. So I see it as a nice kind of segue, and we've started talking already about requirements capture, and the importance of understanding requirements at different levels I guess, and not necessarily being being led directly from the vendors or from the market and manufacturers, because I think there are some gaps appearing in the market in terms of what is perceived as the 'art of the possible' versus 'what's realistic', outside to see some issues now where the dream is being sold, if you like, from a vendor perspective, but when you try to go out and buy that/procure that delivery, you're not quite getting the same level of dreaminess - if that's actually such a thing? So yeah, again, maybe we could touch a little bit around the importance of requirement capture, understanding from a business objective perspective, right down to what do SLAs need to look like? Again, you could maybe talk through that a little bit play Clare?
Yeah, absolutely. I think you do need to be very clear on things like how your network needs to perform, what SLAs, need to be in place. I think you're right in that there are a lot - and you know I mentioned a couple of the watchwords earlier - around some of the new technologies coming to the market. Gaining an understanding of those parts of the market is absolutely essential, like you say, and being realistic about which of those are going to actually match up to what you need in terms of the performance of the network, and what your requirements are, versus what your commercial objectives are, and how much just is this stuff going to cost compared to what you need to be achieving commercially, because a lot of businesses are under immense commercial pressure after the last 18 months. It's always been a balancing act between commercial and technological improvement but now, it's even harder to achieve. We're finding sometimes when it's coming to, (because we assist quite a lot of clients in the deployment phase of their networks as well, as the procurement phase), when it comes to deployment, have Suppliers done the due diligence?, done the proof of concept?, done the testing, on whether their solutions are actually going to marry up to the requirements or not? And so I think putting that detailed due diligence upfront as part of the process in order to marry what the market is saying, with what your strategy is saying, - you must be clear on your strategy and your business case and what you're hoping to achieve, - versus what is actually going to be achieved, and the due diligence the Supplier has done on it. Making all those things line up is difficult, but you definitely need to make sure it happens.
Yeah, I think one of the things that I think that's a really good point, I think one other thing as well in terms of the objectives, is trying prioritise some of the objectives and make them measurable for the process. So you know, use objectives to really drive the the approach to the market. We'll touch upon this in a second but the sourcing of some of these services isn't as simple as what it once was, and we've got disruptive providers in the market, we've got vendors offering services, we've got service integrators there now as well. So you have to have a very clear definition of - this is what we've got today, these are the requirements, and this is our kind of go to market approach. So do you want to maybe touch a little bit on that in terms of that strategic alignment piece and sourcing strategy around the kind of avenues and routes that we're taking to that in a minute?
Yeah, absolutely. Well, I think we're trying to take a more agile approach than we previously did, and also quite a consultative approach with some of the Suppliers because I think some organisations can hear a buzzword like SD-WAN or SASE and just say: "Okay! That's what I want my network to look like!" And in actual fact, even those phrases can encapsulate all different types of models and approaches that mean different things to different people, and mean different things from different suppliers. So you really have to understand from a business and an IT perspective what you're hoping to achieve here. You know, if you want an application to run in a certain way, what what are you hoping to achieve, and instead of necessarily going out with a very set, closed-off RFP process that says "This is the model and we want it to work!", understanding with your Supplier long list, i) what is the art of the possible?, ii) these are the things we want to achieve, what can you come back and tell us that you can do?, because then that will often help cement in the minds of the clients, the directions that they want to go down. Like we've already talked about so many different things that you need to be considering at the start of the process, it can often be bewildering for clients, and being able to sort of have that agility at the beginning of the process to bring the information to the clients, and then enable them to be able to see the clear pathways to all the very different things that are going on in the market and in their business. We're finding this is the most helpful way to approach it, which is quite different from maybe, just that sort of Route One requirement: this what we want our network to look like RFP. So yeah, that's that's something that we've been finding. I think you found that on your projects too?
Yeah, I think that kind of agile methodology around going to market with these things is very important these days, I think it's very difficult to go with a very defined specification and say: "This is what we want". Because, there's definitely a gap between the vendor capability and service provider capability at the minute - people doing things differently - so, it needs to be an agile process, and a collaborative process I think, increasingly, you need to be working with the service providers, with the SIs to understand how you can achieve the objectives together.
Yes. We talk with clients quite a lot I think, about your outcome-based sourcing strategy, and that's very definitely what needs to be at the fore at the moment.
I think also the kind of concept of, there's almost like a minimum of viable products that we should be trying to achieve, but then there's a set of roadmap initiatives potentially for the future, particularly when we start talking about SASE. Because as you mentioned, SASE means a lot of things to a lot of different people, and there's various different components in there. You can't specify in an RFP, or a procurement process that I want to buy SASE, because it doesn't make any sense. So you've got to drill into what components of that do you actually require? What's the Day One requirement in terms of a minimum viable product, and then what's something that you want to innovate on or develop over a period of time? I think that's the whole agile piece you talked about there, and I think it's becoming increasingly important. So I guess we've touched a little bit Clare, on on the market as a whole now, so we're starting to see more interaction with service integrators. We're obviously seeing a lot of interaction still with traditional managed service providers in the network space - the Global WAN providers, for instance. But I guess we're also starting to see some of the Hyperscalers getting involved in some of this kind of stuff, starting to see disruptive providers coming into the market as well. So there's a lot of flux in the market at the minute, I think. So again, it points to the importance of understanding what it is that you want, what your requirements are, what it is you are willing to accept as an MVP, and then trying to identify the right vendors, is that the kind of process that we talked about, from agile point of view?
Yeah, it is, that's very much this type of process that we're talking about, and where you touched on about - we don't really know where things are going to go, and about future capabilities - I think that's a crucial point. I think, if anything can sum up the experiences of the past 18 months, it's very much, delving into the unknown. We try to avoid overuse of the word "unprecedented", but these have been unprecedented times. And so therefore, you need to make sure that when you're developing your sourcing strategy, your vendor strategy, that you have that flexibility baked into it, and that capability of the vendors to maybe take things on into other directions and into other roadmaps because you have no idea what the next challenge is your business and your IT team might be faced with, and what the network might have to cope with. No idea what other solutions are coming down the line from a technical capability point of view, and development from the supplier. So I think you have to be prepared for the unknown and be flexible enough to cope with that unknown when developing your sourcing strategy and, and your procurement processes.
It feels like the only consistent in the process at the minute is change. We've seen that from a customer point of view, and from a Market point of view I guess, so yes, the agility to adapt to change throughout the process for our transformation process, I think is definitely key. Okay, that's really cool. I think if we just quickly revisit what we've talked about then so: 1) Baseline, and the importance of that, understanding what your current costs are, what your current technologies are, life cycle, infrastructure, all that kind of stuff. 2) A very clear definition of requirements, right through from business level to the kind of solution the service is going to be operating. 3) And then a well defined sourcing approach, which effectively is outcome driven and as agile as possible. So we get through all of that, that's great - we're getting to the point now where we've identified providers potentially, that can deliver this service. I guess what next, and this is another area of change, when you start talking about how you contract for some of these services, and the frameworks around this, so how do we bring that level of flexibility, agility into the contracts? What are some of the things that we see in change in that space?
So I think greater flexibility on things like minimum commitments. So you know, that's obviously a positive step from a buying perspective, and I think, clauses written into contracts to allow flexibility and things like divestment, but also incorporating technical change within the contract, and making sure that that's at no penalty. So that flexibility in the contractual model, and we've touched on it a bit before, but that is vital to cope with the sheer scale of change that we're seeing. I think you just have to really keep an open mind when it comes to contracting at the moment, and not accept - you know, probably many of the people watching will be familiar with telecoms contracts that were very restrictive in the past - don't accept that at the moment, because it just isn't fit for purpose for the constantly changing environment and landscape that we're seeing. I think, definitely push on that flexibility.
Yeah, I'd definitely second that. I think we are definitely in this kind of revolutionary stage, in the network space at the minute, we are definitely seeing a significant change from where we were five years ago, and the contracts that are still around today, the sort of legacy contracts going into what we need in the future, it's definitely got to be more flexible, it's got to not be based on certain commitments to connections or revenue, even. It's got to offer the ability to change technologies, whether that's at a physical level or a virtual level, it's got to be moved into a more 'Software as a Service' type capability as well as we get to a more subscriptions and consumption model. So yeah, that's good to know. And we are seeing some success, I guess, in our space. I mean, this is probably an area where it's not as easy to execute some of these things because at the end of the day, it's still a legal document. And I think a lot of the service providers, the SI providers, the legal teams have not quite caught up with the speed of change and technology. So we do still run into some challenges, I think, don't we, but again, it comes down to the planning and it comes down to "What is your minimum via products? What do you need from a flexibility level? a bit of forward thinking doesn't it I guess?
Yeah, it does. Yeah.
Okay. Cool. And then I guess, post contracts, and this is this is probably another topic for another day, but post contracts, what are we starting to see here, so you know, how are people executing these things? Are we seeing this being rapid transformations? You know, for instance SD-WAN and SASE? Are we seeing that revolutionise the way that people can deliver their networks? Or is it still a fairly slow and steady type of process to deliver the overlay, to deliver the underlay, to deliver some of the services?
Well, I think it will depend on the project. But I think underestimating all stages of a transformation project, and how long it will take all the stages that we've been talking about so far, baselining, requirements gathering, sourcing, contracting, all of that tends to take longer than clients think it will. And then the project deployment itself tends to be more complex and takes longer and requires more planning, than clients think it will, and that can often be underestimated. That said, things like SD-WAN, and things like zero touch deployment are there to be had. But it's not a sort of magic wand to instantly transforms networks that roll themselves out. So I think understanding and being realistic about what your resource requirements are going to be in that space is something you should consider very seriously.
Yeah, 100% agree. Very well put. And Clare, I am conscious that we are probably at our 20 minute mark. So I think it has been a very, very interesting podcast today. So I thank you very much for your time. I'm sure the listeners will appreciate that as well. So yeah, finally everybody: thanks for listening. If you do have any questions about this topic or any other topic in this network and telecoms space, you know where you can get in touch with us, either directly through our social media or via our website networkcollective.co.uk. We look forward to speaking to you again in a couple of weeks time. Thank you Clare.
It's been a pleasure. Thanks, Craig.