The First Two Steps to an Updated IT System

May 21, 2013 at 4:47 am | Uncategorized | No comment

In a recent post, I outlined five challenges to keeping your ERP, MRP and CRM systems up to date. Don't despair. There are ways to overcome those challenges. Today, I want to discuss two of them.

1. Application Lifecycle Management.

Lifecycle Management has always been a thorny topic. Quickly scan the Wiki entry and you'll find 17 different subcategories and 56 different products for ALM. Major vendors such as CA, HP, IBM and Microsoft have products and there are many others including open-source tools. Some of these tools manage applications that were created and maintained using a specific development tool (Rational, Visual Studio....). Others are more flexible and apply to a wider environment (CollabNet, FogBugz....). Before you decide which one you'll use, you need to match your CURRENT developmental environment while considering how you PLAN on doing development in the next 4-5 years. Ideally, your choice will avoid duplication of functionality (different tool for managing Rational development vs C++ for example) since coordinating the use of multiple tools requires significant manual effort. The choices are even more difficult because the standards in this area are still evolving and the marketplace hasn't consistently adopted those standards that are more mature. One thing is clear. The more closely you're able to adhere to accepted standards (such as UML), the greater the chances that your ALM program will be effective in the long run.

2. Application Patch/Upgrade Management.

This crucial function has always fallen into the "poor stepchild" category. To avoid this, your organization needs to have a standard process that defines required upgrades and outlines a specific schedule for when they'll be done. Establishing and communicating this standard is crucial. Documenting, assigning responsibility and demanding accountability for implementing this process are musts. This will help avoid the inevitable, last minute "fire fighting" that results from ignoring legally mandated and "mission critical" application changes. Many major applications (ERP/MRP/CRM/Retail...) have tools to assist in deploying patches/upgrades. Some vendors provide these tools under the umbrella of the support agreement while others charge separately. If a tool is available, use it. The application designers obviously think that patch management is important enough to automate. Believe them. The many interconnected systems and applications involved in the coordination of patches/upgrades can be "interesting." For example, if you need to upgrade SAP you'll likely have to upgrade your database, which can lead to an upgrade of your OS. Then you could discover that the Java version used in the new database is not compatible with other legacy applications, which creates additional complexity. Or you may find that other issues arise with complex applications (ERP/MRP/Retail/DataWarehousing) that can have hundreds of inbound and outbound interfaces. Many are generated by external organizations (customers, suppliers, others) that are running on their own schedules. Finally, depending on your environment, you may need to deploy patches across many servers nearly simultaneously. Buy you can't be distracted by this "cascading" effect. Devise a solid plan, get everyone to buy in, and execute. You may be forced to implement the process in multiple steps and phase the changes in over an extended period of time but staying focused and disciplined is the key. The issues are difficult but not insurmountable. Ultimately you'll find that fighting through the implementation pains is worth the peace of mind you'll have knowing that all your systems are up to date. What do you think? Have you implemented an Application Life Cyle Management program? Do you have a documented Patch/Upgrade Management Plan?

You must be logged in to post a comment.