Taking a hard look at the current state of your architecture so as to remove bottlenecks, address constraints and to set your teams up to work independently from each other.
When you’re the CTO of a growing organization, things will break. Not the least of which will be your architecture. Decisions you made months or even years ago will invariably become the obstacles of today and perhaps the show stoppers of the future.
I consider it to be strong leadership when we adopt a hopeful and can-do attitude about upgrading the architecture of our apps to their current and near future needs. Falling into scrutiny as to “how we got here” seldomly serves the greater purpose of focusing our teams on where things need to go.
Do you see your architecture as something that draws engineers into your world? The ability to work on one part of the system without breaking other parts? Independence. Autonomy. When we think of architecture, we see it as a highly technical skill. But what if it’s also an organizational skill? Who do we have? What skills do we have?
What are we signing ourselves up for the future?
I believe it’s important to architect our solutions towards immediate and near future growth. This is where a mixture of product leadership and engineering expertise can create a formidable partnership.
TBD
TBD
The challenge here is knowing which aspects of the architecture need to be addressed first. There may be some obvious bottlenecks but it’s not equally as obvious how the bottleneck needs to be addressed.
Example of how one part of the system could be causing other issues.
In general there are tried and tested patterns for upgrading an aging SaaS architecture.
Strangler pattern involves gradually replacing the old architecture with a new one by incrementally building new components and services around the old ones. As the new components are added, they gradually take over the functionality of the old ones. Eventually they “strangle” the old architecture.
The microservices pattern is an approach to break up a monolithic architecture into smaller more manageable services. The main advantage here is that teams can work independently on these services to maintain and upgrade them.
A giant step towards relieving bottlenecks is the event driven architecture pattern. This is where events, usually in the form of messages, are used to communicate between different components. This provides greater decoupling and flexibility.
Other patterns include the blue/green deployments and circuit breaker patterns but there are many tried and tested patterns that help us scale our technologies in a way that supports a growing development team.
These are just a few examples of the design patterns that can be applied to upgrading an aging SaaS architecture. The specific patterns that are appropriate will depend on the specific needs and requirements of the architecture and the business.