Skip to end of metadata
Go to start of metadata

Let us start with understanding of Geoffery Moore model according to which the business comprises of two set of activities - Core and Context. Core is what the company concentrates on and Context is usually the set that could be outsourced. The Context activities are always expected to be delivered well. But their extraordinary quality would neither add to the monetary value of an organization, nor would give a competitive edge. The core activities actually differentiate and affect the organizational monetary values. The Core activities of one organization could become a Context for another and vice-versa. Initially when SAP came to market, its Core was other's context.

The ERP, CRM, SRM Enterprise Application solutions provided by various vendors turned out to be an acceptable investment based on ROI. However, one important point that was missed was - Would these enterprise packages be able to adapt to situations where the Core gradually became the Context? The situation here required a major organizational transformation because there was no standard way through which these applications could be made to be reused. There ought to be a way to loosely couple applications' functionalities. At this point, Services evolved. Individual functionalities of an application were exposed as services. These services performed their role to decouple the inflexible landscape and were thought to be quite handy for developers. However, these services were short of the business context.

Is an SOA implementation possible without Services along with Business context? Let's take an example to understand this. Consider SOA to be a scientific Calculator. The technologies used to implement SOA would be considered as the various physical components that combine to create the complete Calculator as a product. What uses exist for this calculator for those who don't understand the number system at first place? Without proper numbers as input, the complex calculator would turn out to be a worthless tool. Similar are the Services (like a number system) without which the complete implementation of various technologies for an SOA would become worthless. Now suppose someone knows the basic number system but is unaware to use these numbers for business purpose. This case would make the Calculator usage equivalently worthless. Similar is the case with Services without Business context.  

SAP's answer to this was the use of Enterprise Services as the language that entire SOA implementation would use to communicate.  SAP thought that an individual Web service could behave as an ineffective technical interpretation of functionality. However, when it is attached to a Process context followed by a Business context in compliance with open standards, it gets renovated into an Enterprise Service. Along with this, an Enterprise Service holds the metadata and references of this web service.
SOA implemented through Enterprise Services was termed as Enterprise Service Architecture (ESA) which turned out to be the enabler for reusability and orchestration. The methodology followed was to model and reengineer the existing business process and process components. The processes were transformed into web services which then were turned up into enterprise services. It was made possible to reorganize the services to accommodate the changing Core activities.

ESA is about reusing the existing legacy systems, incorporate them into a Composite Application infrastructure and produce an optimal and efficient process change. ESA decentralizes the decision making with managers handling the modelling tools.

  • No labels