Gaia/Architecture Transition Proposal

Transition Proposal

This is a proposal to migrate our current codebase to the new and unified architecture for Gaia apps mentioned in the Architecture Proposal.

This documentation tries to split the transition process into a multi-steps process. The documentation also try to see how parts of those steps can be done concurrently to avoid a pure linear process.

Step 0: Mirror the architecture proposal into functional teams

The proposed architecture is about strict decoupling of the front-end and the back-end, and focusing on small pieces. This ultimately lead to fine grained parts, which can be classified into 3 high-level categories.

Those categories are:

• Front-End
• Back-End
• Toolkit

Impact on functional teams

As of today, individuals are often working on those 3 categories at the same time. While some may focus more on one aspect over others, this model merge the responsibilities of all categories and distract individuals.

It also prevent categories to evolve independently and results into a general slow down.

In order to mitigate those issues it is proposed to create 2 new functional teams:

• Front-End
• Toolkit

The existing functional teams will still exists, but with a refocus on the pure back-end of an application.

This solution should also provide a better concerns isolation. For example, most of the time UX/UI concerns are unrelated to the back-end logic. Or many WebAPIs changes does not concerns the front-end logic.

The new structure can be visualize as multiple layers of concerns wrapping each others.

Front-End Team

• One team for all front-ends, of all apps
• Likely a consequent team
• Responsible of perceived performance
• High level of interaction with UX/UI

Back-End Team

• One team per app back-end
• Likely a small teams
• Responsible of business logic
• High level of interaction with WebAPIs

Toolkit Team

• One team for all shared components
• Likely a mid-size team
• Responsible of developer story
• High level of interaction with Front-End and Back-end

Impact on User Story

All those teams can work concurrently, without having to worry about other teams.

It creates an asynchronous development model for User Story. Usually a user story will impact the front-end and the back-end team. Those teams can work on the user story asynchronously, and one team may have done its related part while the other may have not started yet.

But at some point, the front-end and the back-end needs to synchronized to validate the integration. Also both front-end and back-end may independently require to synchronize with the Toolkit.

The backlog of each team is scoped to the responsibility of one of the mentioned categories only. It should create more focused and smaller backlog for each teams, but require some additional synchronization.

As an example the front-end and the back-end should be sure to have a shared deadline for a defined feature. But front-end and back-end may have custom deadlines to work on this feature, as long the deadline if not targeting after the shared deadline.