Architectural governance – decision matrices as way to reduce friction

24 Monday Jul 2023

Posted by mp3monster in Enterprise architecture, General

Tags

architecture, decision matrix, governance

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.

CI/CD worker nodes as virtual machines or K8s Containers?

07 Wednesday Sep 2022

Posted by mp3monster in General

≈ Leave a comment

Tags

architecture, CICD, Containers, decision matrix, devops, jenkins, maven, reference architecture, stress test

When it comes to CI/CD deployments, something that doesn’t show very often in documentation is the pros and cons of running your worker nodes as containers in a Kubernetes environment or as (virtual) machines in a cloud environment.

Continue reading →

Decision Matrix aka ‘Stress Test’ as a vehicle to make decisions easier

02 Friday Sep 2022

Posted by mp3monster in General

≈ 2 Comments

Tags

Decision, decision matrix, factor, matrix, stress test, stressor, tree

We’ve all encountered decision trees at one time or another as a means to determine an answer based on a set of inputs. The problem with decision trees is that they are binary in nature. The answer is always yes or no.

From http://www.stodolkiewicz.com/2020/04/27/decision-trees-introduction/

But life is not binary. This is often best underlined by the classic joke of asking an architect what the right thing to do is, and you’ll get the answer ‘it depends‘. The art of being an architect is working out what the right trade-offs are when coming to a decision. This is fine, but to know all the factors (or trade-offs) that need to be considered requires a wealth of experience (a rare and expensive asset) or someone capturing these insights in a consumable manner that enables people who will understand how to use imparted wisdom, rather than try to blindly follow binary decisions.

This is where decision Matrices, or as I was introduced to them ‘Stress Tests’ – so called because the matrix is made up of a factor or ‘stressor’ are tested against one or more options. Each slot in the matrix can either be marked as yes/no or scored on the range (for example 1-5) on alignment to meeting the stressor. If you’re doing a product selection then the options are the different products. But equally the options could be an architectural pattern.

This is probably best illustrated. So the following Matrix looks at different programming languages against a range of different stressors. This isn’t a realistic case, but sufficient to help convey the idea. (The assessments in this matrix are not comprehensively researched, so feel free to argue)

	Java	Python	Ruby	C++
Single binary for multiple OS and architectures	5	5	4 ¹	1
Language evolves quickly to provide standardized libraries for common needs	5	5	4	3
Suitable for scripting and application development	4²	5	4	1
Readily available skills	4	5	3³	3³

Ruby has several variants such as JRuby, Ruby with a C core – this has the potential to impact
Use of Shebang or overlaying with Groovy makes Java more usable as a scripting language
Not so commonly taught in educational settings which typically favor Python and Java

As you can see to help use the matrix we can add elaboration notes. To use the matrix we simply determine which stressors are most important or not and then score the different options. So if I wanted to use the matrix to determine which language is most suitable for developing a deployment utility then we know from the use case performance is less critical, portability is important, and skills should outweigh language evolution. Based on that the answer should resolve to Python failing that Java would be good enough.

While our question and its outcome is fairly obvious, in more nuanced situations the stress test gives several benefits:

The decision process becomes transparent and easily communicated.
The hard work is in developing the stressors and researching the different options in terms of how they fit with stressors.
The matrix can be re-used, to help achieve other decisions. What if I was looking at the most suited solution for running data analytics that can maximize GPUs?

Through the use of the stress test we can translate the ‘it depends‘ to a more concrete but rationalized decision.