Define strategy for architectural observability

[yt-ms]

Feature Request

Description of Problem:

Being able to describe (through CALM) what we think our architecture should be is very useful, however being able to show that what is actually running matches what we think it is would be much more powerful. Architectural drift detection is a problem for architects (did we build what we said?) but also for security and other control groups who typically will have approved an architectural design but have no way to tell whether the required controls are accurate for production.

We should lay out different ways that we could support observation of the running architecture in such a way as to be able to compare back to the CALM definition, identify differences, and potentially even assess the impact of those differences. We should then prioritise which of the approaches to support sooner versus later.

Potential Solutions:

Examples as a starting point:

• Code-scanning (direct source code, or via reflection) for annotations carrying CALM data (c.f. C4 annotations - perhaps being able to use existing C4 annotations...).
• Examining deployment configuration (e.g. Terraform)
• Standard endpoint exposed by services that can be interrogated (c.f. Spring Boot Actuator), possibly using the annotations from above
• Standard information output to logs for scraping
• "Phone home" from services with the service's architecture model to slot into the overall picture