Just a spoonful of sugar helps the medicine go down
In a most delightful way
- From Mary Poppins’ “A Spoonful of Sugar”
I’ve heard quite a bit of rumbling in the Oracle Apps customer community lately about the cost and pain of upgrading to the Fusion Architecture. This rumbling is especially loud in the E-Business Suite customer community, as they’ll be compelled to abandon Oracle Workflow with the demise of Release 12 in a few years. The grumbling often runs along the lines protesting of the expense and effort of making the move without much value added other than generating more license and maintenance revenues for Oracle. Frankly, there is a large group of customers out there that don't see the benefit of taking the medicine.
Personally, I understand the “cost and pain” element for Oracle Workflow users who have built custom workflow processes. There is no clear upgrade or migration path for those customizations. There are things customers can do that may mitigate that cost and pain but, if a customer actually has no feasible options other than moving those custom workflow processes to the Fusion environment, it does look a bit rough as I write this article. Bluntly, this medicine may taste a little bitter.
The “cost and pain” considerations notwithstanding, I do think that the value add of Fusion Architecture will outweigh the cost of upgrading to that architecture: there are some spoonfuls of sugar to help this medicine go down. One example: the impact of loose coupling on future application upgrades.
Many of us have 3rd-party or custom applications that we’ve “bolted on” to our Oracle Applications. Whether it’s because we need to preserve a certain business process, or our customers are persnickety about the user interface, or even just because grumpy old Mr. Potter doesn’t want to change things, most of us have some type of home-grown or 3rd-party app integrated into our ERP or CRM systems. When our apps change in the course of an upgrade (whether it’s Oracle’s apps or the bolt-on app), the change often constitutes taking a virtual sledge-hammer to the bolt-on interfaces.
Enter the loose coupling we get with Fusion Architecture. The idea behind loose coupling is to reduce the interdependencies between applications by utilizing industry-standard interfaces. The upshot here is most apparent in a point-to-point interface: so long as the integration points for each of the two apps remain unchanged and the interface between those points remains unchanged, changes in the applications on one side of the interface (form changes, database table revisions, that sort of thing) have no impact on the functionality or performance of the application on the other side of that point-to-point interface.
So in a loosely coupled environment, I won’t need to change my bolt-on application when upgrading my Oracle applications from one dot-release to the next so long as the interfaces between the two are loosely-coupled…which reduces the risk, complexity and effort associated with that particular upgrade. That sounds like a value add to me.
Now, before you run off thinking that we’re on the cusp of a bright and perfect world, I do need to add an important caveat. In leveraging Oracle’s APIs to construct loosely coupled interfaces with bolt-on apps, you’ll need to keep in mind Oracle’s design practices regarding those APIs. Rather than rehash some great work from another blogger, I simply refer you to Sanjit’s article on the subject at OracleApps Epicenter.
With loose coupling, I've pointed out only one small example of the value add opportunities Oracle applications customers will have after upgrading to Fusion Architecture. There are plenty of spoonfuls of sugar available in the Fusion Architcture that make the upgrade worthwhile, regardless of whether you’re using EBS, PeopleSoft, JD Edwards, Siebel, Retek, or even if you have your eye on Fusion Applications. Let me know what you think.
No comments:
Post a Comment