Oracle & BEA Middleware "FUSION" Strategy

I have been eagerly waiting for this events for past couple of weeks. With no doubt the strategy set forth by Oracle is good for both Oracle and BEA customers.

Oracle has categorized the Fusion Middleware into three categories. Strategic, Continue & Converge and Maintanence Products as presented by Mr.Kurian.

Strategic: Some of the BEA products are being adopted immediately with limited re-design into Oracle Fusion Middleware. Few Oracle products converge with BEA products with rapid integration over 12-18 months

Continue & Converge: BEA products will be incrementally redesigned to gradually integrate with fusion middleware technology to broaden the features with automated upgrade.Oracle will invest to continuely develop and maintain these products for atleast 9 more years

Maintanence: BEA products that were EOL'd before acquisition will be maintanined under the same contract for 5 more years

Now coming into the details of the product offerings and strategy as outlined by Thomas Kurian. Product strategy in SOA area is to unify Aqualogic Service Bus and Oracle ESB and in complex event processor Weblogic event server will be merged. BEA WL-Integration will continue to evolve with common services & techonology with BPEL process manager

In the Development tools arena Oracle Eclipse Pack is added into Fussion Middleware pack with no additional licensing costs. The idea is to package BEA Workshop along with Eclipse Pack. Oracle JDeveloper will continue to evolve as Strategic product along with ADF.

Most complex merger of products is in the BPM arena, integrating BEA AL-BPM with Oracle BPEL PM to form Oracle BPM. Both Oracle BPA designer and AL-BPM designer will co-exist as strategic products. As oracle BPA is intended to be used for more structured and rigourous process modelling, where as AL-BPM designer will be used for iterative process modeling

Most significant direction is the BEA Weblogic named as the strategic Application Server going forward.

Does SOA need Paradigm Shift??

The need for a paradigm shift for embracing SOA within an organization is a lingering question. Certainly, many architects feel the pain of the IT organization when getting them to think on a more service based approach. Some experts feel there is no need for the shift, just a need for adoption of the technology. As many may have experienced, even good technologies can fail when used in the wrong hands.

Although the concept is not new, there certainly needs to be an improvement or shift in thought processes for successful implementations. A good example is building web services (SOA is not just about web services) in a more point to point fashion. Having multiple versions of web services for the same interaction will lead to high TCO and maintenance headache. There is a definite need for governance to maintain the norm in any implementation. Therefore, there needs to be some shift in thought process at different levels of the IT organization.

Oracle eBusiness suite & SOA

The lingering question for most Oracle ERP clients is how to approach SOA. Should interim activity precede upgrading to 12i or fusion apps? Certainly there is a paradigm shift from traditional oracle technologies and point to point integrations to SOA.

1. Educate: Make sure your IT organization understands the concepts of SOA and what it means to their development cycle. They should also understand tech stack and resource pool before jumping into a solution

2. Road map: Prepare a road map on different stages of implementation required to achieve the end goal. You certainly need to look at the ROI before jumping further

3. Start Small: Take one key business process and highly utilized transaction and build web services and integrations for that process. Monitor and optimize your SDLC processes and architecture based on your findings. Refine your approach to integrations before jumping to next level. Tip: Build internal IT skill sets as you progress through these steps. This also applies to building good support processes

4. Remediation: First of all you need an inventory of all existing applications and integrations. Many companies lack this!!! Analyze the current integrations and remediate low hanging integrations with quick turnaround. Doing this should result in business benefits and justifications for moving away from current technologies (Ex: Support cost, re-usability etc.) Note: Make sure the web services you are building are not designed to meet the current business needs but, rather, build with future anticipation

5. Complex & Critical: Now you are ready to take on the much bigger tasks of tackling the most critical and complex integrations that might need orchestration. By the time you start this stage you should have established development & support processes and a resource pool. I have certainly seen companies struggle by stepping into this stage before the technology has had a chance to mature in the organization