Fusion Apps In 2010?

Lots of buzz recently over the Oracle Q3 earnings call. One comment that’s probably gotten more than it’s fair share of examination came directly from Larry Ellison: “…next year we are going to be delivering the next generation Fusion applications, which we have been investing very heavily in over the years…”

It sounds as though we’ll see Fusion Applications sometime in 2010. I’m glad to hear that news. While not knowing all the intimate details and war stories surrounding Fusion Apps development, it sure seems as though much of the work progressed in a “two steps forward and one step back” pattern. It’ll be good to see a resulting product.

Keep in mind that this will be the first iterative release of Fusion Apps. This first release will not be a full-functionality replacement for any single Applications Unlimited product. The first release is not a destination, but simply a mile-marker along the road. While a product release will be a great sign of progress, Fusion Apps development will still be far from finished. So, when the first iteration becomes available, put on the party hats, blow the horns and toss the confetti…just keep in mind that most of the road will still be in front of us.

Just Hold On Loosely

Just hold on loosely
But don’t let go
If you cling too tightly
You’re gonna lose control
-- From .38 Special’s “Hold On Loosely”

In my last article, I came right out and said that customizing packaged apps is a bad idea. Blunt, clear, to the point…no question where I stand on this issue, right? So you’re probably asking “Floyd, how do I automate my unique business processes if I don’t customize packaged apps?”. Let’s talk briefly about that.

If I’m an Oracle E-Business user (or a user of any Oracle Applications Unlimited products, for that matter), I’d want to automate my custom business processes using the BPEL functionality in the Oracle SOA Suite.

Great, here we are in a down economy and I’m suggesting you spend more money licensing more Oracle products…thanks loads, right? Well, before you tune out on this idea and decide I’m shilling the SOA Suite for Oracle, fire up your spreadsheet of choice and run a quick comparison on the maintenance cost of packaged apps versus the costs (both up-front and recurring) of licensing the SOA Suite. Might take a little researching to estimate the numbers for your shop, but I’m willing to bet dollars to donuts that the SOA licensing costs will be the lower cost over a three-year period.

As you create your cost analysis, keep in mind an important point. Keeping your customizations outside of the packaged apps means you don’t have to perform testing and redevelopment of customizations every time you apply a patch to the packaged apps…and at least in the E-Business space, patches are frequent. We live and die by the patch.

So how is it that using the BPEL functionality in the SOA Suite reduces those maintenance costs? This is where the benefit of loose coupling comes into play. In fact, it’s the key to the whole idea here. I wrote a post on this in April of 2008 called “A Spoonful of Sugar”. It might be worth another read now. The upshot here is that the tighter the dependencies between your packaged apps and your customizations, the higher your maintenance costs. “If you cling too tightly, you’re gonna lose control…”

Lessons From A Scorched Satellite Dish

So I’ve got this neighbor…nice enough guy, but definitely not the sharpest tool in the shed. A little lacking in the common sense department. Several months ago, he signed up for Dish TV. Decided to install the dish on the room himself (and this is where the lack of sharpness comes into play). The genius figures he won’t have to put any holes in his roof for the mounting apparatus if he just wedges the dish into the opening at the top of the chimney…yeah, honest, that’s what he did...I’m just not creative enough to make this stuff up. Then he really straps on the old thinking cap and runs the line from the dish to the TV down through one of the air vents for the attic. At the time, my neighbor was really quite proud of his smarts for installing the dish without putting any holes into his roof.

Now let’s fast-forward a few months to just a few weeks ago. Southern California got hit with a cold snap (well, cold for this part of the world, anyway). Guess what my neighbor does? Yup, he lights a fire in the fireplace. House fills up with smoke. Parts of the dish scorch and melt, rendering the dish a disc of scrap metal. Small fire (very small – no real significant damage) starts up in the attic (turns out the cable used to wire up TVs to satellite dishes does a fairly decent job of transferring heat over short distances; who knew?). It’s like a big BBQ gone wild. After the smoke settles and the fire department leaves, my neighbor starts venting about his frustration with Dish TV! He thinks they either should have produced a dish that would hold up to these types of conditions or lat least warned him not to install the dish in the chimney. So he complains to Dish Network. In a true example of going the extra mile in the name of customer service, Dish Network replaces the satellite dish free of charge. Now, here’s the good part: want to guess where my neighbor mounted the new satellite dish? Yup, it’s wedged right back in the top of the chimney. The neighbor says he won’t be lighting any more fires in the fireplace, but I’m not sure his mental electrodes have enough juice running to recall in six months that he really shouldn’t be lighting up another log. I can’t wait for the entertainment to come next winter!!!

On a slightly more serious note, it’s pretty easy to see that my neighbor’s issues came from a failure to learn and follow best practices for installing the satellite dish. His custom installation seemed…and apparently still seems…to be a great idea to him. In the world of packaged enterprise applications, I think many companies may have more in common with my neighbor than they may be willing to admit. For example, how many E-Business customers diverge from best practices and customize the packaged apps in order to preserve a unique business process? The word “bunches” seems to spring to mind here. And, later on, when the customization breaks due to a configuration change from a patch or an upgrade, who do we blame? The company providing the packaged apps, of course! They should build more flexible apps. See the parallel?

Folks, customizing packaged apps is a bad idea. The most expensive approach to enterprise apps is customizing packaged applications…it’s a maintenance nightmare and greatly reduces whatever value you’re receiving from your maintenance agreement. And yet we keep doing it. Isn’t the definition of insanity the repetition of the same action, hoping for a different result?

There are better ways to preserve your unique business processes than by customizing your packaged apps. More on that in my next post. Google up “loose coupling” if you want a preview.

I have to run now…I think I smell a satellite dish cooking and I sure don’t want to miss out on that! In the meantime, comments are always welcome.

NOTE: I define "customizing" as any change to the out-of-the-box code of a packaged app; very different from extensions, tailoring, or personalizing.