Section 4.5. How does ESA meet those challenges?

4.5. How does ESA meet those challenges?

The key is the enterprise services themselves. They are the modular, reusable, flexible building blocks of ESA, which are already capable of meeting all of the challenges outlined earlier, provided they're assembled within an environment that is stocked with the appropriate development tools and honors the contract of the architecture.

Enterprise services are essentially pieces of processes. The pieces can be of any size and degree of functionality. One might be a utility function so small as to calculate only the time of day, and another might be large and complex enough to start the execution of a highly automated manufacturing process. But regardless of how large or how small they are, every enterprise service is designed to be a building block of a larger process, meaning they embody a host of attributes that enable them to meet the architectural challenges outlined earlierthe foremost of which is reusability. Precisely because they are building blocks, they were always designed to be recombined repeatedly, unlike previous generations of applications.

Because they were designed to participate in process orchestration, they were designed to be model driven. Instead of hardcoding services into applications, a new generation of modeling tools will assemble them. In order for a service to participate, it must be able to describe itself to the modeling environment so that its functionality can be adapted and added to the process and connected to other services. This is accomplished using a layer of metadata embedded in the service, metadata that includes descriptions of how to use it, which business processes should be connected to that service, which underlying objects may be implemented using the service, and so on. Metadata can be used to configure the behavior of the service itself and to orchestrate its position within a process chain of services. This solves one of the thornier issues in integrating older applicationsthe absence of information about their internal workings, which usually leads to unintended side effects during integration efforts. But within ESA, the service metadata is sorted in the Enterprise Services Repository and is summoned by modeling tools at design time to describe the services being used.

ESA also provides a complete life cycle approach for designing services, designing the resulting applications, modeling processes, executing the models, and then actually executing the finished code. The architecture specifies and supports all of these things from the moment they are conceived until they are retired. Services built under ESA auspices are guaranteed to work within ESA systems; the ad hoc nature of previous generations' integration efforts isn't an issue here. There are even utility services designed to help knit larger functional services into business processes. (We describe the various types of enterprise services later in this chapter.)

Enterprise services solve the challenges of routing the appropriate data and information to the appropriate interfaces via the use of analytics and roles. Instead of asking users to hunt through the system for the information they need to make decisions, SAP's analytical tools collect data from every relevant source in the system and synthesize it down to a level appropriate for any given user's needs. Analytic tools solve one of the most serious side effects of increasingly automated processes. Instead of spinning out yet another UI for every process, analytics provide the ability to route the output of each process automatically to a role-specific UI created for each class of userfor example, CEOs, financial analysts, customer service representatives, factory floor managers, and so on. The analytical tools compile and recompile the processes' raw data output repeatedly, assembling it in a form that can then be used as a basis for taking action depending on the user's role within the organization.

The UIs themselves are composed of services, and they can be modeled and attached to automated processes on a flexible, as-needed basis. The result is a composite application, which possesses a degree of flexibility unknown in previous generations of applications because it is essentially a mesh of relatively granular, loosely coupled enterprise services rather than monolithic containers of complex functionality. Those applicationsERP, CRM, and the likewill also have services built from them and on top of them so that they can participate within an ESA framework.

The same attributes will solve the problem of heterogeneity by breaking down the integration challenges from absorbing standalone enterprise applications to incorporating much smaller, self-described services designed to operate in an ESA environment in the first place. Businesses won't just purchase enterprise services from SAP; they'll build their own, buy them from third parties, and adapt services from SAP and third parties to meet their needs.