We've just launched plato for individuals

🔥

login


Google Sign inLinkedIn Sign in

Don't have an account? 

Simplifying the Architecture

Team processes
Dev Processes
Coaching / Training / Mentorship

30 September, 2020

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.

Problem

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.
 

Actions taken

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.
 

Lessons learned

  • 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.

Related stories

Introducing Processes for Continuous Improvement
30 September

Peter Berg, Founder and CTO at Forward, recounts how he introduced processes for continuous improvement and thus creating a more psychologically safe working environment.

Impact
Productivity
Coaching / Training / Mentorship
Peter Berg

Peter Berg

Founder / CTO at Forward

The Quick Fix to a Slow Team: A Consultant’s Perspective
30 September

Peter Berg, Founder and CTO at Forward, describes how he helped ramp up a slow-moving team by applying his simple, yet expert approach.

Team processes
Delegate
Productivity
Agile / Scrum
Peter Berg

Peter Berg

Founder / CTO at Forward

Simplifying the Architecture
30 September

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.

Team processes
Dev Processes
Coaching / Training / Mentorship
Justin Potts

Justin Potts

Head of Engineering at MoneyLion

How Different Systemic Incentives Are Making Cross-Departmental Cooperation More Challenging
30 September

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.

Cross-functional collaboration
Dev Processes
Brian Guthrie

Brian Guthrie

VP of Engineering at Meetup

Handling Tech Debt: A Story About a Notification System Gone Amiss
30 September

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.

Dev Processes
Product
Brian Guthrie

Brian Guthrie

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.