Thinking about Architecture

---

Architecture is one of the trendy terms in software development these days. Many people who used to present themselves as developers now have business cards that read “Software Architect,” and you’ll find institutes, certifications, and websites galore for architects. But don’t let yourself get turned off by the trendiness. There is a valuable discipline of software architecture, and for even small projects it remains a good starting point.

What Is Software Architecture?

Darned good question, that. Although most authorities agree that there is a need for architecture in the software field, there’s no generally accepted definition. Martin Fowler offers a definition in his book Patterns of Enterprise Application Architecture (Addison-Wesley, 2003) that I rather like:

There are two common elements: One is the highest-level breakdown of a system into its parts; the other, decisions that are hard to change.

The goal of creating an architecture for your software is to have a general idea of what you’re going to build, before you start building it. Commonly, you’ll use pictures, sketches, and diagrams to communicate this information.

Architecture vs. Design

It’s easy to get misled by analogies between software and other fields. The fact that we reuse words from other fields makes it even easier. Architecture is one of those words. In the real world of buildings and bridges, architects are responsible for design at all levels of detail: Everything from the outside view of the skyscraper to the location of each sink in the janitorial closets will be on the architectural plans somewhere. In computer software, though, most people distinguish between architecture and design.

Generally, when developers speak of architecture, they mean very broad decisions: what database the application will use, whether Extensible Markup Language (XML) should be used as a file storage format, how many tiers the overall solution will use for its structure. Once the architecture is in place, you can proceed to detailed design: what objects the data access code will use, which variables will hold global state, and so on. One way to make the distinction is that you shouldn’t be writing any code in the architecture phase, but once you get into design, you might well dictate such implementation details. Of course, it’s a fuzzy line: Does choosing a collection type to hold a set of objects fall under architecture or design? It’s the sort of decision that’s hard to change, but it’s also an implementation detail. But since one of the themes of this book is that you need to be prepared to move back and forth between different tasks as you develop an application, there’s no need to find a hard boundary between architecture and design.

Software construction is often divided into three stages:

• In the architecture stage, you nail down the most important decisions about the application.

• In the design stage, you make more detailed plans for writing the application.

• In the implementation stage, you actually write the code.

Although this breakdown provides a convenient framework for large projects, a small project might only require two stages (architecture/design—design/implementation). You might characterize these as “thinking about the code” and “writing the code.” Of course, you’ll probably shift back and forth between these two activities several times in the course of developing an application.

Architecture in Small Projects

For small projects (those that will require a single developer or perhaps several developers working closely together), my own feeling is that you don’t need to go overboard on your architecture. A simple sketch, perhaps on the whiteboard in your office, is often enough. If you want something electronic, I recommend a drawing package such as Microsoft Visio. Figure 2.1 shows my initial architectural diagram for Download Tracker.

Figure 2.1: Architectural diagram for Download Tracker

This diagram captures some of the decisions I’ve already made about how Download Tracker will be structured:

• Data will be stored in a Microsoft Access database. I doubt that I’ll outgrow that, but for flexibility I’ll use a separate data access layer to present a structured, object-oriented view of the database.

• Most of the code should be contained in a logic layer. I don’t quite know what that will look like yet, but I intend to separate it from the user interface (UI).

• Downloading will be handled by a separate downloading engine. I see this as an object that can go off and handle downloads on its own thread and notify the main logic when it’s done.

• I plan to use a pluggable architecture for output formats. That way, it’s easy to include additional formats in the future—or to delete some if I run into a scheduling problem.

What about UML?

It’s impossible to read much about software architecture these days without running into the Unified Modeling Language (UML). UML is the closest thing we’ve got to a standard for architectural diagrams, and it’s implemented by quite a few products. These range from the $95 Enterprise Architect (www.sparxsystems.com.au/) to the $3000 IBM Rational XDE (http://www-3.ibm.com/software/rational/). The more expensive products such as XDE can actually go beyond architectural modeling to generating code to implement the model.

Tip

A good starting point in finding a UML tool is Bruce Eckel’s collection of reader feedback at http://mindview.net/WebLog/log-0041. Bruce has collected information on a wide array of tools from his readers.

UML is a powerful tool, but I find that it’s mainly useful for straightforward line-of-business applications. If you’re going to be working out an invoicing system for your employer, you might well find UML models to be a good place to start. For small tools and utilities, though, I don’t find that the exercise of going through formal UML diagrams helps much.

TECHNOLOGY TRAP: The Map Is Not the Territory

“The map is not the territory” is one of the maxims set forth by Alfred Korzybski, founder of General Semantics. It seems obvious when you think about it: There’s a difference between a thing and our written representations of the thing. But despite this, people regularly confuse maps and territories. For example, the word surgeon calls forth your mental map of the concepts surrounding surgeons; for many people, it’s then jarring to be told “This surgeon is a woman.” Somehow their mental map includes the concept “All surgeons are male,” despite good real-world evidence to the contrary.

Why this digression into semantics? Because I’ve seen developers get into trouble when they start to confuse the architecture with the actual code. The architecture represents an ideal view of your application, but you need to be prepared to change the architecture if the application demands it.

One place this turns up is in database design. Most developers know that the ideal database is in third normal form, which means that it complies with a set of rules for avoiding redundant data. Nevertheless, sometimes trying to work with a third normal form database can be a problem, particularly when you need fast access to derived data. In some cases, the best answer is to selectively denormalize the data for increased performance. If your developers are confusing the architecture with the application, you can expect strong opposition to this move, no matter how sensible it is.

The bottom line is that the architecture documents should provide guidance for design and coding, but you shouldn’t be afraid to revisit the architecture if you’re running into a problem.

If you’re interested in learning more about UML, many excellent books are available on the market. I like Sinan Si Alhir’s Learning UML (O’Reilly, 2003) and Jason T. Roff’s UML: A Beginner’s Guide (McGraw-Hill Osborne, 2002). For Rational XDE in particular, try Wendy Boggs’s and Michael Boggs’s Mastering Rational XDE (Sybex, 2003).

---