Reminder: Please copy/paste the Zoom chat into the notes. If you miss it, this is saved along with the meeting recording, but having it here has benefits.
*
Making architectural decisions of various scopes
All
We know that a project of this size is faced with architectural decisions of various sizes, ranging from things scoped very narrowly, which impact only one or a few modules/teams, to platform-wide decisions impacting almost everyone. A one-size-fits all approach to making these decisions is unlikely to work well, and we've seen this already with the RFC process. Let's enumerate the types/sizes of decisions we make, then try to identify the applicable processes for each. If there are gaps, do we need to define additional processes or guidance for dev teams, and architects?
Previous Notes:
Types/sizes of technical decisions
Team/Module-specific
Process: ad-hoc/team-specific, sometimes with the help of SAs
Who: typically make internally by dev teams
Example(s):
Whether certain functionality is added to an existing module, or to a new module.
Technology choices - shared libraries, frameworks, etc., e.g. quartz timers, various npm packages
Storage layout, e.g. jsonb vs traditional relational tables, etc.
Problem-specific
Process:
Who:
Example(s):
Pub-sub/Event-driven communications
Adoption of spring-way
Security-driven
Process:
Who: Security Team
Example(s):
...
Platform-level/Fundamental
Process:
Who:
Example(s):
Eureka
Consortia support (ECS) and cross-tenant requests (possibly problem-specific)
UI architectural decisions
Process: A proposal or problem is brought to stripes-architecture, it's discussed, and a decision is made.
Who: Attendees of the stripes-architecture meeting