This is the list of what should be handed over (checked by SaFi side after handed over), and also it is a good agenda for the handover meeting:
- Jira - how is the work managed, how to work with it
- Confluence - how is documentation structured, a brief overview
- 3rd parties - what, for what, where it is documented
- Contact persons/channels - for 3rd parties, products, …
- Credentials - where are they, how are they managed
- Dev level test - what is covered, what not, where to put the focus, where to be careful
- Bugs/VAPT findings - which are there for SaFi to pick up
- Planned development for MVP - what we were planning to do till the end of January (NFRs, tests, tech debt…)
- Ownership handover
tech leadership (who shall be the person from SaFi’s side if it is already clear)
consult their idea of ownership in the team (if nothing is missing)
cancelation of our meetings and let SaFi create their own invites
- For developers (workshop, and maybe they already know):
code structure
microservices - important microservices and connections for the squad
3rd parties of the squad - how they work, pitfalls,
tooling - linters, how to run it locally, how to run tests…
business logic - short intro to business logic and what is the business scope of the squad and what not
Jira
Board: https://safibank.atlassian.net/jira/software/c/projects/SM/boards/21
[describe briefly if you have any specifics how is the work in Jira organized.]
It’s a Kanban board as it served best the nature of architecture tasks coming in.
Confluence
The Guidelines for tech docs serves as an index page and a guide on how to navigate through the high-level architecture documentation and squad-specific documentation docs in confluence. Newly added docs should follow the structure outlined in the mentioned document.
Data architecture - root page for documentation from application perspective regarding Data storage (GCS), Data flow (Kafka integration), Data privacy and Datalake integration.
List of ADRs - Contains all architecture decision records documented as decision logs. Any newly added decisions should follow the same structure by creating a decision from template “DACI: Decision documentation”
Dev HOWTO - Root page for guidelines on development. The whole SDLC, which contains the day-to-day information for developers on how to develop the services, also containing a consolidated list of NFRs which the services should adhere to.
3rd parties
The 3rd parties are documented in individual squads which connect to them.
Contacts
The contacts for 3rd parties are documented within the individual squads.
The slack channel #chapter-architecture is used to:
discuss architecture related topics and decisions
announce topics for the Architecture Review Board (fortnightly)
Channel #tech is used for technical announcements (such as newly defined NFR or decision with global effect) globally to the whole development team.
Credentials
No specific credentials in the architecture team.
Dev level test
The architecture team doesn’t maintain any services, neither tests.
Bugs/VAPT findings
Does not apply.
Planed development for MVP
Finalize the design and enforce the rest of the NFRs listed in the NFRs page which are not yet applied.
Apply Kafka ACL rules on producers and consumers once
SAF-487 - Add producers/consumers for topics in topicSchemasDefinitions.json Backlog is finished.
Finalize the necessary CI checks and tooling required for REST API versioning approach to work properly. Integrate the approach with Frontend (TYK). What remains to be done:
Check for deprecated endpoint removal. (
SM-5042 - Support removal of deprecated endpoints as non-breaking change Done ) Finds out whether and endpoint which is going to be removed was marked as deprecated and is not used in any of the microservices deployed in PROD.
Enforce the deprecation mechanism on the mobile app side as well. This can be achieved by multiple ways (decision not taken):
Treat Tyk as a regular consumer which specifies the client version (version it expects) of each API it consumes, and provides such API to the mobile app. The Tyk then acts as an umbrella for all mobile app versions, facacing the backend services from the complexity of supporting different mobile app versions
Implement alternative solution which ensures that the API endpoint in backend can be safely removed without breaking any used version of the mobile app consumer - e.g. by Pact testing
Finalize the requirements and implement the regulatory requirements critical for the MVP release from WIP: IT Regulatory Checklist (IT RM, BSP MORB 148)
Design and implement backend-side content management and localisation.
Ownership handover
The main point of contact from SaFi is Yuetong Yang (Unlicensed) . We are having regular daily architecture syncs about the current state of the system and next priorities.