What is Software Architecture? (.pdf)

Definitions of Software Architecture

What Software Architecture is Not

Architecture Training

Software Architecture Class:

Enterprise Architecture Workshop

Role of the Architect Workshop

Architecture Consulting

Consulting Services Overview

Join our
mailing list

I came across the ArchKidecture site (architecture for kids), and it has this story about Bruce Graham, architect of the Sears Tower in Chicago:

"Bruce Graham, architect at Skidmore Owings and Merrill, told the story that when he was trying to think of a design for the world's tallest building (at the time), the Sears Tower in Chicago, he was playing with a bunch of cigarettes at his desk. Soon, he realized that if you bundle up the cigarettes, they made a stronger tower than a single cigarette. He then considered that the building itself would be a bundle of towers (nine in all) and they would be able to withstand the forces of wind that might otherwise blow over such a tall structure."

Architects and Models

Why did I highlight the Bruce Graham piece? Models, including visual models and physical mockups, are important tools of our trade, yet they are not used enough. In our field, the tendency is to do our thinking through code. We tackle a problem, have the joy and satisfaction of getting it working, then expand the scope. But code is expensive. As the code size grows, more is invested: time and money, egos... So we tend to tweak and short-cut and kludge our way to good enough. We don't throw the thing out and start over. Partly, our customers don't see the mess, only the results of the mess, and by then they have to decide whether the gain is worth the pain. Wouldn't it be a different world if customers could see the code structure? Or if designs had to pass inspections, and construction projects had to pass inspections at various phases—like building inspections before the cladding gets puts on the walls and hides key structural details?

At any rate, not nearly enough modeling gets done. We haven't reached the point where, as an industry, we value and expect models before (and during) coding. It has been more than a decade since a program manager for a next generation product solution effort plunked down a pile of models on my desk and said "I don't know what else this means, but our architects have done a lot of work. I suppose it's a good thing." This from someone who had been very influential in the software quality field, before moving from QA to program management! Working code is what we know how to value. Even if "working" is a temporal illusion. Still today, there is the same nervousness around time spent modeling. And the same cowboy bravado associated with cut-it-on-the-fly development.

In the shampoo business they use computational fluid dynamics to model the viscosity of the fluid. In aircraft design they use wind tunnels (and CFD and more). In software, we (at least, many of us) just start to build. Why do we think software is so hard? Because we make it hard! At least, we make it harder than it needs to be! Jumping into code makes us feel good—we're working! And then we're working, and working, and working, with no clear end in sight!

For those who push back, and say we need to incrementally deliver working code to our clients so they can get a better sense of what they want, I say, do the first levels of exploration much more cheaply—use models and mockups. And always think about just how much "tweaking" our clients can afford to make! Yes, we need to take the user goals and user experience into account. A poor use model is inexcusable. If there are a small number of users, and the software does not meet their needs, that is inexcusable. If there are a large number of users, and most find it unwieldy, frustrating or off-target, that is inexcusable. We need to identify the failure modes and address them appropriately. We need to address them appropriately given the state of our art. But we don't take advantage of the state of our art nearly enough.

Yes, technology, user expectations and our business needs are moving so fast that we have no steady ground under our feet to depend on. Our past experience only serves us so well, and experience is the best we have to go on. So we will have uncertainties. And we will only be able to resolve some of those uncertainties by actually experimenting—writing code. But the whole project shouldn't be a big experiment! Architects need to understand where the uncertainties and risks are, and create a strategy to explore and resolve the uncertainty and reduce the risk. This means that architects should be able run tiger-team projects ahead of the bigger development effort to scout out approaches to addressing the big challenges. And it means architects need to create models. Identify architectural imperatives and goals. Visualize the system. Get a sense of the risks. Identify strategies. Visualize approaches and perform thought experiments. Identify focused coding experiments and get a better sense of estimates and budgets and how the thing will really work. And work with the development team throughout the development of this and subsequent releases, so that the architect learns and the architecture as represented and the architecture as built match and evolve in understood, rationalized ways.

From Ruth Malan's Trace in the Sand Architecture Journal, 25 April 2006