Architecture Principles; Application Integration Principles


Principles for application integration

These application integration principles are for:

They provide guidance on application integration in line with the Solution Architecture and Data Integration Principles to ensure interoperability between applications.

Integration principles

Category

Application integration principle

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.

 

Useful links

Title

Description

Link

Non-Functional Requirements

Standard NFRs used by IT Services

Standard, Non-Functional Requirements - University of Leeds IT

Architecture Principles

Fundamental design rules to guide all IT architects and analysts

Architecture Principles - University of Leeds IT

Data Integration Principles

Guidelines for how data should be dealt with to maximise its value to the University

Architecture Principles; Data Principles - University of Leeds IT