The Winchester Mystery House™ is an extravagant maze of Victorian craftsmanship – marvelous, baffling, and eerily eccentric, to say the least. Tour guides must warn people not to stray from the group or they could be lost for hours! Countless questions come to mind as you wander through the mansion.
Is Software Architecture Important?
When we talk about software architecture, we often refer to the The Winchester Mystery House™ as it has a lot of interesting features, like a staircase that descends seven steps and then rises eleven. It has windows in the ceilings and staircases that go nowhere. It has doors that could be fatal if someone carelessly stepped through them. It is said, that it was built as a maze with secret passages everywhere. This house, is very interesting to software developers because it teaches us important lessons about our craft. Have fun, look it up on your favorite search engine, then ask yourself if the software you’re currently working on makes you think of the The Winchester Mystery House™.
Writing software for computers to understand is easy. Modern tools do all the heavy lifting for us. They validate that our code compiles down to something that can be executed, they optimize instructions and they even correct some of our mistakes. But what they don’t do for us, is write code that can be understood by other human beings… Now that’s hard!
As a developer, I isolate myself from the big picture in order to concentrate on a small part of the overall application. This allows me to have the mental capabilities to tackle complex problems.
Where does software architecture come in? Well, let’s start with what it’s all about. Software architecture is about organization. Whether you pay attention to it or not, the computer will still be able to execute your software, but you might not be able to maintain it.
Good software architecture is achieved by never losing sight of the big picture. Generally, we choose a senior team member to keep it under control. The architect’s role is to steer the project, by keeping an eye on dependencies, on accidental complexity, on code quality and the use of proven patterns & practices in order to keep the code base manageable. Furthermore, he is expected to reduce complexity, identify recipes that can be used to implement functionality and for building tools in order to support his team’s efforts.
The truth is that the architect needs developers just as much as developers need an architect. They’re not involved in a competition because they complement each other. Building software is a team effort. I enjoy having someone at the helm. They keep track of technical debt, the overall architecture and plan future investments in our code base. Consequently, it allows me to concentrate on what I have to do.
Software architecture is the one thing that separates a big ball of mud from a maintainable solution. Good architecture isn’t necessarily a clever architecture. It’s about making things manageable by reducing unnecessary complexity by organizing the code base in a way that it feels natural. In fact, the results may surprise you, because investing in your architecture can drastically reduce the time it takes to onboard new team members. In other words, things should be where you expect them to be and code should do what you expect it to do.
Software architecture is important because even if you’re writing clean code, it doesn’t mean that your solution is maintainable. Be sure to keep both your code clean and your solution organized.
When you are building software for Azure, these concepts are even more apparent. Building software for the cloud is more of an organizational problem as much as it is a technological problem. For brevity, I won’t go into too many details in this post, but I will mention the following. Building software for the cloud is about organizing your solutions in order to get the more out of less. What I mean by this, is that by employing patterns we to help reduce the costs of operation and maximize the software’s durability, availability, reliability and its overall flexibility.
Updated: June 2016
This post was written at a time where Azure had a limited number of services. Since then, Azure has grown up. We no longer think in terms of Worker Roles vs Web Roles. Now we think about compute in terms of services like Service Fabric, Azure Batch, App Service, Functions, Web Jobs, Azure Container Services, Cloud Foundry, Pivotal, Cloudare, Hadoop, Azure Data Factory and Virtual Machines. Our options have expanded, multiplied, diverged and converged to the point where it has become hard to decide which one is best for our technical challenge.
For the past few years, we’ve also witnessed the evolution of Agile Software practices. They’ve greatly encouraged Developers and IT Pros to collaborate, resulting in what we now call DevOps. This is important, because it influences our architectural decision. We now build software with toggles and feature gating in mind. Continuous Deployment (CD) is now a desirable reality. Configuration as Code and automation is the new normal. Architecture requires that we stay on our toes. Newer approaches can lead to substantial advantages both for the business and developers. It’s important to reassess available options regularly. Ultimately, changes in our architectures matter and can create innovative opportunities for the business.
How often do you reassess your architecture and pivot to stay ahead of your competition?
Alexandre Brisebois ☁ 