Project Delivery Process D160

D160 - Approach to Integration

DEFINITION

Consider, review and plan the approach to integration, both within the application and with external systems.

SUMMARY

Integration issues must be tackled early in the design work.  It is impossible to define a standard approach to integration as issues will vary depending on combinations of systems, hardware, communications, user needs, organisational issues etc.

This process looks at the issues which arise out of the desired levels of integration between separate elements of the overall project and with external systems.  Plans and approaches will be modified accordingly.

The essence of this task is to identify integration issues and to agree the overall approach to such issues.  It is not a technical design task - detailed technical designs will be made at later stages in the project.

PATH PLANNING GUIDANCE

Optional - may be used where there will be significant interfacing or integration.

DEPENDENCIES

Prerequisites (Finish-Start):

• none

Prerequisites (Finish-Finish):

• high-level definition of the overall architecture, eg as defined in the Delivery Approach Definition (DAD)

Dependent procedures (Finish-Finish):

• design of interfaces

RECEIVABLES

• Delivery Approach Definition (DAD) or similar definition of high-level design

DELIVERABLES

• Integration Issues IP
• Updated segment plan (if required)

TOOLS

• Specialised interfacing tools per package as available

DETAILED DESCRIPTION OF TASKS

Defining the approach

An Implementation Paper (IP) or Brief Implementation Paper (BIP) should be used to define the approach.  Where the project is complex with different departments being involved, an IP is to be preferred as it allows full consideration and acceptance of the issues and the decisions.

The Implementation Paper may identify the:

• Requirements for systems integration
• Options available
• Recommended approach
• Details of how to implement that approach

Requirements and issues

The overall needs should have been spelt out in the Delivery Approach Definition (DAD) or similar high-level definition of the design.  These should be re-examined as appropriate.  The requirements for integration and the issues arising may then be identified.

Requirements usually arise from the need to pass information between different computer systems or functions within a system.  Other needs may concern efficiency or infrastructure, for example the need to share a single corporate database, or the need for a user to have a single interface to multiple systems.

The issue of integration can normally be divided into two aspects:

• integration of functions, modules and data within a single, integrated suite of applications, and
• the transfer of data in and out of the system using interfaces or other methods of transfer.

Integration within the suite of applications

Modern most integrated application software packages provide coherent integration between all modules. Certain less well developed packages can seem like a combination of diverse modules which share nothing in common other than the name of the package’s supplier.

The issues relating to integration within the suite of applications will lead to requirements concerning the design and parameterisation of the packages.  It will also affect the way in which different parts of the Project Team work, for example their  scope and interaction.

Where all parts of the integrated system are being built together by the project team, the issues will relate mostly to organisational needs within the team.  These must ensure that all shared aspects of the system are managed so as to achieve the desired integration without contention between differing needs.  It is important that common issues are identified and managed accordingly.

Where similar levels of integration with other existing systems are required, this is unlikely to be achieved easily unless the new system modules were specifically designed to fit with those of the existing system, for example when adding modules from the same package supplier.  It is extremely unlikely that applications from different suppliers will use the same standards, data and processing methods.

Some examples of typical areas where integration requirements may apply are:

• Common screen design and user interface standards
• Common database and data definitions
• Definition of distribution of data over clients and servers
• Definition of ownership of items of data, and access rights/rules
• Definition of common data standards
• Avoidance of multiple entry of data
• Avoidance of multiple occurrences of data
• Definition of integrated security controls, eg all access rights defined by single log-on ID
• Format of real-time calls between modules, SQL calls etc
• Physical and technical interconnection of separate components of the integrated system
• Definition of who does what, eg creation of master data records
• Control of overall coherence and integrity of data within the integrated systems
• Ability to backup and restore logically coherent sub-sets of full system
• Ability to recover from partial system failures
• Scheduling of processing, availability, backups, etc

Interfacing with other systems

Interfacing requirements occur where it is unnecessary or impractical to integrate systems fully.  Most frequently, data is passed between the systems using serial batch techniques  involving transfer by disk, tape or communications link.  In some cases, a real-time link can be built by passing transactions directly between applications.

This normally leads to the definition of technical tasks to build batch interface functions, often by custom programming.

When considering the requirements for interfacing, it is important to include the requirements of the other system that is sending or receiving the data.  For example, there may be security requirements, audit requirements, control requirements.

Some basic requirements normally exist in any transfer of data:

• control that all data records have been transferred successfully, for example by using headers, trailers, control totals, transaction counts, hash checksums etc.
• ability to reverse out data in the event that a problem is found with the sending system,
• ability to store several separate transfers in case of timing differences or scheduling problems
• ability to process several separate transfers in case of timing differences or scheduling problems
• control that each transfer is made once and once only.

Additional functional or technical requirements will normally be found, for example:

• Conversion between different formats of data, field lengths, storage methods, ASCII / EBCDIC etc
• Translation of codes used on the two systems
• Need to summarise detailed data prior to input to the receiving system
• Need to add information, eg use of reference tables to add missing data items

In addition, many of the general considerations listed above for integrated systems will apply to interfaced systems.

The Integration Approach IP should analyse general requirements for interfacing.  It will not be necessary to consider the detailed requirements of specific interfaces.  They will be designed in later Technical IPs, see Process D600.

Options

The prime choice is whether to integrate functions or to leave them as separate interfaced systems.  A further realistic choice might be not to connect the systems at all, for example where the benefit is completely outweighed by the cost.

Depending on the package involved, there may be options to use interfacing tools provided either by the package vendor or from a third party.  Where these are table driven and specifically designed to work with the chosen software they can provide significant advantages.

The precise options will depend upon the specific modules to be used and the overall functional requirements.  Significant options should be identified and reviewed.

Recommended approach

A recommended approach should be agreed, along with appropriate recommendations concerning the way in which the desired level of integration can be achieved.  These must be discussed with and accepted by key managers.

Detailed approach

Details of this approach should be stated.  This may include some major design decisions, but, more typically, it will comprise detailed standards and recommendations concerning the standardisation of data, design standards, role and scope of functions and team members.

The review of integration issues will often lead to additional tasks or revised priorities in terms of work scheduling.  For example, it might be necessary to prioritise the redesign of a particular business process, or the modification of data in a feeder system to ensure that other design tasks can be built to be compatible with the overall integrated system.  Accordingly, it may be necessary to review and revise the detailed segment plan.