No one builds their own firewall! Well, someone did, but these days if you need a firewall you simply pick up your catalogue of security tools and choose one. Not so with security data analytics products though, but why?
I’ll get to some thoughts on that in a moment, but more generally, there is a decision that organizations need to make as they plan and develop their security programs - do I build [insert control/technology of choice] or do I buy one from [insert trusted vendor]?
Now security folks have egos and many times those egos scream, “we’ve got smart people, we should just build this ourselves!” As we will see, there are many factors that such an ego driven statement sweeps away too quickly, not least the fact that you hired those smart people to do a specific role, not to build and support a product.
Vendor trust and transparency
Let’s start with what might be considered the elephant in the room: a decision to buy will always be affected by whether or not you trust a vendor. There is an entire universe of security products and vendors to choose from that you need something to help make a selection.
It’s therefore not uncommon to draw on your own experience, and you will undoubtedly have been burned by a vendor (or a few) in the past. Alternatively, you receive hundreds of marketing emails on a daily basis all claiming to solve all of your problems.
What you and the vendors both know (but the latter often choose not to acknowledge) is that an ‘off the shelf’ product cannot meet all of your needs. If a vendor is transparent with this information upon hearing about your needs (assuming they chose to listen), then this can be the basis for establishing trust. It allows you to ask more questions about how customizable or configurable the product is and whether you can make it meet your needs.
It’s still not going to address 100%, and so ultimately you are left to decide whether that’s ok or not?
Total cost of ownership
This is a broad topic but let’s try to set the stage straight away. To choose to develop in-house means to design, build, run, support and scale the product using your resources for its entire lifetime, and that’s assuming you have the technical proficiency in your organization.
Phrased like this, I think the product lifecycle starts to look a lot more daunting. Those people in the organization who shouted “we’ve got smart people…” often only consider the build phase and even then, they are probably not thinking about building the way product engineers would typically.
Repeatable, configurable, extensible, etc. Yes, you are undoubtedly capable of building something that delivers on a specific use case, but what if there are bugs or worse security concerns? What if the users keep demanding more features? What if you build the wrong thing? What if it takes longer than you thought to develop? The weight of failed in-house data analytics products speaks volumes.
Despite this, the problem is particularly acute for a data product, and I point the finger squarely at you generic spreadsheet tools and BI products (as well as bad Hadoop implementations)! The ease with which users can manipulate and present data means that the value they place on end-to-end data products is diminished. It’s easy for your smart team to look at a dashboard product and state “I could build that in…” but fail to consider that the product manages the ingest, cleaning, transformation, modelling, presentation and interaction. Not to mention as well as monitoring the health of the whole application so that the analysis is automatically generated and can be trusted.
Now, off the shelf products aren’t immune to additional costs as you’ll be aware, but with a trusted and transparent vendor you will go beyond the simple license costs and look at what extra costs there are to deliver the target operating state and make the costing predictable.
They should be willing to work with you to develop that understanding. In doing so don’t forget to factor in any efficiencies gained through product adoption and the increased speed to value that the organization can derive from getting up and running quicker.
Factoring all of the above into a TCO calculation would, depending on the exact use cases, point to doing it yourself working out more expensive over time as budget overruns and recurring maintenance costs add up. Pre-built software makes these costs transparent upfront.
Pooled knowledge and expertise
Your business might be different, but much of the security framework you deploy will share characteristics with those of your competitors as well as other companies. Security is still to emerge as a real competitive advantage, and there is much wisdom in the shared experience of others helping to improve the industry.
To that end, product teams canvas the views, pains and experience of a much wider pool of users and can offer perspectives and insight you hadn’t thought off or hadn’t gotten around to thinking about. Add to that the technology and data experience, and if the vendor can string it all together, there is no reason it shouldn’t be a compelling product.
It all comes down to the execution: true that they don’t know your business, and that’s where the real value of product management comes in by making something that is repeatable through configuration and customization and whose value can be unlocked by an excellent customer success team.
Vendors often forget that many of their customers are experts in their field - just listen to how many pitches set the scene with a 15-minute problem statement that is universally acknowledged. Customers are looking for answers or tools that help them get the answer. However, customers need to also reflect on the fact that product companies are often started by experts that have felt the same pain and wanted to help solve the problem universally.
The decision to build or buy should be an informed decision where all parties have as much information to hand as possible. In the end, only you can decide to build or buy but at least make the decision with confidence, which comes from being as informed as possible.