Inspiration for software architecture often comes from the world of building architecture. In building architecture, the architect takes in local building codes to understand construction requirements. They analyze various building components like ductwork and furnaces, windows and doors, and figure out where and when to use standard components and when to build custom. They provide cost estimates for each of the components and for the whole, and then build out a blueprint providing upfront design and specification.
As a software architect, you can take a similar approach. You collaborate with IT, marketing, and management to understand any architectural requirements, then see what existing or off the shelf components can satisfy those requirements or where it makes more sense to build something custom. It’s then up to the architect to build out a blueprint and design for what the software might do, and what it might cost to build.
Of course, this understanding of software architecture makes a big assumption: that software plans are accurate. We know this is not true, and have spent years undoing the damage of this assumption. We now know that the ability to react to change by using iterative (or agile) development is a more realistic model for building software. It’s time we also adjust the expectation of software architecture, by equating it not to a building architect, but to a landscape architect.
A landscape architect starts building a plan by collaborating with the client, and learning about the existing conditions on the ground. After agreeing on a vision, the architect can plan the work. In some places, you can leverage heavy machinery to scrape any existing growth from the planned site and start fresh from a clean slate. In others, you will need to work with the existing features by designing with and around the environment. Once the groundwork is laid, you can execute on the vision.
Landscapes are organic. They change over time. And no matter how carefully you designed an initial vision, natural growth will always resist being perfectly controlled. A knee jerk (and nonsensical) reaction would be to throw everything away and start over from scratch. A more sensible approach is to work with the growth. Fertilize the plants that you want to encourage to grow, prune the shrubs that have grown too large, and uproot the weeds that you simply don’t want. A landscaper cultivates in line with the vision, and adjusts their plan according to the designs of nature.
Software is organic too. Software grows and accumulates over time, and it must react to the ever-changing requirements of the business. Software is built by people, who will work with what they have, under time pressure, to deliver something of value that may only resemble the initial vision. As a software architect, you have some choice. You can act like a building architect, design perfect blueprints and execute them with authority, governance, and architecture review boards, or you can choose the organic approach: cultivate the patterns and strategies you want to support, and trim and prune those you don’t.
A good architect embraces the organic nature of software. A good architect curates the mass of ongoing work in the organization, highlighting the good systems using robust patterns and broadening their scope by teaching other teams how to adopt those patterns. A good architect minimizes bad patterns by identifying systems that are functioning poorly and helping to transition them to better designs. A good architect works with their environment, accepting reality on the ground, resisting the urge to dictate and control.