Alternative Thoughts on Software Architecture

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).

Designing Subsystems to Create a Sense of Wholeness

Few developers want to be so specialized in their work that all they do is analysis or design or coding or bug fixing. More often than not, developers want to be associated with the full range of development activities: working with customers or product managers to clarify requirements, developing analysis and design artifacts and implementing them, fixing bugs , tuning performance, and so forth. I think of this as a strong desire for a sense of "wholeness" or "completeness" relative to our work. This desire has deep implications, and good designs are often chosen so that the teams building them can fulfill it.

The concept of wholeness means different things to different groups, and it is important for managers to understand how a given team interprets it. In one client-server application, we considered several alternative designs for the client. I'll use two of them to illustrate how we interpreted wholeness and how it influenced our design choice.

In the first design, one team would be given responsibility for "customer-facing" issues and the other would be given responsibility for "infrastructure" components . In the second design, each team would have both customer- facing and backend infrastructure components.

While the first design may have been a bit easier to manage on paper, it left the infrastructure team demoralized, feeling that they would not be full participants in the release process. Specifically, they wouldn't be working directly with product management, technical publications , or potential customers. They had done this in prior releases and wanted to keep doing it in the current and future releases. As a result, we chose the second design, as it was the only choice that allowed both teams to achieve the sense of wholeness that they felt was important. For them, this included interaction with product management and full participation in the release process.

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.