While the previous definitions of software architecture are useful, they are far too simplistic to take into account the full set of forces that shape, and are shaped by, an architecture. In truth, I doubt that any single definition of software architecture will ever capture all of what we believe to be important. To illustrate , this section raises some issues that aren't often covered by traditional definitions of software architecture but are nonetheless quite important. Unlike the previous definitions, which focus on the "technical" aspects of architecture, consider that these focus on some of the most important "human" and "business" issues, which are all part of the big picture.
Subsystems Are Designed to Manage Dependencies
Having managed distributed teams that have spanned the globe, I've found that an important criterion in decomposing subsystems is having the simplest possible dependencies among development organizations. By simple, I mean manageable based on the people who are creating the system. In work with my consulting clients , I've found that, contrary to "technical" justifications, many architectural choices regarding subsystem design are based on creating easily managed dependencies among groups of developers. The practical effect of these choices is that subsystems are rarely split across development organizations.
Subsystems Are Designed According to Human Motivations and Desires
Many books on architecture remove far too much of the human element from the architectural design process. For example, architectural patterns are a wonderful place to begin the design process, but creating an architecture isn't just taking some form of starting structure, such as a pattern, and objectively tailoring it to the needs of the business. You have to understand and take into account the hopes, experiences, dreams, fears, and preferences of the team charged with building the architecture. Subjective and objective decision making collide as the technical structure of the architecture shapes the social structure of the team and vice-versa.
To check this, ask yourself if you've ever been involved in a project where you wanted to work on a particular aspect of the architecture because you knew you could do a better job than anyone else (confidence based on experience); you wanted to learn the underlying technology ( desire ); you thought that doing a good job might earn you a bonus or promotion (aspiration); or you were concerned that no one else on the team had the requisite skill or experience to solve the problem the right way (fear).
Give in to Great Architectures
I use the phrase "give in" when an architect or development team subordinates , to the extent that they can, their experiences and expectations about what they think is "right," and instead let the forces of the problem domain guide them in the realization of the architecture. Some people claim that this is not a problem and that they or their team always create an architecture solely based on an objective understanding of the customer's problem and its best technical solution. The operative word, of course, is "best." Your opinion of best may not match mine, which is probably more heavily influenced by my experiences than by the problem domainunless my experiences are born from this domain. One aspect of "giving in" to a great architecture is continually assessing if the decisions we're making are designed with the customer and their needs first, and our willingness to change prior decisions when we find they're not.
Beauty Is in the Eye of the Beholder!
We all have many definitions of successful software architectures. While a company may feel that a system is successful because it is powering a profitable product, the developers who have to maintain it may cringe because of its antiquated technical architecture. Alternatively, many truly elegant technical solutions fail for any number of reasons. In addition, we all have our own opinion on architectural elegance . Two of my most skilled developers had very different philosophies regarding stored procedures in databases. I was confident that both could create a good solution to just about any database- related problem you could throw at them, but I was equally confident that their designs would be different and that both could justify their own design while validly criticizing the other's. Few developers can escape the aesthetics of their design decisions.