Section 1.5. How will ESA change how applications are designed and built?

1.5. How will ESA change how applications are designed and built?

Perhaps the most important aspect of the ESA stack to keep firmly in mind is that it does not live in just one application. The ESA stack exists in every part of a network of service consumers and in service providers that are participating to automate a process. Figure 1-11 shows the transition to this architecture from the mainframe stack.

Figure 1-11. Application structure in ESA

Service consumers use the ESA stack to do their jobs, as do service providers. Each type of application may use more or less of each layer in the stack.

The layers of the ESA stack are also constructed differently than in the mainframe era, in which development was performed primarily with languages such as Java, ABAP, and C/C++. All of these languages are still used in ESA, but their focus is to build components that fit into a composition environment in which modeling is the primary method of building applications. Chapter 12 covers how composite applications are structured and how model-driven development tools are used to build them.

Figure 1-12 illustrates how development tasks are separated between developers and programmers who focus on the more technically challenging task of creating enterprise services, and business analysts and process experts who use modeling and orchestration techniques to assemble new applications from existing parts. The UI can be rendered in many more forms quite easily because of the model-driven development techniques.

Figure 1-12. ESA composition environment

Finally, the structure that ESA brings to applications creates the possibility of closing a gap that has long existed in enterprise software. In order to communicate with its customers, SAP has created a system of business maps that describe the scenarios and groups of processes that exist in a particular industry. These maps are of great value in explaining how a product such as mySAP ERP will support a business. The maps show the main areas of the business and break them down into scenario groups, then into individual scenarios and further into processes that enterprise applications automate. You can then divide those processes into process steps that are associated with specific tasks in UIs. SAP has long promoted this sort of high-level modeling as a way to bring clarity to the design of businesses and business processes. The ARIS modeling tool from IDS Scheer has been SAP's recommended approach for business modeling. The ARIS tool, which will become part of the suite of tools surrounding the Enterprise Services Repository, creates the sort of process component models that are shown in Figure 1-13.

Figure 1-13. Process component modeling

Process component modeling defines the process components, the interaction among the process components (called integration scenario modeling), and the interaction between two process components (called process interaction modeling). Inside the process components the processes are modeled using enterprise services and business objects. The value of this modeling is that it closes the gap between business modeling, which takes place in terms of process components and modeling how those process components will be implemented. In the current forms of business modeling, there is a leap from the scenarios to the processes, and this leap does not connect the two as clearly as process component modeling does. This sort of modeling is yet another way that ESA brings the business and IT onto the same playing field.