The hidden cost of not upgrading

The past few weeks have been rough. When I started here I inherited support for a third party program that integrates into the Oracle Apps. The concept of what it does and the service it provides is really cool. I wish my previous job had had this program. The only draw back was that when this program was bought and installed it didn't have all of the features that my new company wanted. That means lots of customizations.

That was 4 years ago for go live, plus a year of development time for the customizations. A Total of 5 years is the version age of the software. 2 years ago a decision on whether to upgrade the product or not came up. The decision was not to upgrade. Each decision comes with a cost. Some are upfront and some are hidden. It's the hidden costs that tend to really cost you.

In the past year we have had to upgrade hardrives, due to running out of storage space. Diagnose OC4J's and the workload passing through them and manually load balancing them. There are 2 issues with the OC4J's memory leak, and the servers ability to handle the workload that they were running on. The Server that the OC4J's were running on had a fatal non recoverable hardware crash. In total about 3 weeks of outage time for 20+ people over the past year. My estimation of cost of extra support, we pay a higher support fee for being on a non-supported version. Outage time for employees, extra hardware costs, extra internal support time, it comes up to almost twice the cost it would have taken to upgrade. Other additional costs that are hard to quantify, can't go to XP SP2, can not upgrade to IE 7, can not use Firefox, OOD issues, Database upgrade issues, lower productivity (reading updates I can expect a 5-10 fold increase in performance when we upgrade).

Now trying to go to Oracle On Demand (OOD) has been an adventure. First, this is an OS platform switch, so all forms, and reports had to be recompiled. Guess what, no source code. Vendor gave us source code to recompile with. It took 3 weeks of trouble shooting to determine that the source code supplied was not the exact version we were on. (Customizations).

At least next year we will get to upgrade.

What is the average life of code?

I’ve been taking a look at some processes that process our EDI invoices. There are 3 main groups of programs. Only 2 groups are being currently used. There used to be four but that is a different story.

The business decided to add a third party vendor to monitor freight charges by the major freight carriers that the business uses. After a manual sampling of invoices it was determined that the business could save “millions”. The Third party vendor likes to use EDI for invoicing. Luckily these freight carriers were sending some invoices to us through EDI. I said some. Actually only for 2 locations and the second location was for only 1 carrier and was added late last year.

The current processes can only handle what they were written for. (the 1 location) We discontinued one process when the vendor started sending in duplicate invoice numbers. Different charges but same invoice number. That violated our unique constraint for invoice numbers on a vendor. Since then we have upgraded the database, the vendor was bought out by another freight carrier, and now that set of programs don’t work.

I usually don’t look at code, but with our OOD project going on, resources are tight. We are under a code freeze, no new programs can be developed and changes to existing ones can not be made unless it’s a production issue. I can’t get changes based on the premise it will save “Millions” of dollars. I usually have a good idea on how the code should look from what I see with the end results and what the developers tell me. The program is more flexible than what I was told it was. Instead of most everything was hard coded only about half was. I did confirm my worst fears. The program inserts directly into the AP invoice tables. BAD, BAD, BAD, BAD, BAD There is a perfectly good payables interface and interface process that has been around since at least 10.7.

One set of code was written in 1998, the other set in 2000. Both programs share a similar history after that. Updates to the code every 2 years or so. This got me to thinking. With some of the other issues I have to deal with. What is the average life of code? These two sets of programs where written 8 and 6 years ago, the latter being a lighter copy of the first. Hours have been spent writing the code, translating the 810 file into another file format that was easier to load and process. In total these 2 processes processed 20 invoices a month. Another issue I have with these 2 program sets, no cost savings except to the carrier since they don’t have to send paper detailing the thousands of shipments per invoice.

Even though the programs were originally written 8 and 6 years they have been periodically updated with major revisions every 2 years. These revisions either reflect changes in the business, or changes in the infrastructure. (upgrading from 10.7 to 11i). Two years seems like a reasonable timeline for the life of code in an ERP environment, from my experience and seeing some more examples at this job. I guess if I was going to apply this to the financial aspects of a project development I would limit the life to two years. You would need to achieve a target ROI using the two year timeline. Too bad the projects here are not analyzed with those criteria.

ICX Form Launcher profile

The ICX Form Launcher profile is a very important profile. I learned this yesterday while trying to figure out why our third party integrated application is not working on the new platform. We are in the process of going onto OOD. This is a switch in OS platforms for the company I work for. We are down to getting this last application working. Anyway, back to the ICX Form Launcher profile.

When you first sign into Oracle Applications 11i you are given a web page sheet that lists all of the responsibilities that you have been given. When you click on the responsibility link it launches the Oracle applications. The way it launches the application is by passing the ICX Form Launcher Profile. This will invoke the J-initiator that loads up all of your Java components for displaying the Oracle 11i Environment.

If you have custom Java components that need to be loaded for your third party integrated application. Then it is in the Profile option ICX Form Launcher that you store this information. This is just a variable call for the web application server to interpret and pass the correct jar files town to the client. The actual location of the jar file is stored in your appsweb.cfg file.

For more information on ICX Configution and how versatile it is check out this link. DataLoad : Dataload is a great tool that I’ve used for years to load data into the Apps. They offer a fully forms integrated solution as well. This section goes over how to setup your record and playback functionality using ICX Form Launcher.