Integration Technical Analyst

Location:

Remote with occasional travel to High Wycombe.

About PACT Solutions

PACT Solutions is a specialist consultancy working with UK higher education institutions to deliver strategy, digital transformation and operational change. We combine deep sector expertise with a collaborative, partner-first approach to deliver meaningful, lasting outcomes.

Role Purpose

We require an experienced Integration Technical Analyst to support the analysis, definition and documentation of data integrations between enterprise systems.

The role sits between traditional Business Analysis and Integration/Solution Analysis. The successful candidate must be comfortable working with business SMEs to understand processes and requirements, while also working directly with technical teams, system owners, vendors and existing implementation artefacts to define how integrations should operate at interface and data level.

The analyst will take integrations from business requirement through to implementation-ready specifications, including user stories, interface behaviour, source-to-target mappings, transformation rules, exception handling and acceptance criteria.

The Integration Technical Analyst will

• Facilitate workshops and interviews with business SMEs, product owners, system administrators, developers, architects and vendors.
• Elicit and document functional and non-functional integration requirements.
• Translate business requirements into clear, implementation-ready user stories and acceptance criteria.
• Analyse existing integrations, technical documentation, system configuration and implementation artefacts.
• Document end-to-end integration flows, including triggering events, participating systems, interfaces and processing stages.
• Define interface requirements for APIs, messaging, queues, files, databases and other integration mechanisms.
• Produce detailed source-to-target data mappings covering:
• source fields and structures;
• target fields and structures;
• mandatory/optional attributes;
• data types and formats;
• defaulting rules;
• transformation and derivation logic;
• code translations and lookup mappings;
• validation rules;
• filtering and selection criteria.
• Define event and message behaviour for canonical, ESB and event-driven integration patterns.
• Identify sequencing, dependencies, correlation, idempotency and retry requirements where applicable.
• Define business and technical exception scenarios and expected handling.
• Specify error handling, reconciliation, retry, dead-letter or quarantine processes where appropriate.
• Define logging, monitoring, alerting and operational support requirements.
• Identify security, authentication, authorisation and service-account requirements.
• Work with developers and integration engineers to resolve ambiguity and refine specifications.
• Support test preparation by ensuring requirements and mappings can be traced to test scenarios and acceptance criteria.
• Assist with defect triage where issues relate to requirements, mappings, transformations or interface behaviour.
• Maintain clear traceability between business requirements, user stories, interface specifications, mappings and delivered functionality.

Expected Integration Documentation

Depending on the integration, the analyst should be capable of producing or maintaining:

• Integration requirements specifications.
• Epics, features and user stories.
• Acceptance criteria.
• Context and integration flow diagrams.
• Interface catalogues.
• API/interface specifications.
• Event/message definitions.
• Source-to-target data mapping specifications.
• Transformation and translation rules.
• Reference-data and code mappings.
• Business validation rules.
• Error and exception matrices.
• Retry and recovery requirements.
• Reconciliation requirements.
• Non-functional requirements.
• Security and access requirements.
• Logging, monitoring and alerting requirements.
• Dependencies, assumptions, constraints and outstanding questions.
• Requirements traceability

Inputs and Access Required

To perform the role effectively, the analyst will require appropriate access to existing technical information and environments. This should include, where available:

• Documentation for existing integrations.
• System manuals, vendor documentation and training materials.
• Technical architecture information covering servers, databases, services and integration components.
• Details of relevant user and service accounts.
• Access to suitable non-production or replica environments.
• Access to relevant source code, configuration and implementation artefacts.
• Appropriate access to secrets, certificates, API keys and credentials where required for authorised analysis or testing.
• Access to APIs, databases, message queues, topics, file locations and other integration endpoints.
• Access to logs, monitoring dashboards and diagnostic information.
• Representative and appropriately controlled test data.
• Existing interface specifications, schemas and data dictionaries.
• Vendor and third-party support contacts.
• Named technical owners and system owners for each participating platform.
• A defined escalation route where documentation, system behaviour or vendor support is insufficient.

The expected outcome is not simply a high-level statement such as

“Student attendance data must be transferred from System A to System B.”

The analyst should be able to take that requirement through to sufficient detail to establish:

• what business event initiates the integration;
• which system is authoritative for each piece of data;
• what message or interface is invoked;
• what data is extracted;
• how source attributes map to the target;
• which transformations or translations are applied;
• what validation occurs;
• how reference data is resolved;
• what constitutes successful processing;
• what constitutes a business rejection;
• what constitutes a technical failure;
• what is retried automatically;
• what requires manual intervention;
• how failures are surfaced and supported;
• how processing can be reconciled;
• and how the completed integration can be objectively accepted and tested.

The role therefore requires an analyst who is comfortable moving continuously between business process, requirements, data and integration technology rather than handing technical definition entirely to a downstream development team.

Requirements

The successful candidate should have strong experience of integration analysis rather than solely general-purpose business analysis.

Essential experience includes

• Requirements elicitation with both business and technical stakeholders.
• Writing detailed user stories and testable acceptance criteria.
• Producing source-to-target data mappings.
• Analysing APIs, database structures, messages, files and other integration interfaces.
• Defining transformation, translation and validation rules.
• Documenting business and technical exception scenarios.
• Understanding asynchronous and synchronous integration patterns.
• Familiarity with Enterprise Service Bus (ESB), canonical data models and event-driven integration.
• Understanding concepts such as publish/subscribe, request/reply, queues, topics, message routing, correlation, retries and dead-letter handling.
• Ability to analyse existing implementations rather than relying solely on greenfield requirements.
• Ability to read and interpret technical documentation, API definitions, database schemas, configuration and logs.
• Confidence working directly with integration developers, solution architects, infrastructure teams and application specialists.
• Ability to communicate technical concepts clearly to business stakeholders and business requirements clearly to technical teams.

Higher Education Experience

Experience within Higher Education would be highly desirable, particularly integrations involving systems or processes such as:

• Student Records Systems.
• Timetabling and scheduling.
• Attendance and engagement monitoring.
• Virtual Learning Environments / Learning Management Systems.
• Student portals and mobile applications.
• Identity and access management.
• Admissions and enrolment.
• Module and programme data.
• Student, staff and organisational data.
• Assessment and results.
• Learning analytics.
• Room and resource management.

The analyst should ideally understand that Higher Education integrations frequently involve shared entities such as students, staff, modules, programmes, academic periods, teaching activities, locations, enrolments and attendance events, with ownership of individual data domains distributed across several systems.