Chapter ONE. ESA in the World of Information Technology
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.
Who is this book for?
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.
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.
Why so many questions?
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.
While we try to keep a natural sequence between the answers to the questions, with one question leading to another, this structure abandons any form of story and instead leaves it to readers to find what they need to know. Our intent was to write a book that would be more useful to more people than any other approach. Only experience will tell, and we would love to hear from you. Now we will begin with the most fundamental question of all.
What forces created ESA?
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:
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.
It is possible to access the functionality in a mainframe/client/server stack through application programming interfaces (APIs). But there was no template for this; each time an API was developed, it came with its own assumptions about how it worked and how it should be used.
The mainframe/client/server applications did anticipate the need for customization through metadata, different variables controlling an application’s behavior, and templates for UIs. Customization, however, is a one-time reuse, and as we will see, services are created to be reused in a context unknown at design time. The mainframe/client/server stack worked well when used by competent hands, and huge leaps forward in automation and productivity were made based on this architecture. But because the stack was contained within one application, with the UI, process, application, integration, and information layers tightly coupled at design time, it was impossible to break open a mainframe application and restructure it to solve new problems.
Application proliferation: systems of record are built out
In the late 1980s and 1990s, ERP systems showed the power of the mainframe/client/server stack. Despite growing pains, the widespread success of ERP—with SAP leading the charge—led to the creation of other applications, as seen in Figure 1-3.
While ERP was focused primarily on only the financial and management aspects of a company—before it expanded throughout the 1990s to sales, distribution, and other key functions—new applications such as CRM, SCM, and supplier relationship management (SRM), among others expanded the range of automation.
This led to a proliferation of applications for most companies under the label of “best of breed.” The idea was to get the best application for each purpose. This allowed the VP of sales to have the best CRM application, the VP of manufacturing the best SCM application, and so on. The main benefit of this proliferation was the creation of a comprehensive collection of systems of record that automated common business processes from end to end.
But solutions from different vendors created a problem because they took away the central point of integration in the mainframe/client/server world: the single database. Data was scattered all over the system landscape, or even worse, was duplicated in multiple systems. For example, the same customer data ended up in the CRM system and in the ERP system, sometimes with variations. Perhaps worse, it was difficult to get applications from different vendors to communicate properly, making it more difficult to maintain data consistency.
Communication and integration among applications became even more important when companies realized that essential processes may flow through several enterprise applications. The process that starts with taking an order and ends with the receipt of money, the so-called “order to cash” process, involved many enterprise applications. A financial transaction in the ERP system would move to the SCM system for a factory order, which then went to the CRM system for service questions, and then back to ERP for the final confirmation of the order. Other processes, such as procure to pay and sell from stock, had a similar cross-application structure and required better interaction among all the systems. The best-of-breed model left no one company in charge of making everything work, and whenever a company bought a new solution, it came with “some integration required.” Getting it to work at all actually required expensive, hard-wired integration projects.
Bridging the gap among systems of record
The next challenge facing companies using enterprise applications was integration. How could all of the best-of-breed applications be made to work together to serve the needs of the cross-application processes that were becoming the key to increased efficiency and innovation? As shown in Figure 1-4, the key question concerned how to bridge the gap among systems of record.
Many different technologies emerged to bridge the gap, so a cross-application, integrated view of enterprise applications was created, based on the new possibilities of the Internet as a pervasive network and emerging technology standards such as HTTP, HTML, Java, and XML:
Portals emerged as web-based UI technology that enabled one UI to connect to functionality from the different applications.
Data warehouses collected data from all of the different databases within the applications in one place.
Enterprise Application Integration (EAI) technology created engines that allowed one application to send an XML message—a standard for data formatting—to another application. The receiving application could send a response back, and all sorts of fancy alerting, monitoring, and triggering could happen in central systems for routing and transforming messages.
Business Process Management applications for process modeling and management were frequently coupled with EAI technologies to create a new way to define and execute processes in the center.
Many of these integration tools were powered by application servers, a new sort of structure for applications based on standards such as Java 2 Enterprise Edition (J2EE) that were created for the world of the Internet.
These new technologies started to bridge the gap among isolated enterprise applications and enabled some cross-application coordination and development. The results were encouraging. Portals could bring together UI elements from different applications, as well as gathering information from different sources and displaying them in one place. Data warehouses created one view of distributed information, albeit with a delay caused by batch-oriented extraction processes. EAI technologies connected applications, but these connections were complex and threatened a new layer of unstandardized spaghetti. Parts of the gap were bridged with these approaches and the requirements for cross-application processes were met to some extent. These capabilities fell far short of a unified approach to UI, process, and information integration, however. They also ushered in a new set of problems—integration of the integration technologies.
Portals might need to talk to the data warehouse, which may need to send and receive data through the EAI system, which could be working with a Business Process Management system. The same sort of integration problems that these technologies were designed to resolve among enterprise applications arose among the integration technologies, which also generally came from a variety of vendors. It was “best of breed” all over again, except this time, it concerned integration tools, not applications.
Consolidation: mySAP? Business Suite and SAP NetWeaver
The cost of integrating enterprise applications and integrating integration technologies quickly mounted, leading customers to ask, “Is this really our problem to solve?” SAP thought not, and solved this problem in two ways. First, SAP assembled its own solutions for ERP, CRM, SCM, SRM, and so forth into a unified collection called the mySAP Business Suite. Second, SAP integrated all of the integration technologies into a unified whole, called SAP NetWeaver. Furthermore, SAP started to develop all of its mySAP Business Suite applications using SAP NetWeaver: in other words, integrated applications built on integrated technologies as a platform.
This created the situation shown in Figure 1-5 in which an integrated set of tools could help manage processes across a set of enterprise applications designed to work together.
This approach solved a large portion of the problem of connecting enterprise applications and integration technologies to each other.
SAP NetWeaver is a single, integrated set of technologies used to unify a huge collection of integration and development functionality, including the portal, the data warehouse, EAI, application servers, Business Process Management, and a variety of other systems for supporting mobile devices, for constructing UIs, and for distributing data and managing master data.
SAP NetWeaver allows you to write programs not only in ABAP —the language that has been used for more than 20 years to write applications in SAP—but also in Java. This helps solve the problem of integrating the integration tools, but still the problem of getting all of these applications to talk to each other remains.
Bringing all of the applications together in the mySAP Business Suite helped solve the second half of the cross-application integration problem in a variety of ways. Because the integration points between the enterprise applications started to become well-known, SAP could support them as part of the product, not as a special integration task. SAP was able to add business packages to configure enterprise applications to work together. This left the challenge of integrating legacy applications and products from other vendors into the mix—and finally solving the “best-of-breed” dilemma.
The challenge still remained, however, to be able to recombine systems of record to solve new problems. The connections made possible by SAP NetWeaver allowed some processes to flow from one enterprise application to another, and solved a host of other problems as well. Much of the power of enterprise applications was still locked in the monolithic structure. Businesses needed to change faster than the connections between applications could be constructed.
The web services era
A new phase in the evolution of enterprise application architecture started with the emergence of web services based on XML. Web services comprise a family of interrelated standards that work together to provide a simple way to allow program functionality in different languages and on different platforms to interoperate.
Web services are based on sending XML back and forth in a way somewhat similar to EAI systems. But they use a simpler protocol—typically based on HTTP—and inside it they can embed XML using protocols such as SOAP so that one web service can send another web service a message very easily. This interaction provides interoperability across applications and technologies from different vendors. Because every vendor supports the basic web services standards, messages can be passed from one service to another, regardless of the architecture of the underlying application.
Web services (described in detail in Chapter 14) emerged as a standard and became popular very quickly. Almost every vendor adopted and implemented basic web services standards immediately and, for once, a standard was quickly agreed on by the entire software industry.
The arrival of web services offered an exciting way to solve the problem of how applications from different vendors could communicate based on a common standard, as shown in Figure 1-6.
One implementation detail here is that SOAP is just one of the communications protocols that could be used with web services. It is possible for other protocols to be used as well, but in practice, most web services use SOAP through HTTP to ensure interoperability. Also, each web service is described in something called a Web Services Description Language (WSDL) file. This file could be stored in a repository that was defined by the Universal Description, Discovery, and Integration (UDDI) standard, which allows the storage, search, and retrieval of WSDL files.
Web services provided a jolt of excitement to IT because they promised a solution to the challenge of connecting many enterprise applications in a standard way. They also offered a solution to breaking apart layers of the application trapped inside the monolith. Any enterprise application could use web services to present its functionality for reuse. Any platform, such as Microsoft Windows, could use web services from another platform, such as Unix, because they were based on HTTP and other standards that were supported on all platforms. Web services could be implemented in any programming language. When programmers wanted to use something that was encapsulated in a web service, they didn’t have to learn a proprietary API. And UDDI promised a way for everybody to learn what web services were out there.
The biggest new idea to emerge from the concept of web services was called service-oriented architecture (SOA). The idea of SOA had its roots in many other ideas and approaches that had been circulating in the computer science world for a while. CORBA, DCOM, and EDI are similar in approach and intent to SOA. The notion is simple: think of components as reusable parts and reusable services. It is a powerful notion, one that discards the underpinnings of the mainframe and client/server architectures. SOA was a collection of data and functionality that is reusable across different programs. In many ways, SOA is an external, cross-application form of object-oriented programming. SOA created reusable collections of data and functionality, which are similar to objects.
So with SOA, instead of a monolithic, big-black-box, mainframe type of application, you could build a series of services that you could recombine each time you needed to solve a new problem. You would not have to constantly start from scratch. The functionality in the layers inside the monolith were now set free. No longer tightly coupled to each other, the functionalities could be put to new uses. With this new approach came new terminology. Systems of record now also became known as service providers. Applications that used services from systems of record became known as service consumers.
The Web services and SOA spawned a lot of work on standards and how to standardize and build applications. XML was a very important way of expressing those standards. Standards started to emerge for making web services more secure to create standards for global data types for reliable messaging. The UDDI standard was created to help people find services. Development of industry standards was also accelerated. This raised the question of what sort of application would be built on top of service providers, as shown in Figure 1-7.
SOA became the blueprint for new forms of applications that bridged the gap and automated new processes based on services from systems of record. These applications clearly were going to be different from the mainframe/client/server applications. Everything would not be contained within one application. Processes could start in one application and be handed off to another, coordinated by the center. Communication inside the composite applications was going to be far more standardized, based on a unified approach to UIs, processes, and managing information. Data would be distributed across many different repositories. These new applications were called composite applications, as shown in Figure 1-8.
For companies such as SAP, which is focused on providing business value, SOA was a great idea, but primarily a technical one. Composite applications are the way that SOA would be brought to life and put to work. To create new functionality, you could use web services from existing systems of record to provide the base for a new composite application that might have to add just a few new services to perform a task. This made profound business sense because many years and much money had been put into creating these applications, and they worked well, solving the problems they were intended to solve. (Remember, you also can think of legacy applications as applications that work well to solve stable problems.) But new problems were emerging that needed to be solved, and innovation was becoming more important, not just as a way to secure a leadership position in the market, but also as a way to survive. Composite applications promised a way to use services from a variety of different enterprise applications that were exposed through web services and then to create a new sort of application.
And because composite applications were reusing parts of other applications, you could separate the process logic for a process such as order to cash from the underlying systems that were implementing it. That made it easier to change and optimize the orchestrated process and helped reduce IT as a bottleneck.
Moreover, UIs could be separated from the application logic, which allows composite applications to have UIs tailored for different process automation roles. For example, one person might need to see the process from end to end, and another person might need to see one step of the process. The UI could simply show what each role needed. All of this ended up creating a new sort of architecture for a composite application, as shown in Figure 1-9.
This simple vision for composite applications is particularly popular for companies selling professional services, as well as selling tools to build web services. The underlying assumption is that the arrival of web services and the tools to build them mean that IT departments should immediately begin building their own services and using them to create composite applications under the SOA umbrella. After the bill for creating and maintaining custom web services increases, this approach will again lead to the question, “Is this really the IT department’s problem to solve?”
SAP’s answer is no, and a simple automotive analogy explains why. A Porsche Boxster has 70 percent of the same components as a Porsche 911. The remaining sections of the Boxster are simply new parts added to the 911, producing an entirely new car altogether. This is possible because a huge inventory of reusable parts exists, and they were constructed specifically to be reused; just the idea of having reusable parts is not enough.
The idea of composite applications is not enough either. A reusable inventory of web services will allow the creation of new applications from existing components. But for this to work, you don’t just need the idea of reusable parts; you need reusable parts that were constructed in a way that promotes reuse.
What is ESA?
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 to refer to all of these sorts of process logic.)
How should applications be developed? Are new development methods needed? How can things be simplified? Who is going to do the work of creating the services that are built on top of the enterprise applications? Is there any standard for those?
How will industry standards be incorporated and made useful? How will all interested parties in the architecture communicate and participate in the ongoing design process?
It is quite clear that there are plenty of questions to ask. One, however, is perhaps the most fundamental: who should answer the questions? Each IT department?
SAP, living up to its traditional dedication to solving the whole problem, is not satisfied to just leave these questions to IT departments to solve on their own. One of the most important aspects of ESA is the blueprint it provides for building composite applications based on the principles of SOA with all questions answered and details filled in. As part of its commitment to ESA, SAP is not only filling in the architectural details, but also creating the collection of reusable parts (the Enterprise Services Inventory), a repository for searching through the parts and using them to create programs (the Enterprise Services Repository), and an ecosystem that includes input from partners, customers, and standards bodies in a systematic way (the Enterprise Services Community, or ES-Community).
To simplify the explanation of ESA we have created a basic stack, as shown in Figure 1-10, that serves as a unified model for UIs, processes, and information, with a clear separation of duties for each layer.
Later sections of this book will examine each area of this stack in detail. But to prepare for further learning, here is a quick, top-to-bottom explanation of each layer of the stack that shows how it answers many of the questions previously raised.
User interface
UIs in ESA have much more structure than in previous generations of enterprise applications. Most of the time UIs are created through modeling, or by using patterns as building blocks, or both. For example, the UI patterns of work center and control center will be a standard part of ESA applications. Work centers are UI elements designed to take a user through the steps needed to complete a process. Control centers show the status and are the central point of access for all of the work centers that a user may be involved in. Common approaches to managing lists of tasks have also been created. The goal is to reuse configurable components and adjustable patterns to reduce the complexity of building and using UIs for enterprise applications.
Process orchestration
Process orchestration is the notion that process logic will be separated from all other kinds of logic. Process orchestration will happen at many different levels. Composite applications will use process orchestration as the coordinator and integrator of a set of process steps available through enterprise services provided by enterprise applications. Service providers such as existing enterprise applications will use workflows for processes within their boundaries and will use layers of process integration logic to accept incoming or send outgoing processes to and from other systems. Individual services may use process orchestration to create composite services. The goal in ESA is to make process orchestration easier to build and modify so that applications can be changed quickly, cheaply, and by a wider group of people than is now possible.
There are two main flavors of process orchestration. Frontend process orchestration is conversational. It is focused on collaboration and interaction with users. A technology called guided procedures can walk a user through a set of steps that may involve many different enterprise applications. Guided procedures are designed to enable you to easily maintain a context for a process by allowing documents to be attached. They are also flexible and allow you to change the process flow for one instance of a process on the fly.
Backend orchestration is about long-running, primarily asynchronous processes. An example of backend process orchestration is the cross-component Business Process Management functionality in the SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI), which has a high-performance, robust business process engine for using enterprise services to automate complex, long-running processes that are triggered by events, send and receive alerts, and coordinate the activity of many transactions asynchronously.
Enterprise services
Enterprise services come in many forms. Usually the term enterprise services refers to services that are being exposed by the enterprise applications or by other service providers to participate in the support of business processes. Reusable utility functionality offered by SAP NetWeaver can also be presented as enterprise services. So can services that specialize in managing a process or engine for special-purpose calculations of taxes.
Although enterprise services are based on web services standards, they are different from plain web services in that enterprise services are created to participate in reusable processes, not necessarily in just the functionality that has been exposed at any level of granularity. Enterprise services live in the Enterprise Services Repository that stores data that describes the services’ interfaces, how the services would be used in model-driven development tools, and how the services fit into models that describe business processes.
SAP has both external and internal processes for controlling the growth and design of the Enterprise Services Inventory, the name for the sum total of all enterprise services.
Business objects
Business objects are the collections of related data and functionality inside a service provider. Business objects also can be units of modeling, a description from a modeling perspective of related functionality. In the purest form of ESA, enterprise services are extensions of business objects. In other words, enterprise services expose the functionality of business objects to the outside world. Business objects also show up inside composite applications, where they consume services and can be the building blocks for services provided to other programs. One of the major challenges of ESA is that enterprise services must be constructed on enterprise applications and other service providers that were not originally designed for ESA. These applications don’t have the equivalent of business objects inside them that make it easy to build services. The challenge of building enterprise services on enterprise applications based on the mainframe/client/server stack is that the functionality in the application is not separated into reusable chunks. In attempting to create a reusable enterprise service, one must take care not to have any unwanted side effects.
Distributed persistence
In ESA, the core assumption of the single database that was so central to the mainframe/client/server architecture is no longer valid. The ESA stack assumes not only a distributed repository, but also certain levels of redundancy. Part of this is handled through aggregation and distribution mechanisms such as SAP NetWeaver Master Data Management (SAP NetWeaver MDM) and SAP NetWeaver Business Intelligence (SAP NetWeaver BI) that create a logically normalized information model on a physically distributed collection of repositories. But the whole solution requires more. Composite applications must have their own robust persistence mechanisms when they store new information that extends systems of record. Distributed database transaction mechanisms that allow many repositories to be updated in a consistent manner are also defined by ESA.
How will ESA change how applications are designed and built?
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.
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.
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.
Process component modeling defines the process components, the interaction among the process components (called integration scenario modeling), and the interaction between two process components (called process interaction modeling). Inside the process components the processes are modeled using enterprise services and business objects. The value of this modeling is that it closes the gap between business modeling, which takes place in terms of process components and modeling how those process components will be implemented. In the current forms of business modeling, there is a leap from the scenarios to the processes, and this leap does not connect the two as clearly as process component modeling does. This sort of modeling is yet another way that ESA brings the business and IT onto the same playing field.
What supporting infrastructure does ESA require?
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.
Model-driven, pattern-based development tools
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.
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.
Enterprise Services Infrastructure
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.
Enterprise Services Repository
In order for enterprise services to be reusable, it must be possible to find enterprise services, determine what they do, and then bring them into development tools. The Enterprise Services Repository is a directory of enterprise services that does all of these things. An easy way to understand the Enterprise Services Repository is to think of what an automotive engineer would need if he were creating a Boxster from reusable parts. First, he would need a directory of all reusable parts. The Enterprise Services Repository is a searchable archive. Once he found a part, he would want to know what it did and how it was intended to be used. The Enterprise Services Repository stores a variety of types of modeling data. It stores how any enterprise service is linked to higher-level business processes that may be part of business scenarios and process component models that describe how an enterprise application or an industry process works. The description for the service interface that is used to invoke the service, the WSDL file, is also stored, and development tools use it to invoke the service or use it in modeling. The Enterprise Services Repository also stores how an enterprise service is related to business objects that implement it. A variety of other documentation and metadata about the service are also stored. Finally, the automotive engineer would like to know if any of the parts were built and available. The Enterprise Services Repository also stores how the service may be accessed at runtime.
Enterprise Services Inventory
The Enterprise Services Inventory comprises the services that SAP is creating, based on the mySAP Business Suite and SAP NetWeaver, to support the creation of composite applications. Enterprise services are described in the Enterprise Services Inventory in such a way that business analysts can easily understand them. In 2005, the first batch of enterprise services were described in the Enterprise Services Preview on the SAP Developer Network (SDN; http://sdn.sap.com). WSDL files and process descriptions were provided for hundreds of enterprise services based on mySAP ERP and some industry-specific solutions. In the first quarter of 2006, the first implementations of services in the Enterprise Services Inventory started to arrive, along with xApps and other composite applications that use those services; since then, implementations have proceeded in quarterly installments. The composite applications include Project Mendocino for Microsoft Office integration of SAP applications, and composite applications for analytics, self-service, and other key processes that extend and improve the functionality of the mySAP Business Suite. In the future, SAP partners and customers will add to the Enterprise Services Inventory by implementing services created through the ES-Community.
Life cycle management, operations, and security
ESA changes what software vendors provide to customers and what is available for reuse. In the mainframe era, applications and parts of applications had life cycles. They were delivered, installed, configured, maintained, and retired. SAP has used modeling in the SAP Solution Manager to simplify the process of configuring applications. Now the world of life cycle management will become a lot more challenging. Instead of a modest number of applications and parts of applications, thousands of services will be delivered to customers. Each will have its own life cycle. Managing this world will require new, model-driven configuration tools and support models. Operations and security practices will also have to change to accommodate the new world of services. (All of this is discussed in Chapters 18 and 19.)
Industry and technology standards
ESA could not exist without the hundreds of standards that have been developed to make application development and interoperability much easier than they have been in the past. ESA creates an environment in which the value of standards can be harvested in terms of both technology and business semantics. At all levels of the stack, ESA uses technology standards such as J2EE, WS-Reliable Messaging, WS-Policy, and so on, to improve interoperability and reduce implementation costs. ESA takes all of these technology standards and provides the context and plumbing for them to work together in a way that maximizes the value each can create. In isolation, technology standards provide a certain level of value, but when combined, a synergy is created. In the same way, enterprise services also bring semantic industry standards to life. Standards such as RosettaNet and CIDX describe standard document formats and provide guidance for how these formats should be used to support various business processes. A set of enterprise services that uses these standards can be put to work quickly to automate business processes among companies so that new partner relationships can be implemented in days rather than months.
ESA ecosystem
The ESA ecosystem consists of all of SAP’s capabilities, plus those of its partners, brought to bear in a coordinated way to solve problems for customers. SAP is promoting ESA adoption by software vendors in important vertical markets. Companies such as Intel, Cisco, Microsoft, and others have agreed to support ESA in their products and are certifying a wide variety of products to work in an ESA-compliant manner. The ES-Community will allow partners and customers to work with SAP to design enterprise services to solve emerging technology and industry problems. This ecosystem will make it easier for SAP, partners, and customers to gain more value from ESA.
Is ESA compatible with event-driven architecture?
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.
What is the promise of ESA?
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.
Unfortunately, there is no magic wand, and instead, SAP and its customers and partners must gradually build the inventory of enterprise services, the repository to hold their descriptions, and the modeling and development tools to construct service providers and composite applications. The next question addresses how that is likely to play out.
How will the transition to ESA occur?
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.
While the transition described here is oversimplified, it does get to the essence of the change that is taking place. The engine of value creation will be composite applications based on ESA. Application design will change from a process focused on solving one problem to a task centered on assembling—or creating, if needed—enterprise services. In essence, the design process will no longer be about how one application supports a process; instead, it will be about how a set of services can be constructed to support many different end-to-end processes implemented by composite applications. (The Enterprise Services Design Guide, available on SDN, is a comprehensive look at this sort of service enablement.)
But the shift to this new way of thinking about processes and applications will be incremental, as the three phases just described suggest, as will the implementation of the new applications. To improve our understanding of how ESA will affect enterprise applications, we will explore in more detail the general areas in which ESA will improve applications, and then move on to how ESA will affect the current installed base of SAP applications, how the next releases will change, and how applications will be structured in the long term. Figure 1-15 shows when various ESA-related products will be generally available.
ESA’s areas of focus for applications
As the “What is ESA?” answer explained, ESA affects all levels of the application stack. So, what will be the value? If ESA can improve many things, what will SAP decide to improve first? Figure 1-16 shows the areas on which SAP is focusing.
Here is how ESA will change the application landscape in the long term: SAP will continue to build on xApps composite applications that SAP and ISVs sell as packaged products, and will create even more composite applications to improve user productivity and extend the reach of mySAP Business Suite solutions. (Project Mendocino is an example of this strategy.) Many of these applications will be intended to promote self-service so that employees and managers will be able to perform by themselves the tasks that power users currently perform. Role-based interfaces that walk users through processes step by step will be one of the key ways that productivity is increased. Providing enhanced analytics capabilities will be another major focus that will be satisfied through composite applications that either stand alone or become embedded in mySAP Business Suite solutions. The analytics applications will not only bring together important information about an issue or task but will also allow action to be taken. Many of these new composite applications will be built with modeling tools such as SAP NetWeaver Visual Composer and other modeling environments that allow business analysts to participate in the construction and configuration of composite applications.
Composite-application building will be supported by an increasing inventory of enterprise services that the Enterprise Services Repository will describe. The first step in this service enablement was the ESA Preview system on SDN, released in mid-2005. Starting in the first quarter of 2006, the first implementations of services in the Enterprise Services Inventory based on the mySAP Business Suite were released, providing a new gateway for composite application development. The composite applications for the purposes mentioned earlier will use these services, but they will also be available for use by SAP customers and partners, who will be able to use the SAP NetWeaver Developer Studio, the SAP CAF, SAP NetWeaver Visual Composer, and other development techniques to put these services to work or to configure and adapt composite applications created by SAP. As each release of mySAP Business Suite solutions and SAP NetWeaver arrives, the Enterprise Services Inventory will grow and enterprise services will become easier to create. Modeling tools for service composition to create enterprise services will arrive and business objects will start to show up in the mySAP Business Suite solutions that will allow the automatic relation of services that support UI and application patterns.
Configuration and administrative functions for applications will be supported with tools for life cycle management. SAP Solution Manager relates high-level business processes to processes automated by applications using a cascading set of models.
While the big picture is helpful to know, most companies that use SAP software are interested in how ESA can help them today. The answer depends on where you are starting.
ESA today: SAP R/3
Many companies that are running SAP R/3 4.6c think they must upgrade to mySAP ERP 2004 or mySAP ERP 2005 to implement ESA. While more is possible with later versions, SAP customers have made excellent progress on their ESA strategies on SAP R/3 4.6c using the tools and functionality provided by SAP NetWeaver. Figure 1-17 clarifies how enterprise services relate to R/3.
You can use SAP R/3 4.6c to create composite applications by using the SAP NetWeaver Developer Studio to create web services based in BAPIs and Remote Function Calls (RFCs) in ABAP or in Java. Creation of such web services can be accelerated through the Web Service Infrastructure, which automatically generates proxy code for accessing RFCs, BAPIs, Enterprise JavaBeans? (EJBs), IDOCs, and other interfaces. The SAP NetWeaver Portal or other programs can use these web services. SAP NetWeaver XI can be used to model processes based on web services and other services described in the SAP NetWeaver XI Integration Repository.
With SAP R/3 4.6c, ESA is much more a do-it-yourself activity resembling the offerings of tools vendors; if you use these techniques, you can create flexible and powerful composite applications.
ESA in mySAP ERP 2004 and mySAP ERP 2005
In mySAP ERP 2004 and mySAP ERP 2005, SAP provides a complete environment for gaining the benefits of ESA. Figure 1-18 explains the relationship of ESA to mySAP ERP 2004 and 2005.
Composite applications for the purposes mentioned earlier, such as Project Mendocino and self-service, will be provided. The Enterprise Services Repository and Enterprise Services Inventory will be populated. Advanced tools for creating composite applications such as SAP NetWeaver Visual Composer and SAP CAF will become available.
With all of this support, companies can start to use these services and development techniques to solve new problems right away. Applying composite applications to the most pressing problems facing a company, as well as to areas in which innovation is important, can increase the quality of IT support for the business and reduce time to market for new ideas.
Based on SAP’s support for ESA, companies can start the process of cultural change. They can learn to think of their IT infrastructure in ESA terms and build their skills so that increasing value can be created.
ESA in the future
In future releases of SAP products, the composite application architecture will expand its scope. More and more extensions of mySAP Business Suite solutions will be delivered as composite applications. Parts of the mySAP Business Suite functionality may also become composite applications. Models will become more visible at all levels of development. The complexity of adapting SAP products will be reduced. Many more role-based and industry-specific applications will be supported at an affordable cost. In this world, the differentiator will be the quality of the business vision for automating processes. Companies that gain the vision and skills required to take advantage of ESA will have an important advantage over those that do not. Figure 1-19 describes the future of ESA.
How can ESA be addressed at a tactical level?
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.
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.
The challenge in discussing ESA is that it can bring up many issues at once, and discussions sometimes wander and become confusing because too many topics are in play. One tool for achieving clarity is a map we created for our use in this book. This map combines the five tactical levels with the three architectural perspectives to create the map shown in Figure 1-21. You can use this sort of map to identify quickly the areas that any discussion is touching on so that you can address issues one at a time and with a clear context.
For example, if a businessperson comes up with an idea for a composite application that automates a process across many different lines of business, how can you carry on a discussion about what must be done? One way would be to go through each box in Figure 1-21 and bring up the issues and questions related to each box. Normally, not all boxes apply. At the end of such a process, you will have a to-do list that you can easily allocate to those in charge of each perspective.
Why does ESA matter?
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.
What are the core values of ESA?
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.
Where can we go for more answers?
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.
ESA in action: Mitsui
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
Both the policies and the objectives were at the top of the development team’s mind when it finally came time to implement what became known as the MICAN (short for the slogan “Mitsui I can!”) Process and the MICAN System, which were composed of three types of reform. Organizational reform was enabled by the Shared Service Center model adopted by the project team. Process reform was introduced using the Process System Integrity (PSI) model based on the Sarbanes-Oxley Act. And the underlying IT reform was realized by the adoption of ESA and was based on SAP NetWeaver—specifically, its SAP Business Information Warehouse (SAP BW) and SAP EP components, with SAP R/3 as the base ERP application.
Mitsui built the MICAN System using SAP NetWeaver as the platform, with SAP R/3 and SAP BW comprising a layer of functionality immediately below. After mapping Mitsui’s diverse IT landscape to the streamlined business processes identified in the MICAN Process, approximately 400 commonly used pieces of IT functionality were redesigned as reusable web services, of which 100 to 150 appeared in nearly every cross-company process. A rudimentary Enterprise Services Repository was created, as each enterprise service was assigned an ID number and was registered in a database to aid in the easy visualization of operational processes.
Business processes that were once unique to individual Mitsui subsidiaries have since been integrated and centralized, vastly improving the speed and integrity of data as it flows across the combined enterprise. To make these redesigned processes visible to Mitsui’s managers, the project team implemented SAP EP to create a portal that would unify them within a single UI. The finished portal serves approximately 9,000 users via a single-sign-on secured site, with role-based profiles providing the appropriate level of functionality and data to any given user.
Looking toward the future, Mitsui intends to keep the MICAN Process and the MICAN System at the heart of its continuous efforts to streamline its efforts in Japan while rolling the system out to its overseas subsidiaries and affiliates over the next few years.
Get Enterprise SOA now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
