The case against maturity models
Maturity models are a popular way of looking at development challenges. The problem is that they are an arbitrary and inflexible tool that tend to encourage the wrong mindset.
Maturity models were originally developed as organisational assessment tools. One of the better known and earliest examples is the Capability Maturity Model(CMM) developed by the US Department of Defence in the early 1990s. It was used in assessing the capacity of software contractors to deliver on projects.
Since then there has been a proliferation of maturity models each describing different aspects of organisational capability, from project management to e-learning. These models normally follow a pattern where the first stage has little or no capabilities while the highest stage represents a complete state of maturity. The levels between describe a continuous progression.
The weaknesses of maturity models
Maturity models are often applied to software architecture and development process. They are popular because they promise clarity, though they do have some inherent weaknesses.
Firstly, there are dangers in defining a “final state” of maturity. In the real world any ideal state tends to vary according to circumstances. You may not even want to define a “final state” as it can undermine a drive towards continuous improvement. What happens when you reach the final level of a maturity model? Is it ever safe to stop improving?
Secondly, problems cannot always be defined in terms of a linear progression. Real world problems tend to be subject to obstacles, tangents and detours and rarely follow an ordered path. A good outcome is more likely to involve a nuanced blend of capabilities rather than an arbitrary level of maturity. These capabilities should be acquired in an order that responds to evolving priorities rather than a fixed sequence.
Thirdly, maturity models are prone to becoming obsolete. They imply a static problem domain and do not change in response to the evolving technical and business context. In a fast-changing environment what may be regarded as “mature” today might be old hat by tomorrow.
Finally, the fixed progression in a maturity model can set the wrong motivation. You are encouraged to celebrate the achievement of levels rather than focusing on meaningful outcomes. It's not always obvious what the tangible benefits of these levels might be.
Applying maturity to technology
Maturity models tend not to hold up to much scrutiny when they are applied to technology solutions. For example, the Richardson Maturity Model attempts to analyse REST APIs in terms of increasing levels of maturity. Implementations can range from lowly HTTP based APIs to the full “glory” of HATEOAS-enabled REST.
The intention is to help promote understanding by explaining REST in stages, but the model describes a false progression. It's difficult to “evolve” an API towards a different paradigm. Fully “mature” REST may not be the most ideal end-state if you are taking a pragmatic approach to development. Strict readers of the original thesis by Roy Fielding would argue that REST is an ”all-or-nothing” proposition with no progression involved at all.
Maturity models fare no better when applied to development process. Which of the various desirable technical capabilities should you implement first? Source code control, deployment automation, unit testing, continuous integration or monitoring? The choice often depends on the technology stack, composition of the development team and commercial context. There's no single order in which it is always best to tackle continuous improvement.
Arbitrary marketing tools?
There is often a certain arbitrariness about the way that maturity models are developed. They are often based on one person's view of a problem. The authors of models rarely reveal their motives for creating them or explain what process they use. In the absence of any credible, published design process a maturity model can feel like nothing more than marketing tools for consultants.
Most models have very little empirical support in terms of real-world observation or comparison. They are rarely backed with evidence that clearly demonstrates the relevance of the problem or defines the target audience. This lack of rigor makes it difficult to tell whether a model can reliably help to deliver any improved solutions.
A weak analysis
Describing something as a “model” implies a degree of rigor or scientific method. Most maturity models don't have any formal theoretical basis and are built on arbitrary decision-making and untested assumptions. They may be based on the judgement of “very knowledgeable people” but they can provide a weak analysis, particularly when applied to technology solutions.
When it comes to software architecture, “maturity” may not even be a desirable target. After all, you could be described as mature when you are about to die. This is unlikely to be a feature of a system that has reached a perfect state…