Section 18.7. How are operations affected by ESA?

18.7. How are operations affected by ESA?

On the software side, the creation of a standardized set of interfaces for administrating and monitoring enterprise services will go a long way toward consolidating and eliminating the often redundant and expensive toolset in use today. By grounding these standards in ESA, it will become possible to fold all of the necessary tools for load balancing, ensuring uptime, scheduling, running diagnostics, and so on, into SAP NetWeaver for automatic administration. That is exactly what SAP is doing.

Standardization will enable SAP to meet the landscape challenge by collapsing formerly individual and isolated tools into the central SAP NetWeaver Administratorthe central operations console of SAP NetWeaver. This systematic consolidation, which is already underway, will lower TCO while creating the link between the business process logic and the operational metadata, which will cause the latter to become contextually self-aware.

In practice, that means having administration tools that will do the following:

• Automatically recognize operational dependencies between services or composite applications

• Allocate system resources to services using their importance to business processes as a method for assigning priority

• Alert IT when service messages are not being received

• Ensure those messages are not lost and can be rerouted and make contingency plans for surges in system activity

Consolidating the tool in a single, remotely accessible user interface (UI) will only make the tasks of outsourcing system administration to data centers and receiving support from ISVs that much easier.

18.7.1. What is capacity planning in the world of ESA?

In general terms, capacity planning is the process of determining the required hardware resources for running enterprise solutions such as mySAP ERP or composite applications, for example. This includes initial estimates on required CPU server capacity, memory requirements, projected disk size and future growth, as well as frontend network-bandwidth requirements. It's possible to distinguish between different kinds of sizing: the initial size of your first hardware plans, adding load delta size after you go live, and upgrading your size when new solutions are added to an existing landscape. Sizing is achieved by translating business requirements into hardware requirements, as customers identify their bread-and-butter business processes and services, and SAP provides tools and guidelines to turn this information into hardware requirement predictions. What is the principle of sizing?

The theory is that each business process creates a load on the hardware that can be measured using standard performance monitors. This load is expressed in terms of CPU second for CPU usage, memory in megabytes, disk space in megabytes, and frontend network load in kilobytes transferred per user interaction step.

Abstraction of business logic from IT is enabled through operations, notifications, and synchronous and asynchronous messages to local or remote systems. When you look at the architecture from a business perspective, it is clear that different business objects have different complexities. For example, a sales order will be more powerful than a pay statement. Different operations may also have more impact on performance than others, and messages passed through the Adapter Framework create additional strain.

To prepare for these challenges, SAP will measure standard enterprise services along the criteria of CPU usage and memory and disk consumption and will turn the findings into a questionnaire where customers can fill in expected business application and volume requirements.

18.7.2. How do you size composite applications?

Composites aim at enabling efficient development of new applications that customers can adopt easily and that allow flexibility in backend connectivity. They are applications that use data and functions provided as services by backend systems and other underlying applications, and combine these into user-centric processes and pages, supported by their own business logic and specific UIs.

The scope of the composite application concept is broad and may be applied in various business cases. For example, small (lightweight) composites implement process logic only, and large composite applications such as SAP xApp Analytics add value at the persistence, object, and service layers.

Provided your software scales linearly, sizing is additive for composite applications. Their size is equal to the sum of their parts. What you can do in this context is begin from the standard sizing of the underlying services and add the requirements for your custom service. For example, you may want to integrate a third-party application with an SAP application via a unified UI, such as guided procedures, for example. You need to size the third-party application, the SAP application, and the load created by the new UI.

18.7.3. How does performance monitoring work in an ESA environment?

SAP NetWeaver contains a number of performance monitors that help you understand exactly which processes create which load in which component. Some monitors collect statistics on CPU utilization of different hardware servers, and others look at the runtimes of individual processes, on local servers as well as collecting performance KPIs from remote servers. There are tools for a quick bottleneck analysis, such as the XI Monitor; there are dedicated SQL traces for tuning access to the persistence layer; there are application traces for runtime analyses across packages and components; and there are familiar tools for measuring server-to-server communication, frontend network load, and rendering times on the browser. Figure 18-2 shows where the optimization potential is.

Figure 18-2. An overview of performance analysis

18.7.4. How does virtualization affect capacity planning?

Virtualization options (see the upcoming section, "What is adaptive computing and how does it relate to ESA?") can help with hardware landscape management by more flexibly deploying hardware, thus lowering TCO with less idle machine time. Although it's easy to virtualize disk storage and CPUs, memory presents more of a challenge. From a sizing perspective, peak requirements must be satisfied, and at some point, all resources must be tuned to meet these peak requirements. With sensible virtualization efforts, the individual peaks can be evened out, again lowering TCO.

If you look at Figure 18-3, you can see a typical load distribution at a customer site. CPU peak usage occurs at around 3:00 p.m. At that point, all services must be available to satisfy the CPU requirements. At other times, the virtualized CPU power may be taken to satisfy other needsfor example, serving web pages.

Figure 18-3. Load distribution at a customer site