Section 4.3. What motivated the creation of ESA?

4.3. What motivated the creation of ESA?

SAP cofounder Hasso Plattner conceived ESA as a solution to the increasingly unwieldy number of enterprise applications appearing in corporate IT environments. As we discussed earlier in this chapter, all the functionality necessary for a given process could no longer be contained within a single application.

Plattner originally conceived of ESA to support cross-applications that could cross the boundaries of the enterprise applications beneath them and combine pieces of functionality into a new application running above them. These became SAP's family of packaged composite applications which were branded as "xApps". The creation of xApps overcame several of the implicit assumptions underlying enterprise applications and the previous architecture that no longer applied in the modern business world.

First and most important was the idea of the database as the single point of integration. This was the dominant model during the era of client-server approaches in the late '80s and early '90s. When entering a purchase order into ERP, for example, that order is added to a database that everyone in the system can access. Anyone wishing to revisit that order later can easily retrieve it from the database. But when an xApp begins crossing the boundaries between applications, borrowing data and functionality from each, the customer data may exist in different placesin CRM, SCM, and ERPand it may not be synchronized across the three, leading to the potential for inconsistency, something that the single-database world was designed to prevent. ESA has many different mechanisms for handling this problem, as we will discuss later in this chapter and later in this book.

Another transformed assumption that ESA had to address was the idea that processes were automated within the boundary of an enterprise application. xApps by definition need to define processes without regard to the existing boundaries between enterprise applications.

The final assumption was the role that standard software would play to meet new business requirements. If emerging requirements were to be met, enterprise software would no longer comprise standard processes encased in enterprise applications. The moving parts would have to be exposed. That need led to the creation of enterprise services. Instead of delivering functionality in the unit of an individual application performing a single task that can't be reused, businesses could free pieces of functionality from their enterprise applications, repackage them as services, and design these services (the job of the architecture) to be flexible and reusable. So, instead of creating a new application every time the business situation changed, you could simply tweak the combination of services within a given application. Now build versus buy has become buy, build, and compose. That's the vision behind ESA; Figure 4-1 provides a visual definition.

Figure 4-1. Defining ESA