Skip to content
- Detailed, well written and agreed upon requirements are critical
- I can’t tell you how many times a CTO or an architect has said “I’ve found this great tool and we are going to buy/use it” or a security team member/cso likes a particular tool that he/she knows well and just “picks it” without first having written requirements and doing a POC to evaluate each tool against these requirements. It can be “which cloud provider do we use” or “which databases do we use” or “which queuing software do we use” or “which security scanning software do we use”. Never get stuck into the game of “our lead architect loves xyz so we are going to use that”
- Don’t create your own tools unless or until that is the best choice
- I love writing custom tools and dashboards. That’s actually my strongest selling point and I’ve written tools that were heavily used in most if not all companies that I’ve worked for…but that is always the last option. If there’s a way to buy a tool that’s an industry standard and supported and managed by a good vendor, that’s always the first choice
- Regardless of whether you are using scrum or kanban, whether your cto wants people to work fast and “break things fast in production” etc, there are some basics IMO
- alway have traceability between the what (code, infra, configuration changes etc), the why (a functional ticket/details) and the when (when was this deployed to each environment)
- make this traceability data simple and easy to use. Spending hours querying multiple tools to find out “what changed on the first monday two months ago” doesn’t cut it. For those doing SRE or support, quickness and accuracy is crucial. If something breaks at 2am on a holiday it must be easy to find out what changed recently, why and when in addition to the “regular” processes to determine and resolve the problem at hand
- Make the requirements specific and detailed. If a tool is required to have roll based access controls (rbac) and strict security to allow/disallow different people, groups or business units different features or functionality, that needs to be in your requirements prior to an RFP