Governance sounds dull. But sometimes dull is a much better option than the sort of excitement that comes from realising that you’ve spent months working to deliver a project and have neglected critical elements. Dootrix’s head of DevOps, Mark Vallins, offers some handy tips on how to lower risk through good governance.

How the drivers for projects can increase risk

It used to be that products were sometimes treated as a fast-turn-around, short-shelf-life consumer items and there was an expectation that it would just be a case of build it, ship it, forget about it. These days, the investment organisations make in projects is generally far higher, the risks are consequently greater and the need to manage those risks is taken ever more seriously.

Nevertheless projects are often conceived by the marketing or business development side of the organisation, and those teams can be so focused on business needs that other considerations can easily get overlooked. Even experienced developers can, in trying to achieve a projects stated goals, become highly focused on functionality and lose sight of other considerations.

Failing to think of a project in the round – putting all the focus on functional areas, while essential non-functional areas are overlooked – increases risk. Conversely, thinking more holistically can improve business decision making. For instance, rushing to launch a product in time simply to impress investors may start to look inadvisable if it has implications for governance and risk, whereas if delaying a product launch could compromise a project’s success the risks around governance might look more reasonable.

Whatever the situation business decisions need to be made as to the appropriate level of governance in the light of the timeline. The compromises that have to be made need to be understood and a longer-term plan that goes beyond the initial release needs to be made.

The role of good governance in reducing risk

A key part of de-risking is establishing the ground rules across a number of areas. You want to allow project delivery teams to make good choices about how they manage risk, but also to help them avoid choices that increase the risk profile. And you achieve this through good governance.

Let’s take one common area by way of illustration: security. Without putting in ground rules and governance around security, how do you guide your developers in your project teams to make sure that they are following best practice; that they are putting in appropriate access controls; that they are making sure that network access and protocols are suitable for the job; that the system is as secure as it needs to be for the environment that it's operating in; that they are coding defensively; that they are doing static and dynamic application security testing to help them understand the safety and security of their code?

You might be familiar with the term DevSecOps: development, security and operations. DevSecOps is about breaking down the barriers between all three and saying, ‘Security isn't just a concern in the final release approval for my software – an afterthought or add-on’. It’s something that ‘shifts security left’, i.e. moves it to the left-hand side of the plan, to the very outset of the project. That will mean putting in place measures to track the security of your solution, your code and your deployment throughout the project. And that’s just one aspect of governance.

Another aspect might concern data management and address a range of issues: where you store data; how you access data; where you cache data in the cloud; your compliance with data protection measures such as GDPR; even which region you are allowed to keep  data because of sovereignty laws.

Governance and compliance have a bearing on a lot of these non-functional requirements. It could be as straightforward as using a standard naming convention, so that anyone across the organisation can rapidly identify services, their purpose and their ownership etc., through to those more complex requirements around data governance, data compliance, suitably tagging data sources or applying the correct controls around the flow of that data.

Equally it should mean factoring in other requirements from the outset, such as budgetary constraints or accessibility requirements.

The importance of asking the right questions at the outset

By asking the right questions you firstly ensure that all the issues you should be addressing are on your radar; secondly, you start looking for answers to them. In some situations you might ask ‘What are the non-functional requirements for a project?’ and find yourself met with blank faces. Or you might ask ‘What IT or cloud governance do you have in place?’ and, again, more blank faces.

With any major software/app development or cloud migration project, there are obvious questions to ask, such as ‘What's the software supposed to do?’, ‘What’s the aim of the cloud migration?’ and ‘Who's going to be the user?’.

At Dootrix, our starting point is generally a series of less-obvious questions, as part of our governance, to ensure the various aspects of the project are effectively aligned, such as:

• What's your budget for the operation of this product?
• What are the operational constraints?
• What conventions do you have for naming and deployment?
• What's your security stance?
• What's your networking strategy?

This sort of conversation helps us align our thinking with the customer’s goals and organisational and budgetary considerations, and – if there are things they’ve not factored in – we flush these out to ensure they’re included early. This can prompt the team commissioning the project to go and speak to their people in security, someone in finance, the policy team, and so on, to ensure all necessary stakeholder requirements are factored in. If you’ve started off thinking only about the functional requirements, our probing is designed to save you running into a roadblock later, for instance, when security says ‘Sorry that compromises one of our secure systems’.

Reducing risk is a win-win

So part of the role of governance and compliance is to encourage organisations to think about their projects more deeply so they can make informed decisions about which of the compliance and governance issues that will crop up are critical and need addressing as a priority, and which can be treated more pragmatically.

And that in turn prompts questions about who within the organisation is going take technical responsibility, and how is this team going to work with the rest of the business to make this happen?

Ideally you’ve started these essential conversations within your organisation early in the process but, if not,  part of our duty of care to our customers is to ensure that they take place before projects get underway.

Ultimately it’s in our interest as much as our customers’ to mitigate and reduce risk. Everyone benefits when projects go smoothly and when every foreseeable issue has been planned for in advance. If we help cut our customers’ risk and stress, not only do we also reduce our own, but we’re the first people our partners talk to when they conceive the next project.

Want to de-risk your next project? Find out more about our Azure Integration Services in a day Workshop.