Microsoft .NET: Architecting Applications for the Enterprise ... - BattleIT

Chapter 1 Architects and Architecture Today 9
are agile, the more freedom and independence you leave to developers when implementing
the architecture.
Defi ning the Borderline Between Architecture and Implementation
The constituent components you identifi ed while breaking down the system represent logical
functions to be implemented in some way. The design of components, their interface, their
responsibilities, and their behavior are defi nitely part of the architecture. There’s a border,
though, that physically separates architecture from implementation.
This border is important to identify because, to a large extent, it helps to defi ne roles on a
development team. In particular, it marks the boundary between architects and developers.
Over the years, we learned that architects and developers are not different types of fruit, like
apples and oranges. They are the same type of fruit. However, if they are apples, they are like
red apples and green apples. Distinct fl avors, but not a different type of fruit. And neither
fl avor is necessarily tastier.
You have arrived at the border between architecture and implementation when you reach a
black box of behavior. A black box of behavior is just a piece of functionality that can be easily
replaced or refactored without signifi cant regression and with zero or low impact on the
rest of the architecture. What’s above a black box of behavior is likely to have architectural
relevance and might require making a hard-to-change decision.
What’s our defi nition of a good architecture? It is an architecture in which all hard-to-change
decisions turn out to be right.
Dealing with Hard-to-Change Decisions
There are aspects and features of a software system that are hard (just hard, not impossible)
to change once you have entered the course of development. And there are aspects and
features that can be changed at any time without a huge effort and without having a wide
impact on the system.
In his book Patterns of Enterprise Application Architecture (Addison-Wesley, 2002), Martin
Fowler puts it quite simply:
If you fi nd that something is easier to change than you once thought, then it’s
no longer architectural. In the end architecture boils down to the important
stuff—whatever that is.
To sum it up, we think that under the umbrella of the term architecture falls everything you
must take seriously at quite an early stage of the project. Architecture is ultimately about
determining the key decisions to make and then making them correctly.