Blogs
The old saying is if everything is urgent nothing is important ...
The old saying is if everything is urgent nothing is important and it is just as true today as it has been in the past. If we continue to make everything urgent when are the important things going to get addressed? We see this often and sometimes it is because the organisation is disorganised but mostly it is because organisations can't prioritise and are not clear on with is important versus being urgent.
We can use the idea of buckets to help with this. The banks concluded some time ago that they needed to prioritise day-to-day running over regulatory change and this, in turn, meant that business changes were third on the priority list.
A more generic take on this is lights-on, security/regulatory changes and then business. This reflects the increasing digital experience that we are offering customers which means that you need to be able to ensure that your core business system are online and available.
The challenge is that when you move to a DevOps model and make the product teams responsible for support this has implications for the operational infrastructure. It must be offered as a service that the product teams can consume on demand. This is a significant change for the traditional infrastructure team which must now change to operate as a platform services team. This may take time to address but it is a critical aspect that needs to be addressed.
The second point is security or regulator compliance and this is heavily weighted towards security these days. The issue here is that you may hear sayings like 'security is everyone’s business' but all too often it is just a saying. You’ll find that security is separate from development and any attempt to move security left to make it part of the development process is difficult.
Here as with availability or lights-on aspects, you need to consider the skills and capabilities of your teams. The fundamental change that is needed is the use of threat modeling as it makes it real and forces security to directly engage in the development process, ensuring that common issues are picked up and addressed.
This complements the standard approach and frameworks that are in use and ensures their capabilities are known and considered as part of the development process. This addresses the issue of these being treated as black boxes and gaps or risk of vulnerabilities not being considered with such an approach.
Then and only then can you start to consider business value.
