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.
Wednesday, June 25, 2008
Tuesday, June 24, 2008
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
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
Subscribe to:
Posts (Atom)
Posts
