When it comes to solving data integration problems, we often overlook the system-level impacts of proliferating integration objects, increasing data volume, and increased logging activity. The tendency is to focus on delivering applications and to ignore broader consequences that could come back to bite us.
As an EXTOL developer who interacts with our front line support representatives several times a day, I have seen, first hand, the perils of poor system maintenance and not having a disaster recovery plan. There are three important points that need to be considered, to keep the ship sailing smoothly and to mitigate extended periods of downtime, should a disaster occur.
The first is the necessity to have a test system that closely mirrors the production system. Configuration issues, mapping problems, and trading partner setup mistakes are just a few of the issues I see reported that could have been headed off earlier in a test environment. In a test environment, troubleshooting the problem is not as time sensitive and costly to the business. While there are costs to setting up additional hardware, and possibly additional software licenses, the benefit of preventing lost business is well worth the investment.
A second, related need is for regular production environment back-ups. We could discuss, ad nauseam, different backup methodologies, but that’s not the point of this blog entry. The important point is that a back up plan exists and is being used on a regular basis. Backups may be supported in the integration software itself or through processes on your company’s back end, or a combination of both. Let’s face it, no matter how much we think the worst will never happen to me, disasters occur. When they do, recovery time and cost can be reduced significantly if a recent backup is on hand. Regular backups can also ensure that production and test environments are in synch.
A third way to reduce the incidence of performance problems is to schedule regular maintenance and ‘clean up’ on the system. In an ideal world, things would run smoothly for months without problems, and without touching the production environment. But production environments accumulate logs and other data as they operate, so it’s important to purge old data from the system, periodically. Some of the worst performing systems I have seen are ones containing data and logging information accumulated over months or years. Ask yourself: do you really have a business requirement to keep data that long? If not, then you should be purging it as quickly as possible from the system. Over time, accumulating data will degrade performance. It may not be noticeable now, but over time, it will become more and more of a problem, and as the problem grows, the time to clean up the system does as well.
While the list above is not exhaustive, it covers the most important factors in keeping your environment up and running smoothly. If you haven’t taken steps to cover all three areas, ask yourself, why not?