|
System decoupling
|
- Service interfaces should promote loose coupling between consumer and provider.
- Individual components should not be dependent on others.
- We should be able to isolate, maintain and update individual components without impacting the overall architecture of a service.
|
|
Interface specification standards/ Interface contracts
|
- Interface specifications must include detail on;
source system; target system; data payload; data mastery; data quality; frequency; exchange protocols; payload scheme definition and articulation; exception handling; test services; security; authentication and authorisation; synchronicity; initiator; transaction management; business processing; and extended conversations.
- The specifications must be held in a searchable repository
- All sourced data should be governed by a data delivery agreement (DDA).
- Service interfaces must be platform-independent.
|
|
Service Orchestration / Service Encapsulation
|
- API should provide services that limit the number of calls that any given consumer of services needs to make.
- API calls should return the minimum amount of data necessary for the process involved
- APIs should orchestrate granular services to encapsulate a logical unit of business work.
- Orchestrated services must support transaction commit/roll-back.
- Services should meet the standard non-functional requirements as defined by UoL IT. (see useful links)
|
|
API Catalogue
|
- APIs should be reused where possible which is enabled through publishing extant APIs in an enterprise-level catalogue.
- APIs must be built with extensibility and versioning as standard.
- The API catalogue will be governed to ensure ongoing integrity and compliance.
|
|
Integration hub
|
- There is only one integration hub (per route-to-live environment e.g., dev, test, prod) for the University to enforce the commonality of features e.g., exception handling.
- An approved list of ready-made integration services can be deployed outside of the integration hub. E.g., MS teams apps
- Application-specific integrations outside of the integration hub and the approved list should be signed off by the technical design authority.
|
|
Integration test environments
|
- When providing any integration services from a platform, that platform should provide a test instance to support integration testing with external consuming systems.
- In addition, platforms should provide stubbed or simulated service modules that can be used by consuming systems in their own development environments.
|
|
Integration landscape view
|
- An application landscape view with lines showing integration points between existing applications and an overlay of the data exchanged should be produced and maintained.
|
|
Integration data models
|
- Data models will define the data movements in terms of entities exchanged between systems, converging on a standard format for common entities.
|
|
Integration preferences inc. third-party supplier guidance and requirements
|
- There is an integration preference to be API based.
- There is an integration preference for JSON REST services.
- There is an integration preference for suppliers to meet industry standards.
|
|
API granularity /
Microservices architecture
|
- APIs should contain atomic services that can be called independently of one another.
- An atomic service is a clearly defined, self-contained function that does not depend on the context or state of other services. An atomic service is constructed from modular components. (See System decoupling)
|
|
Bulk transfer
|
- Bulk data transfers of data should only be allowed through a managed data transfer method and rely on the agreed standard ETL tool.
|
|
Integration conformity
|
- All integrations should conform to organisation-wide standards for security; data; audit; and operational management.
|