When it comes to software delivery processes, governance processes such as architectural governance boards can often be perceived as a hold-up to software delivery processes, so when a project is slipping against its forecast timelines, such processes can become the easy thing to blame (along with any other process that engages beyond the project team). Sometimes, the slip is happening for very good and legitimate reasons in these situations it is just very hard to defend the slip.

There are a number of things we can do, to simplify and streamline the process. One of these is the use of decision matrices – something I’ve written about in the past (Decision Matrix aka ‘Stress Test’ as a vehicle to make decisions easier). The value of the decision matrix when it comes to governance is that it can be used as a catalog of pre-approved solution approaches. Let’s give an example; we could provide a decision matrix to select the best type of application server, which perhaps covers whether a micro profile framework is used and which ones (e.g., Helidon but not Payara because of the support agreements in place) vs. J2EE (and again reflecting decisions relating implementations such as WebLogic but not WebSphere). Then when a team decides on the implementation or developing a roadmap, if they are working within the matrix’s guidance, then the decision could be approved on the spot by any member of the governance team. With the approval given by just checking the approach being adopted is sensible.

If the solution falls outside of the decision matrices recommendations, this comes down to one of the following reasons:

• The approach represents a good approach that could and should be applied within the domain but not yet captured in the matrices – therefore, the matrix needs updating.
• The solution makes sense and follows common industry strategies and/or tools but is addressing an outlier/anomalous situation for this organization – therefore should go to governance seeking a dispensation on this basis. In this situation, it is would beneficial for the designer(s) to highlight the case for dispensation. By highlighting how the existing decision options do not fit. In effect, sharing the assessment of the relevant matrix(ices) against the problem.
• The approach reflects the development team’s preferences rather than perhaps aligning with the organization’s needs for the ability to maintain technologies. For example, keeping development language in use to the top 5 commonly used languages according to TIOBE rather than adopting a niche language such as Haskell or avoiding languages that have a reputation for being difficult to maintain, such as Perl. In these situations, a careful examination of the case is needed by any governance process.

What we are effectively doing is making the decision matrix not only a tool to help developers select the most effective options (given the ability to standardize approaches raises the chance of possible code reuse or refactoring to reuse) to being a way to lighten governance, or the perception of governance. Whatever mechanism is used to record decisions by a team just has to reference the decision matrices.