Interface Strategy – a Functional Approach

Interfaces are mostly assumed being a technical exercise however been on the receiving end of that there is several shortcomings to this approach.

image

When interfacing two systems the transactional flow can become quite complex in terms of functional interaction – an interaction, which is beyond what most technical people can contemplate. Just imagine how to design a purchase order interface:

  • In what system do we enter the invoices in order to track purchase order fulfilment?
  • Do we need to match or part match the invoice to the purchase order?
  • When a purchase order is closed do we need to relay this to both systems?
  • Is receiving being used and if so in what system?

Beyond that, there are the implications of change – like changes to the purchase order – how is this managed and interfaced?

When it comes to multi-phased implementations, the scenarios can become even more complicated. Careful functional consideration must be taken, as if done wrong the transactional flow may be broken or the interfaced system may be impossible to reconcile, essentially breaking business continuity.

Overview

The interface strategy is part of the overall project key deliverables setting out scope and project outcome expectations. The documents below are directly related but should be kept separate:

image

  • Interface Strategy: Define system scope and integration need
  • Data Migration Strategy: Define data retention for decommissioned systems or systems not being interfaced
  • Cut-over Strategy: Define how to orchestrate close down of decommissioned systems and their data migration, switch-over of retained systems and related interfaces, and commence use of new systems

The "strategy" nomenclature indicates these documents are likely to have a significant impact on the overall project plan. Each of the above documents may also spawn a number of functional and technical specifications based on decisions made.

Purpose

The primary purpose of the interface strategy is to facilitate management decisions caused by system change – decisions to ensure:

  • Continuation of daily business activities
  • Correct management reporting
  • Correct legal reporting and compliance

The responsibility of ensuring the above is not a technical decision but a high-level management decision. If the decision is taken at the wrong level or in the wrong perspective, the result can be serious for the business, which again falls back on management.

So therefore, the target audience and signee of the interface strategy is upper management.

A secondary purpose of the interface strategy is to give project management an idea of the effort ahead – both in terms of functional and technical work.

Therefore, the interface strategy must be created early in the project either during a pre-analysis phase or as first phase in an already started project.

Technical aspects are only considered where circumstances require technical assistance to gauge feasibility to accomplish the task due to complexity or extremely high volumes.

The interface strategy may indicate the need for a custom interfaces or an integration hub, which requires functional specification setting out the detailed requirements and then if custom/in-house made/built then a technical specification is needed.

Scope

The scope of the interface strategy is highly dependent on the overall project scope and timeline. Often projects are phased and may have intermediate system scenarios during which the business need to continue to operate.

On a large-scale project, you may want to split the interface strategy according to the implementation phases or sub-project schedules.

Scope Example:

image

The above example is a project looking to replace an old finance; payroll and treasury system with a new integrated finance and payroll system. The business seek to prioritise the business critical retail system and in a later phase to replace payroll and treasury systems.

If the phases are treated as two separate projects it may be convenient to have two interface strategies – one for phase one and one for phase 2. In case of parallel run; parallel implementations or downstream dependency of a decommissioned system, the interfaces may impact each other and should therefore be in one document.

Contents

These are the recommended top level chapters in the interface strategy:

  • General Overview: Upper management and general interest
  • System Analysis: Middle management and functional interest
  • Interface Analysis: Functional interest mainly

In some rare cases a technical considerations part maybe required to describe impacts of very high volume or space requirements.

General Overview

First part of the document should describe general scope and limitations enabling a high-level executive to create an overview of the decisions ahead.

For instance, use these sub-chapters:

  • Purpose
  • Scope
  • Limitations

Purpose: Explains about the overall project and how the interface strategy fits into this.

Scope: Lists key objectives; target systems and high-level project plan with timeline; phases and milestones.

Limitations: This describes both high-level business and legal limitations. Business limitations can the areas like seasonal impacts; other projects; reorganisations and mergers and acquisitions. Legal limitations are mainly based on statutory reporting like year-end; quarterly VAT reporting. In addition, Sarbanes-Oxley; data protection and sector specific rules may impact the interface strategy.

System Analysis

Second Part should contain short description of systems impacted by the above changes and an analysis of these changes and an overview of logical entities involved in the change. This will enable middle management to understand the overall impact on their functional area.

For instance, use these chapters:

  • Interface Diagram
  • System Descriptions
  • Interface Descriptions
  • Change Analysis

Interface Diagram: This is a complete as-is and to-be diagram of systems and interfaces between them. The interface diagram should focus on functional system blocks and logical interfaces.

A functional system block would be a function within a system like "Oracle Payroll" rather than "Oracle" as a physical system. Same goes for logical interfaces which would be "Payroll Journal" or "Salary Payment" rather than "GL data" or "BACS file". Also internal flows within a physical system should not be shown, as that would not constitute an interface in scope, so no flow is depicted between "Oracle Payroll" and "Oracle General Ledger".

A simple interface diagram example based on the scope example from above:

image

Note that the interface flow direction is the logical flow, as an interface can have bidirectional handshakes and feedback loops, which are considered technical rather than functional flows.

System Description: Each system and the specific module used in the interface should be described to a level so the decision maker understands the functionality and importance of this.

Interface Description: Each interface should be described to a level so the decision maker understands what is interfaced and what purpose this interface serves and how critical it is.

Change Analysis: Analysis of the as-is to the to-be transition and how to mitigate business continuity during the transition process.

Interface Analysis

For this chapter I would normally have a table per interface. In most cases this should only be to-be interfaces assuming knowledge of the as-is interface will feed into the to-be interface.

If many interfaces are required, the chapter can be divided into sub-chapters based on the source system or logical entity being interface depending on what is convenient.

The interface analysis should be kept at a high level but detailed enough for decisions to be made without pre-empting any required functional design. The information in the interface analysis should create a basis for the functional design, but not limit it.

These table sections are recommend:

  • Interface Name
  • Source system
  • Target system
  • Logical Entities
  • Structure Analysis
  • Dependencies
  • Trigger/Frequency
  • Volumetrics/Statistics
  • Transformations
  • Process
  • Controls
  • Security/Data Protection

Interface Name: Name of the interface. Ensure unique, consistent and precise naming like “new supplier invoice” or “payroll journal”. For instance the name “payroll interface” is bad, as it may cover multiple interfaces like “new employee”, “payroll journal” and “expense report invoice”.

Source system: Source system and module/sub-system where the interface logically originates.

Target system: Target system and module/sub-system where the interface logically terminates.

Logical Entities: What type of data is interfaced? Any sub-types or all data? For example, for the entity "invoice" is that "new invoices" or "amended invoices". In real life you may find each of these, may require a separate interface due to the nature of the data and how the interface is triggered.

Structure Analysis: Explain differences in entities between the two systems if needed. If the structure is very complex, a logical entity diagram may be needed. This is often very important for customer data as different structures may impact the level of customer information retained between two systems.

Dependencies: Dependencies on other interfaces or any functional dependencies. Like if another interface must be run before this or if the period must be closed before running the interface.

Trigger/Frequency: When and/or how often will the interface be run. Like "run daily at 3am" or functional event triggers like "when new customer is entered" or triggered by another interface "run when customer interface has completed".

Volumetrics/Statistics: How much data by time period. Time period is typically per day/week/month/year. This is important information for deciding on frequency, process and controls. For instance reconciling 1,000 records can be a manual task but if it is 100,000 records or more, some kind of automated reconciliation may be required.

Transformations: Changes to data between the two systems. This can be anything from data mapping to data cleansing like address validation and lookup. At this point only high-level transformation should be highlighted so no need to detail field level transformation.

Process: Automated transfer or any manual steps required for instance some bank interfaces may require manual load into a banking desktop system

Controls: How to reconcile the two systems and how to verify data has been successfully transferred. This may include reconciliation reports or automated controls or feedback loops. Also in case of error if manual check is needed or if automated alert is required.

Security/Data Protection: Any special functional security considerations. This may be encryption or masking of certain data or ensuring the data transferred is not generally accessible.

Conclusion

The above sections may not all be needed as it depends on the complexity of the project but one should ask yourself:

Does the quality of this interface strategy document ensure the right decision can be made?

This entry was written by Kent Willumsen , posted on Wednesday March 19 2014at 03:03 pm , filed under Functional Knowledge, Interfaces, Technical Knowledge and tagged , . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

Comments are closed.