Simplifying the Architecture
30 September, 2020
As companies build out products, oftentimes teams build various systems that over time start to interact in complex ways. Furthermore, as time passes, those interactions become more and more complex. Eventually, you will have to take a look at all of your systems and reassess what belongs where and what should be talking to what. Then, you should simplify some of the complications and reduce the complexity of the systems.
We addressed this problem by implementing domain-driven design (DDD) -- an approach that emphasizes that the structure and language of code should match the business domain. We trained our engineers on the facets of domain-driven design and have them examine the system with fresh eyes, fresh tools, and fresh concepts like bounded context, aggregates, domain events and ubiquitous language.
We also started an architecture team that helped people learn and implement these concepts, and moreover, make key suggestions for the design or redesign of the systems.
The reason we chose this approach was that there are only a couple of approaches when you are trying to teach people architecture. There are paid-for platforms like Pluralsight or O’Reilly Media or we could help with mentoring relationships. However, we already had a team of people who were quite good engineers and we wanted to leverage the in-house knowledge we had since we knew our systems quite well. We chose an architecture team over those other options because it was the quickest to implement, we had the credibility and knowledge and we knew how to make the proper connections with people to make sure that it wasn’t an approval by the committee but information sharing with colleagues about how to better design systems.
The training for engineers went exceptionally well. We implemented it in two ways -- we had workshops where we would give presentations to the company and we also introduced a company-wide process called the request for comments (RFC), where people would draft design proposals. We would discuss the architectural principles inside the RFC with a lot of repetition and soon enough people were able to understand what is, for example, a bounded context and why we care about it. We used the RFC to effectively spread the knowledge about the architecture.
Also, we had one-on-ones with people when there was a need to clarify some concepts without them encountering any problem. There were not part of regular one-on-ones that are driven by employees, those were one-off discussions on challenges they were facing -- if we would notice that someone is struggling with a particular problem, we would reach out to them or more frequently after we built our reputation they would reach out to us, as the goal is always to be pulled not pushed.
- The solution, in this case, is never final because you are fighting complexity and entropy and these things are omnipresent and constantly recurring, but we were able to eliminate tech debt at a faster rate than we were before and the systems were becoming easier to reason about which means the meantime to resolution was also going down -- these are the key progress indicators that we are interested in.
- Don’t do architecture as an approval committee -- that is an anti-path you want to avoid.
- Make sure you take a gentle approach when teaching people architecture. Rather than saying this is the right way, make sure that you are approaching the conversations in terms of facts, impact and then, feelings. It is important not to dictate these things, otherwise, people become resistant to the change.
- The key thing about architecture is not that architecture itself is complex, but that you have to be very considerate of the work people are already doing because this is an addition to their current work.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Vadim Antonov, Engineering Manager at Meta, dictates how he brought a brand new team into the remote learning process by ramping up onboarding and creating a mentor system.
Engineering Manager at Facebook
Vadim Antonov, Engineering Manager at Meta, details his journey to improve his personal hiring process and team pitch.
Engineering Manager at Facebook
Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.
Director of Product at Startup
Adam Hawkins, Site Reliability Engineer at Skillshare, went all the way across the world to build a brand new team who worked very differently than he was used to.
Site Reliability Engineer at Skillshare
Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how to really understand someone else’s point of view.
Divisional Vice President, Global Supply Chain Technology at Trimble Transportation
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.