To build or to buy (your new software), that is the question with Steve Baker

Our guest, Steve, shares his 3 questions to check if it makes more sense for you to buy or to develop new software depending on your situation. Steve and Jarosław talk all things custom vs. COTS, including return on investment (ROI), total cost of ownership (TCO), innovation, competitive advantage, customisation, maintainability and lowering the barrier to building your own software.

Steve also talks about two interesting case studies from the warehousing and distribution sector: one for Fareshare – a national UK charity which was a bespoke project, and one for a national UK retailer who chose an off-the-shelf product. Steve explains the reasons behind their choices and shares his top 3 pieces of advice for those of you who are faced with a similar decision.

Our Guests:

Steve Baker is an independent IT consultant with a vast background in business systems, design, architecture and software development. Steve and his consultancy, Vermillion IT, help companies investigate their processes, assess what kind of systems they need and, if required, run the project to deliver that solution.

Jarosław Granat is Future Processing’s Head of Client Engagement, working to ensure the highest level of services for the company’s clients. He is a graduate of Computer Sciences and Psychology in Business and has worked in IT for the last 10 years.

Jarosław Granat (JG): Hello, my name is Jarosław Granat, and I’d like to welcome you to this episode of IT Leadership Insights By Future Processing. If we take a look at majority of larger companies and their strategic goals, we can see some similarities. Most of them take care of increasing revenue, growing the customer base, or increasing the efficiency and operations. And as we live in the digital age, plenty of those solutions are connected with IT solutions, but what to choose – a ready, off the shelf product, or to build it on our own. I don’t know, but thankfully we have a great guest today here with us, who probably knows the answer. And let me introduce Steve Baker, who is a freelance IT consultant and an owner of Vermilion IT company. Hello Steve.

Steve Baker (SB): Good morning.

JG: Steve, why don’t you tell us a little bit about yourself, your background, and your history.

SB: Okay, so as you said, I’m an independent IT consultant, but I have a background in business systems design, and architecture, and software development. And these days I earn my living by working with companies looking at their processes, figuring out what kinds of software they need, and then, if required, running the project that gets them that software solution.

JG: Sure, thank you for that introduction Steve. So I think it is a big question, so where to start and what aspects should be taken into consideration when deciding whether to choose a ready, off-the-shelf product, or to invest in building it on our own.

SB: Well obviously every company’s situation is quite unique, but I’ve got, more or less, sort of three tests. So the first one is, what’s your time constraint? So if you need something almost immediately or with a fixed date that is in the near future, you probably have to buy something. The next one is probably about fit. So is the problem you’re trying to solve, has that already been solved in the industry? So a good example of what I would consider to be a solved problem is, say CRM – Cost Relationship Management software. If you wanna track customers, prospects, and the interactions with them, the industry has pretty much solved that. You’d be able to buy an off-the-shelf product and adapt that to your need.

JG: So in order words, there’s a little chance of doing it better and cheaper on our own?

SB: Again, depends on the circumstance, but I would regard that as being, there’s so many different CRM products out there, it is almost certainly a solved problem for what you are doing. But when we start to talk about sort of deeper business processes, the things that really are the processes where you’re interacting with customers on a regular basis, then it gets more interesting, because if you bring in a product and it’s not a very good fit to the way that you do business or your customers want to do business with you, then that’s gonna act as a bit of a drag on that business process for the lifetime of it. So it depends on the problem you’re trying to solve, but actually making sure that you’re, if you’re buying something, it’s got a very good fit, and if you are doing something that’s a bit different and not solved by the off-the-shelf products, then you should probably be considering building something.

JG: What about some kind of differentiation, because I can imagine that if would like to be… stand out from your competition, you would rather invest in building your own software, is that right?

SB: Yeah, and I think that’s actually the third one, differentiation or innovation. So if you’re doing something that’s very different, if you want to do something that’s very innovative, then building is probably the way to go. Put it one way, people tend to, let’s take digital initiatives. You are doing something innovative in that space, you want to interact with your customers in a new way, you’re probably looking at a built solution for that, whereas running your payroll is probably a bought solution, unless you’re a payroll company, in which case you’re trying to innovate in the provision of payroll services, in which case you’re probably back to the built. Does that sort of?

JG: Yeah.

SB: Yeah, that works.

JG: Yeah, it does, but there is I think another factor, which is quite important, and it’s usually one of the first things that companies think about, is the matter of price. Are you able to judge which kind of solution is cheaper in the long term, in the short term, or how it differs?

SB: Well looking at that is definitely one of the things that you need to consider on this journey, but I prefer not to talk about price, but instead talk more about the return on investment. So there’s really two components to this. One is the total cost of ownership for the solution and then there’s the benefit of the return that you’re looking to get from that particular solution when you put it in. If you build something, you have an initial upfront cost, but on the other hand, you then own that asset, which means that you won’t be paying any per user license fees, so that changes the total cost of ownership profile. You will, however, almost certainly have to maintain a bit of a development team for that. If you’re buying something in, then you might find that the initial purchase price, should we say, is lower, but you’ll be paying say license fees and an annual maintenance fee on that. So you need to compare the two, the total cost over the lifetime of that expected system, be it five or 10 years, in the space I operate in, which is large business processes, five or 10 years for a system is a not uncommon lifetime. Probably the other thing to just sort of think about in terms of the return on investment, again, comes back to our innovation. If you’re doing something innovative, then presume you were doing it innovative because there’s a better return on investment on it in terms of doing it the way that everybody else does it. If you buy something in, you will be doing that process the same way as everybody else who has bought that product or at least that class of product. So are you gonna get competitive advantage out of that? Possibly, possibly not, but presume you’re doing a build because it’s innovative, you’re doing the innovation because you think that’s gonna give you a better market position. It is hard to work out the total cost of ownership and the return on investment, there’s no getting away from that because you’re forecasting effectively, and you might have very little data to go on it, but there’s no reason why you shouldn’t try. And when I’ve done that, one of the surprising things about it is when you, if you do your returns on investment at the process level, for example, a job I did this year, one of the processes that we were looking at changing and investing in had a much, much bigger return on investment than the other ones. So that immediately gave us our priority list of, when the project went ahead, what was the first thing we wanted to deliver on, it was actually that part of the process because that gave us the most ROI and we could get that in quicker.

JG: You said that this exercise is quiet hard, do you think that there is an ability to do it in the companies, in the IT departments who are usually responsible for that? You are acting as an IT consultant so probably you’re helping some companies in that area as well?

SB: Well it is a good question, and for the audience well you would say that wouldn’t you, but the question is, does your in house resource have the time, first of all, and the expertise to do the evaluation? Because, if we’re talking about quite large systems, non-trivial systems, it’s probably you don’t do it very often as well as a company. So if your internal team doesn’t have the time or the skills, I think it is worth bringing in somebody from the outside to help on that because they will know how to run that process. And when it ends up with, for example, creating invitations to tender to go out to market, they’ll have an understanding of maybe how to do that in a more efficient way.

JG: I think that there is also another part, or another factor that is quite important in terms of decision-making process, which is the maintainability. Are you able to say which one of the approaches is better in that area?

SB: Well can I ask almost what you mean by maintainability, because you can have a, shall we say, a stable, static business that doesn’t change it’s process very often, or you could have a very dynamic business where you’re trying to innovate in a space and you’re trying to find out what works. If you’re a stable business, then probably a bought solution is going to be very maintainable in terms of keeping up to date with your operating system, changes, the database changes, the regulatory changes, after all, that’s what you’re paying your annual maintenance fee for.

JG: Yeah, that’s right.

SB: But if you’re talking about keeping the system maintained in terms of the way that the business is working, and that business is changing, you may well find that a built solution is more flexible and maintainable in terms of tracking what the business is doing over time. But you will need to maintain a development capability through the lifetime of that system. So again, like all these things, it’s almost one of those factors, isn’t it, what does maintainability mean in the context of your business.

JG: All right. If we are talking about the Bespoke Software development, we’ve seen that it is getting more and more attention, and maybe this is connected to the fact that there are more pre-built components that can be easily used and therefore the development is going faster. Is this the experience that you are also getting from the market?

SB: I think there is more developments going on. I think a lot of it is driven by digital initiatives. So by digital I mean reaching out to customers or suppliers and opening up your business processes by either web apps or mobile apps, that sort of thing, so you’re inviting external actors into your business process. So there’s quite a lot of that going on. It’s an interesting question as to whether there’s more of that because there’s components out there. I think the digital initiatives stand alone as the business case, but it is true that a lot of internet-based companies and startups have open sourced some quite significant frameworks which definitely takes a lot of the technical, some of the technical risk out. So there is the demand for digital initiatives and then some of that technical risk is taken out by what you can get in the marketplace, much of which is for free. I’d probably add to that, Cloud-based services as well. So I’m not talking about just putting, just lifting and shifting your existing infrastructure into the Cloud, I’m actually talking about using Cloud-native services. So that would be things like Cloud-hosted databases, message queues, various other architectural components, those take some of the technical risk out. It’s lowering the barrier and cost to building out some of these services, which again, is good for companies that effectively creating software is not their core business.

JG: Speaking about particular software project, you’ve got a nice experiences on both sides, would you be able to share some nice examples and case studies from your experience?

SB: Well as it happens, a couple of years ago I did two projects back-to-back in the same space, which was warehousing and distribution, and one of them ended up as being a bought solution, the other one was a built solution. So one was for a national retailer, and that was a bought in one, and the other one was for a national charity which is called FareShare, which was a built solution. So talk about the retailer first. So going back to my kind of tests. So the first thing is, and anybody who’s been involved with retail will know this, that retail has a calender because Christmas is so important, you know we had to hit this date. So they had a time constraint, so you know, time constraint ticks the build box, sorry, the buy box. The other thing was that what they were going, or what they needed, was effectively a solved problem. There were lots of solutions out there that did what they needed to do, which was retail, distribution, going out to stores, satisfying e-commerce orders, it was actually implemented, we actually implemented a module of a well-known ERP system to do that. And again, what they were doing wasn’t particularly innovative, the marketplace, we could deliver what the marketplace needed at the time with a built, with a bought solution. So they kinda ticked those boxes, definitely a buy it in. FareShare was a different matter, and I’ll probably need to explain a little bit about what FareShare does. So FareShare is a national UK charity and what they do is they bring in, from the supply chain, surplus food. The supply chain is supermarket distribution centres, manufacturers, so we’re talking about surplus by the palette, all the lorry load, the truck load, it’s big volumes. And what they do is they bring that into one of their say 20 distribution centers, which are around the UK, and then they share it out, hence the name FareShare, share it out to a couple of thousand partner charities within the regional areas of these distribution centres. So the challenges with them were, first of all, they don’t fit into the standard retail or wholesale distribution model.

JG: So there was no solution on the market that’s–

SB: Yeah because they don’t know what they’re gonna get and most systems you buy off the shelf aren’t really set up for a business that gives things away, which is what FareShare does. So we looked at a few of those but they either needed quite a lot of customisation, and customisation is quite expensive. The way the business model works for customisation, you’re looking at around a thousand Euros a day because that’s what those organisations have to charge to keep their services division. So that’s quite expensive. Or writing quite a complex, kind of bespoke, a wrapper around it. So that wasn’t tremendously good fit for their business model, but the other thing was, FareShare operates with a lot of volunteers and we wanted to extend the system out so that it could be used by their partner charities as well. So as a system design, it had more in common with a consumer application, a B2C application, than a B2B, so we needed the user interface to be very, very approachable. So the combination of not quite fitting the business model plus the fact, the usability element pushed us down the build route. But the other thing was, when we looked at the costs, so this is back to the TCO, because we had a lot of users involved and you looked at the total cost of ownership with the maintenance agreements and the per units licensing, although the initial build cost was higher, over a five year period it was overwhelmingly the right commercial decision, as well, to make, to build it, because they own the asset and then they could roll that out to as many distribution centers and as many partner charities as they wish.

JG: So then that’s a great example of how important it is to do a proper evaluation and all those number exercises to do a proper decision afterwards.

SB: And I think I probably need to say that the FareShare Board of Directors, which are, in charities they’re called Board of Trustees, the way they ran the governance on that was very good. If I’m being honest, they are the people who taught me the value of actually doing all the tests, because they absolutely wanted to know all the business reasons, but also all the costs worked out. So they, I think, did a great piece of governance on that, and that’s something that that governance process is something I’d recommend to everybody, whether a commercial organisation or a charitable organisation, I thought they did a good job on that.

JG: All right. Thank you for sharing that Steve. If you could say, summing it up, the top three advice for people who are now just in front of making the decision, what should they be taking care of?

SB: It’s a big decision because if we’re talking about large systems, you are gonna be living with the consequence of that for a long time, so make sure your team has the time and the skills in order to do it. We talked about the TCO and ROI, and I think, again, although it’s not an easy thing to do, I think it’s a very much worthwhile exercise. And then the final thing to say is that if you’re going into, obviously a built project, doing all your preparation for that is very important, being very clear on what you’re trying to achieve, but interestingly, if you’re buying something in and it has a customisation phase to it, that’s a form of development as well. So again, before you start on the build or the customisation, getting yourself in the best shape possible before that project starts. It is, again, a very good idea and will probably make that project run a lot smoother, regardless of your build or buy decision.

JG: All right. Thank you very much Steve for sharing your thoughts and insights about that. That was very informative and I think that our viewers will like it.

SB: Thank you very much for having me.

JG: And thank you for watching this episode of IT Leadership Insights by Future Processing. If you found that useful, please, please do not hesitate to share it and recommend to your friends and colleagues who might need that knowledge, and if there is anything you would like us to talk about in further episodes, just let us know. Until next time.