Short Fuse Stuff

This has nothing to do with the Roadmap series of articles. It really has to do with my experience watch Warner Brothers' Road Runner cartoons. Loved 'em as a kid and still love 'em now. In each of those cartoons, there is at least one instance of the Coyote attempting to knock off the Road Runner with some sort of bomb...and, in each case, the bomb's fuse is too short. The bomb explodes before the Coyote can throw or lauch the bomb. The Coyote gets nailed by the bomb...and I laugh until I hurt. The Coyote's problem here is that he never moves quickly enough to compensate for the short fuse. As for me, I've learned that when I encounter short fuse stuff in life, it's time to move quickly.

Much as I'd like to finish with the Roadmap before posting other articles, I have some short fuse stuff for share. There are some breaking events that I really should share with you right now - waiting until later will detract from the value of the information. So, without further delay, let's deal with the "short fuse" stuff before it blows up on me:

• OAUG is sponsoring a Fusion Middleware Boot Camp, with the intent of training developers and other technical types on basic Fusion Middleware skills (web services, XML, BPEL, BI Publisher). The bootcamp will take place October 22 through November 2 at the Oracle Education Center in Chicago, Illinois. You can learn more here. If you plan to attend, get registered - the seats are limited and filling up fast!
  

• Both OAUG and IOUG have put out their call for presentations for the Collaborate 08 conference. The conference will take place April 13 through 17, 2008 in Denver, Colorado. Note that both calls are asking for papers focusing on specific subject areas, and that the focus areas are different for each organization. The deadline in OAUG's call is October 28th. Although I don't see a date in the IOUG call, I would guess that their deadline is similar. You can learn more about the OAUG call here and about the IOUG call here.
  

• Oracle has rolled out the Oracle Innovation Award to honor companies "...already using Oracle Fusion Middleware to extend the business value of Oracle applications in innovative, exciting ways." The top 25 winners will each receive one conference pass to Oracle OpenWorld 2007 as well as a one-on-one conversation with an Oracle executive at an awards reception during the conference. Top 5 winners each receive one Oracle OpenWorld conference pass with a Club Oracle Gold Ugrade, inclusion in a feature article for Profit magazine, and an exclusive appearance on an Oracle Appcast with Cliff Godwin (I recently participated in one of these podcasts myself - a great experience. I hope I get to do it again). Nominations are now open with a deadline of October 5th, 2007. You can learn more about the Oracle Innovation Award here. So, if you've done something innovative with a component of Fusion Middleware and the Oracle applications, there may some benefits to sharing your story.
  

That clears the decks on all the short fuse stuff for now. Back to the Roadmap...

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