Architecting Buildings and Software
I am reading “The Software Architect’s Profession: An Introduction,” by Marc T. Sewell and Laura M. Sewell. I am not writing a book review with this post. Instead, I would like to highlight some similarities between the two disciplines. Whether we are building with brick and mortar, wood, steel, or computer code, the roles and processes are analogous. The role of the architect is important for both, but when it comes to software, the architect often goes unfulfilled.
Compared to architecting and constructing homes, hospitals, and skyscrapers, architecting and developing software is new to many of us. In our minds, whether we understand the processes required to erect the Empire State building or not, most of us possess an intuitive understanding of the distinct roles of the architect, scientist, engineer, builder, electrician, and plumber. We realize that buildings provide shelter, make our lives easier, and consist of rooms specific to living activities. We have living rooms, family rooms, meeting rooms, workout rooms, kitchens, ect. If we want to add on a garage, screened-in porch, or modify an existing room, the architect needs to plan for this in his/her design.
When it comes to software and the processes required to plan, design, develop, and test, many of us lack the intuitive knowledge of what is, or should be, necessary to build software. Just like a building, software makes our lives easier and consists of rooms, such as chat rooms, document libraries, art studios, financial planning, shopping, and home buying to name a few. If we want to add on a new room or modify and existing, the architect needs to plan for this in his/her design.
It becomes easier to see how buildings and software are similar and how the roles specific to each appear to be obvious and necessary. A building needs an architect, a builder, an electrician, and so forth. Software, similarly, needs an architect, a developer, a tester, and so forth.
Ask yourself this, “how many buildings (homes, schools, hospitals, malls, ect.) can I think of that were built without an architect?” Hmmm… I probably cannot think of any, or I should hope the answer is zero.
Now ask yourself, “how many software applications were built without an architect?” This one I can answer more easily - several. I try to convince myself that so-and-so was “acting” as the architect on this or that project, but the nature of it is, too many software projects are built without a dedicated architect.
Why is it that we feel like a building requires an architect, but that software can get by without it?
Is it because over centuries and millennia, we have been exposed to the processes required to construct buildings on a daily basis? Whereas, since software is comparatively new, the processes and roles required are not fully defined, or engrained in us, or we have yet to see centuries worth of catastrophic errors from omitting these roles?
“Blaming software failure or difficulty on ‘changing requirements’ is merely symptomatic of the lack of true architecture.” As owners and builders see what is being built, they realize what is incorrect and begin to make modifications to align their initial expectations with the reality before it is too late.
“It is equally erroneous to blame software failure on poor management. Even the best managers cannot produce a satisfying result from a bad design or a lack of design.”
Without this post becoming tiresome and long-winded, this book draws some good comparisons between the nature of building structures and software and the roles necessary for each.
Do you have an architect in your organization? Is he/she only an architect, or is he/she sharing this responsibility? Why?
The nice thing about software is it’s soft.
It’s a lot easier to change the design of software along the way, then it is the design of a building.
I don’t think that comparing construction with software development goes all the way. An architect in construction is necessary because it is just too expensive to build a house ‘the agile way’. Refactoring is much more expensive than refactoring in the software world. You have to know upfront that the house is build in reasonable fashion.
To me, every developer in the team is responsible for the architecture. It’s not because someone has the title of software architect, that she knows what’s best for the project. The team has to come to an agreement. I do recognize that there should be some experienced people on the team who can lead the way, a true path finder.
If we have to compare with construction, then I see the development team as a team of ‘architects’, while the code are the blue prints and the compiler/build system as the construction itself.
Just some thoughts. I just love to discuss such things
[...] Architecting Buildings and Software (Alex Mueller) [...]
Hi! My name is Vasileios Dimitriadis and I want to share something regarding this nice article.
I have a friend who is a Civil Engineer. And I’m planning on become a Software Engineer. Since we are both into engineering and construction, we have talked about the similarities and the differences between our professions. I don’t want to list everything but I would like to share a few key-points.
Similarities: We both like building things. We both take pride in our work. We both try to be as professional as possible.
Differences: He follows written rules, regulations and laws. I can deviate as much as I like. He knows up front what to build and make minor adjustments along the way. I don’t know exactly what to build and I can start all over again.
But the big difference what’s the two professions distinguish is the nature of software itself: Software has the blessing and the curse to change at any time. Constructions and buildings don’t.
Basically I think this sums up what the previous commentors have stated.
Thank you for your time and keep up the good work!
[...] Architecting Buildings and Software: Software architects are an important component in the creation of quality software and need to continue to refine and improve their role in the development process. No matter how you try to bend and twist it though, the building analogy will always be problematic — so why bother? Maybe that “intuitive understanding” of the construction industry just distracts us from being innovative about what’s required to build software. Sphere: Related Content [...]
[...] Architecting Buildings and Software - Alex Mueller ‘ Why is it that we feel like a building requires an architect, but that software can get by without it? ‘ [...]
Software is a craft without any true analog to other fields. It is a unique discipline and attempting to shoehorn it into the mold of other disciplines, whether architecture, some other form of engineering, or gardening is doing the craft no favors. As another commenter pointed out, our material is soft and malleable and the needs of our users will change sometimes suddenly. Our practices, rather than mimicking those of similar but ultimately divergent fields should be as unique and flexible as the materials we use.
In particular, the analogy between software and architecture falls apart rather quickly. No architect on a skyscraper has gotten two thirds through the building to have his/her client tell them that after some thought, they’d probably prefer a shopping mall. Their materials are too expensive and inflexible and their problem domains are much more understood. Conversely, few, if any, software engineers have ever received the level of detail and sign off from the end-users that an architect receives. The users simply can’t provide that level of detail.
Another, perhaps more important difference lies in the actual construction of buildings versus the construction of software. On a construction site, the people doing the actual construction have no responsibility for the design of the final product. They’re trained to build and to use the machines necessary to build and this is all they do. Every brick they lay is dictated.
On a software project, the construction workers must have the freedom and ability to make decisions concerning the structural minutia of the product. An architect simply can not dictate every line of code written.
Instead of focusing on architecture, developers, all developers, should familiarize themselves with design principles and with the patterns that spring from them. It is these skills that allow us to leverage the unique properties of our materials. If a developer lacks these skills, then they should be paired with individuals who possess them so that over time, the entire team has the skill and ability to drive the design and structure of our applications as they grow and change day after day. The end result of spreading design decisions and competence across the team is software with a sophistication, elegance, and nuance.