Seeing the Forest and the Trees
Explore the relationship between system design and architectural landscape.
We'll cover the following
Architectural landscape and system design
The architectural landscape is not often talked about as a standalone topic outside of specific instances such as migrating from on-premises to the cloud. In many ways, it’s similar to system design in its intention, as well as patterns. In most cases, the design of a single system within a larger ecosystem will match the design patterns of the systems around it. If the trend at our company is to utilize SOA, then we will see SOA at every level. The biggest difference between the architectural landscape and system design is the scope that the design encompasses.
We can’t see the forest for the trees is a proverb that was first published in 1546 in The Proverbs of John Heywood. The idea is that from the middle of a dense forest, we can see every tree that surrounds us in great detail, from the trunk all the way to the crown of the tree—but from this vantage point, you literally cannot see the whole forest; we don’t know how vast it is or the directions in which it flows, because the breadth is lost. This saying has become so common it is now an idiom in the English language.
People often relate to this idiom when they are too close to a problem to see the bigger picture or have been too close for too long to see clearly. Think back to a time when a problem was frustrating you and you worked to solve it with no progress. Then, you stepped away from the problem and when you came back, the solution came to you quickly! It came because you changed your perspective by allowing different information to come into play. Simply put, you saw the forest.
A TPM must have both a breadth and depth of knowledge. The depth (or the trees) refers to system designs and the breadth refers to the architectural landscape (or the forest). We can extend this analogy further and see where a system design and an architectural landscape are one and the same; when no other systems surround the one that the system design describes, then it is both the system design and the architectural landscape, like a lone tree on a hill. However, we can then zoom out from that tree far enough to see other trees and understand where it fits into the larger picture of the trees around it. That is to say, no modern system is in isolation, but the level at which we focus depends on the needs of our role. It may be at the team level, organization or department level, or company level.
Important tools we use to see the bigger picture better (the forest) are program, product, and team roadmaps. These roadmaps encompass different components of an architectural landscape. Each one looks into the future deliverables of a group of systems. More importantly, they describe either directly or indirectly the intention of that group of systems, why they exist, and what they are striving to become. The intentions, as well as discrete deliverables, are what determine the picture of the architectural landscape both as it exists today and how it will change in the future. Some companies publish technology directives that give the general direction that the company’s platforms are evolving toward, which can include the technologies that will be centralized.
Roles in the architectural landscape
A TPM will be expected to pick up on these cues from roadmaps and directives and point out when there’s an issue or an opportunity between multiple projects or programs. A Principal TPM is expected to see these issues or opportunities without being prompted whereas a Senior TPM is expected to see these connections as they relate to the projects or programs they run.
On the other hand, we also need to recognize the individual trees. our contribution to design reviews at the system level will lean on our knowledge of the architectural landscape as we set outside context against the proposed system design. In general, an SDE’s focus is on the system design and its interactions within the context of their own software. Just like a TPM, the SDE’s breadth also grows as they ascend the corporate ladder. Even so, the TPM’s job of looking across projects and across the organization is always required.
The figure below illustrates the varying areas of concern of a TPM, SDM, and SDE across an architectural landscape.
Get hands-on with 1200+ tech skills courses.