Cover | Table of Contents

Table of Contents

Chapter ONE: ESA in the World of Information Technology

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Who is this book for?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

ESA should be of primary concern to anyone charged with making IT support a business. The intended audience of this book includes:

Enterprise architects

Those involved in looking at the whole company from an architecture perspective.

Business analysts

Those who look at different business processes to assess the best way to run them.

Senior executives

Those who rely on IT to support their business and need to know what is expected of their IT departments, enterprise architects, and business analysts.

Developers and engineers

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.

Figure 1-1: Three perspectives on ESA

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Why so many questions?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If the questions and ideas mentioned so far sound interesting, then you are ready for the rest of this book and you are ready for the format.

When we sat down to write this book, we were quickly awed by the breadth of topics under the ESA umbrella. ESA starts with a perspective on how business should view IT through modeled processes and information entities and then explains how applications should be constructed and technology should support these applications along with a range of related issues. It would easily be possible to write a book about just the business perspective, the application perspective, or the technology perspective. But to really provide a service to the SAP community, our mission was to write a book about all three. Covering ESA at all of these levels represented the first challenge.

The second related task was to provide a way to choose what topics to include. To cover these perspectives meant we had a lot of territory to map out and then navigate. Within each perspective there is a wide variety of material. The question we struggled with was how to guide readers to the material that was most useful to them.

Most technology books do this by constructing a narrative or a story that explains things from one perspective. The problem with that approach is that whichever perspective we chose to use to organize the narrative would leave the other two groups searching for what they needed to know.

Our solution was to imitate one of the forms of content that was made popular on the Internet, the Frequently Asked Questions or FAQ document. ESA is so large and affects so many different people in different ways. There are hundreds of stories inside the world of ESA. So, we gave up on the idea of telling one story or making one perspective dominant. Instead, we present questions and answers, lots of them, so readers can quickly find the information they seek. We chose to write each chapter as a series of answers to questions so that the table of contents was a long list of questions. We assembled these questions into chapters aimed at a particular audience so that related questions handled at a similar level of business or technical detail were grouped together.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What forces created ESA?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Modern businesses need functionality that is both distributed and centralized. Existing systems of record, such as Enterprise Resources Planning (ERP), Customer Relationship Management (CRM), Supply Chain Management (SCM), and so on, serve the needs of key segments of the organization. But at the same time, a need for many new processes has arisen that requires a flow that moves from one system of record to another, with the context for the process kept outside of any of the existing systems. The traditional way of building enterprise software is not well-suited to these new requirements and does not take full advantage of the new world of pervasive networks, reusable services, and distributed data. Treating an application as a self-contained world no longer meets the needs of business.

In the past, enterprise applications contained the end-to-end processes that were being automated. One program running on one computer automated a workflow process that began and ended inside that application. A single database was the central mechanism of integration. All elements of the stack were contained within one program, as shown in Figure 1-2.

Figure 1-2 actually shows a prettier picture than what exists in many mainframe applications. Even after workflow mechanisms were in use and points of integration were designated, process and integration logic ended up strewn all over the stack and was mixed in with application and UI logic. This structure, however, captures the spirit of mainframe applications, which at their best were organized into the following layers:

Figure 1-2: Mainframe and client/server architecture

• The UI layer
• The process logic layer (which controls the automation of the steps)
• The integration logic layer (which controls the way the programs interact)
• The application logic layer (which controls what the program is actually doing)
• The persistence layer that serves as the database (where all the information is stored)

From a development perspective, the mainframe and client/server tools gave developers control over a vertical slice of this stack, from the UI to the persistence layer. If functionality in other slices was to be reused, the developer would have a conversation with the developers of the other slices to figure out how to use their functionality. Everything came together and had to be carefully reconciled in the database, which was the central point of integration. One of the major points of ESA is to transform such conversations about reuse from an ad hoc event into a formal design based on the needs of business processes.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What is ESA?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now we are at the doorway of ESA. The simple view of composite applications and SOA leaves many questions unanswered about how the reusable parts will be constructed, who will build them, what tools will be used, and what will make them work together. Here are just a few questions that must be answered to derive the full business value from composite applications:

• How should the portions of the stack be distributed across this architecture?
• How should the portions of the stack talk to each other?
• What is the right structure for each portion of the stack?
• When should multiple structures for a portion of the stack be supported?
• How should the UIs be constructed?
• How should the process orchestration take place?
• How should development methods change?
• Where is the persistence?
• How is distributed data managed?
• How can complexity be managed?
• How can the process of adapting applications be simplified?
• How can developers be made more productive?
• What is the right division of labor?
• Who should solve all of these problems?

The rest of this book is dedicated to answering questions such as these in great detail. To get started, let's look at a few different areas more closely. For example, in a composite application, the data is distributed over many repositories. How can one version of the truth be assembled? How can changes that affect records in many repositories be synchronized?

There are all sorts of different forms of process logic. There is workflow, which happens within an application; there is process orchestration, which happens within a composite application; and there is the logic that is required when a process is handed from one enterprise application to another—let's call this process integration logic. How is all of that logic going to be dealt with? How are the different portions of the stack for process logic, integration logic, application logic, and so on, going to be distributed across the structure? Will all the logic be in the center? Will the enterprise applications have to become smarter? (For the rest of this book, we are going to use the term process orchestration

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

How will ESA change how applications are designed and built?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What supporting infrastructure does ESA require?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This new world of service consumers, service providers, and model-driven development and composition requires a host of supporting elements, each of which plays a crucial role, as shown in Figure 1-14.

Applications in ESA are based on a division of duties among the various layers of the ESA stack. This structure serves to contain the complexity within each layer and to simplify the interaction between them. Further simplification is provided through the use of patterns and model-driven development tools. Modeling is used at many different levels in ESA. UI and application modeling using tools such as SAP NetWeaver Visual Composer helps you to create UIs rapidly. In certain cases, SAP NetWeaver Visual Composer can simplify the task enough so that business analysts can configure applications or even build them themselves. Modeling tools are also available for high-level business processes (ARIS models from IDS Scheer), for backend business processes (SAP NetWeaver XI), and for configuring business processes (SAP Solution Manager). Various abstraction layers such as Web Dynpro provide more detailed representation of an abstract UI that modeling tools can use. Modeling simplifies development and application change and helps to support many platforms with less work.

Figure 1-14: Supporting elements of the ESA stack

Patterns amplify the power of modeling by bringing together large assemblies of components into higher-level structures that repeat themselves. Patterns can be applied to UIs, processes, or the entire structure of applications. Developers who use them have a huge head start compared to having to start from scratch.

The use of model-driven development and patterns is key to delivering the increased productivity and the ability to quickly and easily change existing processes that are crucial to the success of ESA.

The Enterprise Services Infrastructure is a coordinated set of technology, infrastructure, and tools for designing and building enterprise services and ensuring that they operate in an optimized fashion. ESA spells out what service work will be done in the application calling the enterprise service, what will be done in any intermediate layer, such as a service broker, and what will be done in the application providing the service. The Enterprise Services Infrastructure enables developers to create services according to this architecture, to take advantage of web services standards, to help implement patterns, to use global data types, to support security and transactions, and to optimize invocation of services and message traffic between them. The Enterprise Services Infrastructure provides many of the functions that are associated with the idea of the enterprise service bus.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Is ESA compatible with event-driven architecture?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Event-driven architecture (EDA) is another architectural paradigm that is often mentioned in conjunction with SOA. While EDA is fundamentally different from SOAs such as ESA, the two styles are not contradictory, and in fact, they work together well. ESA is a request/response architecture. Service consumers make requests of services and wait for responses. The idea of EDA is "fire and forget." Systems are constructed to respond to events that occur in software or in the real world. Once an event has occurred, a cascading process begins in reaction to the event. Perhaps alerts are sent to people, tasks are assigned, or automated responses are executed. EDA meets ESA in terms of this process of reacting to events. For example, if an event requires a task to be performed, users can use a composite application based on ESA to execute that task. In processing the task, more events can be raised, initiating more chains of events. SAP has long recognized the importance of events in modeling and automating business processes. More than 2,000 core events exist on business objects in the mySAP Business Suite. SAP has created a new infrastructure for turning these core events into business events that can be the foundation of a new generation of event-driven solutions. See Chapter 5 for an expanded discussion of SAP's plans for EDA.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What is the promise of ESA?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Looking back to the answer we provided to the question "What is ESA?" reveals that the answer so far has primarily explained the ESA technology architecture. The next question in this chapter refers to ESA at the application level, and the following chapter is devoted to exploring all of the questions related to understanding the business value of ESA.

The technology architecture came first because that is how most enterprise architects start their understanding of a new trend or idea. First they understand the mechanisms, then they understand what they can do with those mechanisms, and then they determine whether the trend has any relevance to their company's IT situation.

Based on all of the mechanics of ESA that we have explained thus far, we can summarize the likely benefits of systems created using ESA:

• Greater flexibility
• Expanded reuse of existing functionality
• Improved communication between IT and business
• Faster time to market through improved developer productivity based on model-driven development, removing IT bottlenecks
• Easier adaptation through modeling and role-based tools
• Clearly defined roles from the business analysts to the developers
• Better encapsulation to allow heterogeneity or outsourcing
• Lower TCO
• A foundation for an ecosystem
• A foundation for harvesting value from standards

For many SOA vendors, these benefits are promised without the sort of complete, top-to-bottom explanation that we are providing in this book.

But even though SAP's vision is complete, nobody expects the fulfillment of that vision to be rapid or effortless. If Hasso Plattner could wave a magic wand and all of a sudden bring every enterprise service needed by SAP and all its customers into existence, what would be the result? How would this work? What would be the benefit for SAP and its customers?

Another way of thinking of this is to ask the question, "What will the world of enterprise software and IT be like in a completely enabled Enterprise Services Architecture?" Here's one vision.

The first major difference in the world of a complete Enterprise Services Architecture is in the nature of software requirements and documentation. Instead of having lengthy requirements documents that describe systems, a series of models would be used that would always be accurate because the applications would be generated from them. At the highest level would be models of the business showing the relationships among process components. Next, each process component would be modeled in terms of the enterprise services that would automate the business processes. The enterprise services themselves would be modeled from business objects. All of this modeling would be used to create service providers. Composite applications would be generated the same way from UI models, process models, and modeling to create business objects in the composites through service composition. Thanks to Plattner's magic wand, all of the services to enable all of this automation would exist in the repository.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

How will the transition to ESA occur?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

ESA is too large a change to happen in a big bang. Over the next few years, each release of the mySAP Business Suite will become increasingly service-enabled, model-driven, pattern-enhanced, and easier to configure and change. At a macro level, the change that ESA will bring will have the following shape:

• The starting point is the world of SAP R/3 and the mySAP Business Suite as they existed before ESA. Processes are automated inside the applications and are configured with metadata. Almost 100,000 UIs exist in a wide variety of forms. SAP NetWeaver is used for integration and to support processes that move from one enterprise application to another, such as order to cash. ESA-style development is possible using SAP NetWeaver, but the supporting set of tools and the inventory of tools are limited.
• The midpoint comprises the current versions of the mySAP Business Suite, SAP NetWeaver, and those that will be released in 2007 and 2008. These versions come with the Enterprise Services Repository populated with an increasing number of services built on the mySAP Business Suite and described in the context of a high-level process component model. SAP NetWeaver Visual Composer, SAP Composite Application Framework (SAP CAF), and a variety of other model-driven tools that use patterns will be available for the development of composite applications. An increasing number of xApps will be delivered by partners, and special-purpose composite applications such as Project Mendocino or SAP xApp Analytics will be delivered to address urgent problems.
• The destination will be the world of the business process platform. In this world, a fully populated Enterprise Services Repository will be available for use with SAP's model-driven development tools. The power of patterns will reduce the number of UIs that SAP delivers with the mySAP Business Suite from 100,000 to 10,000 or less. These UIs will be easily customizable so that each customer can optimize his processes and productivity. Partners will tailor basic UIs for an increasing number of verticals. The mySAP Business Suite will be delivered as a set of service providers and composite applications.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

How can ESA be addressed at a tactical level?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

ESA is a topic with such a wide range and such depth in terms of its effect on IT that it can be difficult to understand where to start. You can find part of the answer by using offerings such as the ESA Adoption Program, explained later in this book, that provides approaches for understanding how ESA can help a business and for creating a long-term roadmap.

But on a tactical level—the level of today's project list—ESA can be pursued every day. To help understand how ESA can relate to almost every project, it can be useful to think of the five Cs of ESA. These levels are important, because you cannot just push a button and make ESA a part of your business. You must integrate it in steps.

Figure 1-20 shows the five tactical levels. The first is conceiving, which involves making sure you know what you want ESA to do. The next is consuming, the task of putting services to work in simple ways to attack projects that are easy to complete. The skills built into consuming services can support the next level, composing, in which more innovative and complex applications based on services are created. The task of composing applications generally starts with existing services, but if the job cannot be done with services already in the repository, then the next tactical level is required. Creating services is perhaps the most technically challenging level, in which you design and create new services by using a variety of development tools. Finally, controlling concerns tactics focused on policies for IT governance related to the security and operational issues surrounding services.

Figure 1-20: The tactical levels of ESA

Each part of this book will focus on a different tactical level. The goal is that each tactical step will create more flexibility and build more skills. The process of creating a roadmap for ESA (described in Chapter 7) shows how to synchronize all of the tactical work so that infrastructure improvements, software upgrades, system consolidations, and so forth, focus the power of ESA on bringing flexibility and rapid evolution to the parts of a business that will have a strategic impact.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Why does ESA matter?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

ESA matters most because for the first time in IT history, we have a blueprint for all levels of the enterprise architecture. We have a blueprint not just for an application, but also for a platform for flexible automation of business processes.

ESA matters because it provides the ability to align the business architecture, the application architecture, and the technology architecture using a framework that allows all aspects to understand each other. ESA brings the three basic levels together using enterprise services as a common building block.

ESA matters because it standardizes business semantics by providing services that can be used to implement standards and make them useful, or to model and implement relationships among companies.

ESA matters because it makes flexible composite applications possible. When the complexity of applications is encapsulated in reusable enterprise services that are orchestrated through modeling, new ideas can come to life more quickly, a culture of innovation can be created, and the experience gained each day in interacting with customers can be put to work more rapidly to improve the business.

ESA matters because it bridges the gap between buy versus build. Instead of buying an application and having to live with whatever can be configured or customized at a high cost, ESA provides products as composite applications based on models that can be changed in part where it makes sense for a business. The paradigm becomes buy, build, and compose where you need to.

ESA matters because it delivers a different IT, one that is not a bottleneck and a barrier, but a lever and a springboard. We will expand on these topics in Chapters 2 and 3.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What are the core values of ESA?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

At this point in technology development, the idea of SOA is far better developed than the actual technology in the field of SOA. Many solutions that are implemented in the real world of IT cannot take full advantage of all of the elements discussed in this book because the right tools, technologies, and infrastructures are not yet available. This does not make the applications any less valuable; it just means that they perhaps were harder to build or that they make certain compromises that won't be required in the future. Many of the examples we will discuss in this book fall into this category. When we discuss them, we will point out how the application lives up to the core values of ESA, even if the technology falls short of the ideal. But what are the core values of ESA?

The core values of ESA represent the themes that run through ESA that are present in almost every application and technology we will examine:

• Managing complexity, usually through enterprise services but also in other ways, is perhaps the most frequently recurring theme of ESA.
• Simplifying development, frequently through modeling and patterns, is another important theme.
• Promoting reuse happens through mechanisms such as the Enterprise Services Repository.
• Improving productivity occurs through expanded automation and role- and pattern-based UIs.
• Increasing flexibility is based on model-driven development of applications and reusable services.
• Promoting differentiation occurs because existing systems can be recombined in new ways to adapt quickly to changing conditions and to enable innovation.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Where can we go for more answers?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The first book on ESA (O'Reilly's Enterprise Services Architecture by Woods and Mattern, mentioned earlier) is a good place to get an overview of what ESA is all about. The latest book, called mySAP ERP for Dummies: ESA Edition (Vogel and Kimbell), also covers a lot of basic ESA topics, as does SAP NetWeaver for Dummies (Woods and Word) (both published by For Dummies). SDN (http://sdn.sap.com) is one of the best locations for information about SAP and ESA. The Enterprise Services Inventory preview is there; it shows what kinds of services SAP will be introducing. SAP.com also offers a variety of other high-level information as well as a service marketplace.

ASUG, long a valuable resource for those in the SAP ecosystem, is starting a special interest group for ESA that will include thought leaders such as Paul Kurchina. You can find details on this special interest group at http://www.asug.com.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

ESA in action: Mitsui

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Mitsui is an excellent example of a company that is putting ESA to work to integrate its operation based on a strategic look at key business processes. Mitsui is one of Japan's largest general trading companies, with more than 700 consolidated subsidiaries, 177 offices worldwide, and a global workforce of more than 38,000 employees. The company focuses on the trading of metals, machinery, chemicals, energy, and consumer goods, and the scope of its operations contains everything from domestic sales in Japan to import/export to offshore trading. Mitsui's strategic goal, set in 2000, is to become "the world's strongest general trading company." But rapid globalization—along with the challenges of market expansion, fierce competition, and the rising volume of data that comes with it—forced Mitsui to make important changes in its corporate structure.

To this end, the company embarked on a massive business reform and integration effort designed to streamline companywide business processes and consolidate the more than 400 individual systems comprising the supporting IT infrastructure. Mitsui's overarching goal was to replace the individual and diffuse efforts of its subsidiaries with a more integrated and centralized model aimed at optimizing, standardizing, and visualizing the operational processes the Mitsui Group had in common.

Begun in earnest in 2001, the first stages of the company's "business reform project" required four years and 670 project members working around the clock, to identify and redesign core business processes. The project team set four overarching goals for their effort:

• Redesign of the operational processes from the viewpoint of overall optimization
• Support of the redesigned operational processes through use of the latest systems
• Reform of the organization into a shared service center
• Creation of a mechanism for sharing knowledge

With those goals in mind, the team set four corresponding midterm objectives:

• Creation of sales opportunity windows
• Prompt provision of management information
• Small corporate divisions made by professionals
• Thorough digitization

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter TWO: The Business Case for ESA

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The fundamental challenge facing businesses today is to determine whether IT is the solution to problems, or is the underlying problem itself.

Where do you start? For the purposes of this book, we will begin with the problem of speed. The pace of business is quickening, no matter how large or small your company is or in what industry you compete.

For example, product life cycles are shrinking, as shown in Figure 2-1. Years of mature profitability have contracted into months, forcing product makers to move even faster to recognize new market opportunities, to tweak and compensate for changes in demand while the next new thing is still in the womb, and to begin planning the next revisions, spin-offs, or successors the moment next quarter's hit (you hope) is born.

All of this, in turn, accelerates the business from the very top in the CEO's office to the very bottom in the toll-free customer service trenches. If launching a new product is a function of executing a business process—that in turn is broken down into hundreds, if not thousands, of process steps—then a dramatic reduction in time to market or time to volume is possible only if the coordination of those steps becomes proportionately faster. And it is becoming faster. Historically, businesses have predicted time to transparency—i.e., the time between posting a transaction and propagating the data across the enterprise, up the supply chain, and onto the balance sheet—in weeks and months. Today Wal-Mart can predict its quarterly results two months before the end of a quarter. Today you can press a key and produce a P&L statement from a sale within minutes, seconds, or even subseconds.

Figure 2-1: The prerequisite for future growth

This transformation is taking place at the bottom of the organization, where thousands of events—a new sale, a customer service record, or a new batch of market research—generate information that is created, sorted, analyzed, and processed by established IT systems. The first generation of enterprise applications—such as Enterprise Resources Planning (ERP), Customer Relationship Management (CRM), Supply Chain Management (SCM), and others of their kind—were created to automate relatively generic, generally stable business processes relevant to single corners of the business. They comprised a hard-wired value chain that willingly exchanged flexibility and extensibility for an optimized operating environment. At the time, the tradeoff was well worth it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What attributes must ESA embody?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You may be saying to yourself, "Well, all of that sounds thoroughly daunting, and no one would disagree that IT, like all segments of the business, could always do better. But how do we address these challenges?"

For most of the rest of this book, we will thoroughly explore the nitty-gritty details of ESA from the application and technology perspectives. In this chapter, we will examine ESA from a business perspective, and from that vantage point, any IT architecture that hopes to improve upon the existing IT architecture (such as it is) must have the following attributes:

Flexibility

Here it is again. Ripping out a generation's worth of monolithic enterprise applications only to replace it with another one isn't going to reduce anyone's TCO or simplify any CIO's life. More than anything else, the next architecture must find a way to free data and functionality from siloed applications, package them properly, and put them at the service of processes. The way forward, at least at a granular level, is already clear—the concept of web services , which SAP, Microsoft (.NET and Indigo), IBM, and a raft of smaller software companies have embraced. Web services carve interoperability from enterprise applications that you can call remotely from anywhere using fairly simple exchange protocols such as SOAP. Web services defined without a process context are usually too granular to be useful on their own, but when designed as enterprise services with specific processes and process steps in mind, they accomplish the necessary task of transforming powerful, albeit static applications into dynamically available functions flexible enough to be used and reused repeatedly.

In practice, this means that all of the function calls that comprise, for example, the order to cash business process—the ones involved in time to transparency, which we mentioned earlier—are extracted from their respective silos and are loosely coupled in an end-to-end process that mirrors the real-world business logic. The addition of business semantics —e.g., standards, compliance, interfaces, and documentation for data exchange between two business processes—transforms a web service into an enterprise service, a marriage of technical and business standards that didn't exist in previous architectures, as illustrated in Figure 2-2.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What principles should be driving my IT decisions?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Geoffrey Moore is a theorist and consultant who developed a very powerful operating model for how companies should assign scarce time, money, and resources in the pursuit of innovation and profit. And considering that you're reading a book about ESA—a sign that indicates you're thinking long and hard about how to assign your company's critical and scarce IT resources for at least the next two to ten years—Moore's model, illustrated in Figure 2-3, might prove of some interest. It's what SAP itself uses to make the business case for ESA. Here it is:

Any corporate activity that increases shareholder value is core. Anything that doesn't is context.

That's the handy rule of thumb, at least. It sounds simple, maybe even simplistic, but let's pause to think it through for a moment. As Moore notes in his book Living on the Fault Line (Collins), "a business process is core when its outcome directly affects the competitive advantage of the company in its targeted markets. Here is the ground upon which companies must differentiate to win power, and the goal of core work is to create and sustain that differentiation."

From that line of reasoning, Moore reaches two conclusions: "For core activities, the goal is to differentiate as much as possible.... And the winning approach to context tasks is not to differentiate, but rather to execute them as effectively and efficiently in as standardized a manner as possible." That does not mean that efficient execution of context processes is not a benefit; it's just not the differentiating benefit that will dramatically increase the company's value.

What does all of this mean in practice? Well, here's what it doesn't mean. Core doesn't necessarily refer to activities that may be critical to your business, such as customer service in some industries. Your actual customers might believe it's critical, but if that were true, you wouldn't have seriously flirted with outsourcing the entire operation to Bangalore. If customer service does not differentiate you from your competitors, it's context. (Unless, of course, you're an outsourced customer service specialist.) Back-office operations are context. Outsourced manufacturing is context you've already implicitly recognized as such. If it is core, why don't you have it in-house?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What happens when core eventually becomes context?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The reality is that what's core today will not always be core tomorrow. Remember, we're not talking about core competencies here. In this setting, core—a business process, a product, some secret IT advantage, whatever—is anything that differentiates you from your competitors. Over time, core naturally becomes context. An innovation slowly degrades into a best practice, and then into a commodity. What do you do with a core-turned-context process? Moore's answer was simple: outsource it. Find someone who considers that process their core, and if there isn't anyone, then spin out the people responsible for maintaining that process. Let it become their core; put them in charge of innovating it, but whatever you do, get it out of the business if possible.

That might be a little extreme, but Moore has the right idea. When core becomes context, it's critical to divert resources away from that activity as soon as possible in order to give oxygen to a nascent innovation that could become core itself. The IT mechanism for doing so is consolidation, the selective culling and repurposing of software and hardware formerly dedicated to core processes that become redundant as they become context and as those resources become needed elsewhere.

At least that's how it should work in theory. In reality, the static nature of today's monolithic architectures impedes consolidation in much the same way it impedes innovation. Faced with a heterogeneous collection of servers and applications that support a core-turned-context process, there is no easy way to abstract the data and functionality from the hardware and software in order to retire unnecessary components or even to identify what those components are.

Along similar lines, there is no prescribed way within the current architecture to cost-effectively recycle and reuse prior investments in context-enabling applications (i.e., ERP and the like) so that they might support core processes about to become context. Within the current architecture, enterprise applications are like barrels in a river about to flow over a waterfall. Once they've gone over—falling from core to context—there is no resource-effective way for those investments to support the core processes that might come floating down the river in the future. The IT components are differentiated from each other, but the process isn't differentiated from competitors anymore. And the business isn't deriving any value from an expensive IT effort that increases spending on context every quarter.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

How does ESA enable consolidation and reuse?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Through the same set of attributes, actually. Because the enterprise services residing within ESA are loosely coupled, and the composition is not hardcoded, but rather, is assembled through process orchestration and modeling—they're just combinations and recombinations of underlying services, remember?—consolidation is simpler. Instead of having to migrate data and applications to a new, streamlined set of best practices running on a different platform, the process in question is already running on that platform; at this point, it's just a relatively simple matter of reconfiguring the underlying scenarios, business processes, and process steps.

Now—as someone once said, this is where the magic happens—those same enterprise services are able to unlock and recycle the functionality that used to go over the cliff. The investment in context now has a greater chance of supporting core activities. Because the process definition has been abstracted from the enterprise applications, it's possible to recombine the resulting enterprise services into new process steps and the like that can support business processes which are core. To understand what we mean, see Figure 2-4.

Figure 2-4: Consolidate and compose business processes on one platform

These recombinations are grouped together under the banner of composition. In the ESA universe, the IT department has a pair of new jobs: one team, the consolidators, is busy consolidating master data, data warehouses, and interfaces and rebuilding them as cost-efficient, contextual processes; a second team, the composers, is busy recomposing entirely new, potentially differentiating scenarios to support the latest and greatest innovation born inside the company's walls. Setting ESA apart from every IT architecture that has come before is the fact that both teams are building upon the same architecture and the same application platform erected from web services. (We'll spend more time talking about these and the other related teams in a new IT paradigm, the repository keepers and the disruptive innovators, in Chapter 3.) The pain points that previously afflicted IT—the high costs and complexity of integration, the expensive but pointless investment in inertia, and so on—begin to disappear.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What kind of innovation should companies pursue, and how will ESA help them?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

It all goes back to speed again and to the beginning of this chapter, actually. Earlier, we mentioned how the time to transparency that encompassed everything from taking a customer's order to passing it up the supply chain to generating a P&L statement had plunged into the subseconds. That was the result of relentless innovation in process execution, a literal race to see who could extract a competitive advantage from the speed of their operations.

However, the final distance between the winner, the runner-up, and the pack wasn't great enough. Light-speed process execution is a best practice well on its way to becoming a commodity. What's next?

The first thought was product innovation; cell phone makers would race to push more models out the door instead of just racing to sell them efficiently. But that didn't happen. For one thing, it wasn't applicable across all industries (it's hard to innovate on something like cement), and in industries with very high rates of product turnover, such as cell phones and consumer electronics, the components are already so commoditized.

So, the last curve left on the graph that appears in Figure 2-1 at the beginning of this chapter is time to change. Can you accelerate and perfect the creation of business process innovations themselves? Call it process innovation . Master practitioners of that art already exist in the world. Dell is the consummate process innovator. Dell doesn't invest much differentiation in its actual products, which are assembled almost entirely from off-the-shelf parts. Dell's core is its vaunted supply chain and its ruthless commitment to perfecting that supply chain—a textbook example of process innovation.

The strategic value of ESA lies in its inherent abilities to foster this kind of innovation. The switch from a modeling-based approach to development, the distribution of analytical tools across the enterprise, and the increasing automation of systems to manage by exception combine to create a computing environment in which it is remarkably easy to detect and model patterns of behavior within the business. If a process already mapped to these patterns exists, fine-tune it. If not, then build one.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What are ESA's practical implementation issues?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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 company—the 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 architect—like a real one, we mean. If your IT landscape were an actual landscape, what would it look like? What services provide the basic utilities—plumbing, power, and the like—and 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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What's the long-term adoption path of ESA? How quickly will I see ROI, and what form will it take?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Figure 2-11 shows SAP's current roadmap for ESA adoption graphed against the evolution of IT infrastructures once consolidation/composition begins and against the evolution of business process as the model-driven approach to IT begins to transform how scenarios are designed and how businesses are structured. As you can see, achieving the full potential of process innovation is still as long as two years away. And that's what you should expect.

Figure 2-11: ESA roadmap

ESA isn't a silver bullet; it's not "best of breed" repackaged under a different name with a new set of marketing materials. It's a complete architecture composed of a business process platform, standards, services, and infrastructure that become easier to use with each passing quarter. Those on SAP R/3 can create applications using services that provide value through ESA principles. This is easier in mySAP ERP 2004 and mySAP ERP 2005, and will be easier still later on. SAP and a large ecosystem of ISVs are committed to making ESA a reality.

"Process innovation" comes in all shapes and sizes, and before business analysts begin building and rebuilding scenarios the way most of us would juggle an Excel spreadsheet, there are small but important gains to be realized.

You may recall that earlier, we made the case that ESA would be a boon for employees in the trenches forced to conform their natural way of working—essentially ad hoc business processes—to the interface limitations of the software. The enterprise applications told them how to work instead of the other way around.

As you can see in Figure 2-11, "Process integration and user centricity" is the very first step. That's already happening in a joint project between SAP and Microsoft, named Project Mendocino (see Chapter 9). Project Mendocino is an attempt to bridge the gap between daily ad hoc methods of doing business—returning emails, composing documents, passing along those spreadsheets—and the structured information residing in the backbone of the business. Microsoft estimates that more than $2 billion a year in wasted productivity is spent by frontline employees trying to bridge the gap by hand-copying data from SAP applications to Excel and back again, with the possibility of costly transcription errors present at every step. (And that assumes they're even allowed to touch the enterprise application or data warehouse in question, as opposed to handing a presumably contextual task to a dedicated power user whose time is better spent working on core-related process innovation. And so on....)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What is ESA's long-range impact on corporations?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We won't walk you through all of the organizational and cultural issues involved in making ESA a reality within the enterprise (that's what the rest of the book is for, especially Chapter 3), but we will wrap up this chapter by using the figure of the business analyst to explore ESA's long-range impact on corporations.

The business analyst isn't, in fact, a power user by another name, nor is she an IT administrator or a financial analyst. Tomorrow's business analyst is today's operations person—the line managers in every business unit with a thorough understanding of both the financial performance of their unit and the day-to-day business processes driving that performance.

By handing over the keys to the company's enterprise services in the form of the business process modeling tools resting atop ESA, two major shifts in the organizational structure are about to occur:

• The dismantling of IT as a roadblock to change, and a transformation of IT into a strategic weapon, has begun.
• Henceforth, processes will increasingly dominate corporate organization charts and hierarchies as the company reorganizes itself to reflect real-world concerns. In this role, ESA and the business analyst are enablers of cultural change—because they're able to render formerly obscure and ad hoc business logic visible and transparent, they're able to drive organizational change and break down false barriers between IT and business.

Taking them in order, let's first pause to consider the current model for custom application design in which the nascent business analyst is responsible only for creating the process model that a succession of consultants and developers attempt to map onto the application they are struggling to bui