Total Cost of Ownership (TCO)

In this episode of Definitely Maybe Agile,  Peter Maddison and David Sharrock explore the evolving complexities of calculating the total cost of ownership (TCO) in modern software development and delivery.

This week´s takeaways:

• TCO fundamentals remain unchanged, but the environment for calculating and applying TCO has become more complex.
• Organizations must distinguish between strategic proprietary development and commoditized solutions, using tools like Wardley mapping to identify where to invest versus reduce costs.
• Understanding and defining system boundaries is crucial for accurate TCO calculation - using approaches like value chain mapping, value stream mapping, or domain-driven design helps identify hidden costs and dependencies.

Subscribe to Definitely Maybe Agile on your favourite platform and join Peter and David as they unpack the challenges of digital transformation at scale.

Chapters

• 0:04 Agile TCO Exploration
• 8:19 Understanding Total Cost of Ownership

Transcript

Peter: 0:04

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello, Dave.

Dave: 0:14

How are you today, peter? I feel like I'm holding you back from an exciting afternoon evening weekend. However you look at it, it's something like that.

Peter: 0:24

This is another one of those days where I've had like 15 meetings. My voice is getting croaky. It's because I've been talking a lot today. Excellent so what are we going to?

Dave: 0:35

talk about today.

Peter: 0:36

We're going to talk about total cost of ownership and, in particular, it's tough to calculate, and so how do we go about doing this? It's an interesting question.

Dave: 0:49

It is. I'd love to. I'm going to ask you to explain just a little bit about the context of where you're coming up with that. And part of it is because total cost of ownership was front and center for many years and always has been and always should be in terms of procurement and making financial decisions about the investments organizations are making in some very, very costly software, for example. But over the last few years, with this onset of Agile, the total cost of ownership seems to have fallen away from being front of mind with a lot of teams or it's gone back into the procurement piece and it's not really been something that is talked about as we move to SaaS models, as we move to this sort of trivialization or obfuscation about the total cost of ownership for systems that we're using.

Peter: 1:36

Yeah, well, I mean from that part. I mean, if we think of the complexity of CapEx versus OpEx so once we move to an OpEx model, so we're consuming SaaS services which are then a part of it, that in some ways in theory would make it easier, because if I know how many licenses are being consumed, I can directly multiply and calculate how much it costs to do this. So that sort of CapEx to OpEx piece is interesting. I think there's a piece too around the project product switch as well, Because once we think of things as products, we can look at the total cost of owning and delivering that product versus all of the cost of the projects that we run, and which projects impact which products and how does all of those different pieces interact? I think to me a lot of it ends up coming down to the total cost of ownership of what Like. Where do we draw the boundary around this? Like I put everything on a whiteboard and I draw a big circle around. I want to know everything inside the circle. How much is that costing?

Dave: 2:40

Well, but I think that and I totally agree, there's also some, you know Trident total cost of ownership is, broadly speaking, an accounting definition, so that definition is not changing However. So a lot of the tools, the methods that organizations use to calculate total cost of ownership really don't change too much. But one of the key things that does change is we're in an environment nowadays where things don't. You know, the whole point of total cost of ownership let me peel that back was to amortize the investment over many years of using the product. And certainly if we're just getting a SaaS model, we have less to worry about the amortizing a big upfront investment, but we do have the operating cost of those service fees over the length of time that we use the product. It's a lot more challenging for those situations where we have to make an initial big investment because the amortization time periods have now got shorter and shorter and shorter.

Peter: 3:42

Yeah, and it becomes particularly complex on the infrastructure side. If you're looking at things like platform engineering, I'm going to stand up a platform. The first person onto that platform is often paying for a lot of the cost of setup and implementation. Unless you've got some way of like divvying that up or holding some back or looking at some kind of initial funding for a future target state, it can make it actually somewhat unattractive to be the first person onto a platform if it's an internally delivered platform.

Dave: 4:17

But I wonder if there's a paradigm shift towards I'm just thinking of like platform as a service. We've had software as a service and various other things as a service, but platforms as a service is a thing too. Software as a service and various other things as a service, but platforms as a service is a thing too. At what point does the total cost of ownership for some of those standalone platforms that we're going to bring, you know, stand up and have to do all of that initial upfront investment? When does that become either prohibitive or just strategically the wrong thing to do?

Peter: 4:45

Well, I think a lot of it. Well, seeing this across organizations where, if you're experimenting and doing something new and you're able to build out in a cloud first cloud native fashion and using or borrowing basically renting your compute capabilities and your service capabilities from a cloud provider makes an awful lot of sense. If you have a large legacy footprint that is prohibitively expensive to migrate, then running it on something internally can be a more strategically sound direction to take, and there's a spectrum in between those two things.

Dave: 5:27

Well, there's a great trade-off that you can sort of manage there, which is you've got some legacy system that you're either looking at. That cost of ownership, of maintaining or upgrading or migrating to some other internally managed system, versus moving to something which is somehow out in the cloud and you can, you know the cost of it becomes a cost then of I guess, configuration and alignment. You know personalization or customization to your own environment and your own needs, right yeah?

Peter: 5:56

But there's, a strategic loss.

Dave: 5:58

there as well, I mean loss of control, a loss of unique, you know, uniqueness of your way of dealing with things, which gets lost as you move to these standard products.

Peter: 6:07

Yeah, well and well, that's certainly a part of it. So there's a couple of things to look at there. One is, if you consider something like waterly mapping and think of commoditization of services, if I want to map out my value chain and map that then across commoditization, I can start to think about which parts of these are the differentiators. Where do I innovate? How am I going to do something that is actually different in my strategy to deliver? And I know you talked about this at conferences.

Dave: 6:38

You know nothing about this at all, do you? Well, I think it's a great eye-opener, for sometimes we hold on to things and we kind of think they're unique and that we need to keep investing in it. And the TCO, that total cost of ownership a lot of that is. If it's commoditized, the total cost of ownership should be pretty, pretty low. I mean, that should be the whole. So then we're trying to understand which parts of our value chain we actually want to invest in.

Peter: 7:04

Yes, want to invest in. Yes, and I mean. The classic examples are things like the McDonald's building their own sort of point of sale system, because that enabled them to have greater control over that, which enabled them to tie it directly back into their inventory systems, which enabled them to scale to the company they are today. So there's bits like that where the right investments in the right pieces of technology at the right time can be incredibly powerful to drive your organization.

Dave: 7:30

I'm reminded of many of the organizations in insurance that are moving to products like Guidewire, and it's that almost commoditization of the service. And there's a danger there, right, that if every insurance customer journey is modeled on what Guidewire produces out of the box, then how do you differentiate, how do you maintain a premium position in a marketplace?

Peter: 7:55

Yeah, because that can't be, then, your point of differentiation, because I can go get that from anywhere. Your differentiation now needs to become on how do you use the data, how do you use your relationships, how do you use your services that you can surround that in, and those then become the places where you can start to look at how do I do things differently and what sort of things can I?

Dave: 8:18

provide. I was just thinking. I think we're losing connection with our original topic of total cost of ownership. So how do you subtly bring that one round back to that?

Peter: 8:30

Well, I think there's a piece there, I think, a lot of things that we were describing there.

Peter: 8:35

We're talking about really deeply understanding what the nature of the systems that you have under your control are, because that's kind of the root of really trying to understand what the total cost of ownership is.

Peter: 8:48

What does it actually take for me to build and deliver this, and how is it going to evolve over time? And where can I look at reducing the cost? Because, I mean, that's a part of what we would then starting to get into there, I think, is that if we can look at what are the things that make it up, if I understand the value chain of all the things that are needed to do what I need to do, I can start to look at well, which parts of these do I spend more money on, which parts of these should I start to spend less money on, and where can I start to think about what the cost overall is? But also, which parts of this should I be sort of doubling down on, or where are there opportunities? And that's why exercises like worldly mapping are powerful. It helps you identify where should I be looking to start to build a strategy, or an approach and I just want to kind of add in a little bit to that.

Dave: 9:40

So I really think that conversation around worldly mapping and understanding everything isn't a TCO the total cost of ownership conversation. There's a bunch of things which are becoming commoditized, and being aware of the components of our value chain which are being commoditized, I think it's very natural, especially if our organization has invested a lot of time and effort in something, to really hold back from considering it to be commoditized. Yes, and I think there's an opportunity. You know, sometimes you just got to let go, and one of the things that we started the conversation with is that letting go has to happen sooner rather than later. Things are moving at an incredible pace. So not only can I not I can't amortize this total cost over many, many years anybody, you know, eight years or whatever it doesn't necessarily make sense in many cases but also to invest. How quickly can we make that investment hit the ground? Because if it takes us too long, again we're missing the opportunity and we probably shouldn't be looking at that investment we probably shouldn't be looking at that investment, so even with the Wardley mapping perspective.

Dave: 10:49

Once we've identified where we can strategically work, we then have to decide can we work there fast enough to make this a great bet for where we want to go?

Peter: 10:59

Yes, and there can be a lot behind that decision in terms of understanding. What is it going to take to change that Like? Who does like? It's one thing if it's an internal system used by 10 people versus hey, this is something every one of our 100,000 customers logs into a daily base. If I'm going to change it that significantly, I'm going to retrain everybody. There's a huge difference between these two things. So understanding the impact of change is a critical piece too. Another way in which I think the sort of calculating total cost of ownership can become complicated is because of the I think we touched on it before the hidden costs that people aren't necessarily considering. They're like buried off into, they're assuming that they're a given, even though there is a charge back somewhere else in the system that they're just simply not aware of and so they don't and that. That's why it can be good to map out the system and understand. Where are the dependencies, what are all the things that actually make up, um, the delivery of this and well, it's central.

Dave: 12:03

we were I've just been doing um workshops, workshops on sort of advanced product management, and one of the things we're looking at there is how you capture value for a particular product, and I think that's what you're talking about, which is that it's not always obvious where the value is being captured, but it's not always obvious where other organizations that we're paying subscription fees to, or whatever it might be, are capturing value from their end and we're, you know and being aware of those before you kind of get you know, get caught out, having agreed to something which all of a sudden has fees that were associated with scaling. So I'm just thinking one of the organizations we do e-learning and when you try and roll e-learning out into the public, you, you all of a sudden have these fees associated with how many people are using your system, which is in in addition to. I have the privilege of authoring e-learnings in this product yeah, yeah.

Peter: 13:00

Which is interesting, isn't it? When you start looking and use of things like gen ai for similar pieces, because the token to the back end depending on the size of the model, what, what sort of things you're doing. A lot of this can drive problems as you scale if you don't have that baked into your pricing. So again, this is the interesting sort of TCO piece of it. Got to be careful your costs are not going to exceed your revenue. So how would you wrap all of this up into like three points?

Dave: 13:28

Three points, so one is total cost of ownership up into like three points. Three points so one is total cost of ownership is the same conversation it's ever been, and I think that's. I think we very briefly touched on that at the beginning, but I think it's important to recognize there's nothing fundamentally has changed in how that work gets done. However, the environment within which that work is getting done is maybe more complicated. So two things that jump to mind. One is that comment you made about Wardley mapping and just that reminder that there is a difference between you know, strategically, or proprietary development and the costs involved with that, versus things which are becoming more and more commoditized and therefore we need to be fully aware of the elements of our value chain and where we should be investing and where we should maybe be slashing costs as we try and have to be replaced is getting close to I mean, it's certainly shorter than five years in many, many cases.

Peter: 14:34

Yeah, I would definitely agree with that. I think the key piece to me out of all of this is understanding and defining the boundaries, making that visible so we're clear as to what it is. And that's where the Waterley mapping value chains, value stream mapping, domain driven design whatever mechanism you decide to use to capture an understanding of like, where am I putting the scope here and do I have everything that's included in there? So there isn't hidden costs buried somewhere? I think is key. So well, thank you as always, dave. It's always fun having these conversations and I look forward to next time. Yeah, until next time. Thanks again. Thanks. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.