Frankly Speaking 9/6/22 - Stop thinking about "build vs. buy"!
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
Happy Labor Day everyone! It’s crazy to think that summer is already over.
Quick plug. I’m speaking at a LinkedIn webinar with the CEO of one of my old portfolio companies, Appdome, on Wed, Sept 14. We will be talking about the future of DevSecOps and SOCs, a topic that I’m personally excited about. Come join us!
If you enjoy my content, consider spending some of your professional development budget subscribing to it!
LET’S BE FRANK
Those who know me know that one of my biggest frustrations is around the build vs. buy question. Ok, that’s not entirely fair. I do think theoretically, the build vs. buy question is important, but with all theoretical concepts, in practice, the concept doesn’t work out. The core reason it doesn’t work out is that the question is used lazily.
What do I mean by this? Many times, when I talk to a security leader about a problem, they almost immediately jump to the build vs. buy question. Specifically, they say, “we should think about whether we want to build vs. buy.” I agree we should think about it, but we shouldn’t think about it at this point in time. The leader hasn’t fully understood the problem and has prematurely jumped to asking questions about the solution.
To start, you need to first scope out the problem you’re trying to solve. For example, I regularly talk about authentication and access issues being common and critical issues in most organizations. If you were to ask the “build vs. buy” question, it wouldn’t be productive. Do you buy Okta, Teleport, Auth0, or use AWS’s IAM feature? All these products solve different problems, and you can probably need to have a version of them at some point in your company’s lifecycle. However, what problem do you want to solve first? Is it a customer authentication problem? Is it an employee access problem? What is the problem?
With that said, let’s say you want to solve the customer authentication issue. Then, it might be easy to say “just buy Auth0.” Unfortunately, you can’t call up Auth0, buy it, and your customer authentication problem will be solved overnight. I wish it were that easy!
In fact, Auth0 might not even be the right fit for your organization. Auth0 just provides APIs for basic authentication features, such as MFA, SSO, user/password login. However, your organization might have custom needs that require a fair amount of modification on Auth0. Maybe, it will require a lot of refactoring for Auth0 to work, and it might be an easier engineering effort to build your own because there are engineers more familiar with your auth system than with Auth0. Moreover, Auth0 might solve a small slice of your problem, but there are more problems where you might either need to buy another product and/or build your own. The problem just became more complex.
It’s important to figure out the requirements for your problem and/or product before deciding to build vs. buy. Rarely, is it that white and black. Even with products you buy, there will be some building and maintenance. You can also buy the basics and do most of the building. It’s important to figure out all the main stakeholders and understand their constraints before even posing the question. Then, you need to figure out the effort to procure and fully implement the product so that you get the most value out of it. The tragedy (and I see it often) is that after products are bought, they are never fully implemented. They either end up sitting on the “shelf” or are displaced because the organization doesn’t see the value even though its full potential was never realized.
My theory of why security tends to jump to the “build vs. buy” question centers around the fact they tend to be siloed and isolated. In my last newsletter, I talk a bit about why I think this is true. They usually act independently and don’t interact much with engineering. However, that cannot be sustainable if an organization wants to have an effective and efficient security organization.
It’s hard to estimate the effort and resources required if you don’t know the requirements. Where security teams and leaders fall short many times is that they think buying a product will solve a problem overnight without fully understanding the problem. It’s important to understand the business and product requirements around a problem. Also, with all problems, is that really the fundamental problem you want to solve? That can allow you to be more strategic in how you plan to solve and properly resource various problems throughout the organization.
But I get the temptation! It’s easy to face a problem and immediately want to buy a product that solves your problem. Everyone, including me, falls into the trap, but rarely are products as turnkey as that. It’s because different organizations have different goals and problems. However, good products are “general” enough to solve similar problems for many organizations. I find those types of products to be rare, so it’s better to assume that substantial work still needs to be done once the product has been procured.
Effective solutions are nuanced. They usually involve some combination of people, processes, and products. Many times, the people and process aspects require more work than any technical aspect of the solution. It’s important to realize this as a security organization or else, you might be oversimplifying a problem or reaching a solution that will be ineffective.
“Build vs. buy” is a lazy approach to thinking about security solutions. It will lead to ineffective solutions and cause a ton of frustration throughout the organization and with various teams. Solutions can be complicated and nuanced, and it’s important to understand the problem properly before thinking about what products or engineering effort is needed to solve it. In my opinion, doing this will allow you to have a more efficient and effective security organization.