Our Vision of Software Architecture

Ironically, it has been simple idea - easily grasped - that has had the power to spark transformations of thought and knowledge.

Throughout human history, we have seen simple concepts produce radical alterations of worldview. Copernicus's "De Revolutionibus" of 1530 proved the sun to be the center of our local universe, and an apple falling upon Newton 's head was the catalyst for the train of thoughts leading to his Law of Gravitation. These are preeminent examples, but simple 'Aha!" experiences occur in our daily lives, as well. How many times does a solution evade us until we see the light and kick ourselves for not having seen the obvious - what was right under our noses from the start? From time to time, entire groups of us are deluded until some kid shouts: "The king has no clothes!"

A paradigm is a model of thought, a different way of seeing something already seemingly familiar. Creating a new paradigm usually involves examining and challenging simple, underlying assumptions.
There's a perfect, profound analogy between software and building construction. It is this analogy that is the simple idea that we have failed to see. From its inception, the software industry has been plagued by a crisis in the reliability, predictability, cost, and usability of its offerings.

Through experience and observation, we all intuitively understand how buildings are constructed - from the most simple home to huge glass-and-steel towers. Even children have a cognitive map of the process and understand the difference between the roles of the architect, scientist, engineer, and builders. Everyone also knows that buildings are created for shelter as well as to facilitate and enhance our multifarious activities. Kitchens are for cooking, bedrooms for sleeping, offices for working, museums for housing our precious legacies, laundromats for enabling us to wash and dry our clothes. Of course, you can sleep in the bath-tub but hey... it's not what bathrooms are for...

Buildings can be strictly utilitarian and dehumanizing - like modern oversized mason block high schools, ironically, - or they can be structures of ineffable beauty.

With the analogy in mind, it swiftly becomes clear that an entire branch of knowledge has been missing from software construction. The architecture has been largely absent from software construction. The software industry has been struggling without the discipline of true architectural design woven into its fabric. We no longer have the luxury of building complex software structures without a design and without blueprints: problems need to be solved on a large scale, and new types of structures need to be designed.

When the CEO of IBM wanted a new corporate headquarters built, who did he call? A "building engineer"? A construction company? A "guru"? Of course not. He called I.M. Pei - an architect. What would have happened if the Pope had never hired Michelangelo? Would St. Peter's Cathedral have been "developed"?

With the design role largely missing, a vacuum was created. This has been filled in by programmers, engineers, and computer scientists who do not have training and experience in design and who do not necessarily have an architectural worldview. In spite of this, they consider design to be a part of their role, but role confusion and muddled accountability are the results. We are not only confusing our clients with ambiguities, we are also confusing ourselves.

Imagine you were building your dream home without a true architect, a blueprint, or clear roles for engineer and builders. Imagine, in other words, building your home the way software is built: you would likely begin by hiring a building consultant or project manager. In turn, they would bring in a number of people who would complete the requirements-gathering process. They would use a more or less expensive requirements management package, and you would tell them everything you need in a home, how much money you could spend, and where it needs to be built. Your requirements would be very detailed (more or less) because you would have done your research.

The project manager would then hire a team of building specialists and building engineers. Meetings would ensue, and white boards would fill. The work would be divvied up among the groups until all requirements were accounted for. It would be decided that a bathroom, the kitchen, and a bedroom will be finished first, so the owner can save some money and move in faster. They would also show the owner how the rest of the house will look.

The roles of the builders would be decided according to their stated skills, experience, and toolboxes. It could be determined that the person completing a part of the electrical wiring would also hang the garage doors. The person laying the tile would also design the kitchen having had some experience with that. The person doing a part of the plumbing, using the latest "copper pipe architectures", will be "architecting" the roof as well, because that is where some of the plumbing vents lead. The design is to add to the finished rooms in a staged process, designing them ad hoc, until enough rooms exist on the site. There is a building specialist in charge of the interface between the rooms...

Anyone can see that this is a recipe for chaos. A house may result, yes, but what will it resemble? If it is dysfunctional, who's to blame? After all, the requirements have been met: the house has all the items specified by the owner. But does it work? As for the artistic look and feel, well, who can be artistic in a crisis, right?

What would have happened is analogous to hiring an army of technicians and constructions workers to build a skyscraper on East 34th Street in NYC with 120 floors. The stacks of requirements could fill rooms and heroic management controls could be put in place to regulate their minute-by-minute activities. But does that mean that the resulting structure would even resemble the Empire State Building ? (A rhetorical question).