|
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.
- There is an integration preference to use OOTB connectors rather than bespoke connectors using our AIS hub although if the required system is likely to have multiple integrations associated with it then the preference swaps to using AIS as this improves our ability to trace, monitor and report issues in bulk within a single hub.
|
|
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.
|