Introduction :

This is a high level summary for the Interface Transition strategy using Business system as preference/capability to change.

The Transition Period is the changeover period of time when between a legacy system and a new system.  During the Transition Period both systems may need to operate to sustain the business stability. In a nutshell one state or stage must change to another without impacting the business.

This has special implications for Middle ware/ Integration layer, such as Process Integration / Process Orchestration that may be required to ensure both systems are kept in synch.

The Transition period can be handled in different ways.  Here are three common ways to handle Transition Periods.

1) Business system as preference/capability to change

2) Legacy system as preference/capability to change

3) Middle ware/Integration as preference/capability to change

The combination and hybrid of above three also can be implemented to achieve the Transition Strategy.

               Business system as preference/capability to change  –  Interface Transition Strategy

If the Business system is the preference or capability to change in the Interface Transition Strategy, the following points should be considered.

  1. The customer’s preference is to change the existing code/connection of their business system / third party system
  2. If the business system is unable to the change its existing connections it will interact with the legacy system as it is (i.e. the current state)
  3. If the business system is willing to change its connection parameters, then it will interact with Middle ware as per the first option.  then the required data is split by the Middle ware to update the legacy system and new system during the transition period
  4. Data synchronisation is required between the legacy and the new system, to synchronise the master data.
  5. The middle ware handles data transitions between the legacy and the new system. To handle this, the middle ware might need a temporary code. It is good idea to maintain the temporary code/s required for transition period in the Middle ware, so that the customer can control, fix and monitor in the one place, as well as easily switching to the permanent interface

      Business system preference.PNG

Blue colour: No changes (using the existing code/ connection/ drivers)

Green colour: Minor changes (changes like driver/connection/ ftp change/ less than one day code changes, per interface)

Yellow colour: Medium changes (code changes – less than two days, per interface)

Brown colour: High changes (code changes – less than four days, per interface)

Red colour:  Very high changes (code changes – more than four days for one interface, custom and temporary code for transition)


Summary :

This is a high level summary for the Interface Transition strategy using Business system as preference/capability to change.

The goal of this blog is to help users to make aware of the Interface Transition Evaluation Guidelines using Legacy system.  These recommendations are based on my personal experience in SAP Implementation as a technical architect. The user can follow the suggestions provided by the blog and it should supplement with additional information. With any transition strategy proof of concept is a good way to minimise the risk and any unforeseen issues.

                     Interface Transition Strategy – Legacy system as preference/capability to change

Interface Transition Strategy – Legacy system as preference/capability to change

                     Interface Transition Strategy – Middle ware/Integration as preference/capability to change

Interface Transition Strategy – Middleware/Integration as preference/capability to change

Please note: These suggestions are high level suggestions, individual projects might require specific custom variations or another approach, based on the project requirement.

Reference :

http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/08/29/interface-transition-evaluation-guide

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Daniel Graversen

    Good considerations.

    One thing I to consider is the fall back when moving to PI. It is always a good thing to be able to move away from PI if you forget some consideration in the development process.

    (0) 

Leave a Reply