What is Software Architecture and How Can We Share It?

An instructor friend recently asked me for tips on how to introduce his students to his bag of architectural best practices.  This wily old veteran of the software trenches is well aware that he has a multifaceted challenge on his hands.  He knows that it is hard to talk about architecture yet it's important for his students to understand.

Let’s start by agreeing on what software architecture is, at least what it is in this conversation.

Clements and Kazman define architecture as:

"...the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.   Architecture is concerned with the public side of interfaces; private details of elements - details having to do solely with internal implementation - are not architectural."

This definition resonates with me because it scales to the very small and the very large.  It also makes it clear that when you create a public element you are making an architectural decision.  This fits whether we are building an API, a set of web services, a class, or an output variable in a function.

This definition also includes one of the most important parts of architecture - the relationships among the elements.   More specifically, “relationship” refers to dependencies between elements.   Experienced developers know that the single most important thing you can do to keep your software agile and maintainable is to understand and manage the dependencies.