A question we have all heard is: “How do you measure success?” Those metrics can look different for different industries or professions, but they are rooted in hard measurable outcomes: larger revenue for a bank, bigger market share for an automaker, reduced readmission rate for a hospital chain. Those numbers are easy to put on a chart in an executive presentation. But what about software architecture? Measuring success of software architecture is difficult because software architecture is all about long-term effects, positive or negative. Software architecture metrics are hard to define and even harder to evaluate objectively. As soon as a metric becomes a goal, it ceases to be a good metric (think “number of lines of code”). And we know all too well that software architecture is subject to frequent changes – no other industry moves as fast. However, we still need to be able to set goal posts, measure outcomes and present them to executives – in a practical way.
As Eliyahu Goldratt famously said, “Tell me how you measure me, and I will tell you how I will behave”. Focusing on low-level metrics can do more harm than good. A metric’s value becomes the end goal, rather than achieving the desired business outcomes. To fix this, let’s reverse the process. We are going to start by defining the business outcomes we want to achieve. The outcomes we are going to focus on are the ability to run a cost-effective system and ability to evolve it quickly and easily. Foundational to those objectives is the capacity to manage the complexity of the system. In this talk, we are going to explore several simple and pragmatic approaches to architectural metrics that support the required business outcomes.
