GRC
HR
SCM
CRM
BI


Article

 

When Does a Web Service Become an Enterprise Service? An Introduction to the Principles of Enterprise Services Architecture (ESA)

by Dr. Franz-Josef Fritz | SAPinsider

April 1, 2004

by Dr. Franz-Josef Fritz, SAP AG SAPinsider - 2004 (Volume 5), April (Issue 2)
 



Dr. Franz-Josef Fritz,
SAP AG

With a simple Web service, a user can check on some online stock quotes, weather conditions, or next week's movie listings. Web services are also an ideal option for automating much more complex business processes, since they are not bound to a specific platform or programming language, and — more importantly — they provide the potential for worldwide collaboration across systems and companies based on the Internet.

However, to handle enterprise-level, business-scale processes, it is clear that Web services also need to be just as reliable, maintainable, and secure as your current business software. And to keep maintenance costs down, you must have services that achieve the right level of scalability and reuse. As a result, we are now beginning to talk of "enterprise services" that do just that, and an Enterprise Services Architecture to guide enterprises toward a service-oriented IT architecture that can grow and change with your business processes.

What Are Enterprise Services?

In a nutshell, enterprise services are simply Web services that provide enterprise-level business functionality. They may range from very simple lookup services (like finding a company's location or product offerings) to more complex and composite services — but what they have in common is that they're highly integrated into your process or application. Typically enterprise services are high-level components that take more granular Web services and aggregate them into reusable elements with business value.1

For example, take the service Cancel Purchase Order. An elementary Web service like Delete Purchase Order would simply lead to the deletion of a purchase order in the corresponding database. However, if the stated goal is "cancel purchase order," the service has to become a more far-reaching enterprise service that handles this process end-to-end, and therefore has to trigger a number of follow-up actions, including:

  • Check against production orders
  • Check against a corresponding billing process
  • Update of inventory/warehouse information

Or consider the Credit Limit Check service, which at first glance seems to be quite simple. Normally, this service is one ingredient of the Order Creation service. But typically, credit checking is really a more elaborate composite service. Here, the goal is not simply to access the credit information of a potential customer; the question really is, "Should I accept an order with value X and payment terms Y from customer Z?"

First, the service has to take a look at customer master data. Then it may be necessary to look into the customer's financial history to uncover any open invoices or other aspects of payment habits. Finally, a check against external credit-rating databases (from D&B or S&P, for example) may be in order (see Figure 1). The implementation of the enterprise service may combine information from D&B or S&P with information from the enterprise's A/R applications using enterprise-specific business rules to determine whether or not to accept the order, and may allow this information to be called from any order entry application within the enterprise. At the same time, these connections and various data sources are almost completely hidden from the user, who sees this as just another step in the order application he or she is using.

All this, together, makes up the necessary enterprise service.

Figure 1
From Traditional Services to Enterprise Services

What Are the Technical Requirements for Enterprise Services?

Enterprise services must be as robust and reliable as your business applications, which rely on their own set of exclusive and local data sources.

Technically, enterprise services build on established and emerging Web service standards for the big benefit of openness and interoperability. They have demanding requirements in terms of scalability (to support thousands or even millions of calls) and security (to provide authentication as well as end-to-end message integrity and data confidentiality — things that generally cannot be taken for granted on the Internet). What's more, when any problems arise, an infrastructure must be in place to analyze and debug what will almost certainly be a multitude of interconnected components (such as in the Credit Limit Check example above). This is where an Enterprise Services Architecture comes in.

5 Key Principles of ESA

    1. Abstraction — hiding confusing details

    2. Modularity — breaking down complexity, resulting in reusable pieces

    3. Standardized connectivity — enabling flexible composition of services to create bigger processes and scenarios

    4. Loose coupling — allowing for separate evolution of the various components without breaking any points of integration

    5. Incremental design — enabling changes to composition and configuration without affecting the interior of components, and vice versa

What Is ESA?

Enterprise Services Architecture (ESA) is a set of principles that guides the evolution of a service-oriented IT architecture for increased business value and adaptive business solutions. Here are some of the main ESA principles:

  • ESA mandates the componentization and reuse of application functionality according to a standard architecture. Much of the complexity is hidden inside components.

  • ESA provides a conceptual framework for how to connect, compose, and configure components. One of its cornerstones is interface stability, which enables contracts between service providers and consumers. This contract allows both parties to change and evolve as long as the service contract is not broken.

  • ESA relies on a set of clearly specified open standards, which make it possible to independently create components that can work together. ESA relies on proven and accepted industry standards for Web services, security, and process modeling, among others. Where necessary, ESA extends these standards with additional guidelines and profiles for using the standards. In some cases, SAP is creating additional specifications, which will be proposed as standards in the future as well.

  • ESA sets the stage for model-driven development. More and more development tasks can be accomplished by creating and refining abstract models without the need to go to a coding level. And even in cases where coding is necessary, the model layer will give the structure and guidance for inserting code snippets into the framework.

  • ESA introduces a uniform service description and a uniform programming model. Very different engines — UI frameworks, business process engines, and mass data loading facilities — will all make use of the same underlying services based on a common service repository.

Is ESA a Product?

ESA is not a product in itself. However, you will find the principles of ESA at work in SAP technology and software, such as:

  • SAP NetWeaver, which is the open integration and application platform for all SAP applications and solutions (see sidebar). This will provide the technical foundation for implementing an Enterprise Services Architecture for an IT landscape.

  • SAP xApps, the next generation of applications, utilizing multiple application components and built mainly by model-driven composition and configuration.

  • In the new releases of SAP Business Suite, where more and more principles of ESA are applied.

SAP Puts Enterprise Services Architecture Into Practice

How is ESA related to SAP NetWeaver?
SAP NetWeaver provides a technical foundation for implementing an Enterprise Services Architecture:

  • A common service description based on Web services standards
  • A common development process for all types of remote interfaces, including process integration, user interface, application-to-application (A2A), B2B, etc.
  • A common Web services-based runtime infrastructure
  • A common ESA service bus for communication, transaction handling, debugging, tracing, etc.

NetWeaver '04 includes its Web service infrastructure, which enables service-based development and communication. Web Dynpro then provides a service-oriented user interface framework for clean separation of presentation layer and business logic. SAP Exchange Infrastructure and the Business Process Management engine provide a service-oriented process layer.

NetWeaver '05 will take a big step forward regarding model-driven development of enterprise services. And the support of ESA will continue to evolve over time.

How do SAP applications use ESA?
New SAP applications will be built in a purely service-oriented way. Recent examples include:

  • mySAP CRM: In the most recent version of mySAP CRM, the user interface was completely separated from the underlying business logic
  • mySAP ERP: These ideas were taken one step further in the recent development of Employee Self-Services (ESS), which will be delivered as part of mySAP ERP in 2004. Here, a Web Dynpro-based presentation layer sits on top of a service-enabled backend layer.
  • mySAP SRM: The new release of mySAP SRM makes good use of ESA capabilities provided by SAP NetWeaver '04. SRM components are integrated with each other in a loosely coupled way, making use of the service capabilities of the SAP Exchange Infrastructure.

What Effect Will ESA Have on Software Development?

SAP is integrating ESA into its software and technology. But ESA will also change the way partners and customers build and use applications.

Monolithic applications will transition into reusable components. What's more, with ESA there is also a clear distinction between providing a service and using that service. In other words, the software layers dedicated to user integration and process integration are independent of the service provider — the software layer need not be aware of the provider's particular system requirements. This means that the same service — for example, one for retrieving product master data from a third-party system — can then be reused successfully in a dialog application, an automated orchestrated business process, or a mass data load scenario.

What Benefits Will SAP Customers See with ESA?

For enterprises, the ultimate benefit of ESA should be the ability to optimize your business processes continuously, without a bottleneck in your IT infrastructure. Implementing ESA principles leads to clearly architected infrastructure, reusable application components, and new innovative composite applications. Simply put, SAP customers will be better able to configure, compose, and create applications.

Customers will be able to configure SAP applications (the user interface, the business process orchestration, the service composition) without touching the underlying services. This will greatly reduce the need for modification, leading to significant savings of time and cost when upgrading to a new release.

ESA also helps to reuse Web services from all kinds of sources. Among others, ESA is the foundation for open interoperability with all industry-leading platforms, including IBM WebSphere and Microsoft .NET. With this focus on reusability, customers will be able to compose new applications out of services — whether they are delivered by SAP, provided by SAP partners, or developed by SAP customers — reducing costs and time associated with development and maintenance.

And finally, customers will be able to create completely new service-oriented applications of their own based on the Enterprise Services Architecture approach, using the ESA-compliant infrastructure and development tools delivered by SAP.

Of course, ESA lowers the total cost of the software life cycle with clear service contracts. But perhaps most importantly, ESA provides the framework for faster evolution of business processes and easier adoption of new business opportunities.

For More Information


1 Source: Dan Woods, Enterprise Services Architecture (O'Reilly 2003).


Franz J. Fritz has a Ph.D. in mathematics and 30 years of experience in all areas of IT. Workflow and business process management have been particular areas of interest for much of his life. He has worked for SAP since 1993 as Program Director and Vice President with responsibility for the Business Process Technology and Internet-Business Framework departments. Recently, he took over responsibility for SAP NetWeaver product management within SAP AG as Vice President of NetWeaver Product Management and Standards.

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ