Executive Summary

The primary scope of work of the Integration Project is to design the integration of the selected new core ERP into the University of Edinburgh IS Applications estate.  It must identify all required integrations to ensure the ERP operates optimally and integrates with all (remaining) legacy systems.  This will be done in two broad stages.

Firstly, a High-Level Design will be developed which confirms the architecture of the target completion state.  That will be refined into a Mid-Level Design which will identify all required integrations, confirm which legacy applications are candidates for decommissioning, and specify the information flows required.  These two designs will be developed in parallel with the procurement and the project will ensure that the dialogue process delivers sufficient information to complete this “integration blueprint”.  It is likely that a hybrid high-level design document is developed during dialogue which reflects the target architecture across all bidders.  Only once the preferred bidder is selected will the mid-level design be concluded.

Secondly, once the ERP implementation process commences, a Low-Level Design will be developed.  This will consist of specifications for each integration required, and will only be deliverable once the supplier has finalised the design of the ERP and the new business processes have been confirmed.  It may be possible to commence the Low-Level Design during the procurement phase, but until configuration and design of processes is complete the Low Level Design will be incomplete.

For this primary scope of work to be delivered, the integration tools and services available need to be confirmed.  Some work has been done by the University outwith the Core Systems Programme to develop an API framework and select an ETL tool (Talend).

The secondary scope of this project is to select and implement an integration middleware layer which we are calling the Hybrid Integration Platform.  The approach here will be to:

  • Appoint external consultants to help validate our requirements and identify candidate products
  • Develop a short list of candidate products and explore sourcing options (timelines are likely to be challenging)
  • Conduct pilot  exercises (using trial software) to explore key features and determine a preferred product.
  • Procure and implement the product.

The focus of this project will be functionality required for Core System Integration.  Each step will consider wider use in the other application areas of the University.

There is potential for this Integration Project to have a wider scope to manage the finalisation of the integration toolset.  This is called Scope B.  The project would not address any use of these new tools in areas outside of the Core Systems Programme unless specifically detailed in this document.


Business Objectives and Project Deliverables

Ref. Description New / Changed (N/C)
  1. To develop an integration blueprint covering all required integrations.
  • High-Level Future ERP Integration Design.
  • Mid-Level Future ERP Integration Design
  • Low-Level Future ERP Integration Design

To select and implement a Hybrid Integration Platform

  • Requirements report (external consultants)
  • Product evaluation and confirm shortlist (including procurement approach)
  • Product evaluation via pilot approach/use cases and findings
  • Technical Implementation Plan













The project will produce the following major deliverables.  

During the procurement: 

High-Level Future ERP Integration Design. 

  • Mainly graphical, it will detail what applications need to be linked and call out the major architectural features. 

  • This will be driven by assessments of the ERP vendors’ integration approaches, and early versions will be an input into dialogue and help reach the selection decision. 

Integration Middleware - Requirements and Approach report

  • This report will be produced by external consultants (appointed prior to this project).
  • It will cover the requirements of the University for integration middleware primarily for the ERP but also taking the wider development landscape into account.
  • It will identify products in the market that are likely to support these requirements.

Mid-Level Future ERP Integration Design 

  • This will specify individual integrations/flows, timing and triggering events and major entities involved.  It will not go to field level. 

  • This will detail the legacy interfaces intended for decommissioning. 

  • It may also specify legacy integrations that, while not connecting directly to ERP, may be a pre-requisite.  For example, a new integration approach to supplier management to align all supplier data may be a pre-requisite for the procurement implementation. 

  • NB The Mid-Level Design will be commenced when multiple suppliers are still in the dialogue process.  It will not be finalised until the University has chosen the preferred supplier.

Integration Middleware Shortlist and Procurement Approach

  • Procurement timelines will be challenging and it is likely a GCloud approach will be taken.  Not all products are available through GCloud.

Low-Level Future ERP Integration Design 

  • For each integration flow, this will detail the field mappings and business rules.  Ideally, this would be built in the integration platform and sufficiently documented there.  However, this will need to be shared with the supplier so the approach needs to be practical for both parties.  This deliverable cannot be produced until a preferred supplier is confirmed and work starts on the actual integrations.  It may be possible to produce sample sections of this deliverable during the procurement. 

  • NB This deliverable may take the form of an overall integration catalogue referring to a number of integration specifications.  It will not be completed until the end of the vendor's ERP design process.

Pilot middleware exercises, preferred product, installed product/service

  • Evaluation of final two products using trial software.  This evaluation to cover ERP requirements and broader development scenarios where feasible.
  • Recommendation
  • Implementation PLan
  • Service Creation/Adoption plan

NB It is likely that these deliverables will not be completed until after the implementation commences.  They need to be in place for the build phase. 

During the ERP implementation: 

  • Refined Low-Level Design

Note that the development, testing and deployment of individual integrations will form part of the implementation plan and not this project.

Success Criteria



Success Criteria

To develop an integration blueprint covering all required integrations.


The integration blueprint must:

  • Confirm and cover the entire scope of ERP implementation.
  • Cover all ISG owned integration in scope and specify the approach to integration to be taken.
  • Identify areas where additional generic input/output feeds perform critical functions and must be replaced.
  • Provide both a management overview of workload and risk and sufficient detail for the integrations to be developed.


High-Level Future ERP Integration Design.

The HLD must:

  • Identify which applications will be retained and which will be decommissioned.
  • Identify the broad categories of data that need to be integrated from current remaining applications to/from the ERP.  This will be in the form of an integrations catalogue that will be refined by later deliverables.
  • Identify any interim integrations that might be required due to implementation phasing.  (NB These will not be confirmed until the agreed implementation plan is in place).


Mid-Level Future ERP Integration Design

The MLD must:

  • Confirm and refine the HLD where further information is available.
  • Populate the integrations catalogue with individual integrations that will be required, including timing, frequency and mode of integration.
  • Specify the interim integrations needed to the same level of detail, with additional detail on how they will be phased in and out.


Low-Level Future ERP Integration Design

The LLD must:

  • Develop the integrations catalogue so that each required interface (or related sets of interfaces) have a specification document which provides all information necessary for the integrations to be developed and tested.
  • Test cases must be included in the individual specifications.
  • Data integrations must include field level “matching”.
  • Any process integrations must include applicable business rules.

To select and implement a Hybrid Integration Platform


The success criteria for this objective is the implementation and establishment of the recommended middleware product/service.


The product must meet the requirements set out in the requirements report.


Requirements report (external consultants)

The report must:

  • Specify the requirements the University is seeking to satisfy.
  • Confirm the approach is viable.
  • Identify strategies and products that will fit our aims and objectives.
  • Make any further recommendations to improve outcomes.


Product evaluation and confirm shortlist (including procurement approach)

The evaluation must:

  • Refine the shortlist emerging from the consultancy report to two products suitable for verification.
  • Confirm and outline GCloud procurement approach.


Product verification via pilot approach/use cases and findings

The verification must:

  • Demonstrate that an agreed set of use cases are supported by the toolset.  At a minimum these must include ERP modes of operation and broaden out to represent as much of the development landscape as feasible.
  • These use cases to be approved by a set of ISG stakeholders.
  • The use cases to reflect development, operations and support requirements.


Technical Implementation Plan

The plan must:

  • Describe all activities necessary to establish the product/service.
  • Be agreed/approved by all relevant stakeholders.



The scope of the integration blueprint is defined as:

  • Replacement of all current interfaces that integrate with current applications that will be replaced by the Core ERP implementation.  This scope is reflected in the various procurement deliverables provided to bidders and has been refined where necessary by the High Level Design.
  • Consideration will also be given to areas where data extracts from legacy systems are produced as data feeds and then taken up by local applications and spreadsheets.  These requirements are covered in the reporting area of the implementation plan, as the new ERP will provide more comprehensive information enquiry than is currently possible.  This scope "boundary" will be constantly managed during implementation.

The scope of the integration middleware procurement is defined as:

  • Covering all requirements for integration remaining applications with the preferred new ERP solution.
  • Covering expected requirements for generic integration use in the wider estate.  These requirements will be considered during the requirements assessment, and will input into the use cases for the verification stage.

NB - The products under consideration are market leading integration tools that purport to support all manner of integrations.  The expectation beyond the Core ERP is that the integration middleware will be used as other interfaces need to be redeveloped or changed.  However, no timeline or benefit has been attached to this wider scope.


The project will commence in April 2018.

It will run in parallel with the Core Systems Procurement Project for the remainder of 2018.

  • High level Design will be published July 2018.
  • Mid-level Design will be published (first version) October 2018.
  • Integration Consultants appointed May 2018.
  • Requirements report published August 2018.
  • Shortlist production and procurement approach agreed September 2018.
  • Verification of candidate products complete by December 2018.  (Update November 2018 - more work is required to develop use cases and perform the verification work.  This is detailed in the Project brief to avoid duplication.)


The preferred bidder will be known at the start of 2019. 

  • Mid-level design will be concluded by March 2019.
  • Low-Level Design will be issued (first draft catalogue, with interface templates) by April 2019.
  • Verification of candidate products now by March 2019.
  • Implementation of selected middleware by June 2019.



Project Info

People and Money - Systems Integration
Service Excellence - People and Money (SEPCOR)
Management Office
Project Manager
Emma Mcnab
Project Sponsor
Jennifer Milne
Current Stage
In Progress
Project Classification
Start Date
Planning Date
Delivery Date
Close Date
Programme Priority
Overall Priority