Scaling Software Architecture in Your Organization: A Practical Guide to Thinking Architecturally — Part II
As we have seen in part 1 of this series, introducing software architecture practice is not without its obstacles, from understanding what it should comprise, to keeping the focus on what is important, to scaling it.
In part 2 of this series, let’s examine strategies for scaling the software architecture practice, from a federated model to the creation of a technology radar.
Scaling the Practice
Once the software architecture practice is established, scaling it becomes the next challenge. It’s unrealistic to expect to have a dedicated architect for each team or project, and training a new architect is not something you can do in a short cycle.
Federation
To address scalability, SSENSE adopted a federated model composed of two levels: a technology architecture group (TAG) and a domain architecture group (DAG).
A TAG consists of one architect for each domain and primarily focuses on discussing topics that have the biggest impact company-wide. These topics stem from the company’s long-term vision and direction. For example, helping with the decision to adopt a cloud provider or setting up a disaster recovery (DR) strategy to be used by all domains.
A DAG is formed with at least one member from TAG and other leads or staff engineers from the teams that operate in a specific domain. The focus of DAG meetings should be two-fold: the dissemination of practices and directions agreed upon in TAG, and discussions around domain-specific projects and topics, be it challenges or cool things the teams are doing.
This allows DAG to be a multiplier, helping to speed up the adoption of changes and new patterns. At the same time, it keeps the discussions more relevant as all the members are part of the same domain, which by definition has a higher cohesion.
As shown in figure 5, communication between TAG and DAG is bi-directional. Projects with a cross-domain impact that propose new technologies or practices flow to TAG from DAG members after having been peer-reviewed. Those practices or problems can then be picked up by TAG and continue to be adopted by the other domains as well, if applicable.
Technology Radar
Another approach to address scalability challenges is implementing a technology radar. Thoughtworks releases its own radar, which can be useful as a starting point and inspiration, and a tool to create your own.
The idea is to capture tools, techniques, platforms, languages and frameworks that fall under one of the four stages:
- Hold — you should no longer use it.
Either due to changes in direction, because we had a bad experience while carefully using it, or because the option may no longer be supported.
- Assess — you should keep a close eye as it has the potential to provide significant value.
It may not be ready to be used as is, but it may serve as an exploratory proof of concept (PoC).
- Trial — all evidence indicates that you are ready to use it but you haven’t built up enough confidence to do so.
You could select a real project that can benefit from this as a way to build the experience prior to adopting it across the organization.
- Adopt — you should use it.
You have enough experience and evidence of the benefits and tradeoffs to determine when and where it should be used.
The radar helps to scale the organization as it provides guidance to the company, even outside TAG and DAG, on what the recommendation is, and what may come in the near future. You can, and should, define and update your radar periodically by collecting feedback from TAG and DAG members, alongside the community. We will revisit this last aspect in our next article.
It is paramount that you establish a process to justify the transition of any entry on the radar. For instance, you could suggest a simple format to evaluate the results of a trial against predefined success criteria. This way they can be presented and help identify if the technology under discussion should move to the adoption phase.
Architecture Catalog
As you progress in your journey, it is likely that you will start encountering recurring situations where the solution to be applied has been used in the past.
You can scale the architecture practice by capturing those patterns in a catalog that documents the pattern, its purpose, and when to apply or avoid it.
For example, if you have determined that in order to address a two-phase commit for your event-driven applications you need to leverage a transactional outbox pattern, you can add an entry to your catalog with the motivation and a recipe, potentially with an in-house or selected third-party library, to expedite the development.
As we have seen with the tech radar, this should be updated periodically and leverage both TAG and DAG as sources of contribution.
While there is no perfect formula, consider that any entry for the catalog should adhere to a base template containing:
- Title
- Short description
- What problem it solves
- When it should be used
- When to avoid
- The solution
- Example use case(s)
- Additional resources
It’s important to note that the entries in the catalog are not intended to provide theoretical knowledge. It is a practical guide for the adoption of the solution described there.
In the additional resources section, you should reference additional material, such as books, blogs, videos or training content that can explain more. It will serve as the starting point for those that want to know more about it.
We are Almost There
Creating an effective and efficient software architecture is a complex challenge. Add to this the limited number of experienced architects to deal with the demand of projects and you have yourself a tall order.
Overcoming the limited number of architects can be achieved through a federated model. Having more localized, domain-specific architecture groups will give you bidirectional communication that allows decisions to be taken at both levels and flow with fewer chances of contention.
Another approach is reducing the need for involvement from the TAG or DAG by having a technology radar and architecture catalog, which contain well established or analyzed decisions and save time.
But can we do better? Yes we can! In the next part of this series, we will focus on the developers, from junior to senior, and how they can sharpen their architecture skills.
Stay tuned!
Editorial reviews by Catherine Heim & Gregory Belhumeur.
Want to work with us? Click here to see all open positions at SSENSE!
