Enterprise Services Architecture (ESA) is SAP's blueprint for how enterprise software should be constructed to provide maximum business value. The challenge facing most companies is not whether to adopt service-oriented architecture (SOA), but when and how to do so. There is always a lag between technological vision and business feasibility. It also takes time to fully realize the potential of existing technologies, a process that does not stop the moment the new thing arrives. But when the value of a new approach such as ESA starts to make a difference and produces a competitive advantage, the motivation to change skyrockets. The time to change becomes now and the hunger for learning grows. The goal of this book is to satisfy the hunger for information for those who suspect that ESA may be a gateway to transforming Information Technology (IT) into a strategic weapon.
The current state of the art is a long way from ESA. Most enterprise software programs now use Internet-inspired technologies, such as portals, web-based user interfaces (UIs), application servers, and XML-based messaging services, but they still cling to client/server and even mainframe architectures. This will change dramatically over the next five years. IT will become connected by networks, awash in data, faster, more adaptive, more in sync with business. Companies that understand how to unlock the business value of this new architecture before their competitors do will have a huge advantage.
The skeptics among us cannot help but ask, "Has something really changed?" Buzzwords—web services, service-oriented architecture, and enterprise service bus are the current rage—come and go, but the network, the Internet, is here to stay. However, the classic mainframe and client/server architectures make only minimal use of it. In dribs and drabs, enterprise applications have taken advantage of network-enabled functions, but the core architecture in many ways remains untouched. ESA represents a refactoring of the core architecture of enterprise applications to make sense of a flock of new possibilities and to bring them in formation to the level of business, application, and technology architectures.
IT will change not simply because new things are possible, but because most markets are presenting companies with a whole new set of requirements that traditional IT is having a hard time meeting. Most companies live in a world in which business models change every year, or even more frequently. An implementation cycle of a year or more on an IT project can no longer be tolerated. New processes must be designed and built in three months, six months, or nine months. The systems of record that provide the context for most business activity have been built out. Now the challenge is to quickly build a new layer of flexible processes based on those systems of record in a way that preserves flexibility so that future adjustments are affordable.
This book will explain—in more detail than ever before—what ESA is, and how SAP is bringing the concept to life in all of its products as a platform supported by an ecosystem. The first book written on this subject, Enterprise Services Architecture (Woods and Mattern, O'Reilly), described in general terms the context for ESA, the business case for it, and outlined the shape of an ESA platform. Because SAP has made so much progress in fleshing out the details of ESA, many questions can now be answered in great detail. For example, this book will answer the following questions:
How will UIs be modeled and constructed in ESA?
What new components will need to be created to support creating composite applications?
What is the role of business intelligence and analytical functionality in a service-oriented world?
How will process orchestration knit together new processes from the parts of all of the enterprise applications participating in composite applications?
How will the application logic of enterprise applications have to change to best support ESA?
How will a unified process, information, and UI model be constructed out of a collection of distributed services?
What new level of container will replace the collection of functionality now kept inside an enterprise application?
What projects will allow companies to build the right skills needed to adopt ESA?
What is the ecosystem of customers, Independent Software Vendors (ISVs), and systems integrators (SIs)?
How will SAP NetWeaver evolve to enhance and broaden the support of ESA?
Which products does SAP offer in 2006 to help customers moving from a classic mainframe/client/server architecture toward an open Enterprise Services Architecture?
If these questions seem rather technical, well, they are. That such detailed questions about technology can be answered indicates how much ESA has matured. But our attention to technology questions will never distract us from the role that technology plays in supporting business.
Those involved in looking at the whole company from an architecture perspective.
Those who look at different business processes to assess the best way to run them.
Those who will have new roles in this new world and will need to learn the new skills they will require.
This list is a broad umbrella that encompasses a range of responsibilities from reducing total cost of ownership (TCO) to decreasing development time to choosing new platforms and development methodologies. This wide perspective matches almost exactly the domain of ESA shown in Figure 1-1.
What distinguishes ESA from all other approaches to SOA is that ESA explains how the business, application, and technology should be organized to produce maximum value. The business strategy and process design, the application architectures, and the way technology supports applications are synchronized in relation to enterprise services. Figure 1-1 is an accurate oversimplification, but as our explanation proceeds, it will become clear that a unified approach to designing services is the first step. From that first step flows the ability to create a unified process model, a unified information model, and a unified approach to building UIs. All of these things combined comprise the engine of value that makes new innovations possible based on existing systems of record.
Synchronizing business strategy and technological applications through enterprise services has two enormous advantages. First, the business architecture is defined by exactly those processes that are supported by enterprise services. Second, this synchronization brings business executives, analysts, and technologists onto the same playing field as application experts and engineers. Each group has clearly defined responsibilities. Business analysts define and modify processes and UIs using modeling and simplified tools based on services. Technologists build services and tools based on services for use by business analysts. Each group manages its own domain of complexity and can talk about enterprise services from its own perspective. The conversation is structured. Business analysts request services and UIs when they are missing and then modify them from there. Technologists provide these services. The communication disconnect that plagues business and IT is conquered by a form of information hiding in which each side has its own domain, and communication is structured. Improved communication may be the most profoundly valuable contribution ESA can make.