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.
Peter Berg, Founder and CTO at Forward, recounts how he introduced processes for continuous improvement and thus creating a more psychologically safe working environment.
Founder / CTO at Forward
Peter Berg, Founder and CTO at Forward, describes how he helped ramp up a slow-moving team by applying his simple, yet expert approach.
Founder / CTO at Forward
Justin Potts, VP of Engineering at MoneyLion, tackles the ever-intriguing problem of simplifying the architecture and thus reducing the overall complexity of the systems.
Head of Engineering at MoneyLion
Brian Guthrie, VP of Engineering at Meetup, recalls the difficulties he endured due to a lack of cross-departmental cooperation caused by different systemic incentives teams were given to.
VP of Engineering at Meetup
Brian Guthrie, VP of Engineering at Meetup, tells a story of the first project he tackled as a Head of Platform Engineering -- a notification system gone amiss.
VP of Engineering at Meetup
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.