When I first was introduced to the term "software architecture", my mind immediately filled in a picture of someone bent over a massive flow chart, sculpting it into a shape that made sense. Finding the ideal shape that would solve everyone's problems in the most efficient and effective way.
I likened it to an actual Architect, outlining the shape and details of a sky scraper that would sustain for millennia.
And that's sort of the only actual parallel: building a solution that will sustain for the foreseeable future.
Let's define the industries
The building industry:
- Has been around for 12000 or so years (https://en.wikipedia.org/wiki/List_of_oldest_known_surviving_buildings)
- Has a fairly (pardon the pun) concrete and well developed list of fundamental infrastructure materials
- Has stakeholders (landlords, tenants, etc.) that have a very finite list of requirements (working, living, retailing, tenant count, etc.)
- Has generally well defined resource limitations (space, height restrictions, budget)
- Has employees that have a pretty common foundation of knowledge and experience with materials and tooling
The software industry by comparison:
- Has been around for less than 80 years (https://en.wikipedia.org/wiki/History_of_software)
- Has a growing list of relatively volatile infrastructure materials (see: JavaScript frameworks)
- In many cases has stakeholders that are still figuring out what they even are trying to solve and who they are trying to solve it for
- Is still in the process of defining its resource limitations (look up any pricing for any cloud hosting service and you'll generally come out with more acronyms to google than answers on pricing)
- Has employees that will have vastly different levels and types of experience with various tooling (partly due to the large list of relatively volatile infrastructure)
Very different industries, yes, the point?
The point is that the building industry can make a lot of assumptions and have concrete answers on what it's trying to solve and how it expects to solve it. The end result is large, monolithic, buildings expected to last hundreds, if not thousands, of years.
The software industry you can make very few assumptions and there often are not concrete answers, just educated (and sometimes uneducated) guesses. This is why modern Software Architects are inclined to focus on two concepts: standardization (increase assume-ability), and modularity (ease to switch in/out educated guesses).
If we built Software in the Building Industry
You've likely seen Software designed as if there were very concrete answers built on thousands of years of experience. It's a legacy monolith codebase. I like imagining every company has one, some large piece of PHP or classic ASP sitting in the corner gathering dust.
When you have confidence that you're solving the right problems with the right technology, you can mold all of your solutions into an all-in-one self-documenting codebase, and expect it to chug away for eternity.
Because everyone in the industry has some level of standardized experience with the tooling and infrastructure you used, you can hire pretty much anyone to maintain it! It'll last forever!
If we built Buildings in the Software Industry
You're handed the requirements for creating living space for people:
- We don't know how many, if any, people will use your solution
- We're pretty sure that a Bed, Microwave Oven, and Toilet for every person is MVP, but we may end up needing a gas oven.
- There's definitely more appliances we'll need to add in, we can speculate at what those are but won't really know until we have people living there
- We think it needs to interact with this other company's building, they support mail and radio (but only AM).
- We hired one person who knows how to work with brick, and 3 people that know drywall but are very eager to learn brick.
- We also don't have a crazy budget for this until people start using it, so make it as close to free as possible.
It's easy to think "those requirements should really be cleaned up", but the fact is that there isn't many years of experience that could tell us what will/won't work in the industry. We're all literally building the airplane while it's flying (https://www.youtube.com/watch?v=S_dgWl83cTM).
There's a few options here:
Build a Skyscraper
You proactively build one giant building that could fit any possible ask that comes up.
You added the support for gas in anticipation for the gas oven but the request never came. Now you have to spend resources keeping gas pipes up to standard and good repair.
Several appliances you guessed would come up did in fact get requested! Value! Some appliances you had not anticipated, like a sauna room, did not really fit into your design though so they had to be hacked in as part of the bathrooms.
With the delivery industry being so successful, the entire Kitchen was dropped as a supported product. Actually removing all of those kitchens would be a ton of overhead so you remove the appliances that aren't bolted to the wall or floor and leave the rest hoping that someone will be able to use them.
Halfway through the project you realized that Brick 2.0 came out, which has breaking changes with how you implemented the bathrooms. Brick 3.0 is already being talked about in the industry and hiring skilled employees to maintain your skyscraper built on Brick 1.0 is becoming difficult.
You implemented a mail box, radio, cable, and a Batman signal for external communication, but since you only utilize the mail box all of the other systems stop working over time as renovations happen around them. There's speculation that someone may be stealing your cable but there's not enough interest to look into it.
As the skyscraper becomes more popular, there's plenty of room for the inhabitants, but they never quite fully utilize even a decent chunk of the allocated space.
Build a House and plan for Renovations
You build a mid sized house that achieves the MVPs of the request, and make sure you leave room for features you think are coming up.
The request for gas ovens never comes, just means you have extra space in the walls.
You were able to do some Renovations to the house to account for the sauna, as more requests come in you're noticing that the house is starting to bloat in size and maintaining the electric wiring and Brick upgrades is starting to take more time and interfere with other work in the house.
Dropping the kitchen as a product was difficult, but doable with some planned renovations. It did require stopping work on other portions of the house for a bit though.
Eventually a request comes in for a [working] fireplace. But because of the positioning of the solar panels from a few requests earlier you don't have a good place to put a chimney.
As the house becomes more and more popular, room begins to be a problem. You now have to figure out how to build an exact copy of your house multiple times to accommodate more people.
Build a series of Huts
You break down the requirements to identify what particular solutions are being solved:
- Providing a sleeping space
- Providing a way to cook food
- Providing a private area for personal needs
You build three huts, one for each ask. You actually found that Drywall was better suited for the sleeping space hut, Brick for the kitchen hut, and a newer technology Tile for the restroom hut.
Several other smaller applications got added to existing huts, but nothing that really significantly increased their size.
You considered adding the Sauna as an expansion of the restroom hut, but realized it solved problems for a different set of people so gave it its own hut. This way renovations to your sauna won't break your toilet.
Dropping support for the kitchen was super easy (barely an inconvenience). You just took a wrecking ball to it.
The Brick upgrade only really needed to be applied to a few huts. They did interfere with work in those huts but not any in other huts, so was scheduled for a time when the Brick huts would not be worked on.
As more people are drawn to your solution, you can create many more bedroom huts for virtually no effort, while not needing to create as many of the less used Saunas.
Back to software
This last example, the Huts, is what micro services are. They are the centerpiece of modern Software Architecture, and in fact are going the direction of becoming even more micro (serverless, think if a Hut was designed just to have a sink cuz you may need more sinks than toilets).
The big point to be made, is that the end goal of modern Software Architecture is not about creating codebases that survive until the end of time the way Building Architecture does.
Modern Software Architecture is about creating small, modular solutions that can be spun up and thrown out on a whim as a reflection of their parent industries that are still practically in their infancies.
Top comments (0)