Section 5.2. The ESA stack, layer by layer

5.2. The ESA stack, layer by layer

With the general relationship of service consumers and providers in mind, we can now turn to the idea of how the ESA stack works inside both consumers and providers. Each layer of the ESA stack has been conceived and designed to play a supporting role to create service consumers (usually composite applications) and service providers. Each layer has a specific role to play that promotes flexibility, reuse, and ease of development in concert with the other layers. Before we examine each layer in detail, we will take a look at the challenges each layer must overcome to do its job.

5.2.1. What challenges face the ESA stack?

As Figure 5-3 shows, the ESA stack consists of five layers, each designed to address an enduring challenge that has faced enterprise application architects since the beginning of the industry. The vision of ESA has made those challenges more acute in several ways.

First, one of the promises of ESA is that standard software delivered as a set of services can both better fit the requirements of a business and be recombined to solve many more problems. SAP will recombine services to provide automation of many more processes flavored for industry verticals. This expansion of automation will mean that more UIs will need to be created to assist people who will be playing various roles in these automated processes. More processes automated and more UIs mean that development tools must become more productive and applications must become easier to maintain. Otherwise, the expansion of automation to more processes and more verticals cannot take place.

Figure 5-3. Challenges facing the ESA stack

In addition, some of the tools used to create and configure applications under ESA must become easier to use in order to expand the population of potential application developers from highly technical people using development tools that require knowledge of Java and ABAP, to business analysts who can directly apply their deep understanding of business requirements using simplified modeling environments.

Finding and using services will also be a challenge as the number of services expands rapidly. So will keeping track of the much larger number of processes that are being automated. Figure 5-3 summarizes the challenges facing the ESA stack.

5.2.1.1. User interface

UIs must become easier to create and maintain. The job of designing and building UIs must be performed not only by highly trained technical employees, but also by business analysts. This will happen through an expanded use of modeling tools for development instead of coding. Patterns will also be used to further automate and accelerate development and to provide common structures in the UI to reduce training time.

5.2.1.2. Process orchestration

By themselves, enterprise services are not enough to deliver on the ESA promise. They must be combined to create applications in ways that are flexible and that expand the population of developers. For example, ESA would fail if the only way to combine services was to code in Java and ABAP. Instead, process orchestration mechanisms such as Guided Procedures, modeling in SAP NetWeaver Visual Composer, and CCBPM allow services to be combined via modeling rather than coding. This not only accelerates development but also makes applications easier to change to meet evolving business needs. The job of automating business processes can become a task performed by business analysts and application specialists who are closer to the requirements of the business. This avoids creating a bottleneck and frees up highly skilled developers to address the task of creating new enterprise services that are unique to each enterprise.

5.2.1.3. Enterprise services

Enterprise services have a dual identity. From the business perspective, enterprise services are units of functionality used to model and automate business processes. Enterprise services may be used to automate whole business processes, process steps, key parts of process steps, or important utility functions. From the technology perspective, enterprise services are building blocks for reusable functionality designed to be used in model-driven environments and to implement patterns that help automate development. The challenge is to design enterprise services properly so that they serve both of these purposes. Some services keep track of relationships, some are focused on processes, and others provide access to important entities such as purchase orders or to engines for complex calculations. Some provide access to important support functions or third-party applications. The domain of enterprise services is vast, and building all of the services that are required is a massive undertaking. The work of SAP's developers, Independent Software Vendors (ISVs), and customers must be coordinated. Once all the necessary services are built, the next challenge is to find them and use them in advanced modeling environments. While enterprise services are process and technology building blocks inside applications, an entire ecosystem must exist to create and support them.

5.2.1.4. Business objects

Business objects are reusable building blocks inside a service provider or an enterprise application. Business objects are not required to create enterprise services. It is possible to build services on enterprise applications that were not created to support enterprise services. But if business objects exist, then creating enterprise services can be streamlined. The business objects in new service providers created with ESA in mind are designed to simplify and accelerate the job of creating enterprise services.

In the oldest generation of enterprise applications, the architecture was monolithic, meaning that one huge, interconnected program did all the work. As programming became better understood, the idea of reusable objects that encapsulated both data and functionality became the dominant paradigm. Most of SAP's applications, including SAP R/3 and earlier versions, have used the concept of business objects as the main structuring elements of applications to represent real-world business entities. From the beginning, business objects were technical implementations of business ideas.

While many enterprise applications now use objects, most of the objects were designed for internal use in an application. Business objects differ from traditional objects in that they are designed to represent business ideas, support external use, and take into account the processes, process steps, and utility functions they might be involved with creating. If business objects are created according to certain patterns, the process of creating enterprise services according to those patterns can be automated. Higher-level patterns for the structure of UIs or process patterns can then be built on lower-level patterns.

5.2.1.5. Persistence

In the ideal world of ESA, each business object manages the persistence of its data. The evolving world of ESA will fall short of this ideal for some time, and data will be managed by multiple parts of an application using transactional mechanisms to avoid conflicts. In both of these worlds, data will be distributed across many service providers and the same or similar data may exist in many places. Service consumers, however, will not want to be bothered keeping track of all of this distributed data. ESA provides various solutions to this challenge through Master Data Management (MDM), SAP NetWeaver BI, and SAP NetWeaver Application Server (SAP NetWeaver AS).

As we will see in the following explanation, the ESA stack is supported by many different mechanisms from the Enterprise Services Community (ES-Community) that coordinate the design of services being added to the Enterprise Services Inventory both from inside and outside of SAP. Model-driven development tools use the descriptions in the Enterprise Services Repository to simplify development and replace hardcoding in Java and ABAP. Operational, security, and life cycle management tools help guide ESA applications through the process of design, implementation, operations, and retirement. Specially designed processes for creating implementation roadmaps and new governance models help companies manage the new world of services. Standards are used to simplify and accelerate this process throughout. If this chapter and this book are successful, you will be able to understand all of these dimensions and put ESA to work.