Section 18.6. How does ESA affect implementation issues?

18.6. How does ESA affect implementation issues?

Even beyond configuration, the most important issue to be addressed in an ESA landscape is the possibility of conflicts, redundancies, and business process disruptions. As the granular complexity of the landscape increases with each service added, so does the possibility of something going wrong, and the ability of IT to debug or spot potential conflicts with the naked eye decreases proportionally. Furthermore, laboriously plotting the impact of a potential implementation by handi.e., configuring, testing, and debugging every single component that would be affectedisn't an optimal use of IT's time or resources.

SAP NetWeaver Lifecycle Management already does an excellent job of transforming high-level configuration instructions into granular application settings. But dealing with the flexibility inherent in an ESA landscape will require a still higher level of abstraction that would first include preconfigured and automatic initial setup of complete business scenarios. These would ideally shrink a six- to nine-month configuration process to an out-of-the-box installation preintegrated with SAP NetWeaver, with the latter being briefed by the installer on which components have been installed, which key performance indicators to monitor during operations, and so on.

A second aspect of this approach is a concept called business scoping. Scoping takes preconfiguration further, essentially installing a complete landscape of functionally that is dormant until initial configuration, at which time the administrator is presented not with extensive technical documentation on the scenarios contained within, but with a catalog of business processes and scenarios available within the landscape and described entirely in business terminology rather than technical specifications. The landscape then implicitly configures itselfactivating business content, connecting services and business objects as needed, and the like. Instead of forcing customers to keep pace with the rapidly proliferating number of entities, the landscape hides its innermost technical workings during configuration and reconfiguration. All customers will need to know is what they would like done, not how it's done.

This is yet another example of the eventual evolution within ESA away from a specification model (where in this case, the implementation must be explicitly specified) and toward a requirement model, where the only administrator input necessary is the desired result. The responsibility for recognizing the relationship between technical functionality and business processes will be incorporated into the installation process itself.