Section 2.6. What are ESA s practical implementation issues?

2.6. What are ESA's practical implementation issues?

The first step, which Microsoft, IBM, and many others have already taken, is to begin transforming monolithic applications into web services. SAP has gone a step further, seeking instead to create less granular, more sophisticated enterprise services designed to support the business processes and scenarios present in any given company. To that end, SAP has created a preview system with more than 500 defined and published enterprise services. (For a more complete description of SAP's enterprise services, see Chapter 8.)

It then falls to you to think long and hard about the makeup of your current IT landscape. We're back to core/context again. Which scenarios, applications, servers, and so on support core processes, and which ones support context? Which of those supporting services can you buy from vendors? Which are commoditized productivity tools, and which are truly differentiating the companythe processes that can't be bought? All of the services underlying these will be added to the Enterprise Services Repository, a dictionary of services created in the context of business maps, scenarios, processes, and process steps and illustrated in Figure 2-6. Only after you've begun abstracting the functionality from the hard-wired applications are you able to see how a once-ingenious integration solution could just as easily be replaced with an out-of-the-box scenario from SAP or one of a hundred Independent Software Vendors (ISVs). The following checklist offers one step-by-step approach:

• Understand your differentiators.

• Identify business process opportunities.

• Prioritize opportunity versus cost

• Create a dictionary of services, events, roles, and processes.

• Reuse services in the platform.

• Build or buy missing services.

Figure 2-6. Creating a repository of services, events, roles, and processes

Once you've done that, map your business processes and start planning how to consolidate context-supporting processes. Do not reflexively invest in development of custom services. Instead, see whether they exist already, buy them, extend them with less effort, and add them to the repository. Stop thinking only in terms of "buy versus build" and start thinking like an architectlike a real one, we mean. If your IT landscape were an actual landscape, what would it look like? What services provide the basic utilitiesplumbing, power, and the likeand how does your existing array of applications and data objects comprise the buildings? You might think of it this way: the enterprise applications, like most utilities, are buried; the buildings are assembled from enterprise services stored in the repository, and at a certain height, a composition platform hovers upon which composite applications can be built in the future, pushing your buildings to ever-greater heights.

First, though, you'll need to consolidate activity in certain buildings, renovate them, and demolish the empty ones that are devoid of value.

They're empty because the business tasks that used to be performed within them have moved away and are now the tenants of another building. Think of the all-but-abandoned systems that fell into your hands after the last round of acquisitions. Most of the functionality and data have been migrated elsewhere, but so far, it's been easier to keep those systems standing than to knock them downto pay for inertia, in other words, instead of grappling with the complexity surrounding their demolition. But now, it's time to do just that. It's time for your first round of ESA-enabled consolidation:

Map your context systems.

Again, which parts can you replace with parts off someone else's shelf? Which are already up and running elsewhere in the company? What do you need to keep, and which ones can go? Once you identify those systems, as in Figure 2-7, it's time to consolidate the data associated with those systems and then to retire the hardware.

Consolidate master data.

Already we're seeing the power of abstraction in action. Use ESA to create a master data hub that isn't locked into any single application or physical piece of hardware. Why? Because the IT architecture will only become more heterogeneous over time (there are acquisitions to be made and more servers to be bought), and the entire purpose of ESA is to abstract data, processes, everything, onto the platform, beyond the integration headaches that stem from residing in one place all of the time. So, consolidate your data, cleanse and synchronize it, syndicate it back into the environments, and once you're able to manage your data through SAP NetWeaver Master Data Management (SAP NetWeaver MDM), you've essentially transcended your physical systems. Figure 2-8 illustrates this step.

Consolidate your hardware

Stop thinking about one server for each system. Use virtualization to move data out of redundant servers and retire them. Think of it as urban renewal, illustrated in the sparser landscape in Figure 2-9.

Start sharing data and services across the enterprise

Leverage resources across multiple systems; scale functionality as needed to support process innovation, as shown in Figure 2-10.

Figure 2-7. Mapping context systems

Figure 2-8. Consolidating master data

Do you see where we're headed with this? Following one of the earliest steps, the creation of the Enterprise Services Repository, you can clearly see which scenarios are core and which are context. Identify which slices' custom-built functionality are context and therefore replaceable; take steps to abstract and cleanly separate essential data from inefficient hardware and processes; and then consolidate all of that down into a virtual platform which can be scaled up again as needed to support the deployment of new services.

Figure 2-9. Consolidating hardware

Figure 2-10. A shared services backbone, which enables faster upgrades

ESA becomes the mechanism for converting core/context theorywhich sounds so right on paper but was so hard to realize before nowinto action. If that strikes you as a bit of an abstract moral victory, then just concentrate on the reduced TCO.