resilience.org Blog

Got Architecture?

October 18th, 2006

Any architecture should guide and constrain, imposing the best ideas and lessons learned on designers and developers.
But try to wield too much power, and we will encounter resistance. Wield too little, and we make no contribution.
An interest approach to solve this dilemma is called minimalist architecture. Following this guideline we should sort out your highest-priority architectural requirements, and then do the least we possibly can to achieve them.
Keeping the number of architecture decisions as small as possible, while ensuring that the technical staff meets key system priorities.
This idea sounds, like many other propositions in the software industry appear easier to apply than they really are.

However, architectural decisions are those that must be made from an overall system perspective. Essentially, these decisions identify the system’s key structural elements, the externally visible properties of these elements, and their relationships. Ultimately they define the architecturally significant requirements.
If you can achieve the requirement by deferring the decision to a lower level, it is not architecturally significant, and the decision is not an architectural decision at that level of scope.
That’s another misconception about software architecture. In general we use to think that architecture exists only on the high level realms and that the software architects are the only ones making architectural decisions.  At any level of abstractions architectural decisions are being made to address the balance between assumptions and requirements at that level.
If we let the people that are closer the problem have more freedom in solving it then there is innovation happening every where on the stack.
The key is to make sure that at any level we set as fewer constraints as we can but not fewer than we need to fulfill the requirements at that level. When that balance is achieved there is more flexibility on the system that allows full participation of the staff.
For example, if the system under consideration is an individual application, we should defer any decisions that component designers or implementers can make to them.
These decisions should not become part of the architecture. If the architecture’s scope is a family of applications (or a product line), then you should defer any decision that relates to only a single application (or product). Such a decision belongs at the level of the application architecture and is not part of the application family’s architecture.

Entry Filed under: Architecture