As a scaling start-up we often hit hard engineering problems. Taking a collaborative approach to solving these problems has huge positive outcomes.

We have codified these outcomes as a set of technical and social requirements. We have also developed a process to ensure an architectural solution meets these requirements.

Group Architecture originated from an organic rhythm we got into when we were a small team.

Technical requirements

• Performant. The solutions provides a good experience for users. Regardless of device, browser or network speed.
• Scalable. It will serve our known and imagined future scale and use cases. It is only scalable to what our use case feasibly requires. We don't add unnecessary complexity for cases that likely won't eventuate.
• Simple. We create as little infrastructure and technical complexity as possible. This means we don't need a lot of maintenance from engineering. This also ensures a low cognitive load on engineers.

Social requirements

• Team alignment. The team understands the architecture that they will be building. And, they feel a sense of shared ownership of the solution because they had a chance to contribute.
• Architectural up-skilling. The team up-skills in architecting solutions.

The Group Architecture process

Step 1: Describe the problem thoroughly without architectural bias in written form.

Step 2: Discuss the problem. Get the engineering team together and discuss the problem. Come to a common understanding of the problem. This may mean your description changes as new information and ideas come to light.

Step 3: Come up with alternatives. Encourage people to think about possible solutions to the problem asynchronously. Ensure there is enough time to plan possible approaches.

Step 4: Agree on an initial approach. Re-group and weight the options people have come up with. Deciding on a solution will often include a mix of approaches. Record each option, why it was not chosen. For the final approach, record why it won.

Step 5: Keep iterating the architecture. Have two engineers, one senior, iterate the architecture into a formal solution design. When the gist of the solution design is formed get together as a team once more.

Step 6: Re-validate the solution. Look for:

• Things that are missing.
• Things that won't quite work as expected.
• Areas for improvement.

Record all improvement vectors. The small group continues to flesh out the solution design, incorporating the feedback.

Step 7: Rinse and repeat steps 5 and 6 until the architecture solution design finishes.

The hard bits here are when to share.

Some guidelines are:

• When you solve a previous unknown.
• When you hit something in the solution that doesn't quite work out as intended and you make a change.
• When you fill out areas that restrict the options of the remainder of the solution.