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 our (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 [intlink id="quality-attributes-introduction" type="post"]Quality attributes[/intlink] 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 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