Scaling Software Architecture in Your Organization: A Practical Guide to Thinking Architecturally — Part III
As mentioned in parts 1 and 2 of this series, introducing software architecture practice can be challenging, from defining its components to maintaining the focus on what is essential to scaling it.
This final article will conclude by looking at how we can disseminate the architectural mindset throughout the organization, with a focus on developers.
Out With the Old, In With the New
“Experience is like having a time machine in your brain, you can revisit the past and hear its echoes” — Me
The constant evolution of technology presents developers with frameworks, tools and languages that promise to solve all the issues they may face. It’s almost like everything you have been building is wrong or obsolete as soon as you’re done.
We watch those demos and keynote presentations and are enamored with all that we see and start itching to use them immediately for fear of being stuck with “legacy”. Herein lies the first opportunity to change our approach.
With exceptions, it is important to acknowledge that “legacy” represents a proven, tested piece of technology that your team is likely familiar with. Making changes without a deliberate intention–and plan–can be risky, as it may result in discarding something valuable: knowledge.
Being at the bleeding edge usually does not come without pain, it is important to be cognizant of this prior to making a decision.
Instead, I invite you to study the new technology with distinct goals:
- Identify what problems it solves
Do we really have these problems? Sometimes we are sold ideas for problems that we do not have.
- Identify what the trade-offs are
No technology is perfect or immune to physical rules. Knowing those will help you to understand when not to use them. This is as important as understanding when to use a given technology.
- Identify if we have seen this before
Some technologies are based on concepts from the past. Perhaps we already tried to use a different incarnation of the same technology, so looking for this can help you decide if and how to revisit.
Of these 3 goals, the last one is likely the most challenging as it requires significant experience to assess. Later in this article, I will elaborate further on how to start building and capturing this experience. For now, let’s explore how we can try new technologies in a responsible manner.
Trying New Technologies
“Education is not something that you can finish” — Isaac Asimov
Imagine that you have examined a new technology, identified the goals highlighted in the previous section, and decided to give it a try. What’s next?
The first recommendation is to make sure you can do it in a safe environment. This usually means avoiding using it first in the most important or critical process of your company.
Start by listing the use cases or processes that contain one or more of the problems the new technology aims to solve. Then, eliminate those where the trade-offs are unacceptable, prioritize the remaining based on relevance and choose one where the impact is minimal.
If you are still uncertain, seek guidance from your Product/Business team to understand which candidate has the least impact.
Once you have made a clear selection, proceed with the next steps of the development process as per usual, while continuously assessing whether the promised benefits materialize as you progress.
But how do we even choose which technology to explore? We can’t simply try every shiny new technology that appears on the market.
Architecture Presentations
“The most important skill to have as a programmer is the ability to teach yourself new things effectively and efficiently.” — Ali Spittel
We all have our sources of information, be it a blog, a podcast, YouTube, or books. Once you are exposed to something new to you–or to the team–one way to help transition ideas into action is to do an architecture presentation.
Despite the name, you do not actually have to be an architect to participate. The idea is to go past the documentation and experiment just enough with it so you can understand its functioning. Then, prepare a presentation, which does not need to be too long or too formal. Ensure that your presentation covers at least two areas:
- How it addresses relevant use cases
It can be a small demonstration or even a diagram of how it would operate in a real environment. Keep in mind that you are not Netflix or Amazon. Ideas and concepts that may suit them, may not be representative of your reality.
2. What are the negative aspects
Nothing is perfect and you are bound to spot something that doesn’t work for you. Compromises such as cost, complexity, developer-friendliness, and latency may arise.
Present this to your team and form the habit of doing so regularly. If the presentation is well-received, consider proposing it for your company’s technology radar or architecture catalog, and present it to your DAG for further evaluation.
Architecture Design Record
“The faintest ink is more powerful than the strongest memory.” — Unknown source
As you go through the development process, it is easy to look at a given state of the system and ask yourself “why are we doing things this way?”. This question can be harder to answer, especially for new team members or on larger systems. Enter the architecture design record (ADR) to the rescue.
An ADR is a document that captures the options identified to address a given problem, as well as the selected option and the reasons behind it.
On top of providing you with the decision-making process of how you got here, the ADR allows you to have consistency, especially when there are multiple parts of the same system that will be developed over time.
The Structure
While there is no perfect one-size-fits-all structure for the ADR, there are various templates available that you can base yourself on and adjust to your needs.
The basic sections should be:
- Status — if it is in a draft, ready for review, approved
- Context — brief description of the problem and constraints
- Decision — which option of the available ones was picked and why
- Options — the detailed explanation of all the options found to address the context
- References — links to other ADRs, diagrams, tech radar or architecture catalog used in the ADR
The Process
The ADR is meant to be used to capture key decisions that can be harder to change later on. Keep that in mind to avoid making it overhead to the development process.
A sample process could be:
- Identify if there is any decision to be made
- Investigate prior ADRs on the project
- Look at the requirements and list possible solutions
- Capture these in your ADR
- Send it to be reviewed by the team
- Do a presentation (if needed) or discuss with peers to address any concerns
- Adjust the ADR with the results
If you follow an agile approach, like Scrum, it is recommended that an ADR is created prior to the next iteration of coding. It will give you the time to have it discussed and reviewed prior to actually committing to it in the form of code changes.
Wrapping up
Forming a software architecture takes time and effort. But there are simple changes we can make to instill the architectural mindset in our development teams.
Being able to get some perspective when faced with new technologies is the first step. Going beyond the surface layer and vendor information can help you understand the strengths and weaknesses of what is presented to you.
Considering your unique context, not all new options are necessarily better than the existing ones. Do we have the actual problem this new option aims to solve? What is the cost of adopting it (training, tooling, etc.)? Is it already in a stable state, compatible with the risk my company is willing to take?
If you ask yourself these questions, and you end up with a positive answer, find among the upcoming projects or maintenance opportunities the most relevant use case to apply. Measure to verify if it is truly effective and to discover any shortcomings.
Keep the learning cycle on by using ADRs as you go and leverage them for future decisions, especially when you find out a wrong decision has been made.
I know it may sound like a lot, but it is simpler than you think to get started.
Good luck!
Editorial reviews by Catherine Heim & Gregory Belhumeur.
Want to work with us? Click here to see all open positions at SSENSE!
