Oracle Apps In Tough Times

Sorry about not posting over the past week or so, but I’ve had an idea percolating and taking shape in my head to the exclusion of all else. I think that idea has now taken on enough of a definite form that I can write about it…let’s see if that’s true.

Over the past few months, I’ve watched the cold winds of the global economic slowdown blow through the lives of people I care about and organizations with whom I do business. No need to review the gory details here, as most of the media provides better and more spectacular coverage than I could ever hope to achieve.

An important thing to keep in mind is that these economic doldrums will not last forever. Admittedly, I’m becoming a bit of an elderly member of the IT community. Outside of my own shop, most of the folks I come in contact with are much younger than me; too young to have been in the workforce and have memories of the downturns of the early and late 80s, although there is a segment that does remember the dot-com bust that took place earlier in this decade. So, for those of you so young that you’ve never been compelled to survive as a working adult during an economic slump, take it from one old enough to remember – this downturn will eventually come to an end, just like those before it. The trick is holding things together until the upturn develops.

The big question in my mind is, as an Oracle apps end user, how can I best help my own shop hold things together and maybe even prosper during this downturn even as my institution is reducing their investment in IT? I’ve come up with a few answers and thought that sharing those things might be helpful. Keep in mind I’ll be framing things in terms of the E-Business Suite; I’m not currently an end-user of Peoplesoft, JD Edwards, Siebel, or any of the myriad of other apps in the Oracle stable, so I don’t feel qualified to talk specifically in terms of those apps. However, the concepts I’m sharing here can be applied to any or all of those apps as well.

Batten Down The Hatches

When a storm approaches a ship, experienced sailors batten down the hatches. Organizations should consider doing the same with their enterprise applications when times get tough.

First, get to a stable, supported configuration and keep it current. Those of you on EBS 11.5.9 or less should get to 11.5.10.2. Getting there is not an extremely difficult or expensive task in most cases, although the difficulty may vary from organization to organization depending on your current version and the extent of your customizations. Those already on R12 should patch up to the latest version (the RUP for 12.0.6 is out as I write this, but later versions may be available as time passes). Ditto for the underlying techstack and database.

So what should you target for a somewhat stable configuration? From my worm’s-eye view, a stable configuration for the next 18-24 months looks to me like either 11.5.10.2 or the soon to be released 12.1 on the 11.1.0.6 database (and my totally speculative guess for the 12.1 release is sometime in the first quarter of calendar year 2009). Either seems like a good configuration for riding out the current economic storm.

BIG IMPORTANT UPDATE (March 31, 2009): Note that the 11.1.0.6 database will be desupported in October 2009; probably best to think about 11.1.0.7 instead. You can read more here.

Continue To Add Value By Using What You Have

Whether you’re on 11.5.10.2 or R12, you have elements of Fusion Middleware and other tools embedded in your techstack. Use those elements to add value for your organization.

One example is a situation I often see or hear about when working with Oracle apps customers. We often do a great job of leveraging the apps to process transactions. However, we frequently neglect to convert that transactional data into information that can be utilized to make informed business decision. Tools embedded in the E-Business Suite such as Publisher, analytics (whether it’s Daily Business Intelligence, Business Intelligence, Business Analytics, or however else the embedded analytics are branded these days) and Portal are all available to help summarize and share information. Many of us could add value simply by leveraging these tools to provide information to the decision-makers in our various organizations. This is low-hanging fruit – inexpensive, easy to implement, and a big value-add for managers throughout the enterprise.

Another example is the use of the Oracle Applications Framework (“OAF”). OAF is a great means for personalizing and extending the EBS user interface to meet the needs of business users. The big value add here comes from tailoring the user interface to work like the end users work, which in turn increases efficiency and productivity. Even if it’s just a small gain, in tough times every little bit helps. Again, this is low-handing fruit – EBS customers already have OAF, so it only makes sense to start using it.

Know Where You’re Going And Watch For Exceptional Opportunities To Get There

CAVEAT: your organization will need a solid cash position to implement the ideas in this section. If that’s not the case, focus on the ideas in the first two sections and let the ideas here pass until the cash flow improves. Hmmm, maybe you can leverage your apps in some way to help with that as a means of adding value…maybe by providing some info on cash flow through Publisher or some type of dashboard...just a thought.

As I wrote earlier in this post, in my humble opinion, this economic slump won’t last forever. You should know where you want to be headed as the economy turns for the better. So, the first recommendation here: have a roadmap. That roadmap should be based on the values that are important to your organization and a strategy for how Oracle apps and technology will be leveraged to support the achievement of those values.

Once you have that roadmap, you’ll likely discover there are some missing pieces to the puzzle – applications or technology components that you don’t currently have, but that you’ll need to get to where you want to go. Well, one of the silver linings to an economic down cycle is that it’s a buyer’s market. Demand drops because buyers are afraid to buy, worried that they’ll need that cash later on. To encourage those buyers to take the risk and make the purchase, sellers will offer reduced pricing and better terms – opportunities will likely arise to acquire those applications or technology components you need at much better prices and terms than you see today. So know what apps or technology you want to buy or obtain, keep an eye on those components, and bide your time until a great opportunity presents itself.

So, pretty simple ideas that took a long time to form up in my head…guess I’m not the quickest mind on the block (no big surprise there). So, what do you think? Find the comments and share what your organization is doing to leverage Oracle apps as times get tough.

Mile Markers On The Upgrade Path To R12

Even though my groovy "classic" iPhone has a great Google maps app, I have to admit that I still think in very old-school terms when I take a roadtrip...especially in the U.S. My father worked for the U.S. Geological Survey most of his working life, in the cartography division. As a result, I learned to read a map during my early elementary school years (my "final exam" including mapping out a route for a car trip from Minneapolis to South-Central Missouri when I was 8 years old - we actually took the trip based on my directions and arrived at the destination with time to spare). Whenever I travel by car, I still determine where I am by matching up reference points to the map: intersections, unique features, and especially highway mile markers.

As many Oracle E-Business customers are now seriously considering an upgrade to R12, I'm often asked about good references and resources available for planning an R12 upgrade. I have what I believe are a good set of mile markers for the trip to R12. I've been meaning to post something on the subject for some time now, and Steven Chan's recent post on a new best practices whitepaper for adopting R12 reignited this subject in my brain.

My list of basic reference materials and resources for an upgrade to R12 comes mostly from blog posts and discussion with Steven, John Stouffer, Brian Bent and many others. I've just consumed and consolidated some of the info developed by others. With that caveat, here are the references and resources I've found most valuable in planning upgrades from 11i to R12 (including where to find those references and resources for yourself):

• Best Practices for Adopting E-Business Suite Release 12 - Orace MetaLink Note 580299.1

• Oracle Applications Upgrade Guide: Release 11i to Release 12 - here

• Oracle E-Business Suite Upgrade Resources Roadmap - Metalink Note 461705.1

• Oracle Maintenance Wizard, which analyzes your 11i environment and produces a tailored 11i to R12 upgrade plan complete with detailed patching recommendations - Metalink Note 215527.1

• Security Best Practices for R12 - Metalink Note 403537.1

In the cases where information is contained in a MetaLink note, be aware that Oracle considers these notes to be "living documents" - you'll want to check them for changes on a regular basis.

So, that's my best shot on the subject. What about those of you who have recently upgrade or are building plans to do so? What reference docs and resources do you recommend?

ADDENDUM [6/16/08] : In my original post, I failed to point out that Steven Chan has also blogged on this subject. His post includes my mile markers plus a few extras. You can read Steven's thoughts on the matter here.

Rethinking R12 On The Road To Fusion

I spent some time over the holidays reviewing and reflecting on my notes and impressions from OpenWorld. One result of all this pondering is that I'm rethinking my plan of skipping EBS R12 and moving directly from 11i to Fusion Apps. My rethinking is due to the following considerations:

1) During the Fusion Council Panel at OOW, I thought I heard Steve Miranda specifically state that the initial integrated suite of Fusion Apps will not be a full-functionality replacement for EBS (or any other apps suite under the Applications Unlimited umbrella). My shop has a pretty compelling need move from 11i to something (preferably something relatively stable) by November 2010. As the IOUC's Debra Lilley astutely pointed out upon seeing my roadmap for JPL, there's no guarantee that Fusion Apps will be able to completely fill that need by that time.

2) I also got the impression (not necessarily entirely from Steve, so don't blame him for this one) that Fusion Apps would be rolled out incrementally and implemented incrementally (unless you're willing to wait until sometime around the end of the decade before taking on the move to Fusion Apps). An incremental approach would require integration with the applications that a customer already has in place. As an EBS customer, Occam's Razor ("All other things being equal, the simplest solution is the best") tells me that I'm better off integrating with R12 (which runs on the same Fusion Middleware that Fusion Apps will use) than with 11i (which does not run on a Fusion Middleware techstack).

3) That fact that Oracle Corp. itself is in the process of going live on R12 gives the new EBS suite much more traction and reliability from my perspective. Once Oracle begins to "eat their own dog food", I suspect many customers will begin the uptake of R12, which will in turn accelerate the maturity of that apps suite.

I'm not saying that all EBS users should upgrade to R12 before migrating to Fusion Apps. In fact, I'm not even saying that all EBS users should migrate to either R12 or Fusion Apps at all...at least, not in the near future. Each customer will need to make those decisions based on the needs and constraints of their specific enterprise. What I am saying is that, now that I have a better feel for the scope of the initial release of an integrated Fusion Apps Suite, it probably makes sense for my shop to move to R12 and use it as the jump-off point for a subsequent migration to Fusion Apps...after giving Fusion Apps some time to mature.

So, I'm working up a new version of JPL's Roadmap to Fusion Apps based on the recent things I've learned and these thoughts I've had about the things I've learned. This is what an iterative (or incremental or iterative) approach is all about: you plan based on what you know, you learn more, then you tweak the plan for accomodate what you've learned, then you lear more, then you... well, you get the idea. Once I have a new version of the Roadmap worked up, I'll post it here and look for comments from ya'all.

Final Thoughts On The Fusion Roadmap

A few final thoughts to share as we wrap up Roadmap series of articles...

• Getting to Fusion Applications will require a mastery of Fusion Middleware. Although the apps won't be out until 2008, you may want to get started with the middleware right now. In fact, I can't think of a better way to get started than attending OAUG's Oracle Fusion Middleware Boot Camp.
  

• There is a high degree of complexity as well as quite a few interrelated "moving parts" in Oracle Fusion architecture...lots of orchestration and integration required. Customizations will only make things even more complex. Rather than going for a highly complex, highly customized "Mouse Trap" architecture, consider replacing your customizations with vanilla functionality now.
  

• Migrating from sunsetting technology is a recurring theme. We're seeing the decommission of some technology we've come to know and rely on: mod_plsql, Oracle Reports, and Oracle Workflow are all examples. Migrating to the replacement technologies without impacting your enterprise operations is a huge concern.
  

• Moving to Fusion Applications promises to be a big effort with substantial technical underpinnings: it's a whale sandwich. The best way to eat a whale sandwich is one bite at a time. Ditto for Fusion Applications - take it a little at a time using an incremental and iterative approach rather than attempting to make the entire change at once.
  

• Oracle's journey to Fusion Middleware and Fusion Applications continues to be an evolutionary journey; as they learn more, things change. The same holds true with what I've written here...everything is likely to change. I've just shared what I think I know right now. Any errors, omissions, poor predictions or misinformation are my fault alone.
  

• The journey will be a little different for each enterprise. My roadmap is not necessarily a good roadmap for you. My intent in sharing my roadmap in the hopes that doing so will start a discussion and perhaps prompt others to begin their own planning, which is the reason I shared pictures rather than writing lots of words. Hopefully, you've seen or read something that will help you get started.

• [UPDATED Sept. 14 2007] The Roadmap closely follows the guidelines laid out by Dr. Nadia Bendjedou in her presentation "10 Things You Can Do Now To Prepare for Fusion Applications". You may want to review her presentation as a starting point for building your own roadmap. You can find that presentation here.
  

Well, developing this roadmap was an ordeal...what a long, strange trip it's been. Now that I've shared it with all of you, I look forward to hearing your feedback and your own plans for moving ahead.

The Lifecycle Management Layer

So, here we go now with (hold down the applause) the last layer of the Roadmap! Yup, we've finally worked our way through to the Lifecycle Management layer.

The scope of the Lifecycle Management layer is pretty significant. It includes operational components to keep your Fusion environment running in top shape, such as Performance Management, Business Activity Monitoring, the Oracle Applications Manager and the Configuration Support Manager. It also includes other components such as the Implementation Workbench. In my own shop, we'll also need to consider our plan for moving to some type of distributed computing structure (RAC, Grid, etc.). We also have some aging Sun big iron that will need replacing. In short, there's a lot here. Open up the jpeg and take a look for yourself - quite a few tasks dealing with several highly complex issues. Rather than go through them all here, just take take away this single point: please don't ignore or neglect this area when planning your own path to Fusion Applications.

NEXT UP: Some Final Thoughts On The Roadmap

The Development Layer

Sorry about the time lag in posting this next article in the Roadmap series. I've been hit recently with a double whammy: a few days of jury duty immediately followed by an electricity outage that's now lasted for several days. In fact, I'm actually writing this article during the blackout and hoping to post once Southern California Edison pull things together again...gives me something constructive to do while I'm Dancing in the Dark.

In building the roadmap for the Development layer of the Roadmap, three important considerations heavily influenced the final product:

• Oracle's development tools continue to expand and evolve rapidly. In fact, much too rapidly for me to keep up with most of it. This is where I rely most heavily on the buzz from the Oracle user community. This space is just too large and changes too quickly for me to do hands-on testing and form first-hand opinions on all the various development tools.
  

• The development layer is closely tied to certain components in Fusion Middleware. For example, changes in JDeveloper seem to be driven by evolution in industry standards and revisions to OC4J; the latter is really a middleware infrastructure component. As another example, although Oracle is certainly publicizing the hot-pluggable functionality in Fusion Middleware, I suspect the hot-pluggable concept may be a more complex proposition with the addition of ERP or CRM applications. So my goal is to stick with Oracle components in any architecture utilizing Oracle applications until I see more evidence supporting hot-pluggable in this type of environment.
  

• As is true throughout the Roadmap, migration from sunsetting to newer technologies is a concern. Most specifically, the sunsetting of OAF and Oracle Forms and Reports are big concerns here.

NEXT UP: The Lifecycle Management Layer

The Unified Data Access Layer

My thoughts on the Unified Data Access layer are fairly brief, not because it's a subject without much depth, but because I don't feel like an expert in the fields of security and data access. With that being said, the vision I personally have is the idea of a single site for securely accessing all available Oracle applications and data (including any custom apps). The following four initiatives are critical for us at JPL.

My shop is currently working an initiative to implement Transparent Data Encryption (TDE) in the E-Business environment. Our consideration moving forward will be how well TDE integrates with Fusion architecture.

Oracle Single Sign-On and Oracle Internet Directory are two closely-related products, both of which are important integration points between the Oracle Applications Server and the 11i E-Business Suite. At JPL, we'll probably be relying on the functionality of both these products as we incrementally move to Fusion architecture. It will be important for us to know how well both these products work with Fusion Middleware and Fusion Applications.

Finally, the presentation framework for the user interface will be Web Center. So, just as I pointed out in the earlier post on the BI and Reporting layer, learning the intricacies of Web Center will be important to us.

NEXT UP: The Development Layer

The BI and Reporting Layer

In talking about the Business Intelligence & Reporting layer of the future state architecture, it's important to keep in mind that we're dealing with another component of Fusion Middleware. Although the E-Business Suite now comes out of the box with a limited version of XML Publisher, we talking here about a wider scope. That scope includes both driving both business intelligence and reporting with the data contained in the Data Repository layer of this architecture. In my shop, that means BI Publisher will be used to work with data sources that include the various Oracle and non-Oracle "data stovepipes" throughout JPL.

Moving from Oracle Reports (as well as our own custom reports) is not a trivial migration effort for my shop. I understand that Oracle has a tool in the works to help with that migration. Can't wait to see it.

The variety in technology stacks for those same data stovepipes also push my shop toward the more database-agnostic Oracle Business Intelligence Enterprise Edition product over Oracle Standard. In implementing OBI EE, we'll also have to consider how to best leverage Oracle Discoverer with Oracle Answers (one over the other v. using both). In our case, I suspect we'll eventually go exclusively with Oracle Answers. However, your stituation and your final answer could be different.

Finally, there is the impact of Web Center on the BI layer. As we provide user dashboards and similar products, I expect Web Center to improve the user experience through Web 2.0 features. So Web Center becomes a driver in this layer of the architecture as well as in some others.

NEXT UP: Unified Data Access

The Process and Integration Layer

We're continuing the Roadmap series of articles with the Process and Integration layer. Keeping in mind that a picture is worth a thousand words, I'll let my roadmap picture speak for itself and refrain from writing too much here.

We're also jumping back into the slipstream of Oracle recommendations. Keep in mind that much of this layer is actually driven by application server components but, from a conceptual standpoint, it helps to separate this area into a distinct layer.

The main considerations here are the use of the Oracle Business Process Analysis (BPA) Suite for the functional design of business process and the use of Oracle BPEL Process Manager, both components of Fusion Middleware, to coordinate the various services that make up those business process. Migrating from Oracle Workflow to BPEL and stepping up from Portal to Web Center are also part of our plan, as you can see from the jpeg image of the roadmap for this layer.

Next Up: The Business Intelligence Layer

The Data Repository Layer

In charting our shop's path to Fusion Applications, the plan for the Data Repository layer probably represents the most radical break with Oracle's overall direction. The Oracle product targeted for this layer is Master Data Management ("MDM"), formerly known as Data Hubs. However, we already have a data warehouse in our shop - I'm not sure MDM buys us much additional value.

Don't get me wrong: I like the concept of MDM. Centralizing all my data from all my data sources in a single, standardized repository used to drive all my reporting and business intelligence is a great concept. It not only makes my reporting and business intelligence consistent (I'll get the same answer to the same question, regardless of who asks, it can also help improve the performance of my transactional database.

The cause of my departure from Oracle's overall direction is really pretty simple: at JPL, I think we've already built our data repository in the form of a data warehouse. Our data warehouse centralizes and standardizes data from multiple data sources, and it drives our reporting and business intelligence. So, at the moment, I'm not too sure what additional value I'll get from MDM.

As you review the roadmap for this layer of the architecture, you'll see that I do have an initiative planned to compare our data warehouse with MDM. If MDM adds additional value, we should find it as part of that initiative. It may turn out that we do need to replace our data warehouse with MDM. It may also be that MDM and our data warehouse compliment each other, so we'll need both. There is also the challenge of integrating our data warehouse with the other components and architectural layers - it may be a fairly complex and expensive challenge.

As always, your situation and decisions may play out differently. I would strongly encourage you to become familiar with MDM before deciding if to use the product or how to use the product.

Note that I've also included an initiative to investigate the Oracle Common Object model. As Oracle develops standard enterprise business objects, those objects will appear through Oracle's ERP and CRM products. We'll need to track this development and possibly emulate those objects in our data repository in order to integrate well with the Oracle reporting and business intelligence tools.

NEXT UP: The Process Integration Layer

The Applications Layer

So let's talk about the layer of the roadmap that, as a former business systems analyst, is near and dear to my heart: the applications layer. This is also where I diverge a bit from Oracle's recommendations for moving forward, due to the needs of my specific enterprise. That divergence consists of choices regarding which version of the E-Business Suite will provide our "jumping off point" for Fusion Applications and the timing of that jump.

In examining the new functionality Release 12, JPL has not uncovered substantial value for our business end users. It's not that we don't like R12 - the SWAN user interface and the chance to run on Fusion Middleware are both pretty appealing. It's just that, in our particular business environment, R12 does not seem to give us much value over 11.5.10.2. So, we've decided to leverage Oracle's "Lifetime Support" to sticking with 11i until we jump off to Fusion Applications (both 11.5.10 and R12 are certified "jump off points" for migrating to Fusion Applications).

The next divergence from Oracle's recommendations is based on our historical experience: we don't want to be first...nor anywhere near the "bleeding edge". When 11i became generally available, JPL was among the first Oracle customers to implement the new version into our production environment. Unfortunately, the early versions of 11i were just not "ready for prime time"...at least not in JPL's environment. It was not a fun experience, especially when our users began planning to hang IT managers in effigy...okay, it wasn't quite that bad, but the relations with our internal customers did get a bit "frosty." As we've talked with our internal customers about our plans to migrate to Fusion Applications, they've asked us to exercise some caution about migrating too early in the product lifecycle. We intend to listen to the concerns of those customers. So, as you examine the roadmap, you'll see that we don't plan move to Fusion Applications in our production environment until about two years after the first planned release of an integrated Fusion Applications suite in 2008. In the meantime, we plan to begin our evolution to Fusion by implementing Fusion Middleware and utilize that technology with the 11i E-Business Suite in an Oracle-supported configuration.

So, now that we've covered the strategy, let's briefly cover the three intitiatives needed at JPL to support a successful move to Fusion Applications:

• Catalog/Reduce/Plan Migration - Customizations: JPL has developed some significant customizations to the E-Business Suite (and I suspect we're not alone in this regard). We need to catalog our customizations, eliminate customizatons with newer "vanilla" functionality where possible, and plan for the migration of those customizations that cannot be replaced.
  

• 11i Functionality Mapping and Implementation: We'll be making one last pass at discovering functionality newly provided by 11i, mapping that functionality to our business processes, and implementing that functionality where it adds value to our business. In other words, let's take one more look at 11i functionality to be sure that we're maximizing the value of what we already own. The idea here is to make our baseline environment for the migration to Fusion Applications as feature-rich and valuable as possible.
  

• Fusion Applications Mapping and Implementation: As we learn more about the functionality in Fusion Applications, we'll map that functionality to our business processes, identify any gains and gaps, then build a plan for filling the gaps.
  

NEXT UP: The Data Repository Layer

The Applications Server Layer

In talking about the Application Server layer of the architecture, we're really talking about the components that support running the enteprise applications. Much in the same way that the apps server shipping with R12 is not really the full-featured Fusion Middleware server, the portion of the apps server we're discussing here consists only of those components needed to support the enterprise applications themselves. The additional features will be covered in future roadmap-related posts.

The initiatives needed to support JPL's migration in this area really emphasize sunsetting Oracle E-Business technology components and their replacements:

• Oracle Reports -> XML or BI Publisher

• Oracle Workflow -> BPEL Orchestration

• Portal -> Oracle Web Center

• Servlet Engine -> OC4J
  

• Jinitiator -> Native Sun J2SE 1.5 (5.0) Plug-In (this is really not an apps server issue, but it's so closely related to the apps server that I thought it deserved consideration here)

NEXT UP: The Applications Layer

The Database Layer

Let's start by taking a moment to discuss the format of this picture. You'll see that the timeline runs across the top of the page, by quarter, from 2007 through 2011. On the left side, you'll see two sections: the upper section lists the various versions of the technology component (in this case, the Oracle database) that we'll likely deploy over a 5-year period. The lower section lists the technology initiatives that we'll need to execute in order to implement those technology components. The color code is translated in the Legend found in the lowest portion of the picture: Blue is time spent investigating and implementing, Green represents the deployment period, Yellow is the time transitioning into decommission, and Red represents out of service. I'll follow this format throughout this series of articles for all layers of the roadmap.

In this first layer of the roadmap, we're talking about the transactional database that supports the enterprise applications - the layer dealing with the master data repository will come later. In developing a roadmap for this layer of the future-state logical architecture, I considered the following points:

• The timing of various Oracle product releases. I don't have an inside track on the timinng and Oracle's not talking much about future release dates these days, so I took my best guess.
  

• The timing of certifying various Oracle database releases for the E-Business Suite. Again, my best guess.
  

• JPL's NBS currently runs, for the most part, on big iron. We'll need to migrate to at least a RAC configuration, if not a full-up grid.
  

• I assumed going that our future operating system will be either Solaris or Linux. We're currently on Solaris, but we're looking at Linux.
  

• We'll need to deal with sunsetting technology. The demise of mod plsql and Oracle Workflow are significant for JPL. I planned around the elimination of mod plsql in E-Business R12 and the termination of Oracle Workflow in the apps environment after R12 (yes, I know that the 11g database does not support the Workflow engine. However, there is an exception for E-Business customers).

So, after all that, the picture above is a pretty good representation of our plan regarding the transactional database in our move to Fusion Applications.

NEXT UP: The Applications Server Layer

Before You Dive In

As a child, my mother made me consider several things before I was allowed to dive into the swimming pool: did I eat within the last hour, where are the lifeguards, who are you swimming with, and so on. Before we dive into the details of the roadmap, there are a few things to consider:

1) We are sailing on a sea of change. Technology components such as Portal, Workflow and mod pl/sql are desupported, upgraded, or otherwise changed very quickly. The rate of change is so great that portions of this roadmap will likely be obsolete shortly after posting. You need to stay current.

2) Much of my timing is speculative. Although I won't include my best guesses for release dates of Oracle products in this series of articles, it's fairly obvious that much of the timing in this roadmap is based on those release dates. If I'm right, lucky me! If I'm wrong, then the timing of some elements could change. Wish I could offer more comfort but, frankly, that's just the nature of the business these days.

3) This is a proposed roadmap for my shop. It's built around the issues, concerns and needs of my enterprise. Although I'm sharing this information in the hopes that it will help others, your optimum roadmap (should you decide to pursue this path) will likely be very different.

With all that being said, let's get to the details...

NEXT UP: The Database Layer Roadmap

Architecture Drives The Roadmap

Your future state architecture really drives the roadmap to Fusion Applications. Gardner McKay once said "If you don't know where you're headed, how will you know when you get there?" A future state architecture is simply a depiction of where you're headed.

The picture above depicts the logical future state architecture JPL's New Business Systems' ("NBS") implementation of Fusion Applications. For clarification, NBS currently consists of the Oracle E-Business Applications used at JPL plus a number of custom applications. In our future state, the E-Business Applications will be replaced by Fusion Applications. This may not be how things finally work out, but it's my best attempt based on the information I have today.

Take a minute to consider the picture. One point should be readily apparent: this is pretty complex stuff we're dealing with, if only because the architecture consists of many layers. Each of those layers has many "moving parts".

One of the significant purposes in depicting an architecture is to share ideas with others. In sharing complex messages, it's my opinion (and just my opinion) that complex messages are best communicated by breaking the architecture down into digestible chunks. So, in order to get the message across to my audience, I've broken down the roadmap effort into layers - in essence, I've created a roadmap for each architectural layer depicted above. That layer-by-layer roadmap is what we'll be diving into for most of the remainder of this series.

NEXT UP: Before You Dive In...

Detailed Roadmap to Fusion Applications - Intro

I often hear complaints from Oracle Application customers about the difficult of strategic IT planning in the face of an absolute dearth of available information on Fusion Applications. I’ve written previously about the balance Oracle must strike between sharing and withholding information, so I don’t plan to rehash that subject here. What I do hope to do here, through a series of “deep dive” articles”, is share what I consider to be a pretty good and detailed roadmap from my own shop that may serve as an example to help you in your own roadmap planning. This post is the first in that series.

Caveats

Some caveats to keep in mind for this series of articles:

1. Your organization is very different from mine. Your needs, considerations, planning and results may vary.
2. Any representation or speculation made is strictly my own opinion, which does not represent the opinion of the Jet Propulsion Laboratory or Oracle in any way.
3. I am the father of seven children, so I have no money...suing me would be a huge waste of your time and effort.
   

Background

JPL’s ERP system is currently running on version 11.5.10.2 of the Oracle E-Business Suite. We’ve implemented Financials (with the exceptions of Receivables and Fixed Assets), Project Accounting, Payroll, HRMS, Purchasing, iProcurement, and Discrete Manufacturing.

Some Assumptions

Some major assumptions in building JPL’s roadmap to Fusion Applications are:

• Applications Unlimited won’t last forever - it's likely that all Oracle Applications customers may have to move to Fusion Applications at some future time.
  
• Oracle will continue to support EBS 11i as a “jump off point” for migration directly to the first two or three releases of Fusion Applications.
• The “Five Years Plus Forever” approach of the Unlimited Support program will continue through at least 2015.

Why Fusion Applications?

In past articles, I’ve written about the need of each Oracle customer to determine their technology needs based on their business needs. At JPL, we’re planning to migrate from EBS to the Fusion Applications for three business-based reasons:

1) Integration and Orchestration: we have many internal customers and partners that utilize different technology stacks: PHP + MySQL, .Net, and Cold Fusion + SQL Server are some examples. We also have compelling needs to integrate the various data repositories and to orchestrate business processes across these multiple technology stacks. The Fusion Applications hold the promise of loose coupling through standards-based integration, which will ease the integration and orchestration of business processes across various technology stacks and data repositories.

2) Flexible User Interface: we’re often faced with customer requirements for user interfaces that go far beyond the capabilities of OAF and the E-Business Suite. The Fusion Applications, which will allegedly utilize ADF, will allow us a greater trade space for tailoring our UI before crossing into the dark and dangerous world of unsupported customizations.

3) Better Conceptual Fit: at JPL, we manage our enterprise in terms of business processes. At its core, EBS is organized around vertical application modules: HR, PA, GL, and so on. Fusion Applications will be organized around business processes: Procure-to-Pay, Hire-to-Terminate, etc. Fusion Applications seem be a better conceptual fit for the process-oriented way we think about and manage our enterprise.

Migrating Directly From 11i To Fusion Apps

At JPL, we have yet to identify a significant business benefit from moving to R12 (again, you may decide otherwise because your business is different from ours) – so our plan at the moment is to stick with 11i until we migrate to Fusion Applications (more details later on how we’ll do this). However, if we learn something in the future that causes us to reconsider, “Plan B” is to upgrade to R12 on Fusion Middleware. This backup plan will at least allow us to achieve the integration and orchestration benefits.

NEXT UP: Architecture Drives The Roadmap