Software architecture should start with Why

I recently saw Simon Sinek‘s TEDx talk on Start with Why (see below) talking about leadership.

But WHY  am I telling you this? For one, it’s a good talk on leadership and inspiration in itself (well worth the  18 minutes or so it would take you to watch it). The main reason, however, as the title says, is that it also pertains to software architecture decisions.

Simon talks about “the golden circle,” going from Why -> How -> What. Saying most people work from the outside in (rarely getting to the why), and leaders work from the inside out (starting with Why). It is true for us as well –  Software architecture decisions should start with why

We’re not just building an SOA (What) using mule or “nservicebus” (How). We’re doing that to build a flexible solution so that we can respond to changing business needs (Why).

We’re not just using a NoSQL solution (What) using Cassandra cluster (How); we’re doing that to solve a database reliability and availability problem of managing a large dataset with high write  (Why) to allow the business to support X millions of images (in xsights case) with Y concurrent users and search times less than Z seconds (a better Why)

This is the essence of why it is a very good idea to describe quality attributes in terms of functional scenarios. We want to make sure that an architectural solution will be tied and will answer a real business scenario within the system. We don’t want to provide fault tolerance or 99.999% uptime. That’s not interesting. We need to define why we need high availability; what will be the consequences of the downtime loss of a business transaction? Loss of 100K dollars? Loss of life? – For the last case, maybe 99.999% uptime is not enough, and for the first case, maybe a 95% uptime will do. Start with why. It can save you money, it will help you get to the right requirements, and it will help you justify your decisions

Illustration by venturist

Related posts:

Evolving Architectures – Part III starting out Utility trees and quality attributes Nanoservices anti-pattern pdf version