With so many definitions of architecture 1 (specifically software architecture 2) already available on the internet, I am not going to attempt creating yet another. Instead, I will try to explain what architecture is, in a way that hopefully makes it easier to understand. I am also not going to delve into various types of architecture, such as Enterprise Architecture, Solution Architecture, Technical Architecture, Information Architecture, etc. and the differences between them. I will focus on the essence of architecture regardless of what area it is in.

The Long Road

Let’s say we want to build a road from Shanghai to Beijing. It wouldn’t make sense to start laying the road in that general direction. We would want to survey what mountains, deserts, gorges, water bodies, etc. lie in the way. We might want to account for other cities and towns along the way that can also be connected to maximize the benefits of this road. We would want to allow for road widening to accommodate higher usage in the future by a growing population. We also need to have a better understanding of challenges such as soil consistency, elevations, traffic control, avoiding blockages, safety, environmental impact, aesthetics, budget outlook, etc. And so on.

It would make sense to bring in a team of experienced experts like a lead planner, construction specialists, surveyors, geologists, etc., the size of the team being commensurate with the scope of the project. If they are an efficient team, they can quickly understand the needs and challenges, provide high level master plans, give direction on work that can start right away, and continue to focus on areas that need further planning. At this point, we could contract various next tier vendors to start laying out 1 mile stretches of the road in a “heads down” fashion. If there are common procedures, standards, structural consistencies, etc. to be met, the specifications, tools, etc. to accomplish them should be made available. These vendors are not as concerned about the overall plan as they are about their piece of the puzzle, and how it fits into the big picture. I don’t have a background in road construction, so I’m sure there are inconsistencies in this analogy. But it suffices for the point I am trying to make. If you are into analogies, here is another that I liked 3.

The “important stuff” or “architecturally significant items”

If I map the above example to a software effort, the experienced team that is needed right from the beginning is a team that consists of a lead solutions architect, a program manager, information architects, technical architects, human interaction expert, etc., the size of the team being commensurate with the scope of the effort. Their job is to figure out the “important stuff” 4 i.e. items that this team, based on their knowledge and experience, deem to be architecturally significant. Typically, these items are business pain points like feature gaps, slow time to market, high cost of ownership, cost of compliance, etc. which in turn map to systemic qualities like flexibility, extensibility, maintainability, performance, scalability, availability, security, etc. While there might be a temptation to get things moving by gathering an implementation team (with varying skill sets & geographic locations) and having them code right away, such an approach often has counter-productive outcomes. It’s equally counter-productive to attempt planning everything to the nth detail before starting implementation. It just works way better when you start in the near term with a small team and grow it incrementally; when the average skill level of the initial team is much higher than that of the eventual larger team; when team co-location is emphasized before the growing team is allowed to spread out; when the architecturally significant items are understood, prioritized, and some of them even addressed early in the journey; when repeatable and reusable processes, tools, or artifacts (that are considered important) are implemented earlier and made available to the growing team; and when this leadership team of experts stays engaged to ensure that the blueprints and the implementation evolve consistently over time. Regardless of employing waterfall, phased, or agile methodologies, the need to start figuring out architecturally significant items earlier on in the effort, does not change.

If architecture is about architecturally significant items, what are those items? And what makes them significant? There is no cookie cutter list of such items (though there are oft occurring candidates like the ones mentioned above). Each effort has it’s own context, and each leadership team brings in it’s own biases. Based on the context and their biases, a leadership team interprets the business goals, pain points, root causes, risks, mitigation, etc.; decides on what is significant; and goes about solving the problem with that view point. A given problem can be solved in different ways just like the same road could have been built multiple different ways. Many can pass muster in the short term but only a few will stand the test of time (within the context of the vision and goals for a particular effort). We often come across implementations that meet initial functionality requirements but expose unexpected time & cost implications when it is time to meet the next set of requirements, when the solution proves not to be extensible, scalable, more performant, etc. Such outcomes are directly related to whether or not the leadership team was correct in their identification of architecturally significant items. This is why some aspects of architecture is an art form. Apart from experience and expertise, a good architect must have intuition, imagination, and problem solving ability, to correctly identify what really is important in the context of a given effort. That is not to say there is no science to identifying what is important. There are techniques that can be employed to help narrow down what is architecturally significant for a given effort. I will cover that topic in a future post.

Form, Function, Future

Some may scoff at drawing too many parallels between Architecture of physical structures (ex: buildings, bridges, etc.) and Software Architecture. But if one looks at it in the right spirit, it is a great way to draw analogies, explain concepts, and also to translate lessons learned from one sphere to another. It stands to reason that several concepts (ex: design patterns) and terms (ex: firewall) are applicable in both spheres. With my justification now in place, let’s move on to my next example, the Dallas Fort-Worth (DFW) airport 5 6.

The DFW airport (that I travel in and out of frequently) is very inspiring to me. It is one of the busiest airports in the world, yet it’s design allows me to park close to my specific gate, and get through security and boarding within a short walk. As you can see from these referenced diagrams, each terminal is independent of each other, unlike several airports where all passenger traffic is funneled from one entry point. This makes the DFW airport more “failure resistant”…so issues, repair-work, etc. impacting one area do not shut the whole thing down. Also, it is very expandable i.e. if they need to support more air traffic, they can simply add another semi-circular terminal to the backbone, and rely on the excellent network of runways to accommodate that growth. Getting from one terminal to another used to be time consuming for travelers connecting via DFW, but that was fixed with the recent “skylink” high-speed train system. In other words, the design is flexible enough to accommodate significant feature add over time.

Vitrivius, a 1st century Roman Architect, stated that architecture has 3 conditions: “strength, utility, and aesthetic effect” 7, or “commodity, firmness, and delight”, or “durability, utility, and beauty” (different interpretations meaning the same thing). I’ve often heard the phrase “form and function” being used to capture what architecture is all about. I like to think of architecture as being about “form, function, and future”. A soundly architected system should first fulfill the function for which it was built for. It should also be durable, flexible, extensible, and maintainable enough (not to mention performant and scalable enough) to fulfill future functional needs within the realm of reason. That it has a certain order to it, and is aesthetically pleasing, is a by-product of achieving the other two principles. In other words, you can’t achieve function and future with a chaotic, non-aesthetic structure. It all comes down to the principles of coupling and cohesion (keeping like things together, and unlike things separate), separation of responsibilities, reducing duplication, increasing reuse, ensuring high quality especially for the significant artifacts, etc., which leads to a well-structured solution, which in turn enables the solution to meet current and future needs in a cost and time effective manner. Just like viewing the blueprints or master plans of physical constructions, viewing the architecture specification diagrams and documentation of software solutions, can give you a sense of whether these three principles have been adhered to.


In summary, architecture is about taking a longer term view that adheres to the principles of “form, function, and future”. It is about correctly identifying the important stuff, and prioritizing the effort appropriately to solve for the important stuff as early as possible, while still allowing overall progress to be made. Since correct identification and proper solutioning of the important stuff is so key, it bears repeating that good architecture is also a function of the quality of the architect(s).