There was a time when it was in vogue for software developers to refer to themselves as “software architects” but few could really articulate what was the role of an architect as opposed to a developer or “coder?” Even today, many years later, I still run into this lack of understanding and frequently use the following thought experiment to illustrate…

Consider that you want to deploy a web-service that allows users to submit two numbers and receive their sum as the result. The previous sentence completely describes the functionality we wish to provide, i.e. the functional requirements.

Further consider the following two scenarios: (A) you want to support one million users accessing the service at the same time; (B) you want the service so secure that only two specific people are ever allowed to access it. The systems that result to satisfy those two scenarios will look radically different in terms of how they are structured or shall we say, “architected.”

In other words, the non-functional requirements (scalability vs. secureability) drive the resulting system design. This is the heart (and art) of systems architecture: how do you satisfy not only the functional requirements but more importantly the non-functional ones, sometimes referred to as the “-ilities” (e.g. scalability, availability, manageability, secureability, etc.).

This topic is covered thoroughly in the book, “The Art of Systems Architecting” by Maier and Rechtin, which I highly recommend.