Four Goals for an Architecture Review Board
By Jared Hrabak, Consulting Cybersecurity Engineer, cStor
Having a validated IT design is important and takes time to build. Every organization has some footprint of operational IT. In every environment, there is constant change, improvement, broken applications, hardware, networking, patching, etc. Some organizations struggle to effectively implement new technologies and maintain current ones. Without effective planning, you might feel like you are constantly putting out fires, and your IT team has assumed the role of firefighters.
Purpose of an Architectural Review Board
Planning for change can shift a team’s posture from response to effective prevention. The thoughtful and deliberate transition is hard and takes effort to drive the team towards a planning mentality. If you have ever utilized the Eisenhower Matrix then you understand that everything is important and urgent when you are in pure reaction mode. This state of continuous firefighting is detrimental to an organization, its clients and even employees. As technologists and leaders, we should be striving to be effective planners in the important but less urgent quadrant. An Architecture Review Board (ARB) helps organizations be more proactive in making technology decisions and emphasizes teams to do their due diligence.
ARB Mission: Make technology decisions through due diligence.
ARB Goals:
Mitigate risk and impacts
Optimize and control costs
Establish validated design
Prioritize projects
Preparing to Participate in an ARB
Every department that owns or manages some part of the IT stack (YES, security needs to be included) is required to build out its technology roadmap. This includes planned projects for a team to upgrade and maintain the infrastructure of that platform. Don’t forget that the security team will have a big role in this, as hardware and software might go through a lifecycle just like yours. Firewalls may be near the end of life, and the SIEM could need more storage for logs – both need to be considered.
Focus on all individual technologies across the platform and identify dependencies. All of these items should be rolled up and coordinated for requirements from other teams, helping those teams plan and allocate resources that your team needs. This process will also encourage teams to collaborate for shared resources and capacity management.
During the ARB meetings, focus on supporting and improving the organization’s infrastructure while maintaining security. Corporate risk tolerances should be identified so the ARB can understand the cost of acting (or not). These risks will often drive the priorities of the proposed projects.
When building or buying new technology, all of the requirements should be fully considered. A new application may need additional physical or virtual servers, which may strain or impact the infrastructure and/or virtualization teams. The application may also generate excessive logs that would necessitate additional SIEM licensing for the security team and additional disk capacity for the storage team.
Adopting an Architecture Review Board is a start, but integrating it into an operating process takes time, buy-in and effective communication. It will be hard work at first; however, once the process is built it will just entail maintaining that process. The end goal is to build an Architecture Review Board (ARB) that involves all IT and Security stakeholders.
As always, if you need help implementing an ARB or evaluating your IT organization’s processes as a whole, please contact us.
