"What preparations should my company make in preparing for Fusion Applications?" In my role with OAUG’s Fusion Council, I’ve been on the receiving end of this question several times over the past few months. After repeating my answer on several occasions, I thought it best to put it in writing.
First, recognize the scope of the change. The scope of the change is a move to Service-Oriented Architecture ("SOA")…or least each Oracle’s version of SOA. The move to SOA requires a significant conceptual shift. You can find a brief primer on the concepts here. Although I won’t push the issue here, the real question may be "What preparations should my company make in preparing to adopt SOA-based ERP applications?"
Having prefaced my comments, this is my "laundry list" for preparing for Fusion Applications:
1) Break down your business architecture based on high-level requirements. In simple terms, at least be able to address the writer’s best friends (who, what, when, where, why and how) for all aspects of your business.
2) Identify your choices and prepare a plan for each choice. Are Fusion Applications and E-Business 12 competing or complimentary choices for your organization? What about the PeopleSoft HR apps you’ve already integrated with the E-Business Financials? Could you stick with Siebel? In order to make the optimum choice for your organization, you should know each of your viable options and create a high-level plan for implementing each option.
3) Develop skills in Business Activity Monitoring ("BAM"), Business Process Execution Language ("BPEL"), data hubs, integrated analytics, portals, SOA concepts and web services. All of these technologies will be important components of the Fusion Applications environment.
4) Install Oracle Fusion Middleware and become familiar with it. Many of the components mentioned in item 3 are already available for use with Fusion Middleware. What better way to learn more about them than by working with Fusion Middleware?
5) Begin to consolidate your data respositories. The concept of a "Single Source of Truth" is at the heart of the Fusion Applications architecture. Consolidating your data respositories will be a significant step on the road to realizing that concept.
6) Identify customizations and begin to eliminate them. Customizations will very likely add to the complexity and cost of any upgrade or migration to Fusion Applications. Decommissioning those customizations beforehand will allow you to avoid those burdens.
First, recognize the scope of the change. The scope of the change is a move to Service-Oriented Architecture ("SOA")…or least each Oracle’s version of SOA. The move to SOA requires a significant conceptual shift. You can find a brief primer on the concepts here. Although I won’t push the issue here, the real question may be "What preparations should my company make in preparing to adopt SOA-based ERP applications?"
Having prefaced my comments, this is my "laundry list" for preparing for Fusion Applications:
1) Break down your business architecture based on high-level requirements. In simple terms, at least be able to address the writer’s best friends (who, what, when, where, why and how) for all aspects of your business.
2) Identify your choices and prepare a plan for each choice. Are Fusion Applications and E-Business 12 competing or complimentary choices for your organization? What about the PeopleSoft HR apps you’ve already integrated with the E-Business Financials? Could you stick with Siebel? In order to make the optimum choice for your organization, you should know each of your viable options and create a high-level plan for implementing each option.
3) Develop skills in Business Activity Monitoring ("BAM"), Business Process Execution Language ("BPEL"), data hubs, integrated analytics, portals, SOA concepts and web services. All of these technologies will be important components of the Fusion Applications environment.
4) Install Oracle Fusion Middleware and become familiar with it. Many of the components mentioned in item 3 are already available for use with Fusion Middleware. What better way to learn more about them than by working with Fusion Middleware?
5) Begin to consolidate your data respositories. The concept of a "Single Source of Truth" is at the heart of the Fusion Applications architecture. Consolidating your data respositories will be a significant step on the road to realizing that concept.
6) Identify customizations and begin to eliminate them. Customizations will very likely add to the complexity and cost of any upgrade or migration to Fusion Applications. Decommissioning those customizations beforehand will allow you to avoid those burdens.
No comments:
Post a Comment