Software Architecture Metrics

Chapter 5. Private Builds and Metrics: Tools for Surviving DevOps Transitions

Christian Ciceri

Many people think of software architecture as a craft, but I understand it more as a science. Scientists tend to measure things as a basis for further reasoning. Even when you can’t get precise numbers, mathematical approaches to software architecture depend on measurable quantities, like metrics and indicators. Sometimes such approaches depend on which metrics make sense and which do not in a given situation. How can you make sure that your KPIs are providing the information your organization needs to make decisions about how to invest time and effort?

Getting to great metrics requires a well-assembled system and a whole lot of work. But the truth is, you might not be working with a well-assembled system, or perhaps your organization has yet to put in the effort it takes to get all the way to fantastic metrics based on DevOps best practices. DevOps is a cultural shift; it’s easy to misunderstand the concept, and companies don’t always commit to adopting best practices fully. Even when that’s the goal, learning and implementing best practices is a process that takes time. Reality is not always a best-case scenario, and standard metrics do not always reflect the real problem.

So what can you do when you’d like to implement best practices but your organization isn’t there yet? In those less-than-ideal situations, I think it’s still useful and important to have a set of practices and metrics ...