Integration Architecture Design Goals
A set of goals and principles for building a robust integration architecture that can be reused across application integration scenarios.
Core Architecture Principles
The architecture should be multitenant and reusable for any application integration scenario. It must be scalable, allowing new endpoints to be added without rewriting or rearchitecting. It should be performant, maintain separation of concerns, and ensure systems are decoupled and not co-dependent.
When loosely coupled systems are down, the architecture must implement appropriate techniques including considering blocking the transaction entirely, implementing retries, and handling scenarios where the source system requires a key from the target system to complete a transaction.
The solution should be cost-effective and preferably cloud-hosted.
Monitoring and Observability
- Robust monitoring of infrastructure (e.g. alerting when Azure Service Bus is down) with proactive alerts
- Monitoring of Azure Function failures
- Verbose logging option
- Telemetry where possible, leaning on Microsoft infrastructure
- A dashboard concept where the operations team can view the health of all integrations in one place
ALM and DevOps
- Source control, continuous integration, and environment promotion across DEV, TEST, QA, UAT, and PROD
- When provisioning an endpoint, a concept of endpoint registration including its environments should be followed
Development Standards
- JavaScript/TypeScript as the programming language wherever possible
- Custom code should be consistent and easily supportable by junior developers
- Unit testing built into all custom code
Ticketing and Operations
- Integration with internal ticketing systems
- Based on a RACI model, tickets should be routable to different vendors
- Operational separation of concerns between integration vendor and customer
- RACI used as a mechanism for documenting and automating responsibilities
Security
- Secrets stored in a vault concept and accessed from there — no clear text passwords
- Infrastructure must have accessibility through the vault
- Security considerations factored into operational separation
Integration Patterns
The architecture must address all necessary integration patterns including fire and forget, batch/time-based scheduling, event-based, and publish/subscribe (where multiple systems may subscribe to a single message).
Open Standards and Portability
- Support for open standards
- Balance against codependency with Microsoft Azure or other vendor infrastructure (e.g. Azure Service Bus vs open standard ESB)
- Abstract code where possible to allow vendor swapping
- Mobility where applicable
Documentation
- Code should be self-documenting and capable of generating documentation
- Where possible, documentation should be dynamically generated based on current environment state
- First-level support through Teams and TeamSite for collaboration
- Support for file-level documentation and knowledge base articles