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