Disclaimer: These are all my own views only, and do not represent that of my employer's or anybody else's
I am fortunate enough to get to the vicinity of a couple of migration projects, where we had been replacing some other middleware(eg. eGate , Mercator) with SAP PI. During the process, I have learned that migration requirements pose a different set of challenges than implementation requirements. During implementations, our main focus remains on getting clarity on the requirement, which generally changes, and gets refined in some form or the other, till the point of go live and beyond, and then use the middleware tool's features to best design the interfaces. Thus, best design is driven by the tool's abilities and out of box features provided. Over that custom codes are written to supplement the gaps and fulfill the requirement.
However, when we are talking about migration, the requirement is already known and functional with a different middleware tool. The present design is based on the present available tool's capabilities and best practices. These capabilities and best practices will differ from tool to tool , so, what is best designed on one tool might not be the best design for PI, thus posing frequent challenges to the migrating tool's capability. Thus an as is migration might not be the best possible way to choose, and in most cases might not be possible altogether. These technical challenges will lead to greater complexities, and might lead to a very clumsy situation unless dealt with properly from the very beginning of the project.
Thus approaching a migration project turns out to be a vital parameter for the success of the project. Below are some of the factors which should be taken into account from the Blue Printing phase.:
1. It is important that a comparative study between the tools is handy.
2. Study the present requirement and try to classify them (based on the visible PI design). examples might be "Control M" - Signifying interfaces which works along with the scheduler Control M; another example may be "External Web services" , denoting interfaces interacting with external Web services. Below are the few patterns /"pointers to define patterns" that I can think about now:
- Synchronous / Asynchronous
- Interfaces working along with other scheduling tools.
- EDI Interfaces
- Stateful Requirements / potential ccBPM requirements
- Special Scheduling requirement
- Dependency requirements
- High Volume interfaces
- High Frequency
- Real time requirement
- Protocol support required which are not provided by PI standard adapters
- Special security requirements, eg: involves digital certificate / sFTP requirements etc.
- Publish-Subscribe pattern
- Business Critical Interfaces
- Any requirement for High availability for specific set of interfaces
- Any other patterns specific to the requirement
- Third Party systems -- in most cases 3rd party systems pose unique(specific to the 3rd party) interface challenges
Next, carry out a high level design and feasibility study of each pattern. Incase adequate time is provided , a deeper look at the individual interfaces is worth. Try to narrow down the classifications into PI design patterns.
In the process, certain limitations of the tool is expected to crop up. There are chances that these limitation will have a certain common solution and should be studied carefully for something which is generic / at least can apply to a group of interfaces as generic-parameterizable solution. This solution might range from --a design pattern, writing custom Java or ABAP Maps/ proxies / Adapter Modules / operating system scripts , creating a map convertor etc. A cost analysis needs to be carried out to gauge the advantages / disadvantages of building the generic solutions - it is more likely that certain generic solutions will pass and will be applicable for a significant mass of the interfaces.
At this point of time, we should have some generic solutions available and some specific problems to be addressed which looks to be much simpler and less clumsy to be dealt with than where we started from. A lengthy Blue print/ requirement analysis / design phase is worth invested!!
