When and why do you need an architecture?
you are going to build something small or even medium in size, you can
just wing it. Small stuff requires little architecture and medium
systems most often crystallize along some crude architectural lines
without much intervention. If you are going to build something large and
you start without an architecture, what you will wind up with is a
large series of disconnected and/or overlapping pieces that are
impossible to stabilize. The project will die.
So what is an architecture?
its most simplest explanation it is the overall organization of the
underlying sections of code. For something to be ‘organized’ that means
that there are a series of rules which categorize a specific layer to a
‘reasonable’ number of sub-pieces. Most often I prefer to refer to these
as ‘lines’ and to leave the number of layers to be relative to the
problem. An unreasonable number of categories is somewhat dependant, but
lower numbers like 3 or 5 are nice, while larger ones like 20 or 30 are
How does one describe an architecture?
any good blueprint, an architectural description is a top-down listing
of the lines and the layers. But since there are essentially two
dimensions to an architecture there need to be two main roots to the
design. The first is the underlying data in the system, while the second
is the way the code is constructed to manipulate this data.
top-down view of the data is essentially a hierarchical structure,
starting with the major entities and gradually breaking them down into
the details. The overall organization however needs be contained within a
reasonable number of categories at each layer, so the major entities
are most likely collected into a smaller set of categories at an
abstract layer. That ‘organizational’ constraint flows all of the way
down to the details. The data itself often cross-references other
entities, but it does so internally (as data), thus it often be arranged
in a hierarchy.
the code the situation is similar. A hierarchical structure of
categorizations forms the basis, however code is a little more
difficult. To avoid redundancies many well-defined parts of the system
will be shared at many layers, so here a hierarchy really fails to
capture the expressive requirements of a well-designed system. Thus,
although there is a root (a place to start), the lines in the code form a
graph of categorizations, although these should still be presented as
well-organized layers (unwinding this is part of the challenge).
overall a well-documented architecture has two main sections that each
descend down into the details. At each layer, there are a reasonable
number of sub-pieces that are either specific or abstract (if necessary
to be reasonable). A group of programmers should be able to walk their
way through both parts of the document and use all of the contained
information to solve all of the final coding-level problems.
all is going according to plan, they still have significant problems to
work on but all of the external decisions have been resolved and they
understand how their individual pieces will interact with each other.
How does one create an architecture?
software system needs a well-defined problem to solve. The underlying
details, driven by this problem, come from analysis of the solution,
which identifies the required data and the algorithms to operate on the
data. There may also be analysis into the operation environment for the
system and possibly the development environment as well. All of these
details need to be sorted and arranged, then finally organized into
layers. Although the final architecture is top-down, assembling the
pieces in a bottom-up manner is often simpler and produces less
redundancies. Generalization and abstraction are key to reducing the
effort and getting it presentable. The architecture is ready when it’s
depth matches the programming team’s capabilities.