Adding tools without proper design and planning results in double work and wasted money. I often compare implementing a new security tool to building a house. Building a house without proper design and architectural thinking may expedite the process, and in the short term, it can shield you from the sun and rain. But eventually, even the weakest whirlwind can force you to reinstall the entire roof from scratch. Not working smart is working twice.

Is Cybersecurity Architecture Necessary?

Let’s be honest: many people think that architecture in cybersecurity is just a bureaucratic position that provides little value. In reality, cyber architects play a key role in integrating new solutions into the existing cybersecurity program. Architects are a perfect example of why looking at the forest, not just one tree, matters in cybersecurity.

One of the biggest challenges for every organization is to keep evolving as fast as cyber threat actors do. I remember the first time I went to Black Hat: lots of vendors, lots of solutions… lots of promises. People are very creative when it comes to fixing problems and finding common issues across multiple organizations. Like me, many people have acquired security tools to fix one problem, and that’s fine. You should fix one problem at a time.

But when it’s time to implement the solution, people often get excited to see it working, which is understandable. Everyone wants to start seeing the return on investment as soon as possible, so they often skip the design and planning stage and move directly to a plug-and-play approach. This can be fine for a proof of value phase, but in the long term, implementing a security tool without proper planning and design can bring a lot of unexpected headaches.

Manage the Tribal Knowledge

“The guy who implemented this already left the company.” I’m sure most of us have heard this a few times during our careers. For some reason, people in IT are not known for being the best at documentation. This is where a proper architectural process plays a key role. Imagine that when you build a house, you have the blueprints. Years later, if you need to repair or install something new, you can reference those plans instead of breaking walls to find where the tubing was installed.

It’s the same in cybersecurity. It’s impossible to eliminate tribal knowledge completely, but at least it can be managed better, reducing dependencies on a few people who are the only ones who know how things were installed.

One of the key responsibilities of cybersecurity architects is to create relevant documentation that can later be used as a reference to understand the product’s key components and how it integrates with the rest of the environment. This documentation can be as simple as an integration diagram or a short document that explains all the moving pieces and how they work together. During my brief time as an architect, this documentation was also a formal deliverable of the integration project, shared with customers during the transition from project to operations.

Bringing Architects into the Discussion Avoids Wasting Money

People get excited when it’s time to spend money on a new toy. But depending on the size of the organization, visibility is often limited to only the process someone is in charge of. I recall a time when a security tool required integration with a CMDB, and the people buying the product didn’t even ask how the integration worked—or whether the tool was compatible with the organization’s CMDB solution. While the integration was eventually possible through a workaround, the time required wasn’t considered during implementation. That challenge could have been a decision point for selecting another product.

Most security tools enter your toolbox to fix one problem in the short term, but the short term should not become permanent. In the long run, security tools need to remain integrated. What does this mean? In the first weeks, integration focuses on proving the tool’s value, but not on exploiting its full potential. Especially with integrations, some components require manual intervention. Over time, however, additional integrations can expedite processes and enable automations that make operations more efficient.

Too often, tools are not integrated. People pivot from one tool to another, run manual queries, and dig through multiple repositories of information to complete an investigation. Features remain unused or poorly implemented. Sounds familiar? It’s not uncommon.

Unfortunately, buying security tools and pushing them into operations without design and planning inevitably creates double work in the future. And in cybersecurity, with threats constantly evolving, the last thing we want is to work twice. So why not do it right the first time?

Remember, installing tools without proper design and without understanding operations is just like installing a toilet in the kitchen.