Architecture abstractions: Prescriptive and descriptive

Dec 29, 2008 | George Fairbanks

If you decided to create some abstractions to explain the architecture
of existing software, it is unlikely that you would end up with the
standard set of architecture abstractions (components, connectors,
ports, roles, etc.) The standard set of architecture abstractions
seeks to point future software development in the right direction, and
so it is prescriptive in that it encourages encapsulation and clear
channels of communication.

When we document existing systems, we are simply describing them as
they are. Consequently, there are some challenges when we try to
simply describe software that does not conform to our ideals. Much of
what we find is beautifully designed, but not everything. We will
have trouble with systems that have no internal subdivisions and are a
bowl of object soup. We will have trouble with “glue code” that
expediently interconnects other systems and is often written in terse
scripting languages. Above all, we will have trouble with frameworks
because while our abstractions encourage encapsulation with components
and narrow interfaces defined in ports, frameworks often reveal their
implementations through inheritance hierarchies and have wide and
poorly defined interfaces.

Note to Kevin and Ciera, if you are reading this: we still need to
write that paper on the framework definition language, which would be
the first step towards reconciling architecture abstractions and


George Fairbanks is a software developer, designer, and architect living in New York city

+1-303-834-7760 (Recruiters: Please do not call)
Twitter: @GHFairbanks