Why team structure matters, when we approach the system architect.
Long time ago that I haven’t done writing the blog until I met P’Bank Apirak Panatkool who is an expert in Experience design.
P’Bank has explained that in the order to design the architect we should know what the problem is…
Connect with the problems
Suppose that we are going to create new system architect for a marketplace platform, we have 4 teams with different stakeholders and team which are
- Marketplace team
- Logistic team
- Payment team
- IT team
The question is how we design the service to be most suitable for this requirement. One of the solutions is to apply service-oriented architecture then separate it like
Marketplace API Service is responsible to reserve all the requests from other services in the organization including frontend, Android, IOS, and Web, which are maintained by the same IT Team.
Once the product is built and we have new requirements that the product should be able to see how much shipping cost will spend before making the order so they need to book the meeting to refine the requirements.
Not only do developers need to join many meetings they also need to remember the context of each feature as well, so now developers have too many cognitive loads because a lot of business requirements they remembered and switched the context to relate the meeting or work.
Concept
Such a problem appears when we design the architect without organization structure knowledge. instead of separating teams like the above, we can let the developer to sit around each team and work together with stakeholders to reduce cognitive load. When the changes arise the developer would be able to contact the business unit directly it might spend less time on meetings and no need to know other business needs from other domains.
Example
Imagine that 3 developers work with Marketplace team they are responsible for code only marketplace business logic so the architect would be like this, if they need to show shipping cost they just ask logistic team to provide API that use for calculating the shipping cost without knowing the business logic inside the source code, or if the code of marketplace team change they just contact to business owners directly which is faster.
Summary
Now that we see only marketplace service that holds a lot of things seemed ineffective, so the suitable way to make it easy to maintain is spin-off service to each team so that the developers don’t need to remember all source code of every team so that can focus and work effectively by don’t wasting time remember things or “We can’t remember the impact right now we need to go revisit our source code then tell you later”
This is because as a human we have limited cognitive load, so reducing cognitive loads is the way to increase developer experience.
By following this not only do we reduce cognitive load we also follow the conway law’s as well
Further recommended book
Thank you for spending your time here, and thanks to P Bank spend his time on explaining the abstract thing like this.
