TAM Guiding Principles
Overview
To drive consistent, scalable, and maintainable design decisions across our evolving landscape, we define a set of Architecture Guiding Principles. These principles serve as foundational rules that align teams toward the target state architecture while enabling autonomy within clear boundaries.
Each principle is:
- Actionable - tied to practical outcomes
- Measurable - has a clear check question
- Aligned - bridges the gap between current and target architecture
The 10 Principles
Principle 1: Adhere to the Platform by Default
| Aspect | Details |
|---|
| Description | Teams should build, deploy, and run applications using the Internal Developer Platform (IDP) by default. |
| Outcomes | • Reduced cognitive load on teams<br>• Faster, safer delivery through paved paths<br>• Governance embedded in workflows<br>• Efficient infrastructure usage and reduced cost to run |
| Check Question | Are we using the IDP's standard tools, templates, and deployment pipelines? |
| Reference | IDP Catalog |
Principle 2: Use APIs or Events for Communication
| Aspect | Details |
|---|
| Description | No file transfers, shared DBs, or point-to-point integrations. |
| Outcomes | • Observable, contract-driven integrations<br>• Decoupled teams and versionable interfaces<br>• Reduced fragility and debugging effort |
| Check Question | Are all our integrations using APIs or events rather than file transfers, direct DB writes, or CDC? |
| Reference | Standard for API-Driven and Event-Driven Communication |
Principle 3: Respect Architectural Boundaries
| Aspect | Details |
|---|
| Description | Do not bypass a boundary's mission by re-implementing its logic locally. Prefer well-defined dependencies and collaboration. |
| Outcomes | • Avoids platform duplication<br>• Reinforces ownership and accountability<br>• Enables coherent domain architecture |
| Check Question | Are we using existing boundary capabilities or duplicating them in our service? |
| Reference | TAM Boundaries |
Principle 4: Encapsulate Logic with Private and Internal Contracts
| Aspect | Details |
|---|
| Description | Each boundary defines private contracts and internal APIs/events for intra-boundary interaction. |
| Outcomes | • Clear separation of internal vs external interactions<br>• Easier to refactor, test, and replace components<br>• More robust domain encapsulation |
| Check Question | Have we defined clear private vs internal contracts for our boundary? |
| Reference | Standard for Types of APIs |
Principle 5: Data Subscribes to Business Events
| Aspect | Details |
|---|
| Description | The data platform and analytical consumers should be fed primarily through event streams. |
| Outcomes | • Real-time and decoupled data ingestion<br>• Reduced need for heavy ETLs<br>• Traceable, domain-aligned data pipelines |
| Check Question | Is our data flowing to the Data Platform via events rather than batch ETL or CDC? |
| Reference | Standard for Kafka Topic and Message Design |
Principle 6: Boundaries Own Their Data
| Aspect | Details |
|---|
| Description | No cross-boundary table sharing. Data schemas align to domain ownership. |
| Outcomes | • Autonomy and responsibility stay together<br>• Scalable and compliant data architecture<br>• Better auditability and data lineage |
| Check Question | Does our boundary exclusively own its data, with no shared tables across boundaries? |
| Reference | TAM Boundaries |
Principle 7: Design for Production-Readiness
| Aspect | Details |
|---|
| Description | All services must follow the organisation's SDLC Golden Rules, covering CI/CD, testing, observability, deployment strategies, and operational practices. |
| Outcomes | • Consistent and automated delivery pipelines<br>• Unified deployment and rollback standards<br>• Better MTTR and traceability across environments<br>• Higher confidence in changes and faster releases<br>• Platform-aligned observability and alerting |
| Check Question | Does our service meet the CI/CD standard, observability requirements, and go-live checklist? |
| Reference | Standard for CI/CD, Standard for Observability |
Principle 8: Everything is Versioned
| Aspect | Details |
|---|
| Description | APIs, events, infra configs, schemas — all have lifecycle-managed versions. |
| Outcomes | • Safe incremental changes<br>• Enables backwards/forward compatibility<br>• Controlled deprecation and rollout |
| Check Question | Are all our APIs, events, and configurations versioned with a clear lifecycle? |
| Reference | Standard for Types of APIs, Standard for Kafka Topic and Message Design |
Principle 9: Favour Asynchronous, Resilient Workflows
| Aspect | Details |
|---|
| Description | Prefer non-blocking communication and patterns like retries, dead-letter queues, circuit breakers. |
| Outcomes | • More resilient runtime behaviour<br>• Reduced blast radius on failure<br>• Easier horizontal scaling |
| Check Question | Have we designed for async communication with proper resilience patterns (retries, DLQ, circuit breakers)? |
| Reference | Standard for API-Driven and Event-Driven Communication |
Principle 10: Tech Choices Must Align with the Tech Radar
| Aspect | Details |
|---|
| Description | All technology adoption must follow the organisation's Tech Radar guidelines. |
| Outcomes | • Reduced tech sprawl<br>• Easier support and onboarding<br>• Better component reuse and consistency |
| Check Question | Is our technology choice on the Tech Radar as "Adopt" or "Trial"? |
| Reference | Tech Radar |
How to Use in Reviews
Architecture Review Checklist
Use these principles as a checklist during architecture and design reviews:
| Principle | Check | Status |
|---|
| 1. Platform by Default | Using IDP tools/templates? | ☐ |
| 2. APIs or Events | No file transfers, shared DBs, CDC? | ☐ |
| 3. Respect Boundaries | Not duplicating other boundary's capabilities? | ☐ |
| 4. Encapsulate Logic | Clear private vs internal contracts? | ☐ |
| 5. Data via Events | Feeding Data Platform via events? | ☐ |
| 6. Own Your Data | No cross-boundary table sharing? | ☐ |
| 7. Production-Ready | CI/CD, observability, go-live checklist? | ☐ |
| 8. Everything Versioned | APIs, events, configs versioned? | ☐ |
| 9. Async & Resilient | Retries, DLQ, circuit breakers? | ☐ |
| 10. Tech Radar Aligned | Tech choices on radar? | ☐ |
Red Flags to Watch For
| Violation | Principle Broken | Action |
|---|
| Direct database writes to another service | 2, 3, 6 | Refactor to use API or event |
| File-based integration | 2 | Replace with API or event stream |
| Duplicating capability from another boundary | 3 | Use existing capability via API |
| Shared database tables across boundaries | 6 | Split tables per domain ownership |
| No versioning on APIs/events | 8 | Add semantic versioning |
| Missing observability | 7 | Implement per standard |
| Using technology not on radar | 10 | Consult Architecture team |
Related Documentation
