Introduction

The main focus of this guild is to enable product squads to make cross-chapter technical decisions that are effective, high-quality, consistent, and efficient so that they can design and implement robust, scalable, and maintainable systems. This means providing technical standards and best practices, an architecture reference, and processes to the squads and ensuring the technical direction is aligned with the business needs and objectives.

The guild might also provide technical support to the product squads on cross-chapter topics when needed.

The guild is also an opportunity for different chapters to contaminate one another about standards, best practices, and processes, benefiting from the collective experience of all the different engineering functions and so to raise the bar from the technical point of view.

Participants

The guild coordinator is the VP of Engineering.

Besides the guild coordinator, the guild members are all Engineering Chapter Leads. If there is no Chapter Lead for a given function, the VP of Engineering can act on behalf of her/him or delegate a representative engineer from the chapter.

Themes

Examples of themes the guild could focus on are

• API: standards and best practices on how to structure endpoints, how to handle filtering, sorting, and pagination, how to handle errors, and how to handle versioning.
  • Chapters involved: BE, DE, FE
• Security: standards and best practices on how to handle sensitive data, how to prevent common types of attacks, and how to implement security protocols.
  • Chapters involved: BE, DE, FE, SRE/DevOps, QA
• DDD strategic patterns: best practices for DDD strategic patterns such as Domain Modelling, Bounded-Context, Anti-Corruption Layer, etc.
  • Chapters involved: BE, DE, QA
• Event-Driven Architecture: best practices for event-driven architecture and how services from different product squads could communicate with one another.
  • Chapters involved: BE, DE, FE, SRE/DevOps, QA
• Incident Management: standards, best practices, and processes for reporting incidents, notifying people who should get involved, and resolving them in a timely and effective manner.
  • Chapters involved: BE, DE, FE, SRE/DevOps, QA
• AWS resource provisioning: standards and best practices provided by the SRE/DevOps chapter for AWS resource provisioning (e.g., what services can be used and how they could be structured).
  • Chapters involved: BE, DE, FE, SRE/DevOps, QA
• CDK code reviews: standards and best practices to create pull requests to be reviewed by the SRE/DevOps team.
  • Chapters involved: BE, DE, FE, SRE/DevOps, QA
• GitHub actions: standards and best practices for setting up and configuring actions, testing and debugging actions, and optimizing action performance. We could also provide templates for common actions (e.g., deploying to different environments, running automated tests, or creating release pipelines).
  • Chapters involved: BE, DE, FE, SRE/DevOps, QA
• Service logging and monitoring: standards, best practices, and tools on what types of logs should be collected and how they should be stored and analyzed (e.g., latency, traffic, errors, saturation), what platform we use to monitor our services. This would provide the squads with a standardized way of troubleshooting and debugging in case of issues.
  • Chapters involved: BE, DE, FE, SRE/DevOps, QA
• Software selection: an agreement on what services SRE/DevOps can afford to maintain on AWS for queue management (e.g., SQS, RabbitMQ, etc.), data streaming (e.g., SNS, Kafka, AWS EventBridge, etc.), distributed cache (e.g., Redis, etc.).
  • Chapters involved: BE, DE, FE, SRE/DevOps, QA
• Data modeling, pipelines, and quality: standards, best practices, and tools to make product squads autonomous in creating data models and pipelines for their own data and accountable for the data accuracy and reliability.
  • Chapters involved: BE, DE, FE, QA