My job is mostly based around an Enterprise Resource Planning tool called Oracle E-business Suite. This is a really big piece of software that can track data around almost all of your business functions. You can run your finance out of it as well as purchasing, inventory, manage your customer relationships, pay your employees… the list goes on and on and on.
Unfortuantely Oracle E-business suite doesn’t cover absolutely everything and people in your business might not like the way Oracle wants them to work, so you end up writing code around the edges of the product to make it fit your business, this is called customization. All this is fine as long as you follow Oracle’s rules about what you can and can’t do in your customization.
My company runs Oracle E-business suite version 11. Oracle came out with version 12 a few years ago and we are now looking into upgrading E-business suite to the latest release. From a technical point of view, this is where the fun really starts, because between releases of Oracle E-business suite Oracle make changes in the way the business data gets stored. So all those lines of code you have spend the last few years carefully polishing now become a bit of a headache. Will they survive the upgrade? What’s going to go wrong? Is there anything I can do now to avoid problems when the upgrade happens. It’s a problem that people like me worry about at nights.
Recently I had a demo of product that has got me excited, which gets more difficult every year I work in IT. The product is Panaya Oracle EBS Upgrade Automation. Panaya seem to have created a datbase of all the changes that happen between R11i and R12 of the E-business suite and developed a very clever tool that you can run against your E-business suite instance which identifies all the custom code you have developed over the years. You upload the output of their tool to the Panaya portal and they run all your code through their database and identify all the places where your shiny code is going to fall down when you upgrade to R12. They even reference possible solutions that have been published by Oracle to the problems identified by the tool and indicate if it would be possible to fix the code ahead of the upgrade process. So the great unknown of the Oracle upgrade process is transformed into a heap of issues with potential fixes. Even better they have developed quite a slick portal where you can upload snapshots of your code as you proceed towards your upgrade and track how your E-business suite instance is (hopefully) getting more and more fit to be upgraded. The portal also allows you to track issues and fixes.
If you are into offshoring your upgrade it’s a great starting point for your development because it produces a huge list of simple tasks. This is what you need if you are working with teams who are geographically remote and in a different time zone – these guys don’t have someone across the desk when they can ask when they run across a problem. The biggest issue with offshore development I have seen over the years is the huge amount of time required to deliver a quality specification that allows the offshore developer to work independantly and understand the business requirement with little communication with the customer.
Finally it’s all based on a cloud service so there are no servers to provision and is available with very little delay, this is music to any IT manager’s ears.
I don’t know if the company I work for will buy Panaya, but I sure hope they do!. Note – I’m not an employee of Panaya and haven’t received any inducements to write this.