Susanne Tedrick loves architecture and is a big fan of the work of architect Frank Lloyd Wright. One of her past offices was even in a building he worked on: the Rookery Building in Chicago.
Built in the late 1880s and then partially remodeled by Wright in 1905, the Rookery Building was built to be artistically spectacular. Intricately decorated columns and arching stairways rise over beautifully detailed marble floors. The ornate glass ceiling fills the light court at the building’s center with natural light. All the elements of this grand building invite visitors — of which there are many — to look up and experience the building as a piece of art.
What Is Software Architecture?
But it was not designed to meet the needs of a modern office building. The marble floors can make slipping an issue in rainy weather. The fact it is a tourist attraction means visitors sometimes sit on the grand staircases even though they aren’t supposed to, impeding employees who are trying to get to work. Given its size and age, heating and cooling can be another problem.
The architecture just isn’t the right design according to modern expectations of an office building, Tedrick said.
Tedrick, a senior Azure infrastructure specialist at Microsoft, looks at software architecture the same way.
“Depending on what exactly it is that you’re trying to build and what your high-level requirements are for that building — structural requirements or aesthetic requirements — there are going to be some approaches that lend to your success versus detract [from it],” Tedrick said. “Having the correct architecture in place makes all the difference.”
What Is Software Architecture?
Software architecture is the fundamental underlying structure of a software system. Just like physical architecture defines and limits how a specific building can be efficiently used, software architecture defines what software is or can be. While generally invisible to users, software architecture shapes their experience with a particular software.
Similarly, software architecture has a massive impact on software developers. When poorly selected or haphazardly executed, software architecture can hamper developers by boxing them into a system that is hard or costly to adapt. When done well, however, software architecture allows for flexibility to expand or adapt to meet future needs.
Software Architecture Organizes Code and Defines Development
Software architecture organizes where all the raw material (code) will go and how the construction crew (developers) will approach the creation and maintenance of a software system.
At its core, software architecture encompasses the patterns and practices necessary to manage the often large volumes of code and complexity involved in producing software, according to Harry Brundage, co-founder of Gadget, a serverless stack that develops architecture with built-in scalability for e-commerce apps.
And those patterns are very necessary. “My engineering team is 10 people strong and there’s no one, including myself, who knows the whole codebase anymore,” Brundage said. “It’s already too big.”
When the scope of a piece of software or a software system increases in size or complexity, the relevance of the underlying architecture as a pattern to organize its complexity becomes even more important. Brundage gave the example of his past experience at Shopify, an e-commerce company.
“The task of a large software team is to build a system that solves an important problem for the business,” he said. “In the case of Shopify, it’s to facilitate commerce online, where one party has something to sell and one party wants to buy it, securely exchange the money and get the product shipped.”
The complexity involved with the software system Shopify used to solve its problem includes many smaller problems: how to process credit cards, how to model the idea of a cart, how to handle discounts, package deals or flash sales and more, Brundage said.
Well-chosen software architecture provides a predictable pattern for those developing and maintaining software. This is especially important as the project or the development teams get bigger.
“If there’s 150 different people working on [a software system], but if they all tend to make the same decisions and their output all looks the same, it makes individuals much more portable between different parts of the codebase,” Brundage said. “They have some degree of familiarity because it works the way they would expect according to the kind of rubric.”
He gave the example of a construction team working on a housing subdivision involving a large number of individual units but only a few floor plans. The structure or pattern represented by the architectural plans mean that anyone on the construction crew can more effectively, quickly and easily build each individual house.
“If the studs are the same in every single house, that means the drywall team doesn’t have to relearn how to mount the drywall each time they move to the next house,” he said.
Monolithic vs. Services-Based Architecture
But the relationship between software architecture and software developers is not unidirectional. The nature of the team will often indicate which software architecture will work best for a project. Just like there are approaches to the architecture of buildings — neoclassical, industrial, gothic — software architecture has some identifiable approaches. The two main approaches to large-scale software today are monolithic and services-based.
Monolithic architecture is a design style where a single software product or system does it all. Software built with this underlying architecture tends to be holistic and self-contained. It can also get too complex quickly and if something breaks in the system, the whole thing breaks.
The second main approach is based on services where the overall problem a software system addresses is broken down into smaller problems and tackled independently. Within the services-based approach, there is service-oriented architecture and microservices. There is debate as to whether microservices are a subset or evolution of service-oriented architecture, or whether they represent a completely different architecture, according to Tedrick. The fact the two architectures have a lot in common makes the exact nature of their relationship complicated.
“The needs of one developer working on a project by themself is very different than a team of 150 developers working on the project altogether.”
Despite their similarities, service-oriented architecture and microservices are different. On the one hand, service-oriented architecture often shares and reuses elements between different components of the software system. On the other hand, microservices often break components down farther than in service-oriented architecture and create each of those smaller components as self-contained units. So a microservice will likely have its own database, for example, whereas several similar components in a software system built with service-oriented architecture might share one, Tedrick said.
The monolithic approach and the services-based approach represent two opposite poles on the spectrum of software architecture styles, according to Brundage. The two sides each come up with a different answer to the question, how many problems will this software solution solve? And they work better for different types of development teams.
“The needs of one developer working on a project by themself is very different than a team of 150 developers working on the project altogether,” Brundage said.
A single developer or a small team working on a small project can understand a whole system in its entirety, making the monolithic approach workable. But, as in Brundage’s Shopify example, the complexity of a piece of software can easily expand beyond the scope of a single developer or small team’s ability to keep track of. Similarly, when there are large teams of developers, a services-based approach would work best.
Take Amazon, which has tens of thousands of developers who work across its various software systems, like AWS. “At that point, the software architecture is so dominant in its effects on their productivity that they have to care really, really deeply about how to keep 20,000 people all moving forward without stepping on each other’s toes,” Brundage said.
The services-based approach to the software architecture segments Amazon’s massive software systems into smaller problems. Similarly, the massive developer team can be segmented into the company’s two-pizza teams approach, which tackle the little problems and work more efficiently than they would as larger teams.
Neither approach to software architecture is better or worse than the other. Each is best suited to different project and team situations, Brundage said.
“Like any architecture, what is the right architecture demanded by the situation that you’re in,” he said. “And your average startup is in a very different situation than a 20,000 person-strong dev team.”
Software Architecture Sets What User Experiences Are Possible
Though software architecture is entirely internal-facing — something only developers will see — it will define a user’s experience, be they internal or external to the company.
Consider an architect designing a skyscraper office building in the heart of a city. They would need to think about what office workers would need and expect. This could include adequate heating, ventilation and air conditioning stems; enough parking, restrooms and meeting rooms; and the infrastructure necessary for utilities like water, power and internet. An office highrise that lacks these things would result in a poor experience.
The same sort of considerations apply to software architecture within the contexts of the problem a software system is trying to solve, according to Tedrick. A software architect would need to design for factors like performance, reliability, speed, security and user needs. Software built on an architecture that does not provide for these things could result in unpredictable performance or the possibility of having their data stolen, for instance.
Even with the right software architecture, different designs can result in vastly different user experiences. For example, Brundage pointed out that most websites since the 1990s have operated on a very similar architecture where users navigate from page to page where each time a user clicks a link, a new page appears. This compares to a growing number of collaborative platform sites like Google Docs, Figma or Canva that feel — to the user — far more like a desktop application than a series of pages. And that was due to very purposeful architectural decisions made by those who built those software systems.
“The software architecture often dictates what quality of user experience as possible,” Brundage said.
Bad Software Architecture Can Limit Scalability
The underlying architecture also dictates what a company can do with its software in the future — namely, how scaleable its software products or systems can be. Architecture that doesn’t fit the needs of a project or team, or software that was built without consideration paid to its architecture, is bad architecture.
Tedrick pointed to the monolithic and services-based approaches: While they can each work well for different situations, a monolithic architecture will inherently limit scalability.
“With a monolithic application, [it] needs to be taken offline and then taken apart or adjusted in order to make changes, as each part is dependent on the other to function,” she said. “With microservices, you can update existing services of an application quickly, and without taking an entire application offline.”.
“A poor architecture can make changes to the software much harder than they need to be.”
Similarly, whereas monolithic approaches to software architecture will rely on one programming language which can make it more rigid and limit who can work on it, the services-based approach — especially microservices — can utilize different languages across the different independent components of a software system. The ability to use multiple languages allows a company to take advantage of different capabilities across the team.
In addition to poorly chosen architecture for a particular situation, Brundage explained that bad architecture can also just mean poor quality design. Software architecture is supposed to provide a pattern of organization to the software’s code. When it doesn’t do that, scalability can be severely limited simply because it can slow down and complicate the actual task of working on the code.
“A poor architecture can make changes to the software much harder than they need to be,” he said. “Things are hard to find, more things need to be changed than necessary, changes have unexpected ramifications and break things, or the correct change is really hard to identify for new developers.”
Why Bad Architecture Happens
The influence software architecture has on the scalability of a piece of software — and usually the company that uses it — makes decisions about software architecture very important. Ideally these decisions get made early on in the development process before any code is written, according to Tedrick. This isn’t always possible or realistic however.
Brundage said that for most software developers — especially when they are working at startups or at the very early stages of programming something out — the approach to software architecture is happenstance or unsophisticated.
“When you sit down to certain projects, oftentimes, you just open up an empty file — it’s like a blank Word doc — and you begin writing your first lines of code,” he said of the process for many developers. Many of the software architectural considerations that will impact a software’s scalability must be made early on in the process, but are not very important at that point. So many companies, especially startups, don’t pay as much attention to their software architecture at the beginning — something they might regret a few years later.
“You want the next person who comes along to be able to understand it very quickly and change it for whatever their needs are immediately.”
They have other things to worry about, so they work with what they have. “Often, at the start of a project, you pick an architecture or you just land on an architecture that doesn’t happen to be very scalable, and then you need to change it later to be more scalable,” Brundage said.
Software architectures can be adapted and scaled given the malleability of the materials — it’s all just code in the cloud, Brundage said, and changing it just takes time and money — but some designs and approaches are more natively scalable than others. Knowing which architectural approach will be the most scalable in a specific situation often comes down to experience.
“This is an art, not a science, and a young one at that,” said Brundage. In his experience, however, most people who work on software consider simple, straightforward code design to be the most “beautiful” because it is the most adaptable.
“You want the next person who comes along to be able to understand it very quickly and change it for whatever their needs are immediately,” he said.
Build Software Architecture With Future Needs in Mind
A good approach to software architecture keeps an eye to the future.
“The last thing you want to do is box yourself into a situation where you see these things coming, but the existing systems and applications that you have in place are so monolithic that — if you’ve tried to change just one thing — you’ve got to rebuild it and there’s nothing that you can do and you do have to start from scratch,” Tedrick said.
She gave the example of a municipal transportation authority where she used to live that had built its entire system using COBOL, a programming language originally created in 1959. While it is still used, COBOL is a very rigid language that isn’t regularly taught in the same depth as more modern languages, making it a difficult building material to work with in a system’s overall architecture. That element of the system’s architecture makes it poorly suited to adapt to future needs.
In that situation, Tedrick says that a complete overhaul or rebuild of the system might make more sense than continuing to build in COBOL. But that drastic approach is not usually necessary, especially when software architecture is considered at the beginning of the process.
There will always be new needs that come up as companies grow, consumer expectations change and new technologies are developed, but good software architecture is flexible by design, according to Tedrick.
“Good software architecture design thinks about almost future-proofing, allowing you to kind of make adjustments as they come up or as they’re needed,” Tedrick said.
