Chapter FOUR. ESA Fundamentals: Learning to Think ESA
The preceding chapters provided an overview of ESA, along with a survey of ESA’s business value and information on how a company can evolve toward ESA. While these chapters effectively set the context for a deeper discussion of ESA, more work remains. ESA is essentially a new way of thinking about how enterprise applications are constructed and how they are used to support a business. At almost every level, ESA reshapes traditional thinking, introduces new concepts, and sets forth a new paradigm for building IT to support the needs of modern businesses. This chapter will introduce and explain the ideas that are fundamental to the transformation of IT that ESA will achieve.
What is architecture and why is it important?
In essence, architecture is a contract that organizes the work of hundreds of thousands—or even millions—of people. It describes the structures used in the course of that work, which in the case of software refers to data and other abstract mechanisms that will have a certain responsibility and that will be connected in a standardized way.
Architecture makes these standard abstract mechanisms or components useful by clearly defining the relationships between them. Complex, unwieldy systems can be reduced to their essence—i.e., to these relationships—and it becomes possible to see which pieces of the system are the most important. It works both ways: if you are attempting to create a piece of software that fits into an existing architecture, you’ll need to understand what that piece needs to do, how it will connect to other pieces, and what its relationship to the rest of the architecture will be.
Architecture also defines the life cycle of the components. Who builds them? How are they built? How are they used? How can they be improved, and, eventually, how will they be retired? In other words, how will an architecture come to life, and how long will it live? The answers lie in the details of an architecture’s design at specification time, design time, and implementation time, all of which we will explain later in the book.
For now, the key thing to remember is that the architecture circumscribes the capabilities—and the limitations—of any component within it, which is why great care must be spent in crafting the architecture before creating any components. If done properly, everyone who participates in building a system atop the architecture will know—because of the relationships clearly defined by the contract—what they should be doing and how they should be doing it as they create each component.
The goal of any software architecture is to enable the construction of systems to execute some type of task in efficient and flexible ways. For the purposes of this book, the architecture we’re focused on is the Enterprise Services Architecture, and the goal of ESA in particular is to enable businesses to use software in a manner that is both more flexible and less costly than any previous generation of software architecture.
What is enterprise architecture and how will ESA change it?
An enterprise architecture is two things, only one of which has to do with IT. The first step to creating an enterprise architecture is to understand how the business should best be organized. An enterprise architecture begins with business goals, which are met through the design of a complex of interrelated business processes. The second step specifies how IT will support that organization and the underlying processes.
Historically, enterprise architects have been limited in their ability to design with processes and IT solutions to support them by the flexibility of enterprise applications such as Enterprise Resources Planning (ERP), Customer Relationship Management (CRM), Supply Chain Management (SCM), and the like. Enterprise applications started as large, complex collections of processes that were configurable up to a point. So an ERP application contained a basic process for running purchase orders or invoices, a CRM application had a basic process for handling a customer inquiry, and an SCM application had various processes embedded within it for interacting with suppliers, monitoring the factory floor, or managing inventory, to name a few.
It is easy to forget that before the advent of ERP and the rest of the enterprise applications that emerged, most business processes lacked standardization. The first generation of enterprise applications created a standard form for the automation of the common processes that appeared in most businesses. The architecture of enterprise applications allowed for configurability, but that was not the main point. When the requirements that these enterprise applications met remained stable, the applications did their job brilliantly.
The challenge for enterprise architects—the managers tasked with defining and refining an enterprise architecture—came when new business requirements and new business processes were needed. They were forced to tailor their organization’s appetite for new processes as closely as possible to the business logic embedded in existing applications. It quickly became clear, however, that many processes might start in CRM, move to ERP, and then finish in SCM, and the challenge for these architects and for IT departments became understanding, defining, and adapting these processes to work within these constraints. In many other cases, businesses became frustrated at their inability to adapt the processes embedded in standardized applications to meet their emerging needs.
Enterprise architecture soon became the dark art of splitting the differences between the functionality provided in enterprise applications and the actual needs of your business and then solving urgent problems via expensive and time-consuming custom applications and integration efforts.
ESA was created to satisfy the needs of modern businesses that are interested in process innovation, which means being able to automate new processes as well as improve and optimize stable processes to take advantage of new challenges. Dell, for example, is famously successful, not because of any innovative products (it builds all of its products using off-the-shelf parts), but because of the execution and continual refinement of its supply chain and manufacturing processes.
The demand for flexibility to automate new processes and to improve existing ones changes the landscape dramatically. The standard processes of enterprise applications explode into smaller bundles of enterprise services built to execute proportionally smaller tasks. So now, for example, one service might accept a purchase order and another one might validate that order according to a defined set of rules. A metaservice might control the handoff of data from one service to another as it’s passed along a string of orchestrated processes designed to reflect how the real-world business process actually works.
ESA preserves the gains of the previous generation of enterprise applications while introducing flexibility. All of the standard processes that made ERP, CRM, and other enterprise applications so vital to efficient operations will stay in place. Instead of being powered by monolithic architectures, however, they will be powered by services. The existence of services is the engine of flexibility. It’s not important where these services originate—whether in ERP, CRM, or SCM—because it’s now possible to orchestrate them independently. The Enterprise Services Repository incorporates, a central tank of services that SAP has created for customers, and it will include services that companies create on their own. All of these services will be stored for use and reuse, subject to the rules and standards implicit in ESA.
What does this mean? It means that instead of having to think of business processes within the constraints imposed by the limits of today’s enterprise applications, you and your enterprise architects can begin mapping the functionality of a service or collection of services to the actual needs of your business. The barriers to adapting services to your needs are much lower, thanks to their finer granularity. Instead of splitting the difference between the functionality available and your actual need, you can focus on adapting these highly granular services to match your processes perfectly. And because the processes aren’t welded together with hard code, but rather are knitted together with modeling tools and process orchestration mechanisms, you should have a much easier time adjusting and readjusting the alignment of these services over time to meet your needs.
In this new world, the CIO is transformed into a chief process innovation officer, someone who focuses less on tools and ensuring that the IT environment does not break and more on perfecting processes and realigning IT resources to support them. The chief IT officer will focus on creating the systems to support these processes and squeezing out costs and inefficiency.
One simple way to think of ESA is as a technical enabler required for process innovation. In the previous generation of enterprise architecture, processes were automated but not flexible. Enterprise services promise to make them automated and flexible at an affordable cost.
What motivated the creation of ESA?
SAP cofounder Hasso Plattner conceived ESA as a solution to the increasingly unwieldy number of enterprise applications appearing in corporate IT environments. As we discussed earlier in this chapter, all the functionality necessary for a given process could no longer be contained within a single application.
Plattner originally conceived of ESA to support cross-applications that could cross the boundaries of the enterprise applications beneath them and combine pieces of functionality into a new application running above them. These became SAP’s family of packaged composite applications which were branded as “xApps”. The creation of xApps overcame several of the implicit assumptions underlying enterprise applications and the previous architecture that no longer applied in the modern business world.
First and most important was the idea of the database as the single point of integration. This was the dominant model during the era of client-server approaches in the late ’80s and early ’90s. When entering a purchase order into ERP, for example, that order is added to a database that everyone in the system can access. Anyone wishing to revisit that order later can easily retrieve it from the database. But when an xApp begins crossing the boundaries between applications, borrowing data and functionality from each, the customer data may exist in different places—in CRM, SCM, and ERP—and it may not be synchronized across the three, leading to the potential for inconsistency, something that the single-database world was designed to prevent. ESA has many different mechanisms for handling this problem, as we will discuss later in this chapter and later in this book.
Another transformed assumption that ESA had to address was the idea that processes were automated within the boundary of an enterprise application. xApps by definition need to define processes without regard to the existing boundaries between enterprise applications.
The final assumption was the role that standard software would play to meet new business requirements. If emerging requirements were to be met, enterprise software would no longer comprise standard processes encased in enterprise applications. The moving parts would have to be exposed. That need led to the creation of enterprise services. Instead of delivering functionality in the unit of an individual application performing a single task that can’t be reused, businesses could free pieces of functionality from their enterprise applications, repackage them as services, and design these services (the job of the architecture) to be flexible and reusable. So, instead of creating a new application every time the business situation changed, you could simply tweak the combination of services within a given application. Now build versus buy has become buy, build, and compose. That’s the vision behind ESA; Figure 4-1 provides a visual definition.
What are the architectural challenges of ESA?
The architectural challenges of ESA stem from the violation of the implicit assumptions referenced earlier; the ideas of the database as a point of integration and the application as a process boundary no longer apply.
The first challenge is flexibility . Once services are created and processes are automated, optimization and innovation depend on a company’s ability to not only implement processes, but also be able to change and improve them based on experience. This is a huge challenge, considering the average optimization cycle of today’s custom application projects, which may range anywhere from 9 to 18 months—a timeframe that is no longer acceptable. Companies need to implement a new IT system within weeks and months in order for it to have an impact. The tradeoff for flexibility has traditionally been cost—it’s easier to make changes to a system when development costs are no object. But that implies the system was never very flexible in the first place. Inherent flexibility implies a corresponding reduction in cost to make changes because flexibility has to be affordable in order to be meaningful.
The second challenge facing ESA is data consistency —how to unify and synchronize all of the information and process flow in an automated process where data is stored in lots of different databases and lots of applications are supplying services.
The third challenge is heterogeneity . The modern enterprise can’t assume that all of its software and systems will always come from a single vendor. A heterogeneous computing environment is a given in today’s world. In fact, it is inevitable. Even if management consciously set out to choose a single vendor, mergers and acquisitions make it inevitable that systems from a different vendor will arrive with some acquisition down the road. And even if the company is an island, homegrown applications or specialized tools from a niche vendor will ultimately introduce complexity at some point.
The fourth challenge is the user interface (UI) . Now that companies have the ability with ESA to combine and recombine enterprise services in any manner they wish, designing the most efficient and the most appropriate interfaces for the delivery of the right functionality to the right person becomes extremely important. As processes are developed, roles must be developed in tandem for the employees charged with collecting information, evaluating that information, and making a decision based on that analysis. But what data, presented in what form and at what level of aggregation, is appropriate for each person in that chain? Torrents of data may be flowing from any given business process, but to be efficient, each role that plays a part in that process needs that data reduced to the level at which people in that role can best perform their appointed tasks. Previous generations of enterprise applications had been built as reflections of the database’s internal structure rather than as reflections of the roles people play in the application’s process. In practice, this meant that performing a simple, real-world task required using 4, 5, 10, or even 15 UIs reflecting different aspects of the database structure instead of accessing a single screen specifically created so that that person could perform his task. The UI challenge is one of bringing together and making affordable the creation of many role-based interfaces for the convenience of human users.
All of these challenges point to a tremendous impact and change in IT development. The need for inexpensive flexibility, along with the demand for customized interfaces throughout the organization, implies that development must become cheaper and faster in a hurry. That will require the demystification of IT. Development must become simple enough so that not only will highly trained programmers and information architects build and deploy services, but managers outside of IT will as well. SAP has envisioned the role of the business analyst, a manager versed in IT but lacking traditional development skills, though she has a much deeper understanding of the actual business processes being automated than the developers in IT do. While IT focuses on exposing services and maintaining the architecture, business analysts will receive the tools to create the necessary applications and interfaces to extend process automation even further.
At this point, the gap between IT and the business will be bridged. IT will supply the business side with those tools, and the resulting conversation—about how to create those interfaces and automate those processes—will replace the lengthy, inefficient negotiations in which the business side explains what it needs to IT, which tries to figure it out and then returns with a requirement spec. And so the traditional dance would have gone on, except that within ESA, the use of services and modeling tools creates a very unconventional development environment.
How does ESA meet those challenges?
The key is the enterprise services themselves. They are the modular, reusable, flexible building blocks of ESA, which are already capable of meeting all of the challenges outlined earlier, provided they’re assembled within an environment that is stocked with the appropriate development tools and honors the contract of the architecture.
Enterprise services are essentially pieces of processes. The pieces can be of any size and degree of functionality. One might be a utility function so small as to calculate only the time of day, and another might be large and complex enough to start the execution of a highly automated manufacturing process. But regardless of how large or how small they are, every enterprise service is designed to be a building block of a larger process, meaning they embody a host of attributes that enable them to meet the architectural challenges outlined earlier—the foremost of which is reusability. Precisely because they are building blocks, they were always designed to be recombined repeatedly, unlike previous generations of applications.
Because they were designed to participate in process orchestration, they were designed to be model driven. Instead of hardcoding services into applications, a new generation of modeling tools will assemble them. In order for a service to participate, it must be able to describe itself to the modeling environment so that its functionality can be adapted and added to the process and connected to other services. This is accomplished using a layer of metadata embedded in the service, metadata that includes descriptions of how to use it, which business processes should be connected to that service, which underlying objects may be implemented using the service, and so on. Metadata can be used to configure the behavior of the service itself and to orchestrate its position within a process chain of services. This solves one of the thornier issues in integrating older applications—the absence of information about their internal workings, which usually leads to unintended side effects during integration efforts. But within ESA, the service metadata is sorted in the Enterprise Services Repository and is summoned by modeling tools at design time to describe the services being used.
ESA also provides a complete life cycle approach for designing services, designing the resulting applications, modeling processes, executing the models, and then actually executing the finished code. The architecture specifies and supports all of these things from the moment they are conceived until they are retired. Services built under ESA auspices are guaranteed to work within ESA systems; the ad hoc nature of previous generations’ integration efforts isn’t an issue here. There are even utility services designed to help knit larger functional services into business processes. (We describe the various types of enterprise services later in this chapter.)
Enterprise services solve the challenges of routing the appropriate data and information to the appropriate interfaces via the use of analytics and roles. Instead of asking users to hunt through the system for the information they need to make decisions, SAP’s analytical tools collect data from every relevant source in the system and synthesize it down to a level appropriate for any given user’s needs. Analytic tools solve one of the most serious side effects of increasingly automated processes. Instead of spinning out yet another UI for every process, analytics provide the ability to route the output of each process automatically to a role-specific UI created for each class of user—for example, CEOs, financial analysts, customer service representatives, factory floor managers, and so on. The analytical tools compile and recompile the processes’ raw data output repeatedly, assembling it in a form that can then be used as a basis for taking action depending on the user’s role within the organization.
The UIs themselves are composed of services, and they can be modeled and attached to automated processes on a flexible, as-needed basis. The result is a composite application, which possesses a degree of flexibility unknown in previous generations of applications because it is essentially a mesh of relatively granular, loosely coupled enterprise services rather than monolithic containers of complex functionality. Those applications—ERP, CRM, and the like—will also have services built from them and on top of them so that they can participate within an ESA framework.
The same attributes will solve the problem of heterogeneity by breaking down the integration challenges from absorbing standalone enterprise applications to incorporating much smaller, self-described services designed to operate in an ESA environment in the first place. Businesses won’t just purchase enterprise services from SAP; they’ll build their own, buy them from third parties, and adapt services from SAP and third parties to meet their needs.
Does ESA make all my existing systems worthless?
Far from reducing the value of existing systems, ESA is likely to extend the lifespan of your existing applications by gradually exposing their core functionality as an increasing number of services. While past generations of software struggled with version control and obsolescence—when even simple upgrades could pose threats to an installed base—ESA is implicitly designed to repurpose these systems.
Service enabling the monolithic functionality of older applications actually increases their value and extends their lifespan by allowing the applications to participate in new processes and composite applications without having to worry about compromising the systems. This flexibility is also extremely useful while still transitioning to ESA, since any system can yield services that are invisible to users and are safe for the underlying systems. Companies are able to choose when, where, and how to adopt ESA principles without tearing anything out and starting over.
What are systems of record?
Systems of record is the term used to describe the role that enterprise applications play in maintaining the state of the enterprise. ERP, CRM, SCM, and all the other enterprise applications keep important information concerning the company’s finances, inventory, personnel, business partners, projects, and other issues. When we refer to systems of record, we are emphasizing how enterprise applications are an authoritative database. When enterprise applications were invented, the role of systems of record was perhaps their most important function. As time passed, however, the foundation provided by a consistent and authoritative database laid the foundation for expanded process automation of the sort that ESA expands further still.
What are transactional systems?
Transactional systems or transactional applications are names for enterprise applications that emphasize the way these applications record information about transactions and are updated through discrete transactions. Sometimes transactions refer to business transactions, such as taking an order, generating an invoice, and accepting payment. Transactions also include important events such as hiring an employee and recording the terms of a contract in a system. When we speak about enterprise applications as transactional systems, we are emphasizing their role in keeping track of business activity represented as changes to databases in a consistent manner.
What are web services?
Web services are a standard way of creating a self-describing service based on XML that uses the Internet to communicate. What is a service? A service is a program that talks to other programs. The self-describing part of web services is the Web Services Description Language (WSDL). Every web service has a WSDL file that describes its interface. This WSDL file, which is expressed in XML, can be used to generate a program automatically to invoke a web service and get information from it. While communicating with a service can be automated, more study is required to understand the information that must be provided to a web service to get the desired result and to use the information properly. The Universal Description, Discovery, and Integration (UDDI) protocol is a standard for creating a searchable directory of WSDL files so that web services can be located and the WSDL files obtained. You can use UDDI when you are designing or running a program. Web services frequently use the SOAP standard for transferring data back and forth, although it is possible to communicate in other ways as well. http://OASIS and the http://W3C, two technology standards bodies, are primarily responsible for the architecture and standardization of web services. The Web Services Interoperability (http://WS-I) Organization has been developing a series of profiles to further define the standards involved for interoperability. New standards for managing web services and improving reliability and security are under development. You can find a detailed description of web services in Chapter 14.
Enterprise services use web services standards to communicate. So, in an important way, enterprise services are web services. But enterprise services are not just web services. Enterprise services have many additional elements, as described throughout this book. Enterprise services are built with semantic standards as well. They are created to help automate processes, and to perform utility functions related to such automation. Descriptions of enterprise services are stored in the Enterprise Services Repository, which contains not only WSDL files but also models that show how an enterprise service is related to business processes and business objects.
What is the difference between a web service and an enterprise service?
A web service is just a standardized interface to a service’s functionality. It contains instructions written in WSDL describing how that service is going to be called. And that’s all.
An enterprise service is a web service designed as a reusable component in process automation. It exists within the larger context of ESA, and it contains metadata about its functionality and about how it connects to other services. Web services contain much of the same functionality as enterprise services—usually at a more granular level than is useful for process orchestration—but the soul of an enterprise service is that it’s there to help you, and it contains enough functionality to make a meaningful difference in processes. Enterprise services are large enough that combining and recombining them is a fairly easy task. In practice, as demonstrated in Figure 4-2, an enterprise service, when called, will execute any number of instructions across any number of underlying applications. A web service will call only the application to which it is related. Therefore, in Figure 4-2, clicking “delete order” in a menu might simply delete the order from an ERP system if one were to use a web service to do so.
The question then becomes, does this act help the larger business process of cancelling an order? The larger scope of that process includes many actions beyond deleting a record in the ERP system. There might also be a CRM system handling the sales aspect, an SCM system containing its own order objects, and so on. Therefore, the business process of cancelling an order contains many steps: revising the supply chain plan, flagging the material in stock, notifying the customer that his order has indeed been cancelled, and so on.
Whereas a web service simply deletes the record, an enterprise service is able to orchestrate the larger process of cancelling an order by sending individual messages to each of its systems, and most likely many more.
Enterprise services typically fall into one of four main categories:
- Process services
Trigger a process and manage its consistent execution.
- Component services
Keep track of the context—the relationships, data, and external information—related to an important business function. Commonly, this context takes the form of a set of rules applied to the operation of other services. When one service inputs data to a purchase order, for example, a second component service determines—based on the identity of the supplier and corresponding contractual relations—how the purchase order should be handled.
- Entity or engine services
Provide access to a business object or a discrete piece of functionality, such as a pricing engine, and manage all of the necessary events and activities triggered by the service.
- Utility services
Perform a common function for other services. A service providing the required values for a specific field—the “value help service”—is a classic example of a utility service.
Setting all of these apart from garden-variety web services is the fact that enterprise services have been created within a business context, process their own semantic meaning, and are built to be reusable, configurable components that aid in the flexible automation of a greater process.
What is service-oriented architecture?
Service-oriented architecture (SOA) is a term that many different people use in many different ways. Most of the time, SOA refers to architecture for software systems in which services are the fundamental building blocks; that is what we mean by SOA in this book. This is a good, broad definition, but there are many shades of meaning when you start digging into the details of what someone means when they use the term. Sometimes people mean architectures based on web services, and others think that architectures such as CORBA and DCOM are examples of SOA.
Simply put, however, SOA refers to any system that exposes its functionality as services. The next question, naturally, is “what’s a service?” We will turn to a metaphor to explain that one: think of services as a mechanical watch with hands, numbers, and an internal mechanism. The hands and numbers are the “interface,” and the mechanism is the “code.” To do more than simply tell time—to function as a stopwatch, for example—a watch would need additional components, such as mechanisms to start and stop the time, to display the elapsed time, and to reset the timer. Those operations are essentially simple services.
To be useful, the service orientation needs to exist everywhere across applications and systems. The emphasis here should be on the word across. As opposed to the old model of developing applications using proprietary languages, customized interfaces, and hard-wired packages of functionality, in a service-based world, composite applications are created using a potentially infinite combination of services drawn from these existing applications. It’s critical that the service orientation be able to draw upon any application and any database in the system, or else the usefulness of the architecture is crippled from the very beginning.
SOA has led to the creation of many related terms, some that were created because of SOA and others that were given new life. The term loosely coupled, for example, refers to a property of systems in which the complexity of the system is partitioned inside a small number of building blocks that are connected in clearly defined ways. Loose coupling means that the building blocks do not depend on each other in complex ways and can easily be rearranged to meet new challenges. The idea of the service grid has also gained a lot of currency. A service grid is an infrastructure of many different services all designed to work together. Many terms such as these are being created every year as new ideas emerge.
What is the difference between ESA and other approaches to SOA?
The biggest difference between ESA and other approaches to SOA is that from the ESA perspective, web services are only the beginning of a solution to the larger problems that any enterprise faces when it sits down to draft a roadmap of its business processes and the systems needed to support them.
Web services are very flexible standards, and many vendors already provide the necessary tools for building them and, in some case, modeling applications using web services as inputs. However, the question of where these web services will come from to automate processes is usually left unanswered by the vendors offering SOAs. The general idea is that companies are expected to build their own, and that the SOA vendors will provide help in selecting which ones they need to fit into a modeling environment.
While this approach may work, it doesn’t solve the larger business issues, nor does it require the vendor to do much. By contrast, ESA provides a full repository of enterprise services already built and ready to automate processes for its customers.
SAP has gone a step further, creating a full suite of modeling tools at the UI and the process orchestration levels, a framework for the creation of composite applications that is actually embedded in those tools. Not only is SAP committed to building its composite applications composed of services (its xApps line), but also it has created a roadmap for the transformation of its entire product line into collections of enterprise services. ESA adds an “ecosystem” for including its customers and partners in decisions that affect the ongoing evolution of ESA. ESA is therefore more than an SOA; it supports business processes framed in terms of business semantics.
What are composite applications?
Composite applications, illustrated in Figure 4-3, are applications built using services as building blocks. The word composite has two shades of meaning that make it easier to understand. As a noun, composite means something that is composed of many different things. For an application to be a composite, it means that it is assembled from many existing parts. This is in sharp contrast to applications that are built through so-called greenfield development in which the entire application is created from scratch. The idea of composite applications is that development is accelerated because existing services are used as a starting point and development of new functionality is kept to a minimum. Composite applications are about reuse. Another shade of meaning enters when we think of the verb composing. Composite applications are composed rather than developed. Composing means assembling all the required services and orchestrating them so that they work together to perform a new task. Composing frequently takes place through use of modeling rather than coding in traditional languages. Development of composite applications is accelerated in another way. Modeling and the use of services mean that the logic connecting the services is not nearly as complex as traditional applications and is clearly separated into layers. This makes adapting a composite to meet new purposes much easier and faster. So, what are composite applications about? Reuse, speed of development, and flexibility.
Figures 4-4 and 4-5 depict an example of one such composition. They illustrate the composite applications now at work inside a manufacturer that decided to turn its supply chain and manufacturing processes inside out. Instead of thinking of new products, building them, selling them, and shipping them, this manufacturer decided to start with its suppliers first, asking them, “What can you sell me cheaply today?” The manufacturer runs the answers through its APO to compile a list of everything it can build with that day’s grab bag of cheap components and then sends that list to all of its distributors, creating an auction in which the distributors bid to distribute and sell whatever the manufacturer built that day. When an order arrives through the auction system, the manufacturer goes back to its suppliers, orders the components it needs, manufactures the goods, and then checks to see what it no longer has the potential supplies to make, pulling those orders off the auction block.
The company runs this reverse-auction process using a composite solution assembled with pieces of functionality from its APO, CRM, and supplier relationship management (SRM) applications, including common business processes such as procure to pay, order to cash, and manufacture to inventory. The manufacturer just needed to wire them differently. Normally, however, it might take a company 12 months to figure out what it needs to change in its systems and another 18 months to change it.
What are service consumers?
Service consumer is a general term for applications that use services. Services are so versatile that they can fit into many situations. A cell phone can invoke a service. A special-purpose hardware device such as a radio frequency identification (RFID) reader can invoke a service. Services can be invoked by another service. Composite applications are the most common service consumers.
What are service providers?
Frequently when we think of services, we imagine freestanding entities that just exist somehow. However, services are computer programs, and like all computer programs, they must be loaded onto a computer and executed to work. The simplest definition of a service provider is any computer program that offers its functionality to other computer programs as a service. For this book, when we say service, we usually mean web service, so service providers are programs that offer web services. As a practical matter, though, what kinds of programs are service providers?
The most common kind of service providers are existing enterprise applications that are making their functionality available as services. Most of the first wave of services will be created in this manner. This means that enterprise applications such as ERP and so forth will operate in their traditional manner and will provide their functionality as they always have. They also will provide services that will be used by service consumers, mostly composite applications. Eventually, extensions to ERP may be made as composite applications, and then perhaps someday all of ERP may be architected as a service provider with composite applications on top.
What are xApps?
Even before SAP announced ESA in January 2003, SAP and its partners were using SAP NetWeaver to build composite applications known as xApps. Initially, xApp was an abbreviation for cross-application, or an application that implemented processes that spanned across systems of record. Over time, the x in xApps became dominant, and now this term is pronounced ex-apps. The unique feature of xApps is that they are created to be sold as products. In this regard, they are examples of what was formerly known as packaged composite applications .
SAP created several xApps, including SAP xApp Resource and Portfolio Management (SAP xRPM) for managing large portfolios of projects, and SAP xApp Product Definition (SAP xPD) for managing the product definition process. Partners created xApps such as SAP xApp Integrated Exploration and Production (SAP xIEP) for managing oil and gas exploration. Each xApp was created with early versions of the SAP Composite Application Framework (SAP CAF) supplemented by functionality from SAP NetWeaver. This first generation of xApps did not have the benefit of the infrastructure, such as the Enterprise Services Repository and other parts of SAP NetWeaver built especially to support ESA.
What role does the mySAP Business Suite play in ESA?
The mySAP Business Suite will be the powerhouse of ESA as it becomes service enabled. Each mySAP Business Suite solution will be an important service provider, offering hundreds or thousands of enterprise services for use by service consumers. The mySAP Business Suite will also be the first beneficiary of ESA because each solution will be extended using composite applications for analytics, self-service, and solving special problems for industries.
What role does SAP NetWeaver play in ESA?
SAP NetWeaver is the technology foundation for ESA, for the mySAP Business Suite, and for everything else that SAP creates. SAP NetWeaver, shown in Figure 4-6, is a comprehensive platform designed to make the development, composition, and maintenance of enterprise software as easy as possible. SAP NetWeaver contains an application server that can run code written in ABAP or Java. All of the modern enabling technology for XML messaging, Business Process Management, data warehouses, OLAP, for reporting, searching, collaboration, building and managing UIs, and extending applications to mobile devices exists inside of SAP NetWeaver. SAP NetWeaver has a collection of development tools such as SAP NetWeaver Visual Composer to enable rapid development through modeling, and ABAP Workbench and SAP NetWeaver Developer Studio to implement services. SAP NetWeaver has been extended with such things as the Enterprise Services Repository that stores descriptions of enterprise services and how they work along with many infrastructure layers devoted to the creation and support of services.
As ESA evolves, SAP NetWeaver’s role is changing from an integration platform to a platform where the composition of new applications and the recomposition of existing objects and enterprise services will take place. Still later, as ESA reaches maturity, SAP NetWeaver is envisioned as being absorbed into the architecture itself, evolving into the business process platform that supports and offers enterprise architects access to the enterprise services and business objects operating above it (see Figure 4-7).
What are IT practices and IT scenarios?
IT practices and IT scenarios are SAP’s way of expressing the value that SAP NetWeaver provides and the mechanisms used to provide it. When facing any sort of IT project, whether it is ESA-related or not, IT practices and scenarios can provide another tool for analysis, such as the five Cs of ESA, that can help teams of people communicate more clearly about what they need to do.
IT practices are focused on the business impact of SAP NetWeaver rather than on isolated technology components. The idea is that when facing an IT issue, instead of thinking of the portal, a unit of functionality, you will think about user productivity, the goal. IT practices identify how you can use SAP NetWeaver to solve specific business problems familiar to almost any IT organization. IT practices are intended to evolve as business issues change. They are currently defined as shown in Table 4-1.
|
IT practice |
Description |
|
User productivity enablement |
Helps users and groups improve their productivity through enhanced collaboration, optimized knowledge management, and personalized access to critical applications and data |
|
Data unification |
Consolidates, rationalizes, synchronizes, and manages all master data (e.g., customers, suppliers, catalog items, etc.) for improved business processes |
|
Business information management |
Increases the visibility, reach, and usefulness of structured and unstructured data |
|
Business event management |
Ensures that business events from multiple systems are distributed to the appropriate decision makers within the context of relevant business processes |
|
End-to-end process integration |
Makes disparate applications and systems work together consistently to perform business processes |
|
Custom development |
Rapidly creates new enterprise-scale applications to drive your company’s unique advantages |
|
Unified life cycle management |
Automates application management processes and optimizes all facets of an application’s life cycle |
|
Maintains an appropriate level of security and quality for your intellectual property (IP) and information assets | |
|
Consolidation |
Deploys a consolidated technology platform with the ability to allocate computing power according to changing business needs |
|
Consolidates and standardizes basic processes while leveraging existing investments to compose new, distinctive business processes |
Associated with each IT practice are a number of IT scenarios that support a process-oriented implementation approach. IT scenarios are not collections of technology, such as a portal or a data warehouse; rather, they represent the way that SAP NetWeaver will be used to address an issue related to the IT practice. IT scenarios break down the IT practices, allowing an incremental approach to implementing SAP NetWeaver functionality that maintains a tight business focus. Figure 4-8 shows the different IT scenarios associated with each IT practice.
Each IT practice has multiple IT scenarios—or approaches—that organizations can use to solve a business problem. For example, the business information management practice lists the following IT scenarios:
Enterprise reporting, querying, and analysis
Business planning and analytical services
Enterprise data warehousing
Enterprise knowledge management
Enterprise searching
For each IT scenario, second- and third-level maps list various IT activities that need to be performed along with systematic tasks for accomplishing each IT activity.
IT practices and IT scenarios bridge the world between IT’s business challenges and technology implementation.
What is event-driven architecture?
Services are request/response mechanisms. A service consumer makes a request and a service provides a response. Essentially, a service consumer calls the service operation of a service, and the information flows through the service interface. Then the service implementation processes the request and provides the information to the service interface that responds.
However, what happens when there is no requestor, and instead something happens that triggers a chain of activity—for example, a sensor shows that the temperature of a tank in a chemical plant is too high or a business object monitoring the inventory level of a product shows that it has dropped too low? Each of these things is an event. Event-driven architecture (EDA) is the architectural paradigm used to describe systems that are built to react to various events that may occur. In general, once an event is raised somehow, the program that is notified that the event has occurred attempts to respond appropriately. If the tank temperature is too high for a well-known reason, one of several planned responses may be initiated. If the program cannot figure out what to do, an alert may be raised so that some human being can look at the issue and attempt to take corrective action.
Because of the way in which EDAs constantly wait and observe, companies frequently use them to help implement various forms of business activity monitoring. Because they generally attempt to provide an automated response, EDAs are also associated with the management-by-exception paradigms.
Why are analytics so important to ESA?
Using the flexibility of ESA to embed analytics inside enterprise applications provides the opportunity to close the loop between analysis and action.
Enterprise services provide access to functionality and information across the entire universe of enterprise applications. Services provided by SAP NetWeaver Business Intelligence (SAP NetWeaver BI) and capabilities such as the BI Accelerator, provide the ability to analyze large volumes of information. SAP xApp Analytics combines the ability to analyze what is happening in a process and then take the right actions.
In the past, users were required to leave enterprise applications when they needed to perform some analysis function. In other words, a context switch was required from the enterprise application to an analytical environment. Once insights were gained, another context switch back to the enterprise application was required to move the process forward in the right manner.
Now, hundreds of SAP analytic xApps are being embedded in enterprise applications. This means that management of the business process, analytics, and the means to take action to resolve problems or work with others is part of one seamless environment.
Analytic applications are being created using SAP NetWeaver Visual Composer, a model-driven development environment that simplifies development and allows business analysts to create and adapt analytic applications.
In all of these ways, the development of analytic capabilities acts as a catalyst to crystallize the creation of value based on ESA.
How does ESA provide for easier adaptation and a better requirements fit?
Historically, filling in the gaps between a company’s IT needs and the out-of-the-box functionality of any given enterprise application required any number of steps. Configuration of the application using metadata might address some needs, and tighter integration with preexisting applications and their processes would address others. If those were not enough, IT was expected to create extensions—new components welded onto the application—or even customized code written by the company’s developers.
As depicted in Figure 4-9, these efforts gradually narrowed the gaps between the customer’s requirements for the application and its actual functionality, but at a growing cost of complexity, and its corresponding costs of developer time and resources.
Enterprise services fill more of these gaps by creating the reusable building blocks that companies can combine easily to meet new requirements. As mentioned earlier in this chapter, the phrase loosely coupled describes enterprise services’ characteristic of interacting in well-defined ways without needing to know each other’s inner workings. This means that the service’s functionality can change without affecting the services that use it, as long as the behavior described in its interface remains the same—that is, as long as it continues providing the functionality it promised.
The opposite of loosely coupled is tightly coupled, which means that the internal workings of a system are exposed and that to work with it, you must understand the minute details of its inner workings, resulting in a very high level of complexity. Changing a single piece leads to unpredictable results, which leads to businesses becoming more afraid of potential side effects than excited about improving processes.
But that isn’t a problem for enterprise services, which represent much smaller portions of functionality—small enough so that opening the hood and tinkering is a more productive and less intimidating endeavor with a greatly reduced risk of disrupting existing processes. The net result is that it’s much easier to adapt an enterprise services environment to meet a much larger set of requirements than it is to adapt a conventional application. When you add the new tools that make development easier and that widen the potential pool of developers, it’s easy to see how a much larger set of processes can be automated as needed.
What is the basic structure of an enterprise service?
An enterprise service is composed of two things: the service interface and the service implementation . The interface is a structure defined by a WSDL file and code that sends and receives messages to and from applications and other services that wish to consume the service, and the implementation contains the functionality and performs the actual work.
The interface itself is composed of service operations, or the specific ways a service is invoked. Each service operation has an interface and implementation that understand information received by the service, perform any transformation that takes place, manage any persistent state that is changed, and prepare any information sent back to the caller. Also present is a piece of metadata—the service documentation—that explains the functionality and other inner workings of the service implementation.
It’s important to understand that each piece of functionality contained within the service requires a service operation to expose that piece for consumption by a service call from an application. For extremely simple services, only one service operation may be present. But most have at least several operations. Enterprise services are always a gateway to functionality that is provided by an existing system called a service provider, which may exist in the form of an exposed enterprise application or which might be built from scratch. Figure 4-10 shows the relationship between service operations, services, and service providers.
It’s important to understand here that not all enterprise applications are able to expose the same amount of functionality with the same level of ease via service operations. Enterprise services resting atop business objects—an organized container of functionality and data designed specifically to operate well within an ESA framework—are able to offer a greater variety of service operations more easily than a service consuming functionality from an enterprise application that was never designed to provide discrete services.
What are global data types?
Enterprise services offer revolutionary possibilities for reuse of services, but this revolution comes with challenges and responsibilities. One of the most challenging issues is making sure that the data the services are moving around and managing is the same, and that task is the mission of global data types. The easiest way to understand the value of global data types is to think of how you must conduct business without them.
Let’s imagine a service that offers the ability to look up the credit score of a consumer based on the consumer’s name, address, and Social Security number. If the service required a name that has three fields—one each for last name, first name, and middle initial—but a service consumer that was calling that service had only one field for name that had the entire name in it, some work would have to be done. Either the service consumer would have to parse the name into three fields, or the service would have to change to accept only one name. In practice, the code required to do this sort of translation could be lengthy and error prone.
Global data types are designed to avoid all of this by setting forth one standard way for common types of information to be represented. If everyone uses global data types, then all this nasty translation coding can be avoided. SAP’s approach to global data types is to use standards for data set forth by international standards organizations as a starting point, and extending them as needed.
Why is XML messaging so important to ESA?
XML is the language in which the double-sided conversation of services is actually conducted. The message itself can take several forms. The caller of the service might send an XML message and wait until a response is provided—a synchronous call—or he might send a message representing a service call that waits while the rest of the application continues—what’s known as an asynchronous call. XML messages are analogous within ESA to individual neurons firing in the brain; they are the tiny unit of information comprising larger events.
XML is also a key open standard. It provides great flexibility for changing data representations without having an impact on existing components. XML has become the de facto standard for data interchange, enabling integration among partners, protecting the company’s investments in its IT infrastructure, and lowering the cost of flexibility.
What is the difference between a frontend and a backend application?
Frontend applications are geared toward user interaction, and backend applications focus on the high-volume automation of complicated processes. Each kind has its own set of features and limitations. Frontend applications are conversational in nature, and they tend to be equipped with collaborative tools and highly customized interfaces. Backend applications are created to handle a number of service calls several orders of magnitude larger than frontend ones experience. Later chapters in this book will discuss tools built for each environment, such as guided procedures—an interface designed to walk end users step by step through a business process—or the SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI) component capable of automating processes that run for days, weeks, or months without human input.
The distinction between frontend and backend applications is ultimately fuzzy, however, as it’s not uncommon for a frontend application to call a service provided by a backend-oriented application. The difference ultimately lies in the tools designed for each.
What is service composition?
Just as it’s possible within ESA to compose applications from services (thus creating composite applications), it’s also possible to compose new services from existing ones. These differ from composite applications in that they are still services that are designed to be consumed by other applications, and thus they contain all of their functionality within themselves instead of consuming them from other services, as composite applications do.
Service composition is especially useful for creating specialized services that might be simpler and better suited to a task than composite applications.
What is the role of business objects in ESA?
Business objects are collections of data and functionality that represent an important business entity. Common business objects are entities, such as business partner, customer, and invoice. Since the beginning of enterprise applications, software designers have used the idea of business objects inside software to represent important parts of the real world. Business objects are not enterprise services, but like them, business objects represent a discrete piece of functionality. And like enterprise services, business objects were created to be reusable, which makes it much easier to build services atop them than to do the same with older, monolithic applications never intended for the purpose. Service providers based on business objects intended to support the creation of enterprise services will automate the creation of certain types of enterprise services. (We discuss business objects further in Chapter 5.)
Conceptually speaking, business objects might contain just about anything. They might exist within composite applications as a piece of dedicated functionality; they might do that and use services to expand the scope of their functionality; or they could be a new piece of functionality that just doesn’t exist in any service provider.
How does persistence change in ESA?
The problem with persistence—a word describing the storage and synchronization of data in databases—is that the old architecture of enterprise applications assumed there would always be only a single database beneath the application. There would never be a risk of redundancy or duplication, as anyone seeking to change the data would always use that database, which could be kept consistent through rock-solid database transaction mechanisms.
In an ESA world, however, with data from CRM, SCM, third-party applications, partner systems, and beyond, data is scattered all over the system map. Redundancy, duplication, and inconsistency are real problems, and in order for ESA to succeed, it must provide a framework to deal with them.
In the case of ESA, SAP NetWeaver provides the technical capabilities to align and unify, clean, and harmonize data across the system landscape—and to provide a virtual view of that data as though all of it originates from the same database. (SAP NetWeaver Application Server handled persistence-related tasks for a single database in the past.)
From a technology perspective, the information management framework uses capabilities such as Master Data Management (MDM), data warehousing, and business intelligence, as well as knowledge management, to meet the challenge of managing overlapping information in a collection of distributed repositories.
Why does modeling matter? Isn’t it just another form of coding?
Modeling is as old as computer programming itself. The first time a programmer added a parameter or two to his code, he created a model. While using modeling to configure and design software is nothing new, it is important to understand how modeling manifests itself at multiple levels, in a variety of forms within ESA, and not just as code. ESA shifts the burden of application development off the backs of IT and onto the shoulders of the emerging business analysts discussed earlier. To enable that shift, business analysts will need models that not only envision code, but also trace the flow of data through business processes, visualize the business objects in which transformations take place, and then finally use modeling tools to produce the code that makes all of this possible. Let’s walk through each type of model.
At the highest, most abstract level is process component modeling, where complex business processes are unpacked into functional components that represent business objects and services, such as a purchase order connected to another similarly large financial component. These models don’t specify the process automation itself, just the components needed for carrying out that automation. This kind of modeling is how the structure of a business is captured.
After that, business analysts zoom into each process component to orchestrate the process flow and the individual business objects and services comprising that flow, creating a model that’s even more detailed. But it’s still not a complete picture of the underlying automation, which is what’s specified in the code inside those business objects.
In each instance, the models operate at differing degrees of abstraction from the actual code. A low-level specification model is essentially another form of coding in which changes to the model or the code are automatically reflected in each other because the specificity in each is roughly equivalent.
A high-level specification model manipulates components larger than simple code—the business processes within a process component, for example. These models exchange the flexibility of a low-specification model for the simplicity of fewer objects.
Other kinds of models include pattern-based models—which provide large assemblies of model components as a jumping-off point for additional configuration and which can be low- or high-level specifications—and requirements models, which are the most powerful of all. In requirements models, instead of a user expressing how she wants something done, the model takes an expression of the user’s goals and simply creates the solutions.
To imagine the differences in scope between each kind of model, picture a chef in a kitchen instead of a business analyst hunched over a screen. In a low-level specification model, the chef works alone, using a recipe as his simple model. In a high-level specification model, the chef commands his assistants to produce dishes with a few alterations: make this one spicy, that one sweet, and grill the meat medium rare. A pattern-based, high-level specification model would have the chef ordering his staff to produce a five-course meal in which they substitute a dish or two—salmon for veal, perhaps. And whether they knew it or not, the patrons in the dining room would embody a requirements model at the moment they placed their orders. They know what they want, and now they will wait for their meals to appear from the kitchen.
Modeling is used throughout ESA to create the simplicity and flexibility required for widespread use by nontechnical users and to increase the productivity of technologists. It will be impossible for most businesses to realize the full potential of ESA without the ability to have business analysts lacking specialized knowledge in IT rapidly configure business processes. Several of the challenges mentioned earlier in this chapter—such as the looming proliferation of UIs—will be addressed by spreading the work of building these interfaces across hundreds or even thousands of suddenly empowered enterprise architects wielding simple modeling tools. Such tools already exist in the form of SAP NetWeaver Visual Composer, which was first designed as a high-level specification modeling environment.
Modeling tools use composition languages that represent the relationships among business objects, services, and the applications providing functionality, all of which are then translated into executable code. Modeling tools present to their users a visual representation of the composition language that is even simpler than the composition language itself. While displaying the data of an entity service embedded in a UI table may have a lot of plumbing buried under the service, a visual development environment simplifies that complexity down to the act of joining one object to another with a certain type of connector. The composition language used to represent that connection is much more complex, and the executable version has still greater complexity, but all of this is hidden from the business analyst who may be configuring a piece of software.
Will modeling replace coding?
The goal of modeling is to replace most coding, but modeling will never be able to replace all coding. In every environment that modeling is applied to, new needs will arise that will require more complexity than can be expressed in the modeling environment. Enterprise services and modeling will keep coding to a minimum, and when coding of new enterprise services is done, those services will become usable by others in the future.
How are patterns used in ESA and what value do they provide?
Business analysts will almost never have to start with a blank page. Either they will be configuring an existing application developed using modeling tools, or they will simply be borrowing the accumulated best practices of design embodied in collections of ready-made applications and components known as patterns.
Patterns borrow an idea that has always been implicit in programming. Every application ever designed for a desktop operating system follows thousands of patterns—the most noticeable of which are the common windows and menus of the interface—and applies them to the modeling of process orchestrations. Instead of remodeling an interface or process in every instance, why not create a persistent pattern that retains the common attributes?
In a pattern-based modeling environment, development becomes less about writing code and modeling applications from scratch (freestyle modeling) and more about executing best practices embodied in patterns. The patterns themselves become high-level building blocks that spare developers the detailed work of connecting components and instead free them to explore the optimal combinations.
The same holds true at the more granular level of modeling business objects. Objects built according to a pattern—all sharing the same search, save, and read methods, for example—can have those methods translated into services containing their own patterns and can then be used by interfaces or processes or even applications operating according to their own patterns. If done right, cascading automation follows in their wake since it becomes possible to automate service enablement on a massive scale, thanks to their shared patterns.
Patterns also occur during the act of development. Because they embody best practices, and because SAP is embedding pattern recognition in its modeling tools, business analysts and developers are experimenting with the practice of guided development in which the tools automate and enforce best practices for design, development, and testing. Guided development might best be described as the development equivalent of paint-by-numbers: the developer’s only responsibility is to fill in the gaps in functionality.
What is process orchestration?
Process orchestration is the act of assembling the enterprise services representing components of a process into a composite application that completes the process. The goal of ESA is to create services with enough size and scope that they can be used inside a simple orchestration mechanism (modeling tools) to configure and orchestrate the process.
If the services are too small and too granular, the advantages of orchestration are lost—you might as well write code from scratch. Model-driven process orchestration is designed to be easier and simpler, an exercise in configuration rather than in gluing components together with customized code. It’s not always simpler, however, as some services and business objects may actually have more functionality and complexity than are needed by the process you’re trying to orchestrate.
What is process integration?
Process integration is what’s needed when process orchestration runs into difficulties because one or more services need help receiving and handing off data to other components. This help can be found in a process integration layer within ESA that essentially attaches translators to the service so that arriving and departing data is accepted and processed smoothly.
How will ESA change the way applications are packaged and delivered?
As ESA continues taking shape, it appears that the basic structure of the future will be the business object, which can best be thought of as containers of functionality where data will be managed and processed. In this vision of the future, business objects that are highly related to each other will exist and will pass messages back and forth without mediation by enterprise services. These business objects will then be grouped together into larger containers, on top of which will rest enterprise services that allow for external access to the business objects beneath. The result is that enterprise applications will no longer be UIs to monolithic functionality and instead will become UIs resting on top of process components composed of related sets of business objects exposed for external use as enterprise services.
What are the special needs of composite applications?
Composite applications face problems previous generations of applications did not have to grapple with.
One problem is distributed persistence, which refers to data scattered across a potentially far-flung network of business objects and other structures connected by enterprise services and unaware of each other. It becomes necessary to create mechanisms capable of resolving that distributed persistence, two of which SAP NetWeaver provides: MDM and the SAP NetWeaver BI data warehousing ability. Analytic services are expected to compile and process data from this distributed source and route the results in the right form to the right UI at the right time.
Another problem is flexibility. To handcode composites from scratch is too costly to be effective. Composites need to be intrinsically flexible enough to change easily and quickly without a large investment of time and resources. This is where modeling comes in.
It’s also expected that modern composite applications will include or integrate collaborative tools such as email, instant messaging, and lightweight project management tools. Equally important are search and knowledge management capabilities for unstructured documents and information. So are UIs for mobile devices; composite applications simply have higher user expectations than their predecessors. (For more information on composite applications, their architecture, and how SAP supports them, see Chapter 12.)
What is the relationship between ESA, standards, and commoditization?
ESA could not exist without standards. Enterprise services are built upon and depend upon common standards such as web services for general functionality, XML for messaging, and Java and other programming languages for creating the services themselves. ESA creates an environment in which all of these standards coexist and interoperate, and it is inevitable that this interoperability will become standardized (take, for example, standards such as RosettaNet for process orchestration in the high-tech industries), leading to the evolution of the service grid.
Within the grid, automation using enterprise services ceases to be a differentiating factor. What matters will be how you choose to organize your processes and how you choose to structure your business. ESA will have simply become the platform on which all of this happens.
Is buy versus build a false tradeoff in ESA?
In the past, there has been a debate about the tradeoffs between committing the resources to building custom applications versus buying standard (and thus nondifferentiating) applications from vendors. Taking into account all of the short- and long-term implications, what is the total cost of each? And how does this dichotomy apply in the far more granular world of services?
In the world of ESA, organizations will do both—they’ll buy some services and build others—but what will really differentiate them from their competitors is the deployment of processes based on those services. Because of that, companies should plan to buy as many necessary services as possible, then use them to automate and improve new and existing processes unique to them. Buy, build, and compose becomes the model. Because of the nature of services, changing them and extending them is a simple matter. Instead of building services from scratch, customers will often adapt and extend services in ways that differentiate them and meet unique business needs. Over time, there will be a core of standardized services, new ones appearing on the market, and custom services created by customers and partners. But building versus buying stops being a dramatic choice because they’ll do both on a regular basis.
Figure 4-11 illustrates the previous divide between packaged applications and custom code. Figure 4-12 shows how this divide is bridged by composite applications drawing upon the relevant functionality of both. Service enablement will simultaneously drive down the cost of custom development by eliminating the need to develop code from scratch each time out, while also increasing the value of commodity software by raising the possibility of innovation through creative reuse.
Why is an ecosystem of companies and standards so important to ESA?
As ESA adoption spreads, services will begin to proliferate. SAP will provide them, other vendors will provide them, customers will build their own, and so on. As the number of vendors and users expands, it will become increasingly important for commercial vendors to design services that meet their customers’ specific needs. SAP has created the Enterprise Services Community (ES-Community) as a way for all sides to give feedback on the design and specifications of new services in order to guarantee the highest quality before delivery. It also provides a setting to ratify services that become de facto standards so that organizations can begin using them to create integration processes.
SAP realizes that it will never create all of the services its customers need. It hopes that by creating a flourishing ecosystem around ESA, specialized developers will step in to fill the gaps profitably and help create a universal inventory of services (see Figure 4-13). You can find more information about the partner ecosystem in Chapter 6.
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.
