Software development now focuses significantly on architecture.
"The architecture needs to be right up front to help us succeed."
"We need to know the architecture for this feature before we can start building."
"Let's have an architecture planning session."
"I want to be a better architect."
Even as Principle Studios' Principal Architect, the last one or two may be the only ones I can actually help with.
No, I don't believe I just admitted that I'm incompetent at my job. The reality is that architecture means a lot of different things to different people. I take a view that is different from many, but I hope it resonates with others.
Architecture is an attribute of software. The architecture is worked on, improved, and adapted as the needs of the software change. As a result, a fresh project has very little architecture other than what is granted to it by the chosen frameworks. Moreover, what is considered architecture is very different to different people.
- To an API developer, architecture is the pattern of communication between software components. This can start with a basic understanding of REST, GraphQL, or gRPC for network-based APIs. Within a smaller unit, this can look like using inversion of control, factories, fluent interfaces, builder patterns, or any number of other common (and uncommon) design patterns.
- To a cloud developer, architecture is the orchestration of deployable units, where API gateways and security boundaries are, how services fail over, and how to mitigate redundancy and uptime.
- To a database developer, architecture is the modularity of the database, how indices are created and utilized, the degree to which stored procedures are avoided or used, the access levels for different applications.
- To an enterprise architect, architecture is the communication and structure of teams and how projects (whether new features, new projects, or traiging issues) flow through the organization.
- To a UI developer, architecture is the mapping of components into the design language, the APIs of those components, the ability to reuse the existing components in new locations, and the flexibility to use the same components with new data sources.
- To a junior developer, architecture is how quickly they can find what they need to change to get their task complete… and how easily they can verify that they didn't break anything else.
I think the last one is actually the most important. The best code is read hundreds of times more than it is written; developers will come to it, learn what they need, and hopefully never need to change it.
Architecture, then, is a side-effect of the software. It is how the software communicates about itself to anyone reading it, and reflects the communication structure of the development teams that created it.
What about architecture plans?
Plans are something completely different. We could call them "development plans" or "software plans." When writing any plan to solve a problem, it makes sense to consider the current state and the end state… so a software plan should consider both the current architecture and the architecture at the end of the project. (This is different from declaring the architecture at the end of the project.) Any plan that fails to account for how the plan will actually be implemented (timeline, staffing, requirements changes, etc.) will ultimately fall short; anyone who has written a plan knows that it is out of date as soon as it meets reality. In software, when this plan is adhered to in spite of any changes, it often results in a poorer architecture.
As a result, the best architecture plans tend to be high level, present various options with the benefits of each, and propose a recommendation given the information available at the time. These plans need to be treated as a point-of-time document and not held as an prescribed manual for the remaining development.
What is the Principle way?
Don't worry, I'm not about to say all is lost and don't bother thinking about architecture. Instead, every developer has a responsibility for the architecture of the codebases they work within. That means that "architects" are developers who have a thorough understanding of the architectural goals of a project and should be available to any developer to help make decisions on how to improve the codebase.
Further, architects should be producing documentation for developers to refer to for guidance (as a contrast for developers providing documentation of changes to architects.) This documentation can be architectural guidelines, developer-oriented stories for improving architecture, or even simply feedback on pull requests and suggestions. The more proactive an architect can be at providing valuable guidance, the more time they'll have to dive into the codebase and think about other ways to improve the software.
When I'm asked for an architecture plan, I put together the best plan I can for the information I have. When I get new information that conflicts with the plan, I'm usually the first to declare the plan obsolete. I'll inform the team, and we'll pivot to a new plan, in whatever form that may be. In most cases, we've kept the architecture flexible enough that the change to the plan doesn't have cascading effects.