I remember talking to a former software exec at Amazon and he actually told me a personal philosophy that I thought was pretty profound at the time. To set the

I remember talking to a former software exec at Amazon and he actually told me a personal philosophy that I thought was pretty profound at the time. To set the stage this was when web services where coming into fashion and he was a big proponent of them, he said that he likes to focus teams around business domains (e.g accounts receivable, road logistics, etc.) then let them control their destiny. He said that he liked a service based architecture because it allowed him to build Amazon scale software, a piece at a time and more importantly the nugget that I really took away from the conversation was that you cant stop bad software from being written, but you can isolate bad software from the rest of the system which allows you to measure all kinds of things that give you an overall metric on the quality of that software. Things like time to defect resolution, uptime as well as true business metrics given that they are aligned with a vertical (i.e did the software empower the core business goal). If the numbers are lacking the software is bad plain and simple. Isolation makes it easy to replace. I don't think enough people who architect large systems give thought to how do we protect the overall system from bad code which is a certainty to happen on large projects because they necessitate large teams. As developers and architects we tend to focus on elegant designs, but the overall support of an application thru it's life is anything but elegant.