Discuss business intelligence, integration, compliance and a host of other SAP-related topics – implementation, best practices and resources to negotiate the world of SAP better!

« Decision making for managed services engagement | Main | BO and BIA Combo - How does that look like ? »

Arrival of SOA-based Composites: What makes sense – Reuse or Replace enterprise applications?

Continuing from my previous blog post….”Composite applications and the 3 "R's" of your "Green" SAP” ; http://www.infosysblogs.com/sap/2008/12/composite_applications_and_the.html#comments

CIO in many organizations is struggling with the fact that over the years IT application landscape grew in a heterogeneous manner where individual division cherry picked applications to meet their division specific requirements. Further, a lot of custom application development also took place on platforms that are outdated now. Business divisions are also looking at newer capabilities from IT application for web support, better process control and visibility into important business events early on to become more proactive. Further, business divisions expect IT capabilities to support quick expansion into newer markets and customers.

CIO faces dilemma whether to modernize by replacing what they have or by reusing them in newer and innovative ways. Replacement has its own set of difficulties related to unearthing the business logics coded into custom developed applications, risk of broken interfaces, higher IT budgets requirement as modern IT applications need modern hardware as well. This situation further gets complicated where 50 to 60% of the business is supported by ERP applications and rest is supported by heterogeneous applications. Any upgrade of one application can throw the whole landscape unstable. For example, latest ERP application is Unicode compliant and if other legacy applications are not then this will lead to broken integration. So modernization brings its own set of non-negotiable architectural requirements. On the other hand, latest ERP can fulfill all the business process requirements that were not supported by previous releases of ERP application. Hence there is also a chance for the organization to bring standardization and get rid of heterogeneous landscape. But it is left to any body’s guess and it is not future proof.

Reuse on the other hand has its own set of challenges related to building and supporting newer business requirements under the constraints of older application infrastructure. However, recent advancement in Web Application server (WAS) platform has made it possible to bring live newer business processes through reuse of existing application landscape without any need for replacement. Composition environment supportedby WAS goes further to even help organizations in building their own custom application. Service enablement of legacy applications allow them to getting reused in newer business process scenarios. The workflow created using Composition environment can integrate any system from like R3, web service(third party ) and other software(.net, oracle or  other home grown) with in the organization. This provides flexibility to organizations to meet division specific requirements at low time to market today as well t’row. But then it can take organization away from standardization of business process and IT landscape.

It would be interesting to hear your thoughts on this.

TrackBack

TrackBack URL for this entry:
http://www.infosysblogs.com/apps/mt-tb.cgi/2707

Comments

Reuse Vs FireFight:

Reuse in IT has been a term which is spoken at the launch of every new technology wave. It's difficult to get a true assessment of reuse. Today, one of the main features of SOA and composite applications are based on reuse. But in most of the models where projects are conceived normally business are keen to deliver something quickly in a time bound manner. If we look at all the models of project delivery whenever given a option to a project team to reuse existing things or develop new things somehow developing new components are always preferred. The reasons are not very difficult to understand. Project teams are independent and willing to quickly deliver production ready solutions and then it's much more easy to do that if they don't have to touch any other existing applications (which would also imply organizational interaction). This would happen in almost all projects unless there is an incentive for project teams to reuse. If the same project team is involved in delivery of all IT solutions may be as a good architectural practice they may try to reuse. But who has heard of project teams imposing metrics upon themselves where reuse is one performance indicator. We would like to wait and watch to see how composite applications deliver what it proposes.

One of the important aspects of reuse in case of composites is related to the fact that you are not required to abandon your legacy applications. These legacy applications can be exposed as web service for them to be reused in composites. This has been successfully demonstrated in many projects. It is highly likely that the two projects consuming existing application functionalities have requirements that are mutually exclusive. Let's take a case where a document management system is providing following functionalities - uploading the document, searching the document and downloading the document. One project needs only the upload function and the other project needed download function. So even if both the projects are using different function, legacy application is reused.

Take another case of order fulfillment process supported by SAP ERP. Two different business divisions of the same company have different business process. One division is involved in selling and delivery of services. Second division is involved in selling and delivery of tools and hence needs more elaborate inventory management functions. However, both the divisions have common requirements for functions related to inquiry , quotation and sales order creation and these SAP ERP functions are reused across these two projects.

It is important to differentiate the application and the functions that the application provides. Reuse will happen at function level and it is important that a central registry - service registry or function module listing is maintained that project teams can query to get the appropriate application function for their project.


Further the main idea behind composites is to provide a business process orchestration and the core functionalities are provided by reuse of functions of already existing applications. Besides, reuse in the context of composites has multiple dimensions:
* Reuse of existing application's functions (already discussed above)
* Reuse of webDynpro applications providing search and other common utilities such as message manager, mail manager, download manager etc. that can take upto 10-20% of development & testing team time
* Reuse of IT hardware infrastructure , failover and DR supports
* Reuse of BASIS, security and user management activities that can take upto 20-30% of development team time

However, it is common for people to talk about reuse in the context of applications and other aspects are missed out.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter