Make or Buy? A Structured Framework for Smarter Tech Decisions

If you say, I am just building this capability and no matter the cost or no matter the other perspectives, and that means no matter what I leave out, that is the thing that is dangerous. So when I miss the risk and security aspect, for example, this cheap solution can quickly turn into a security risk, quickly turn into an open attack, turning into a breach, turning into much more cost than thinking about risk and security by design. Welcome to the KuppingerCole Analysts chat. I'm your host. My name is Matthias My guest today is an analyst and advisor with KuppingerCole Analysts.

Before we go into more detail, first of all, welcome, Phillip. Good to have you.

Yeah, thank you for having me. And I'm excited to share my knowledge and my experience on Make or Buy today. Right. You highlighted that already. But to show the origin of what we are talking today about is that you actually bring together the two skills that people working with and for KuppingerCole need to have. One is the advisory work. So talking, working with our customers, our clients, supporting them in decision making processes.

On the other hand, the writing exercise, the analysis, taking one step back and looking at what have I learned from several engagements, what have I learned from several vendors where we as analysts can shine. And this is what you mentioned, make or buy. And that is a question that sounds simple. The question is, and we support organizations all the time with two choices, how we call them.

So RFI, RFP processes to identify the right solution. The question is, why do I have to buy at all? Can't I build that myself? And that is what we want to talk about. So first of all, is this a simple question?

No, absolutely not. I mean, you can make it a simple question, can say the right or the left way. But in the end, it is much more complicated. So what seems to be a simple operational question, do I want to buy something or make it myself? Becomes much more complicated if you have a structured approach. Right. And the structured approach, I think this is taking a step back. So why do organizations actually struggle with that decision?

What is the challenge that they are facing where we can support you with the organization or where such a document, such an advisory note that you've written, which is the result of the research, how can that support them? Where are they struggling? So when we think about that topic in general, the idea originates somewhere. And this somewhere has a certain perspective. So let's think about a business unit that requires a new solution. They will have a certain perspective. If that comes from a security team, that's a completely different perspective.

Same for IT, same for other units that have different perspectives. So definitely the questions that you ask heavily depends on the perspective that you have. So in the end, the business unit is focusing more on functional capabilities and in general stuff around that, while the security team is asking security questions and for requirements in that regard. And the IT team cares about the deployment and how to operate that thing. The complex thing about that is who is asking the questions first and which perspective is the primary perspective.

Yeah, I think and also to make it more tangible, of course, we are equipping a call. We are dealing with customers who are heavily invested and looking into identity and access management, consumer identity and access management. So the question is, do I need to buy a solution that is covered in our leadership compass and hopefully in the upper right corner of such a diagram? Or can I build that myself? So what are the assumptions that you typically hear when it comes to even asking that question? What is behind the effort? Is it money? Is it security? Is it feature completeness?

Or we are so special, a regular solution won't fit our requirements? So overall, I think it's a mix. What I often hear is the question around the cost. So we can do it cheaper. We can develop it ourselves. The product that we would be able to buy is very expensive. So it would simply be cheaper and faster to do it ourselves. That is one thing that I would expect. But I would expect that such initial decisions that are in the back of their minds somewhere have blind spots and are a bit biased. Because they will tend to one or the other to say, okay, yeah, buying is easy. I get service.

I get a solution that is tried and tested and test-driven. On the other hand, to say, okay, let's build something that really suits our needs. And both will be biased decision-making processes, right? Absolutely.

As I said, the perspective is the most important thing about that. So when you have buyers that come in with the idea of, hey, we can do it cheaper, they have this perspective. They are focused on just this dimension. And sometimes they are simply forgetting about the other dimensions. So focusing on, in this case, make based on, I need to have low effort to do that, is very minimalistic in the end. And such an approach usually falls short in other dimensions. And the same way when we think about buy, but from a different perspective.

Going back to your research, and I think because having that research needs to be expanded in experience that you had, and I know that you have several projects around that in different areas. So it's not only IAM, but it is IAM as well. What are the biggest mistakes that you see that can be done and that should be prevented and where you try to support the organizations with?

Yeah, I mean, as you can already guess, one of the biggest mistakes is to focus on just one perspective. That happens very often, actually, because the idea starts somewhere and those people are making a local decision for themselves. They are saying, hey, for example, the business unit says we need a functionality, so we put a tool on top of that, regardless of IT, of the security aspects, of the organizational fit, of probably the budget is least important because business usually cares about the budget. But I think you get my point here. So this is definitely one thing that I see a lot.

And what is even worse is that those cases often result in, hey, if we can't make it, if we want to buy a solution because we have seen that it looks fancy, it's nice, they have in mind we want to have this solution. So even if they go into a formal process of buying something, they have in mind, I want this solution. And if there is a formal process with procurement and asking vendors and so on, still they have in the back of their minds, there is this solution. So make the process end with the result that we get this solution. So this is a recurring challenge. Right.

And I think there are also lots of emotions in there because this make a decision that does not come out of thin air. That is something that is most probably, these are my guesses, but somebody built a prototype, somebody scribbled something, somebody created something and hey, let's work. It works fine. And look at the performance and it's running in a nice little container on my Kubernetes platform. Let's continue working on that. So there are tons of emotions in there as well, right?

Yeah, I mean, what we can see at the moment is that there are a lot of organizations that have experienced T-people and they basically say, whatever the vendors are giving me, I can do it better. I can do it with open source. There are no operating or lower operating costs in the back and we are much more flexible. So they build an MVP within less than a week just to fix a certain problem, regardless of the security risks in the back, regardless of the questions, regardless of the strategy, how to maintain that over a longer time.

Going back to strategy, and I think now that we are 10 minutes in, I think we understand the challenge quite well. So it's really to say, okay, as you described, do I buy something just off the shelf and configure it a bit and this will work and I have support and everything like that, or I'll do it completely myself. So we have our shiny personalized solution available. This is understood. The question is, we need a strategic approach and this is exactly what you lay out in your document.

As we are analysts, we try to create a proper, full-blown analysis that covers all angles, all perspectives. What are these perspectives? I've seen you came up with six evaluation criteria. What are they, at least? As you said, I have six evaluation criteria. They are organizational environment, technical features, functional capabilities, risk and security, contract and finance, and future proof. All of these cover different perspectives to ensure that these questions are asked in the process for make and for buy. And every of these criteria have a different focus.

So it's simply important to have them in the back of your mind when you are making a make or buy decision. Right. Okay. Then let's walk quickly through that organizational fit. What are the questions that need to be asked in an advisory situation or when they read the document? Why is organizational fit so important or isn't it? It is absolutely important because you need to ensure that you are able to support your organization to use the solution. And that's an important thing, especially from the perspective when we talk about usability and how the organization accepts that solution.

So how is the user interface? Are my users willing to work with that? And if there are any questions, what kind of support do I offer? So am I able to support it 24-7? Am I able to support my user with certain questions and incidents? Do I have the capacity to do that? And in the end, do I have the knowledge to do that? Because when I start building a solution, I have the experience, I have the knowledge, probably, but at a different point in the organization, at the developer side and not at the support desk or help desk side.

And that might be different for a buy solution where knowledge is more available and there are services out there that would help you to support that. But that in turn would mean that a solution that is technically better, that is homegrown or bought from the market still becomes the wrong business decision, right? If it is not accepted, it can happen that people are simply not using it. If they are not understanding it, if it feels unintuitive, if there is no support, no learning concept behind that.

And if you are not able to help your users to find a way to use it, then it's not accepted and then it's not used. Right. And I think it's a great idea really to start with the organizational topics rather than, second question, technical. You've mentioned that as the second point, because if it does not work for the organization, it doesn't matter if it works technically. So coming to technical features, of course, ideally, especially those who are actually building that solution, people are interested in technical features and what is state of the art or what is expected to happen next year.

But the question is, what technical features do you need to look at when you are preparing such a make-or-buy decision? What is key? When we are asked for support, we often work with enterprise architects and those people are quite interested in the new solutions and what they can do, how they can be deployed, how they can be set up. And later is the question, how can they be operated? And as an enterprise architect, one of the most important things is, how do they fit in my landscape? So another solution as island somewhere is not really helping my organization.

If I have manual processes to transfer data, if I have another silo of data, if my data is somewhere, because one of the topics that is becoming more important lately is data sovereignty. So these are questions that you need to ask and you need to ensure that it fits into your technology stack to make sure that it is well integrated and then it can be properly used and monitored and operated. So the wrong technical decision can lead to hidden efforts, even to preventing the solution to be deployed properly, right?

Yes, and it can lead to massive additional efforts. So let's imagine we have a business unit that is not caring about the technical background. They just buy a solution or, I mean, obviously a business unit will not make the solutions by themselves. But if they buy a solution, put this solution somewhere. We have that, especially in the times of software as a service, already seen a couple of times, very often actually. And they need somebody to operate that solution in the end. And this is usually then where the IT people come in and say, there are no connectors.

I have no chance to integrate that. I have a solution that I don't know. I need to operate that somehow. And I'm not able to apply our standard security procedures. What do you want me to do here? This is an island somewhere. I have no experience with that. And this is something that you don't want to have in your organization. Right. Next step. So we looked at organization. We looked at technical platform decision-making processes, and we do not talk whether we are specifically focusing on make or on buy. I think this applies for all solutions that they are comparable afterwards.

Next step would be functional. So the functional requirements from an organization and what the solution needs to implement, I think they are key. And when we want to prevent organizations from making mistakes in decision-making processes, why do feature comparisons often become misleading in that aspect when comparing make with buy?

I mean, I've already explained the idea of the business is making a decision. They see something shiny. They buy it. They don't care about a different perspective. So of course, as you stated, it is a very important aspect, if not the important aspect. I agree So especially when you are trying to replace an already existing solution, you need to ask yourself, are these capabilities that I'm trying to replace the right capabilities? Or is there something else that I'm missing? Is there something better out there, meanwhile, that I can replace my old solution with?

And this is something that you need to be aware of in the moment you do that. But also the solution that you are bringing in will be there for some time. So you need to be aware of what will happen in the future as well. Right. So in the end, there's also this old discussion between standardization versus customization comes into play. Do I really need a four-step approval process? And do I need that to code myself or to build and customize in a commercial solution? Is it also maybe the idea of maybe taking a step back? There are standard processes. They are there for a reason.

Maybe they are good. Maybe I should just use them. Might that be a thing to consider as well?

Yeah, absolutely. I mean, when we talk about functional capabilities, and there we have a distinction between make and buy. When we think about a buy solution, there are usually out-of-the-box standard processes that often offer a quick way to deploy processes and use them in a standardized way. On the other hand, we have a make solution, and there I can, I'm free to do whatever I need, customize it until it fits my requirements. But that is also a challenge.

Okay, next step. We are running out of time already. So let's focus on the other three aspects that we need to look into to get to a proper solution.

Security, compliance, risk management. I think they are not completely different between both aspects, between make or buy, but they are different. So the question is, where do the requirements of risk and security come into play when making such a make or buy decision? And where are typically the wrong decisions made based on wrong assumptions again? I think risk and security is an interesting topic when we think about make or buy.

While we have these perspectives of businesses that I need a certain solution or I need a certain capability, not really many people from the business think about risk and security. And for make or buy, this is an important piece that we need to think of. If the business is coming around asking for a solution for a certain challenge, they usually don't care too much about risk and security. When we think about risk and security, people are bringing in this perspective and these requirements.

And this is something that we've often seen when you have the make decisions, that risk and security is not a major focus. For buy solution, you have a certain level of risk and security built in automatically, because that is a solution that scales off with other organizations. And sometimes or often these organizations are regulated as well. So this is something that secures a minimum level of security.

I think if you create a solution yourself and the next regulation is just around the need to implement additional capabilities that are not functional actually, but actually enable you to be compliant to the next industry specific or global regulatory requirement. Just think of GDPR when you're building an IAM solution or a CIM solution and making that yourself. That can be challenging while a commercial solution might have that already in the basket when they come around and provide such a solution.

So I think that's really an important point to actually understand the requirements good enough to make a proper decision towards make or buy. And you've mentioned non-technical and non-organizational facts as well. So the fifth point was contract and finance. This is something that when we do leadership conferences, of course, we look at the strength, at the financing, at the recent acquisition history of a vendor.

But how do you compare such an information for a vendor with a homegrown self-built solution when it comes to finance on the one hand, but also contractual in the end service delivery, right? Yeah, absolutely. When you think about the initial thought of I have a problem, I need a solution. I need it quick and I need it cheap. And this cheap aspect, that is really a criteria that is often asked for. So we need a cheap solution for our problem. The point is that especially when we take a closer look to make, this cheap part includes or better excludes certain risk and security thoughts.

It excludes certain deployment of support ideas. It excludes scalability aspects. So this cost aspect sometimes costs you important capabilities, important aspects of the solution. And a buy solution on the other hand is usually more expensive, but comes with a bigger basket of capabilities of topics that are covered, comes with a certain development speed from experts that know what they are doing in the background. That means about cost, you also have the speed aspect in there as well. So how quickly can you adapt certain challenges? Right.

And these are the solutions and the challenges that you understand right now. And I think that goes perfectly hand in hand with your final criterion, which is the solution being future-proof. This sounds like something, yeah, let's look into the future and pick out the crystal ball, but this is not true. We are talking about new technologies, new application systems that need to be connected to an IAM. Organizations change, thinking of mergers and acquisitions, which might raise really new requirements or just, as I mentioned, regulations that change.

So looking into the solution being future-proof, no matter whether it's commercial or a make solution, is essential and it should be started with the decision-making process at day one, right? Absolutely. And when we think about most tools, the lifetime or life cycle of those tools is measured in years and sometimes even decades. So let's assume we have that tool for the next 10 years. What we see very often, especially with make solutions, is that they are replacing already existing solutions.

Meaning, if we have the wrong perspective, we are just talking about capabilities of today. We are not talking about capabilities of tomorrow or in five years. And that is really a challenge because you need to be aware that the whole landscape is shifting, is changing. There are new capabilities, new threats, new topics. And we have seen that at EIC approximately a little bit more than a month ago, that there is a lot of movement, especially in the IAM market, and vendors are reacting to that. In a make solution, you have to do that as well.

You need to be aware that there is a cost position that means development for the future. And that needs to be done. You need to have that on your roadmap. You can't say, I developed that now and this will hold for 10 years without improvements. I think that's an important question. You also need to have the right people in place to do that, the right solutions and the understanding of technology.

Vendors, they are forced to do that. The organization is also forced to do that. So there needs to be a constant evolution of the solution. This decision-making process with the six dimensions, this is all laid out in your document. We don't go into more detail, but there's of course a way to get to a scoring, to a mathematical approach to understand, okay, I can understand and assess these six dimensions and get to a recommendation based on your document. All in there, but we don't mention that here. I'm much more interested in real life experiences.

When you develop these criteria, when you apply them within organizations, what are the lessons that you've learned from real projects that in the end also made you write this document? What surprised you most as a starting point about make or buy decisions? What was the main outcome that you saw as a pattern or as an anti-pattern?

I mean, I've already mentioned that a little bit. The most impressive thing is how many people think that they can do it cheaper and faster than a vendor. And that fits very well with the aspect that I mentioned also earlier, the perspectives. They are focusing on a single perspective, ignoring everything else. So I'm cheaper, I'm faster, I can customize it more. And they go with that. They focus on this one thing, they deliver exactly that capability and at the cost of everything else. And that is very impressive how often that happens.

Another question that I really see is, okay, I once opened a presentation with a saying that there will always be a simple solution that is easy to understand and wrong. So that's why I'm not a big fan of rules of thumb. But if you want to get to something that gets close to such a rule of thumb, or you contradict me, there is none. What are the strongest arguments, the strongest points you can make for building internally? When do you think it's even worth thinking about it? I would say it's less about when, it's more about the how.

Usually make can be cheaper, make can be more specific, it can be more targeted. So vendors are building for more than just one organization. They are building capabilities that you as a single organization might not need. So in a buy solution, you would obviously finance these capabilities that you might not need. For a make solution, that is different. You can build what you need, you can use what you need, and you can leverage that. The how is much more important for me.

Because if you say, I am just building this capability and no matter the cost or no matter the other perspectives, and that means no matter what I leave out, that is the thing that is dangerous. So when I miss the risk and security aspect, for example, this cheap solution can quickly turn into a security risk, quickly turn into an open attack, turning into a breach, turning into much more cost than thinking about risk and security by design. So in the end, it could mean you implement what you want, but you not necessarily know what you want. So that might be a challenge in that area.

Rule of thumb for the other side, when is it typically the better solution to lean more towards buy? So buy is better for you if you don't have the experience or if you don't have the people that know the topic very well, if you don't have the developers that are covering all the perspectives or not just developers, but the people that are able to cover all the perspectives.

What the buy solution will help you with is having a good basket that is covered from all perspectives that are not organization specific, obviously, like is it an organization that is something that you still need to figure out? But buy solutions come with a couple of capabilities. They have a couple of deployment methods. They have different ways of setup and support. They come with a good stack when it comes to risk and security. And that's what you are buying from them. That's what you are paying for.

Another important aspect when it comes to buy that I think is very important is also speed and the constant development forward. So for every vendor, there is a roadmap and they are moving forward. And the interesting thing is also the scalability. So if a vendor is developing a new capability or a new feature and you measure it to protect you, this is not just done for you. So you are not the only one taking or caring for the cost. That is in terms of scalability, you are one of many. And that can also be a very important point here. Absolutely.

And I think it's an interesting and the fact that there is not a document that says, oh, don't build yourself. Oh, don't buy. That there is a document that supports in making the right make or buy decision actually shows that there is no universal, perfect, correct answer for each and every organization, for each and every tool. So the final recommendations that you would give in supporting organizations in making the right decision, of course, A, would be read your document finally.

But on the other hand, what would be key takeaways that you would give as a final recommendation now that we're getting closer to the end of this episode? I think the first one is very clear. So the first one is that there is no universal answer. You said that just yourself, there are situations you want to make the solution yourself. There are situations you simply can't. You want to buy a solution for different reasons, but there is no right or left from the beginning. It really depends on your situation and on your appetite and your situation. Right.

So when we get to final recommendations and to taking the next steps, if there is something to take away from this episode, one thing that I can recommend, but I really want to do that, and the link will be shown below, you did a great series of LinkedIn posts around that. So you don't have to go to kupingerkohl.com, but you can go to LinkedIn. You should go to kupingerkohl.com, but you don't have to, to read the LinkedIn posts that you had. So it's a series of episodes that build upon each other that take you on that storyline that we walked through in this episode as well.

So this is highly recommended, a good reading. And there are also comments below that that really go into more detail. So this is highly recommended. And another question that I have towards you is what should be a change in the mindset within an organization when they approach the next make or buy decision? What should they keep in mind as a learning from what you just explained and what you did in your analysis? So I think when it comes, when you are in such a situation, the most important thing is to prove or to approach that process in a structured and transparent way.

And this is what this framework is offering you. It is offering an holistic approach so that you can ensure that you are not missing one of the perspectives and that you can prove, Hey, I have a holistic approach. I thought of everything. I've answered all the questions and that's why I have chosen make or buy independent of what the result is. The important thing is whatever you choose, the resulting choice will be better than doing it without a structured approach. That's what I'm convinced of. Okay.

I'm fully convinced of that because I think this is a question that is not often answered and providing a right and a proper framework for getting to the solution and that supports you in making your own decision and the right decision based on the right criteria. I think this is really something new. For those who are, I have to admit this is an advisory note, so you need to be a subscriber of KupingerCole services. You should be anyway, but if you're interested in the material on a high level, please use the LinkedIn post as mentioned before.

And on the other hand, this is something where we support as well. And if you're, this is a test, but let's try that. If you're interested in that document, maybe you want to reach out to Philip by mail. It's phm at kupingercole.com. And maybe there is a chance that you get access to that without a subscription. And maybe that convinces you to have a subscription because you should. Final sentence, Philip, before we close down, what would be the other next steps or is this something that is built in stone? This works. We are convinced that this is the right approach.

Well, this approach offers you some flexibility when it comes to the criteria and to what you are evaluating in the end. So it's not built in stone, but I'm still convinced that it offers you a transparent, well-structured and aligned approach for your decision in the end. And that's, that's what it is all about. Right. And thank you very much. I fully agree. And I think this is really also something where, and this is a bit taking pride into what we do. This is where kupingercole can actually shine.

We derive analysis and research from our advisory experiences and map that to the, to the overall principles that we apply in our advisory work. And I think that is a good, a good, not mixture. It's a good essence of what we do at kupingercole. So that was the 30 seconds pride section.

This, I think this is something that I think only we can do because we are not trying to sell a product or convince you of doing make, but making the right decision. And that is, I think where we, where we can shine.

Thank you, Philipp, for being my guest today, for sharing your experience, for writing that document, for providing guidance in such a difficult process. I'm looking forward to having you soon in the next episode. Thank you. Yeah. Thank you for the questions and a good conversation and the opportunity to present my, my learnings and my experience. Thanks. Looking forward to the next episode. See you. Bye-bye.