Skip to Content

This is part 2 of a blog series “Implementing & Sustaining Interfaces in SAP ERP applications”. The complete list of blogs in this series can be accessed from my weblogs. Implementing & Sustaining SAP ERP Interfaces – Part 1, Essence of Interfaces explained why interfaces need special attention and why it is important to have a strategy to deal with interfaces. This part explains what an interface strategy contains and what needs to be addressed in the strategy.

Part 2 – Interface Strategy

SAP projects vary largely in their nature and approach. Those that identify interfaces as a “critical success criteria” would usually estabilish a strategy for interfaces. And, they should. But often, I come across SAP projects and SAP IT teams that do not have a strategy. Sometimes, it is because they do not think it is critical to do so. Sometimes they dont want to invest in the extra cost to estabilish and implement one. Sometimes, they are ignorant of its importance. But invariably, it is always vital to estabilish an interface strategy, even when it not very apparent to do so.

For instance, in a phased implementation, there may not be many interfaces or any critical ones during the first phase. But that does not mean that an interface strategy is not required. SAP systems have a very long lifetime, and sooner or later, invariably, either during the subsequent phases of the project or during operational enhancements, it will be required to build critical interfaces. However, at that point of time, it may be late to build a strategy given other constraints like budget, reduced team size, lesser think tank and other operational priorities. Even if you did, interfaces built until then would not be consistent with the new strategy.

Having said that, I would also say that it is never too late to build a strategy for interfaces. Building one would identify gaps and risks in your systems that can be addressed in future improvement projects and help you be prepared.

What makes up an interface strategy?

An interface strategy should contain 4 major sections.

1. Technical Approach – What systems, technique and tools are going to be used? how files will be handled? What middleware will be used? How external communication will be handled? How web services, RFCs, EDI, IDoc etc. will be used? What file system is used? etc.

Figure: Interface Strategy

Interface Strategy

2. Standards – What protocols are allowed? What are the naming conventions for filenames, RFCs, Web Services, file directories etc.? Which techniques are obligated, limited or restricted?

3. Guidelines – Which techniques are to be used for different scenarios? Synchronous or Asynchronous? Whats the error handling mechanism?  What security is used? How is performance measured? How external and internal interfaces are handled differently? What are the translation options to use? Where is translation done?

4. Methodology – What processes are followed? What methods are used for requirement elicitation, evaluation, design, building, testing, implementing and maintaining interfaces? What would be the review process and who does it? How is quality ensured? How the strategy enforced.

 

Together, these 4 sections should address the 5 major concerns in interfaces

 

1. Integrity of the interface data – Does any records gets lost in the process? Does every record gets processed completely? Do records get processed more than once?Is the integrity of the target system data is kept intact?

2. Error Processing of interface errors – Is the error handling manageable? Is there sound error reporting? Is error handling easy and usuable? Are error fixes auditable and secure?

3. Throughput of the interface – Is the throughput measurable? Are the runtimes short? Is there enough flexibility in the interface to break it down to smaller functions? Can the throughput be increased or decreased with parallel processing?

4. Security & Auditability of the interface – Is the access to the interface data controlled? Is the interface record traceable from source to target and vice versa? Are the changes in the interface record auditable?

5. Robutness of the interface – Are failures handled (like runtime errors, memory dumps, system shutdowns etc.)? Can an interface be reconciled after failure? Can an interface be rerun to sysnchronize both systems after failure?

A reliable and high performing interface would have all these aspects of an interface covered. A sound interface strategy is one that can produce the such reliable interfaces, when they are built using the guidelines, standards, approach and methodology defined in the strategy

In the next part of the blog, I’ll illustrate a simple interface to explain the common pittfalls in interfaces and how the above concerns can be easily overlooked in such scenarios interface.

To report this post you need to login first.

2 Comments

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

    1. Salai Sivaprakash Post author
      Hello Prabhu,
      Thanks for your kind words.

      I havent planned too much to write on the project management and business alignment part of it. But I have some plans to write about branding the interfaces. I’ll try to address some of the ownership constraints as well. You are welcome to add to it.

      But I’m going to take a while to get there since the next few parts are heavy on the design aspect of this.

      Salai.

      (0) 

Leave a Reply