It keeps the system from crashing.

What is "software architecture"? Or why do we call things "architecture" when they apply to things other than buildings?  What is it that drives this goofiness? In this post, I will present my glibly-phrased but dead serious definition.  How that plays out in the practice of creating software, well, that is for later discussion.  For now: In construction, architecture keeps the building from failing. It is equivalent with naval architecture — it keeps the boat from sinking. Huh? Sounds a bit.. er... negative? It should be pretty obvious that anyone can toss up a ten-story building given some labor and materials and good conditions.  What makes the architect's ten-story building different is that his or hers stands up in a 5 mph wind, doesn't suffocate its inhabitants, has indoor plumbing - which works at the tenth floor - you get the point. There is a degree of scale at which the basic materials and components no longer stand on their own.  Their use can exceed their capabilities.  They need to be engineered, that is, to be created and installed with a complete understanding of requirements, capabilities, tolerances, and tradeoffs. If you're still with me, you might ask 'we still call it "architecture," and not "engineering."  Why?' The girders and cabling and plumbing fixtures and ventilation ducts can all be engineered.  Why can't the ten-story, 40,000-square-foot office building?  Why must it be "architected"? The reason is that we have hit yet another level of scale.  That is where the interdependencies of components can cause catastrophic or cascading failure throughout the entire structure.  The job of the architect is to recognize the conditions in which materials and components can be stressed outside their ratings and design ways to prevent, minimize, or contain resultant failure. The metaphor of architecture is often disputed for software. I think it is very useful - so long as one remembers to keep it a metaphor. Software architecture keeps the system from crashing. At the same time, if we take this metaphor seriously, most of us practitioners will admit we don't create architecture.  We don't keep the building from failing - the system from crashing.  We just don't go about our work in a fashion that justifies the title of 'architect,' or even 'engineer.'  And we're complacent about it because all the rest of our colleagues are just as undisciplined. It really is never a given that a software system will work reliably, and the bigger it gets, or the faster it must be, the harder it is to achieve acceptable reliability.  What happens if the messaging system fails?  What happens in case of a DDOS attack?  If the database is corrupted, will that prevent the authorization system from working? These questions may be raised by the engineer, but they can only be answered by the architect.