Contents
- How we define 'Emerging Architecture'
- How we got here and why we needed to
- How we use this philosophy
- Advantages of an 'Emerging Architecture'
- Disadvantages of 'Emerging Architecture'
How we define 'Emerging Architecture'
'Emerging Architecture', as my team uses the term, is: 'Designing the system as minimally as possible, only changing the design when completely required for a user requirement. Keep the system simple, with no over-designing for the current needs.'
This philosophy means we only change the system's design when we have a reason, with zero over-engineering (in theory). The need for change can only be driven by user requirements so that we keep a clear focus on what's important.
How we got here and why we needed to
Our team has been using this design philosophy for around ~6 months at the time of writing, but it took some hardships to find it was suitable for us.
Around the beginning of 2023, we started on a project codenamed 'Bifrost'. The aim of Bifrost is simple: make the access and developer experience of using specific ancient but central systems considerably better. It takes way too long for teams to integrate with this system, and we want to enhance the quality and speed (of development) of the many teams/systems wanting to use it.
Whilst simple in theory, there are a lot of challenges - primarily with the upstream system. We created a 'Tracer Bullet' to try and crack some of the challenges early.
We struggled. We were trying to do a big design up front, and we had yet to agree on anything. We also disagreed on the tracer bullet's purpose; the combining two factors led to failure. There were too many unknowns we wanted to discover and too many ways we could attack the problem. Analysis paralysis then kicks in, too.
So, how do you move forward? We regrouped. The team had been working in fragments, and the solution was to mob together and design something that works for the known situation. We agreed that the best thing was to build something simple that worked for the current user needs and that moving forward, we should keep this approach - an 'Emerging Architecture'.
Once we agreed on this simple design, we also did some 'divergent thinking' exercises to develop a guiding design that our solution may look like at the end of our milestones. I'm not sure how helpful this part was, but it did allow everybody to collaborate, build interpersonal relations, and stretch our architecture design legs.
How we use this philosophy
We do all our planning as a team, which is JIT (Just-In-Time) with a particular use case focus. When planning, we consider if there needs to be system design changes - the answer is almost always no. If yes, then we work together to ensure we only make the most minimal change in design required - absolutely zero over-engineering allowed. By doing this designing together, we will collectively ensure that no over-designing happens.
Our use case suits 'Emerging Architecture' exceptionally well, as we're building an API gateway with success milestones containing expected user count/load.
Our milestones allow us to design iteratively, as we only need to develop with the following user milestone in mind. We can run performance/load tests against our API to see how we fare against our milestone. If our tests indicate that we aren't ready for the next milestone, then we plan the design (and work) that will get us there. Once implemented, we can rerun the tests and prove our design is good for the milestone we're working towards.
Here’s an example: Our first milestone in the team is to enable 100 users at the same time (concurrently). We know that the milestone after that is ~3,000 users concurrently.
Our design is built with 100 users in mind. Our session management is all done in memory, in one running service instance. We purposefully chose only to have one instance of our service running because we think it will handle this milestone. We suspect it won’t work for the next milestone, and for the milestones after, we’re almost certain it won’t scale.
We’ve run load/performance testing and fixed bugs that arose in the session management area, bugs that would go away if we changed our design to handle the next few milestones, as we are confident this is the area that doesn’t scale. However, we know it’s easier to hit this milestone with this design. It takes less time to build with this design and gives us more time to focus on everything else. For this milestone, we are also building the rest of the system. We know there’s no point focusing on scale if we don’t have a working system first, so we make our lives easier and choose our battles. Scale is a complex problem down the road; our problem now is a usable system.
Advantages of an 'Emerging Architecture'
Caveat: We are still in the midst of delivering our project using this philosophy, so we have yet to discover everything great and not-so-great about it.
So far, the 'Emerging Architecture' philosophy we've been using is working well for us. Here are some advantages that I think have come from following it:
- It creates space that allows you and the team to dedicate time to the most important things that your users need (features).
- Lack of over-engineering leads to less refactoring when you inevitably go too far in the wrong direction.
- It's easy to pivot and change direction as you become more practised.
- Your design is more flexible, making tackling unknowns easier.
- Iterative design allows for iterative feedback.
- Iterative feedback (and design) means you can solve the challenging problems individually when they appear rather than all simultaneously.
- It's easier to catch the problems in your design if only small parts change at any time. You can be more confident that a solution change will work with fewer moving parts.
Disadvantages of an 'Emerging Architecture'
- Greater chance of system design rework - The changes that get you to your next milestone may not be the correct change for the milestone after. Sometimes, certain choices don’t scale as well as others but are better at lower user counts.
- Greater chance of feature rework - If you design for more significant user numbers early, it can affect how a feature is implemented. You may choose to do something in-memory because of the scale requirement but later need to move to a separate service for higher throughput/user counts - leading to other changes, such as how you get data into a system. You may have to rework multiple features between milestones.
- You must be mindful of costly/irreversible design decisions, or you can find yourself in a challenging situation.
In Summary
'Emerging Architecture' is a philosophy that we follow. It has advantages and disadvantages, but it's working for us, and the trade-offs seem worth it. We're keen to see where it takes us and hope we make the right decisions - and when we don't, at least we'll learn some things on the way.
Let me know what you think in the comments below. Have you tried this philosophy? How did it work for you?
Top comments (0)