6 Essential Steps to Interface Building Success

When an interface runs well it is a time saving – accuracy increasing – data visibility thing of beauty. When it doesn’t, it is a time-sucking – stress inducing – data reconciliation nightmare.

In my career I have had the opportunity to fix (or improve) a lot of broken and sub-optimal interfaces. Like a CSI investigator going through a crime scene, I have found that at least one of the 6 essential steps was missed or done poorly.

While the reasons for skipping or speeding through one of these steps may seem legitimate at the time, they will almost always come back to bite you in the end. It is far better to suck it up and build a resilient interface from the beginning and enjoy years of data flow bliss.

The following are 6 essential steps to building a successful interface. Even if you are trying to repair an existing interface that is not running as desired, it is worth going through the steps and see where your interface is lacking.

1.) Ideation

The idea for an interface usually originates from some pain caused by having two or more systems that do not communicate. This fragmenting happens for a variety of reasons including acquiring a company with different systems, buying special purpose off-the-shelf software, and internally building software to meet a business need without integrating it to the rest of the software ecosystem.

The goal of the ideation phase is to determine if the idea is feasible. To know if it feasible we define why, who, what, and when.

• Why? – Why should this interface be built
• Who? – Who are the players, as-in which systems are being interface
• What? – What data (and supporting data) needs to be interfaced, in what direction
• When? – When does the data get interfaced, what is the triggering event, how often

Once we have an idea of why, who, what, and when, we should have enough of a basis to determine if the idea should proceed to the design phase.

If the idea is not feasible, it is best that it dies in this stage where only a minimal amount of time and effort has gone into the idea. Too often I have seen an interface make it all the way to the testing phase before it was determined that there was something fundamentally flawed with the idea.

For more detail on getting through the Ideation Phase, check out my post “7 Must Ask Questions About Every Interface Idea”

2.) Design

The design phase should be over 50% of the effort in creating an interface. This is where most the details get ironed out.

• Mapping and Validation – The mapping and validation task requires people with domain knowledge of both the source and destination systems. Each data element needs to be identified and dealt with. For more detail on the mapping step see my post “Navigating the Interface Data Mapping Exercise”
• Architecture – The technologies and design patterns to be used to build the interface needs to be determined. If your company already has existing interfaces it should follow the same architecture already being used, if possible.
• Monitoring – How will the interface be monitored and who is responsible for monitoring. Unfortunately, your interface will not always follow the “happy path” and there will be exceptions that need to be handled. They can be unplanned exceptions where something unexpected happens or they can be validation exceptions that are expected.
• Exception Handling – Once an exception is discovered by the person monitoring the interface, what do they do with it? Different types of exceptions will have to be handled in different ways and possibly by different people or groups.

The design process is tedious and requires a lot of effort from different parts of the business. But if any of these areas are skipped before going on to the build phase they will surely become an issue once the interface is deployed and has real data flowing through it.

3.) Build

The developers takes the architecture, mapping and validation, monitoring, and exception handling designs and builds the interface.

If the design phase was done correctly the build phase should be relatively uneventful. I am not saying it is easy, but it should not be filled with unanswered questions that require the developer to stop and seek answers from other groups.

If your interface project is filled with a lot of questions that are raised during development that require group meetings to flesh out the answers, you probably proceeded from the design phase too early. It takes a lot more time and effort to work through design issues once the development has begun.

4.) Test

I always say that every hour of testing saves me 5 hours of post-production support (and fire-fighting). I don’t have any empirical data to support this, but I have felt the pain of insufficient testing, and I won’t forget it.

The biggest mistake made during testing is only testing the “happy path” use case. This is when all of the circumstances for success are there and the data flows through as expected. Everyone gets excited to see the data flowing and decide “it works, let’s deploy it to production”.

Another mistake is skimping on testing because of a time pressure. Management may think that since development is complete, the interface is done and needs to be deployed ASAP. This is a recipe for disaster.

You should create a test plan that includes exception cases for every mapping and validation defined in your design. Knowing how the interface is going to behave when something is wrong with the data will save you tons or heart ache and stress later on.

When an untested interface makes its way to a production environment, everybody loses.

• The very problem the interface was supposed to solve has been compounded
• System users quickly lose confidence in the interface and revert to manual data entry
• IT management gets an earful from business management
• Designers blame developers, developers blame designers
• Cats and dogs start living together… fire and brimstone falling from the sky…

Don’t skimp on the testing. You will regret it.

5.) Deploy

Your interface has been well designed, developed, and thoroughly tested, it is going to be a huge success, right? Not if the deployment gets bungled.

The key to a successful deployment is communication!

Deploying an interface to a production environment is not just a mechanical IT exercise. There are many groups that are potentially affected by even the most basic interface. Everyone should know what is happening, when it is happening, and how it will affect them.

• Notifying users of changes to their current business processes
• Any system downtimes
• If services need to be restarted

6.) Monitor

Once your interface is “live” and real data is flowing, it will need to be monitored. Hopefully, you have identified who is monitoring the interface and how they are monitoring it during the design phase.

For the first few months an interface is running in production there may be some exceptions that were not anticipated during the design phase and not discovered during the testing phase. These should be minimal and not too difficult to address.
Even if everything is running as expected, there is an opportunity to “tighten up” the interface and make it more efficient.

The exception data should be reviewed periodically to see what types of exceptions and validation errors are occurring and determine if anything can be done to prevent the exceptions from ever happening.

For example, if 50% of the data exceptions can be solved by implementing a simple validation in the source system, it may be worth implementing. Or, if a value can be defaulted if it is blank instead of causing an exception the interface should be modified to default the value when blank.

Conclusion

By ensuring each of the 6 steps is done thoroughly you are setting yourself up to have a successful interface. Each step builds on the prior one and makes sure all ingredients needed for a successful interface are addressed.

What are some of the things you do to ensure the interfaces are successful?