Section 4.12. What is the difference between ESA and other approaches to SOA?

4.12. What is the difference between ESA and other approaches to SOA?

The biggest difference between ESA and other approaches to SOA is that from the ESA perspective, web services are only the beginning of a solution to the larger problems that any enterprise faces when it sits down to draft a roadmap of its business processes and the systems needed to support them.

Web services are very flexible standards, and many vendors already provide the necessary tools for building them and, in some case, modeling applications using web services as inputs. However, the question of where these web services will come from to automate processes is usually left unanswered by the vendors offering SOAs. The general idea is that companies are expected to build their own, and that the SOA vendors will provide help in selecting which ones they need to fit into a modeling environment.

While this approach may work, it doesn't solve the larger business issues, nor does it require the vendor to do much. By contrast, ESA provides a full repository of enterprise services already built and ready to automate processes for its customers.

SAP has gone a step further, creating a full suite of modeling tools at the UI and the process orchestration levels, a framework for the creation of composite applications that is actually embedded in those tools. Not only is SAP committed to building its composite applications composed of services (its xApps line), but also it has created a roadmap for the transformation of its entire product line into collections of enterprise services. ESA adds an "ecosystem" for including its customers and partners in decisions that affect the ongoing evolution of ESA. ESA is therefore more than an SOA; it supports business processes framed in terms of business semantics.