ADR-016 - Responsibilities
| Status | accepted |
|---|---|
| Date | 2025-04-14 |
| Decision Makers | Dardan Bujupaj (AX), Marc Gähwiler (AX), Markus Brenner (Griesser), TODO(mg) Who else? |
Context
This document outlines the key responsibilities within the Sunny Calculator Add-On and assigns ownership to specific individuals or teams. Clearly defining responsibilities is crucial for the following reasons:
- Clarity of Ownership: Ensures that every necessary task and area of the project has a designated owner, preventing tasks from falling through the cracks.
- Improved Accountability: Makes individuals and teams accountable for their assigned responsibilities, fostering a sense of ownership and commitment.
- Efficient Collaboration: Facilitates smoother collaboration by clearly identifying who to contact for specific aspects of the project.
- Reduced Conflicts: Minimizes potential conflicts and confusion regarding who is responsible for what.
- Scalability: Provides a structured framework for managing responsibilities as the project evolves and the team grows.
- Onboarding: Simplifies the onboarding process for new team members by providing a clear overview of roles and responsibilities.
The need for this ADR arises from the confusion who is responsible for what during the initial project kickoff.
Decision
The following table defines the key responsibilities within the Sunny Calculator Add-On and assigns ownership:
| Responsibility Area | Description | Responsible Person (Deputy) | Contact Information (e.g., Email, Telephone) |
|---|---|---|---|
| Project Management (AX) | Planning, organizing, and overseeing the project’s progress and resources. | Oliver Schneider (Sandro Wyss) | oli@ax.tech (sandro@ax.tech) |
| Application Owner (Griesser) | Provides strategic direction, ensures alignment with business goals, and makes critical decisions regarding the project’s priorities and outcomes. | [Name(s) (Griesser)] | [Email(s)] |
| Application Manager (Griesser) | Oversees the overall functionality, maintenance, and lifecycle of the application, ensuring it meets business requirements and user needs. | [Name(s) (Griesser)] | [Email(s)] |
| Software Architect (AX) | Designs and oversees the technical structure of the application, ensuring scalability, maintainability, and alignment with project requirements. Includes system design, data & API modeling and infrastructure decisions | Dardan Bujupaj (Marc Gähwiler) | dardan@ax.tech (marc@ax.tech) |
| Backend Lead (AX) | Design, development, testing, and deployment of server-side logic and APIs. | Dardan Bujupaj (Marc Gähwiler) | dardan@ax.tech (marc@ax.tech) |
| Frontend Lead (AX) | Design, development, testing, and deployment of user interfaces. | Martin Klapper | martin@ax.tech |
| Infrastructure (Griesser) | Provisioning, configuration, and management of the project infrastructure. | Pascal Heller | pascal.heller@griesser.ch |
| DevOps (Griesser) | Configuration & management of the project CI/CD pipelines. | Silas Näf | silas.naef@griesser.ch |
| UAT Lead (Griesser) | TODO: Revise! Planning, execution, and reporting of various testing activities (unit, integration, E2E). | [Name(s) (Griesser)] | [Email(s)] |
| First & Second Level Support (Griesser) | Handles user inquiries, troubleshooting, and resolving issues at the initial and intermediate levels to ensure smooth operation and user satisfaction. | [Name(s) (Griesser)] (probably same as Application owner) | [Email(s)] |
| Third Level Support (AX) | Handles complex or critical issues that cannot be resolved by first or second level support, often involving in-depth technical expertise and collaboration with development teams. | AX Support | support@ax.tech |
| Sunny Configurator Lead (Griesser) | Manages the Sunny Configurator project. | Moritz Bolli | moritz.bolli.extern@griesser.ch |
| CRM Lead (Griesser) | Manages the Griesser CRM design, development, testing and deployment. | Markus Brenner | markus.brenner@griesser.ch |
Note: This table represents the initial assignment of responsibilities. These may evolve as the project progresses. Any changes to these responsibilities will be documented in an ADR that extends / supersedes this one.
Consequences
Implementing this decision will lead to the following consequences:
- Positive:
- Clear understanding of who is accountable for each aspect of the project.
- Improved communication and collaboration within the team.
- Reduced ambiguity and potential for duplicated effort.
- More efficient issue resolution due to clear ownership.
- Facilitates better planning and resource allocation.
- Supports better onboarding of new team members.
- Negative:
- Potential for bottlenecks if a single individual is responsible for a critical area and is unavailable.
- Risk of knowledge silos if responsibilities are too narrowly defined.
- May require periodic review and updates as the project evolves and team composition changes.
- Potential for resistance or discomfort if individuals are assigned responsibilities they are not comfortable with or feel unprepared for.
Alternatives
The following alternatives were considered before making the above decision:
- Single Point of Contact for Everything: Assigning a single individual to be responsible for all aspects of a broad area (e.g., one “Development Lead”).
- Pros: Clear single point of contact.
- Cons: Potential for overload, single point of failure, may not leverage specialized skills effectively.
- Fluid Responsibilities: Allowing responsibilities to shift dynamically based on current needs and team availability without formal assignment.
- Pros: Increased flexibility, potential for shared learning.
- Cons: Lack of clear ownership, potential for confusion and tasks being overlooked, difficulty in tracking progress and accountability.
- Responsibility Matrix (e.g., RACI Matrix): Using a more detailed matrix to define the roles of Responsible, Accountable, Consulted, and Informed for each task.
- Pros: Very granular definition of roles and responsibilities.
- Cons: Can be overly complex for smaller projects, requires significant upfront effort and ongoing maintenance.
- Team-Based Responsibility: Assigning responsibilities primarily to teams rather than individuals.
- Pros: Encourages collaboration and shared ownership within the team.
- Cons: Can make it difficult to pinpoint individual accountability within the team, may require strong internal team coordination.
The chosen approach of assigning specific responsibilities to individuals or teams within defined areas was deemed the most appropriate for Sunny Calculator Add-On at this stage, balancing clarity of ownership with the need for collaboration.