One of the big announcements to come out of Oracle OpenWorld 2010 was the general availability timeframe (not, you'll note, a date) of the long-anticipated Fusion Applications ("coming soon, since 2006!"). The demogrounds were full of people test-driving Fusion Apps; there are tons of new features and a highly improved user experience. Now that we all know it's for real, it's time to ask for a new set of upgrade boots for Christmas, because when Q1 2011 arrives, it's going to be time to download the software, pore through the fresh, pixels-still-wet documentation, and plan for a transformative experience!
Yeah, okay, maybe not.
Whaddya mean, "maybe not?"
Please note: despite my tone above, Fusion Apps look pretty awesome, and really are a big deal. There's no doubt about that. But Oracle is definitely promoting a "dip your toes in the water, don't dive" approach to the implementation of Fusion. Why? Let's start with the obvious: Fusion Apps, despite all the love and care that went into its development, is version 1.0 software. It incorporates the best-of-breed features from all of the applications platforms; it's not a re-skin of E-Business Suite (or PeopleSoft, or JD Edwards) with Frankensteinian bolt-ons from other Applications products. As such, no matter how much testing is done, no matter how hard the early adopter customers beat on their 1.0 and pre-1.0 releases, there are going to be bugs. Possibly big ones, possibly small ones that turn out to be big for the way you do business. If you don't have a relatively strong need for particular features, or a high tolerance for the *ahem* thrilling rush of excitement that comes with the early-adopter experience, you might want to sit out version 1.0 and let the big dogs hammer out some of the still-to-be-discovered issues.
It may also be that version 1.0 of Fusion Apps doesn't cover all of the features that you need to run your business, or even have a corresponding module that maps to that small-but-critical applications product that keeps the lights on in your organization. This is one of the main drivers behind Oracle's "co-existence" strategy for its applications products. They want you to be able to implement pieces of Fusion Apps as it makes sense for your business, and not have to "leave behind" functionality that isn't quite ready yet on the new platform.
Those are two reasons that Fusion Apps may not be ready for you. It's also worth considering that you may not be ready for them. There are technology components in play in the Fusion Apps tech stack (Fusion middleware, or FMW) that are still relatively new on the scene, and it will take time to adjust to using them for reporting, development, business process modeling, and general systems maintenance and administration. If you're not currently using FMW components in your organization, it may make sense to start easing them into your infrastructure before also taking on Fusion Apps. A bit more on that below.
Planning for an "big-bang" upgrade or re-implementation?
If there isn't a one-to-one mapping of features between your current applications deployment, you aren't stuck. In fact, you probably shouldn't plan for a monolithic upgrade. As noted above, and in just about every piece that Oracle writes on the topic of Fusion Apps, it's possible, and generally recommended, to take an approach that results in Fusion Apps and your existing "Applications Unlimited" products existing side-by-side. For example, you could elect to upgrade Financials to Fusion Apps, and wait for Manufacturing components to mature to the point where you feel comfortable taking that upgrade (Note: That's just an example, not an implied judgement of the quality of either product suite. Remember, I'm an Apps DBA, and not particularly qualified to judge the maturity of products from a functional perspective). The impression that I got is that full one-shot moves to Fusion Apps, whether through re-implementation or upgrade, are going to be exceedingly rare.
There are downsides to this approach, of course. Without (or perhaps even in spite of) careful planning, a split configuration is all but guaranteed to involve a broader footprint of installed software: different middle-tier and database software installations, along with multiple databases, to support the deployment Applications Unlimited and Fusion Applications. Hat tip to Floyd Teter for pointing this out to me after one of his presentations, thereby confirming a nagging suspicion. This has implications for the size and complexity of test and development systems as well; I look forward to reviewing the inevitable white papers that address ways to ameliorate these architectural issues.
Fine, then, what do we do instead?
A major theme of the discussion around Fusion Apps at OpenWorld was "Upgrade, Adapt, Extend." Nadia Bendjedou's "10 Things you can do today to prepare for Fusion Applications" presentation goes through this in detail, but here are the high points:
Upgrade: not what you might think. This is "Upgrade" as in, "Upgrade to the latest release of your current Applications Unlimited platform"
Adapt: This was the meat of Nadia's "10 Things" talk, and elements were reinforced throughout other sessions I attended. The idea is that once you're on the most recent version of your current applications platform, you can take advantage of the various components that underpin Fusion Applications, before implementing Fusion Apps themselves. Examples include: BI Publisher, OBIEE, BPEL, SOA (everyone's favorite), WebCenter, Secure Enterprise Search, and UPK. Furthermore, "Adapt" includes taking advantage of new functionality in the more recent releases to eliminate customizations, or convert them to configurations that are more likely to survive an upgrade. The phrases "upgrade-safe" and "future-proof" were tossed around at the conference, but I try to maintain some level of healthy skepticism.
Extend: This doesn't imply extending applications functionality with external components, but rather extending your applications deployment into Fusion Applications. Find the areas of your business that are ready for and can benefit from Fusion, and take up those portions as it makes sense to do so. Ideally, this comes at a time after your DBAs and app server admins are familiar with supporting the FMW tech stack, your developers are up to speed on Jdeveloper and the latest development frameworks for Apps, you're managing your business process flows with BPEL instead of Workflow, and your business intelligence architects are cranking out BI Publisher reports and OBIEE dashboards like they've been doing it for years.
The big message, then, is: don't sit still. Get to the most recent version of your current applications system, get comfortable with the new functionality and technology components, see what problems they fix for you, and then start looking at Fusion for the problems that it doesn't fix.
What about EBS 11.5.10 customers?
Now that Fusion Apps are genuinely on the horizon, it may be tempting for E-Business Suite customers that are on 11.5.10 to try to ride out the extended and sustaining product support cycles, and make a big jump to Fusion once the dust settles a bit from the initial release. As implied above, though, monolithic upgrades aren't being encouraged, and there are benefits to getting on the more recent version of EBS (some of which I covered earlier). Oracle is strongly recommending that E-Business Suite 11.5.10 customer get to R12 as soon as they can. Furthermore, as Floyd Teter points out, Oracle is has committed to an upgrade path from 11.5.10 to version 1.0 of Fusion, but they haven't made a commitment for anything beyond that (second time I'm linking him in one post, but hey, Floyd's a smart dude. I listen to Floyd). We've already talked about the potential pain of a jump to 1.0. Do you want to inflict that level of change on your organization, from techstack to data model to end-user experience? Sounds like a recipe for massive levels of discontent to me.
So, bottom line: If you're an EBS 11.5.10 customer and thinking about jumping directly to Fusion Apps, rethink that strategy. You have more to gain by upgrading to R12, building organizational competencies with the more modern technical components, and taking up Fusion Apps as the benefit to your business becomes clear. Naturally, this advice also applies to Peoplesoft, JD Edwards, and Siebel customers; I'm just not up-to-date on the versions numbers in the lifecycles of those products.
But I really want to kick the tires on this stuff! I have pain! I think Fusion Apps is the cure!
Well, that's a topic for discussion between you and your Oracle reps; I'm just one blogger trying to synthesize notes from a week's worth of sessions and informal discussion. Obviously, Oracle has an Early Adopter program for Fusion Apps, if you think you're a viable candidate. I also learned that Oracle has "assessment workshop" teams: groups of functional experts that can come onsite to evaluate your fitness/readiness for Fusion Apps. I didn't scribble down the reference quickly enough, but I'll try to dig up a link and post it here.
Okay, I think I've repeated myself enough here. On to the next post!