Software designers talk about the “architecture of the software.” Investors and buyers want to know if the software is “well-architected”, developers want to understand how to use the architecture, product managers want to make sure the functional and technology architectures will support sales, etc.
Software, or technology architecture defines the physical and logical components and services of the software that support the development, maintenance, execution and monitoring of the software. In some cases the architecture might be provided as a tool or a service from a vendor (including open source), or assembled from multiple vendors with some combination of additional development and customization and extension.
What is good software architecture and how do you design and build it? I’m going to summarize my experiences and ideas on this topic in the next posts. But I want to start with an observation that software architecture, like all architecture is situational or contextual. You can’t evaluate this question without considering the constraints and influences on the design and development of the architecture.
Let me give you an example from the physical world. Near where I grew up in the southern suburbs of Pittsburgh there is a road interchange called the West End Circle. The picture below is a real sign entering the interchange from Carson Street. Wow, clearly this is a poorly architected intersection. My favorite is the instruction that you can go North by turning left or right. How convenient.
However, when you consider the geography of rivers and mountains in Pittsburgh, and the fact that this interchange is in a valley that has had a road configuration for 300 years or more and evolved from Native American trails this intersection actually functions pretty well. A lot of traffic moves through this intersection safely and quickly every day. Its an interchange architecture that makes the best of a set of constraints (geography, funding, legacy roads, need to maintain traffic flow, etc.)
My first observation in considering how to design and build a good software architecture is to define and understand your constraints and be realistic. How much funding and time do you have to build the architecture? What are you starting with? What people do you have to design and build the architecture and what skills do they have? What do you need? How long will the system be expected to last?
In a way these are a form of requirements, but I would argue more foundational. In future posts I’m going to define some of the principles that help create a good architecture for software. First, though in the next post I’m going to define the biggest failure I’ve seen in software architecture.