practice
Doi: 10.1145/1831407.1831424
Article development led by
queue.acm.org
Component models can help diagnose
architectural problems in both new and
existing systems.
BY KeVin montaGne
tackling
architectural
complexity
with modeling
the ever-increASinG MiGht of modern computers
has made it possible to solve problems once
considered too difficult to tackle. Far too often,
however, the systems for these functionally complex
problem spaces have overly complicated architectures.
Here, I use the term architecture to refer to the overall
macro design of a system rather than the details
of how the individual parts are implemented. The
system architecture is what is behind the scenes of
usable functionality, including internal and external
communication mechanisms, component boundaries
and coupling, and how the system will make use of
any underlying infrastructure (databases, networks,
among others). The architecture is the “right”
answer to the question: how does this system work?
The question is: What can be done
about the challenge to understand—
or better yet, prevent—the complexity
in systems? Many development methodologies (for example, Booch1) consider nonfunctional aspects, but too
often they stop at the diagram stage.
The mantra of “we can address [per-formance, scalability, and so on] later”
can be crippling. Individual components (applications) in a system can
typically be iterated, but it is often far
more difficult to iterate the architecture because of all the interface and
infrastructure implications.
In this article, I describe an approach to architectural design when
embarking on creating a new system.
But what if the system already exists in
some form? Much of my architecture
work has been with existing systems—
many times as an “outsider” who is
invited (or sent) in to evaluate and improve the state of the system. These
assignments can be quite challenging
when dealing with complex systems.
One advantage to modeling an existing system is that the general behavior is already in place so you are
not starting from a blank state. You
also probably do not have to contend
with the creation of the functional
parts of the system. This comes at a
price, however. There is a fair chance
the system’s architecture is complex
and not well understood. Additionally, many solutions may not be practical because of the high cost of a system overhaul.
With any type of system the goal is
to understand the architecture and
system behavior as much as possible.
When a large system has been around
for years this may seem like a monumental effort. Many techniques are
available for discovering how a system
works and ways it can be improved.
You can ask members of the development and maintenance teams. Diagnostic tools (for example, DTrace)
can help make quick work of finding
performance or scalability offenders
in a system. You can comb through
mountains of log files to see what the