6 Steps for easy to make support integration landscape

Posted by on Apr 22, 2014 in Integration, White Papers | No Comments
  1. Understand what you have.

So many companies have programs and interfaces that are critical for the business to run, but the knowledge is distributed across employees in the company and is never aggregated in a single location. From a support standpoint, your life will be infinitely easier if you can answer the following questions:

  • How many interfaces exist? (by functional area)
  • How do the interfaces communicate?
  • What triggers each interface?
  • Who are the points of contact for the interfaces?
  • Contingency plan if the interface doesn’t work/criticality of the interface.
  1.  Define requirements before building.

Many companies face complicated support environments because they want to implement things as fast as possible. In the short term, skipping some of the following steps may result in the interface being developed faster, but eventually will result in a difficult environment to manage. From a functional standpoint, starting development before the requirements are fully understood and the approach is fully vetted, will occasionally cause throwing away prototypes and reworks. If I were a customer, I would only want to pay for development that I am going to use. From a technical standpoint, if you don’t have an interface baselines (Naming conventions, security policies, development best practices) in place, it is difficult and near impossible to put them in after the fact, especially after things have been transported. The sooner in the process that problems are identified, the easier it is to fix. If you really want to be successful you should have your standards defined and distributed, and development reviewed for compliance to a set of standards before transport.

  1. Periodic Review of Development and Continuous Improvement.

You may be reading this and wondering when you are going to have time to do a review of your interfaces. That in itself may be a sign of a problem. The time saved by having stable environments should be enough for you to utilize resources for process improvement and new functionality instead of constant break fixes. Once or twice a year, it is a good idea to check out your environment and in addition to any other audits you may have (Sox or otherwise), investigate the environment to ensure that all of your development is still needed or is working in the best way for the business. Major issues can be circumvented by occasionally going to the business and looking for problems. The response may be something like, it works fine, but would be so much easier/better/efficient if it could do this. I have been at many places where a simple task could be done by a job instead of a manual function, but because there was little communication between business and technical, things were being done the hard way.

  1. Limit technical approaches.

PI or Process integration, has 15+ adapters, robust mapping capability, and the option to extend functionality almost endlessly through a custom code. Often times, because the tool is so robust, there are many ways to achieve technical integration. While we at Morinteresting, love investigating the different ways to solve integration challenges, you the customer should not. The KIS (Keep It Simple) approach is almost always best. If not managed, the solutions turn in to chimeras (The beast in greek mythology with a lion-front and snake behind, a goat in the middle, capable of snorting out a breath of the terrible flame of fire {Description from the Illiad by Homer}. Don’t let a chimera integration approach bring your company down. Simply by evaluating the different interface approaches and limiting to the ones that work best for your support organization as part of your standards, you can avoid the fire breathing monster and end up with something easier to manage.(BTW we are much better at SAP than we are at PS)

  1. Play each solution landscapes strengths.

If you are trying to cut down an oak tree with a screwdriver, it is going to take a while. Just because it is a report doesn’t mean that we can’t query the data just right in ECC (Enterprise Central Component) before passing to PI. You wouldn’t want to waste effort writing a custom connection in ABAP when you have PI, and you can sometimes do sorting easier in ECC before passing to PI. If you can have an integrated development approach, you can utilize the strengths of all the tools in your kit and come up with a more reliable and straightforward approach. Remember, just because you can get it to work doesn’t mean that there isn’t a much simpler way.

  1. Have a well-defined alerting/problem resolution infrastructure in place

Companies have fire drills, tornado drills, emergency response plans, and complex DR solutions. Even with this preparation, many don’t consider what they would do if a critical function of their business software was not able to work. In fact, if the right checks and alerts are not in place, things can be broken for a long time before people are aware, and that can make a mountain out of a molehill. When things are broken in production, stress levels are high, and it is really not an ideal time to come up with a plan. Because projects are typically focused on getting things live and working people sometimes forget that a significant amount of emphasis should be on how we are going to catch issues, alert users that something has gone wrong, and track identification that a problem exists to root cause analysis, technical resolution, and future mitigation approach.