Post on 02-Jun-2018
8/10/2019 06wp02 Impl SAP From E2E Scenarios
1/22
WHITE PAPER:
IMPLEMENTING SAP FROM END TO END
BUSINESS PROCESS SCENARIOS
8/10/2019 06wp02 Impl SAP From E2E Scenarios
2/22
Table of Contents
ABSTRACT...................................................................................................................... 3
INTRODUCTION............................................................................................................. 3
BACKGROUND...............................................................................................................4
METHODOLOGY............................................................................................................ 7
COMPONENTS OF THE REFERENCE MODEL APPROACH TO IMPLEMENTING
COMPOSITE APPLICATIONS ...........................................................................8
THE REFERENCE MODEL APPROACH ................................................................... 14
CONCLUSIONS............................................................................................................ 20
RELATED PAPERS...................................................................................................... 20
REFERENCES ............................................................................................................... 21
END NOTES ..................................................................................................................22
Table of Figures
Figure 1: The center of the universe consequence of non-enterprise implementations............. 5
Figure 2: An end-to-end viewpoint required for true enterprise integration. In this approach,
IT supports the E2E business process. ................................................ ........................................ 6
Figure 3: A generic reference model for E2E order execution using the SCOR model for
organizing the business objects....................................... ..................................................... ....... 10
Figure 4: Example of a Place-Order Composite Application...............................................................13
Figure 5: Transitioning an E2E scenario from the ARIS Toolset into SAP NetWeaver for
execution ........................................... ............................................... ................................................ .....16
Figure 6: Object sharing across the enterprise is accommodated by the SAP Business
Process Platform.................................................................................................................................19
8/10/2019 06wp02 Impl SAP From E2E Scenarios
3/22
8/10/2019 06wp02 Impl SAP From E2E Scenarios
4/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 4
bounding of the composite process with a reference process that is first presented in
generic terms, and then translated (through object mappings or interface service
presentations) into a composite application that can be implemented across aheterogeneous system landscape.
BACKGROUND
Historically, organizations have evolved as circumstances have permitted. Product
demand, available resources, competition, partners and alliances, and management
style among a host of many other factors have influenced enterprise development.
These factors have similarly influenced the growth of the organizations information
systems that it has either developed or procured. For the most part, these systems
comprise a mix of applications that address particular requirements that are specificto a functional area (i.e. sales, customer support, etc). In effect, they have become
islands of automation. Enterprise Resource Planning (ERP) applications 1raised the
hope that an integrated solution2would address and resolve the integrity problems
that result from these disparate information systems. However, early generation ERP
implementations were limited constructs, and did not achieve the single source of
truth that managers sought. Indeed, the solutions offered within these enterprise
packages have in many cases been implemented in stove pipes; and have been
limited to supporting only specific and individual organizational functions that are
bound to the vertical solution. In the end, they increase, as opposed to reduce the
complexity of the information technology (IT) landscape; the promise made by the
business development teams.Neither has the perceived promise of these large and complex systems materialized
with the evolution of Enterprise Application Integration (EAI) solutions. Interoperable
systems have only enabled the passage of data, and little more, with the business
processes remaining trapped in the stovepipes. As such, a vast and heterogeneous
landscape of information systems has often come to characterize an organization. In
the center of theses interfaced systems stands a complex and expensive enterprise
application, which has become the center of corporate activity (see figure 1). With its
pre-defined and scripted business processes, the ERP system and its satellites enable
enterprise business processes. Processes within this domain are driven by the scope
of the ERP system, and they are typically not true end-to-end business processes.
Also, they are usually not fully integrated, nor do they enable an agile and innovativeprocess-centric organization. In short, the competitive advantage of ERP is often
compromised because organizations do not implement the solution as it was
intended to be implemented. As opposed to being implemented as an enterprise-
1See Gulledge, et al (2005) for background information on the basic concepts of ERP.
2Integration is a word that means different things to different people. Gulledge (2005) describes the usage context
for ERP systems. In this case, the authors are referring to Big I in the classification scheme proposed by Gulledge.
8/10/2019 06wp02 Impl SAP From E2E Scenarios
5/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 5
wide solution, ERP is implemented as a sub-component of the enterprise, and in
some cases, even within an organizational stovepipe.
Sub-enterprise Scoping Diminishes
ERP Value Proposition
GCSS-Army
LMP
TC-AIMS II
LIDB
MC4
TMDE
J-CALS
OTHERS
BCS3FBCB2JC2
DFAS
Joint System
ARMY System
DoD System
Legend
FCS
BSM
DIMHRS
AllServicesMTS
OSMIS
AALPS
TAV
TLDD
IETM
Figure 1: The center of the universe consequence of non-enterprise implementations
As noted above, frequently enterprise system implementations produce a state of
affairs where the ERP solution becomes the center of the universe. When ERP is
implemented in this way, it is just another system that must be managed across a
complex technology landscape; and business processes that depend on this system
are bounded by its stovepiped scope. This is a common problem. Fortunately, the
Center of the Universe paradigm is being replaced by new enterprise solutions that
support an end-to-end composite application framework.
The business environment has become increasingly competitive, and will no longer
tolerate those enterprises that do not posses the inherent agility within their businessprocesses to respond to the demands of the environment. Enterprises have extended
and networked across functional and/or geographical boundaries, and in doing so,
have sought competitive advantage in areas regardless of where these value-added
activities may be found. A true enterprise management approach demands an end-
to-end viewpoint (see figure 2) that flows unimpeded across the constraints imposed
by information system. Hence, where Okrent and Vokura (2004) focus on those
processes that fall within system boundaries, we focus on those that flow inside and
8/10/2019 06wp02 Impl SAP From E2E Scenarios
6/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 6
outside. End-to-end business process management is the viewpoint that provides
transparency to identify cost reductions, efficacies, opportunities, new practices, and
other related benefits. In this model, IT supports a corporate strategy and embeddedbusiness processes, it does not dictate them. This result is in direct opposition to the
Center of the Universe model where all business processes are constrained by the
interfaces across system components as in Figure 1.
ERPERPCRMCRM
End-to-End Business Process ScenarioEnd-to-End Business Process Scenario
InquiryInquiry
Process
Flow Process
sequence
Time
CreateCreate
quotationquotation
SalesSales
staffstaff
Accep tAccept
orderorder
CustomerCustomer
managementmanagement
CreateCreate
shipping listshipping list
ClerkClerk
WriteWrite
invoiceinvoice
GroupGroup
leaderleader
CheckCheck
paymentpayment
ClerkClerk
LegacyLegacy
ServiceService WrapperWrapperServiceService
OrderOrder ShippingShipping
listlist InvoiceInvoice PaymentPayment
receivedreceivedQuotationQuotation
Figure 2: An end-to-end viewpoint required for true enterprise integration.
In this approach, IT supports the E2E business process.
In the real world scenario of figure 2, there are also very real constraints. It was
previously stated that many organizations already depend on a universe of disparate
systems, and they already have deeply ingrained corporate practices that are tied to
their existing systems. Improving upon these business processes may appear to be a
daunting, if not impossible, task. Many organizations have already gone down this
path before, and many only achieved a limited return on their investment. Further,
end-to-end processes themselves can be vast and extraordinarily complex.
Identifying, let alone enabling an accurate end-to-end business process, is difficult.
The question is then, how does an organization implement an end-to-end process
across a complex heterogeneous IT landscape?
8/10/2019 06wp02 Impl SAP From E2E Scenarios
7/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 7
METHODOLOGY
We demonstrate an E2E implementation approach using a reference scenario - E2EOrder Execution - a critical business process for most enterprises. This process
begins with the receipt of an order that triggers an order execution process and
terminates with an output that is delivered to the customer. We show how our
general reference model evolves into a customer specific reference model, is
aligned with application solutions, is enabled by data, tested, and executed. There
are many possibilities for demonstrating the concept, so we focus on one type of
composite application, a process that is comprised of both SAP and non-SAP
components3. Table 1 presents the general steps that define the methodology.
Step escription
1. Develop a business architecture.
2. Develop or procure a generic E2E reference scenario.
3. Align the reference scenario with the target organization, creating a customer-specific
reference model.
4. Determine which segments of the process will be scoped within SAP, and which
segments will reside in other applications. This is accomplished using a known
commercial approach, such as ARIS4.
5. For the SAP segments, map (or replace) the company-specific objects with objects
from SAP using NetWeaver.
6. For the non-SAP components, wrap the interfaces so that the functionality provided
by the system may be instantiated as an enterprise service5.
7. Synchronize the complete customer specific model with SAP Solution Manager.
8. Bind the data to the services using the capabilities of the SAP Web Application Server6.
9. Test the E2E composite application.
Table 1: Steps in a Reference Model Approach to Implementing Composite Applications
3See Wood (2004) for the definition of a Composite Application within the context of SAP and non-SAP
components.4
This approach is quite complicated, and is comprised of a complete architecture-driven methodology. Information
on the approach can be found at http://www.ids-scheer.de/.5It is also possible to evolve this step through traditional Enterprise Application Integration (EAI) techniques, but we
focus on the service-oriented approach for this baseline example.6While we have not explored all possibilities, it should be possible to execute some sequence of these steps by
alternative means, with the orchestration falling in third party non-SAP products, such as those from Digital Harbor
(http://www.digitalharbor.com/)
8/10/2019 06wp02 Impl SAP From E2E Scenarios
8/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 8
Table 1 describes a new paradigm for implementing enterprise solutions. Notice thatthe focus is not on the configuration of ERP modules, but on business processes.
Also note that there is no requirement that all business processes fall inside the
enterprise integration domain; i.e., inside of a single enterprise solution providers
product offering. In fact, we specifically consider in our example the case where
some components are external to SAP. The main point is that the reference scenario
and the company-specific reference model, which ensures a true business process
orientation (as opposed to an interfaced family of systems) drives the
implementation. Throughout, we focus on SAP and non-SAP composite applications,
but a similar approach would be used with Oracle, or the product of any vendor that
permits the orchestration of business processes from enterprise services7.
COMPONENTS OF THE REFERENCE MODEL APPROACH TO
IMPLEMENTING COMPOSITE APPLICATIONS
We acknowledge that we use terms that may not be familiar to readers who are
unaware of the new enterprise system paradigm. The following sections provide an
overview of the key components that are critical to the understanding of the
reference model approach to orchestrating enterprise services.
Reference Models
When it comes to successful Business Process Management (BPM), it is important tounderstand and be aware of three main items: (i) the business processes that are to
be managed; (ii) how these processes compare against best practices, and (iii) how
these processes can be implemented in supporting IT systems that are available to
the organization. Gaining an understanding of these items is where reference models
can assist. In the scope of this paper, the term reference model is used to refer to any
model that represents an overview of a particular business process regardless of
the level of detail of the model8.
Generally, reference models will either focus on a business process, or how it can be
implemented in a specific IT environment. The former will typically be based on
research into existing implementations. Here, a generic process will be applicable to
most organizations, regardless of the particular IT environment. The latter is typicallybased on an existing and proven implementation of a business process within a
specific IT environment for a specific organization. It may or may not be applicable to
7Wood (2004) provides a management overview of enterprise services.
8In general, a reference model could apply to any view of an architecture, such as data, organization, function, etc.
We focus on the business process view, since that is the most important for implementing ERP solutions.
8/10/2019 06wp02 Impl SAP From E2E Scenarios
9/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 9
other organizations, largely due to potential differences in the IT environment9. Both
can however present a starting point against which an organizations existing
processes can be compared and built upon to arrive at a to-be model of a newprocess.
The benefit of a generic reference model is that it will be applicable to many
organizations and will easily allow an organization to compare its own processes
against the model. As these generic reference models are not based on a particular
IT implementation, they should be considered with caution. What may look good in a
generic reference model may not be able to be implemented in the organizations IT
environment, or it may be costly to implement. Apart from not necessarily being
based on best practices, non-generic reference models also need to be considered
with caution for a similar reason: they pre-suppose a particular IT environment. What
may appear to be slight changes in the IT environment can result in costly changes
to the actual implementation of the business process.
A generic business process (reference) model illustrates the business entities and
their relationships. It is not tied to the technologies or standards of the IT landscape;
rather it depicts the general method of executing a business process. The detail that
is specific to the needs of an organization will be added as required so that it can be
used to implement a targeted business concept. Even in establishing a generic
model, it is often useful to use a frame of reference to assist in the overall
development of the business flow, the various business activities and their
relationships. To that end, a blueprint, or an architecture that helps to guide the
layout of the generic process is also recommended. Any such appropriate
overarching mechanism will be adequate. For example, the Supply Chain Council has
released a reference model that visualizes a supply chain as different areas of intra
and inter-company activities. This Supply Chain Operations Reference Model (SCOR)
has served as a useful mechanism in building our generic order execution model (see
figure 3). For the reference model using the new SAP implementation paradigm, SAP
will provide Business Process Snippets, or short business processes that may be
modeled as components of larger aggregated business processes that are
documented in the SAP Business Process Platform. These process snippets are
referenced for usage in the Enterprise Services Repository (ESR), which is a type of
super UDDI10reference repository that identifies all the required objects that are
available to assist in implementing the new SAP paradigm.
9A discussion of some of the organizational and management issues associated with these types of misalignments is
provided by Clemmons and Simon (2001). Additional misalignment issues are presented by Ho, et al. (2004).10
Universal Description, Discovery, and Integration (UDDI) is an industry initiative to create a platform-independent,
open framework for describing Web services, discovering businesses, and integrating business services using the
Internet. More information about UDDI may be found at http://www.uddi.org/.
8/10/2019 06wp02 Impl SAP From E2E Scenarios
10/22
8/10/2019 06wp02 Impl SAP From E2E Scenarios
11/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 11
absorption of BPML. As of this date, BPML is the standard that is supported by all of
the major enterprise systems vendors, including Oracle and SAP.
Service Wrappers
One of the principal challenges typically encountered when building an enterprise
application is accommodating pre-existing (also referred to as legacy) systems and
their associated data. Because it is usually infeasible to implement an entire E2E
enterprise application due to cost and time constraints, enterprise implementations
are usually blends of new and existing systems. Wrappers (also referred to as
adapters) serve as a bridge between different applications and enable the
construction of an enterprise architecture composed of different systems. Web-
based wrappers are software tools that interpret information delivered from an
external business application (on the Web) and translate it into a structure which is
compatible with the master application (Mecella and Pernici, 2001). In practice, aservice wrapper would collect data presented on a Web page through HTML (Hyper-
Text Markup Language) and translate it into the more structured XML, (eXtensible
Markup Language). Once translated into XML, the information can be presented to
other applications that can parse the particular XML flavor in which the data was
stored. In this way, customer data from one business application can be
automatically passed to another application.
Web Services
There is a growing array of software methods, standards, and tools being developed
to enable the development of blended enterprise applications. A key element of
these tools is their adherence to industry-wide standards. Web-based protocols, suchas XML, SOAP11, WDSL12and UDDI, can be used to allow disparate systems to
communicate. Utilizing such protocols and standards, Web services allow different
applications to interact with each other (without human interaction and regardless of
the applications development platform).
An E2E solution links internal and external business applications, systems, and staff
so that they can respond to dynamic business conditions. In the enterprise systems
literature, such linking is known as a composite application (see below). To
effectively support end-to-end processes, an organization must identify how Web
services are used to choreograph activities within a business process, how business
processes are represented as Web services, and also which business partners
perform what parts of the actual business process (Leymann, 2001). Identifying thesekey components will facilitate the integrated solution needed to support Web service
11The Simple Object Access Protocol (SOAP) is a lightweight protocol for exchanging information in a decentralized
and distributed environment. This XML-based protocol is typically used with HTTP. SOAP is a key component for
accessing and invoking a Web service.12
Web Services Description Language (WSDL) is a specification for describing Web services as a set of end points
operating on messages.
8/10/2019 06wp02 Impl SAP From E2E Scenarios
12/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 12
activities. These Web services are orchestrated in accordance with a service-oriented
architecture.
Service Oriented Architecture
In order for composite applications to work in concert, enterprises must implement a
Service-Oriented Architecture (SOA). A service-oriented architecture is a modular
architectural framework that enables Web services and legacy components to
interact seamlessly. When an organization needs to create a new business process to
facilitate interaction with suppliers, customers, subsidiaries, or partners, the SOA
allows quick adjustment of components and creation of new virtual applications.
Business requirements can thus be met more easily and programming efforts and
costs are minimized. Mergers and acquisitions, strategic alliances, portfolio
management, new product rollouts, or supply chain management can be eased using
service-oriented architectures. (Hurwitz, 2003)
With a SOA, a business process involving two or more business partners can be
realized by composing Web services offered by the individual business partners
while taking into account the constraints and requirements defined for each
participating Web service in a hierarchical scenario (Leymann, 2001). The top-level
process in a hierarchical scenario does not have to be owned by an individual
business partner because the standard-based rules are defined in a "virtual
enterprise." Though Web services have held out great promise for integrating
business partners, their true potential remains to be tapped. That is clearly the plan
for next generation enterprise system implementations.
Composite Applications
In todays rapidly evolving business world, companies must be able to quickly adapt
and change their business practices (and in turn their underlying business processes)
to retain competitive advantage. However, organizations typically possess a host of
complex interfaced applications, many of which are from different vendors.
Consequently, even minor changes to a business process may require timely and
costly modifications to the IT environment. Replacing any or all of these systems may
not be possible as significant investments have already been made in these existing
solutions.
Composite applications provide a means to address this challenge. The goal of
composite applications is to preserve the existing software infrastructure by reusingexisting business services, or defining new services around existing functions
(Waloszek, 2005).
8/10/2019 06wp02 Impl SAP From E2E Scenarios
13/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 13
Taken from Seebeyond.com. (2005). Composite Applications and Service-Oriented Architectures.
Figure 4: Example of a Place-Order Composite Application
Figure 4 represents an organization, which employs existing systems to create acomposite application called Place Order. Four layers are shown: the existing
systems, business services, assembly and orchestration, and composite applications
layers. The existing systems layer contains several heterogeneous systems found in
different parts of the enterprise. Objects must be selected, transformed into common
object models, and then integrated into one or more business services. Services like
Create customer or Determine product availability are defined in the business
services layer. These services are part of a service-oriented architecture and are
reusable across the enterprise. The business process is defined and executed in the
assembly and orchestration layer, also called the process layer. The composite
application is now ready for presentation to the user, who is in turn ready to enter
customers order into the system for execution.
Enterprise Services Architecture
This section provides the foundation for bringing all of the previous concepts into a
framework for supporting an enterprise solution. Earlier solutions based on EAI
typically used interfaces to enable communication among disparate systems. Today,
leading businesses are in the early stages of implementing service-oriented
application servers the technology of choice to connect disparate systems. The
application server manages the services that are orchestrated as business processes,
8/10/2019 06wp02 Impl SAP From E2E Scenarios
14/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 14
and binds the data from relational or object-relations sources to the services.
Therefore, it provides the ability to create and maintain the integration logic in a
flexible and efficient manner, sharing objects across disparate system components.However, the challenge has been how to plan, build, maintain, and utilize application
server integration for real business cases. By "real business cases" we mean those
that cut across an organization's internal and external boundaries. Realizing the need
for E2E real business scenarios, SAP has defined a Business Process Platform as a
core enabler of its Enterprise Services Architecture (ESA). The ESA, SAPs response
to the SOA, takes Web services standards and services-oriented architecture
principles and extends them to meet the business solution needs of the extended
enterprise. The concepts are summarized by van de Loo (2005).
With the Enterprise Services Architecture, a composite application can use
enterprise services to automate the flow of information from application to
application. This orchestration is accomplished using a new concept from SAP that is
known as the Composite Application Framework. Enabling the flow of business
processes across internal business units and external customers provides disparate
systems the ability to interact globally and in real time, in order to orchestrate,
oversee and operate complex internal and external business processes such as order
execution.
THE REFERENCE MODEL APPROACH
For purposes of our illustration, we present a medium size manufacturing business
that offers a family of products with variants, as well as customized orders. Thebusiness has a dynamic supply chain and a customer relationship process that
continues to mature. The business environment within which the company operates
is customer oriented, fast paced, and demands attention to achieving competitive
advantage. The company struggles with establishing a broad perspective of its
business processes that span the entire enterprise. Specifically, it cannot fully
articulate what its value added activities are, both internally and externally with its
partners and suppliers. Furthermore, it has had only limited success in capturing
benefits of collaboration and innovation resident in its own employees. Finally, its IT
environment is complex and heterogeneous. It includes components of the mySAP
business suite, but also interfaces with non-SAP applications needed by its internal
organization, partnerships, alliances, and customers.Given this assumed background, the company needs to become more agile and
responsive to not only rapidly evolving business opportunities, but also to an
increasingly demanding customer base. Therefore, the company cannot be
constrained by its own systems, interfaces, business processes, or by any incapacity
to fully leverage its enterprise wide capabilities. Hence, the company needs to know
(i) what its processes are, (ii) how the processes can be integrated and improved,
and (iii) how new processes can be created to address changing business demands.
8/10/2019 06wp02 Impl SAP From E2E Scenarios
15/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 15
Please note, that we are referring to business processes that extend from the start to
the end of an enterprise wide activity, rather than processes that are bound in
functional departments or stand-alone information systems.
The first step in this undertaking is establishing an overarching blueprint a high-
level architecture. Included in this architecture are the different views of the
company (i.e. systems, organization, processes, etc). The business process map of
the enterprise describes the companys overarching business process strategy and
will help to illuminate the value added (process) chains in the enterprise. It models
the company view of what business scenarios are desired. In other words, it is the
company reference architecture that allows management to illuminate, and focus on
a business process orientation as opposed to disjointed functional activities driven
by its interfaced family of information systems.
Once the architecture is established, the focus turns to the key business scenariosthat have been illuminated by the business blueprint. We have noted that the order
execution business process is fundamental to this enterprise, and we shall use this
scenario to illustrate its development into a company specific reference process.
After developing the architecture, the company must now layout an entire end-to-
end product ordering process. Developing an E2E order business process of this
magnitude requires particular attention to detail. To start this process, a generic
reference model greatly facilitates this effort. Although it is not specific to the
company, it assists in revealing the general landscape of the operations. At this point,
it is nothing more than a conceptualization of a basic E2E scenario from which a
company specific model can be developed.
Technology can support this modeling effort. Thus, it is important to note therequirement for an effective and automated tool that supports the development and
subsequent management of the process. As the order execution business process is
being designed, the final results must be documented and implemented in the
company regardless of complexity. All of these initial steps can be accomplished by
using an automated modeling toolset such as ARIS13. ARIS can be employed as a
stand-alone product, and through a bi-directional interface, an E2E scenario can be
synchronized with the SAP Solution Manager14that is itself a component of the SAP
NetWeaver. Besides creating models using ARIS, another option is to use reference
models (i.e., process scenarios that exist in the SAP Solution Manager, which is also a
part of NetWeaver). These pre-designed models describe a business process, and
can be customized for use, and imported into ARIS. It is important to note here thatsophisticated modeling tools will assist in developing, configuring, and implementing
the E2E process. The complete process is presented in Figure 5.
13ARIS stands for Architecture of Integrated Information Systems. Additional information about ARIS may be found
at http://www.ids-scheer.com/.14
For those not familiar with the SAP Solution Manager, see Gulledge and Simon (2005).
8/10/2019 06wp02 Impl SAP From E2E Scenarios
16/22
8/10/2019 06wp02 Impl SAP From E2E Scenarios
17/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 17
into a solution. To that end, we must communicate the execution process through
the various applications and legacy systems.
As noted earlier, integrated systems are fundamental to passing processes related
information between applications. Although application programming interfaces
(APIs) allow different enterprise applications to communicate with each other, the
business process logic in these applications is never passed between them. In other
words, the data is sent without any understanding of the process. The passing of
relevant and accurate data, let alone the integrity of the process is problematic.
NetWeaver provides a solution to address the data and process integration problem.
We discuss NetWeaver as a solution for implementing our extended order process in
SAP and non-SAP enterprise applications (as well as legacy systems) for those who
wish to pursue these options.
NetWeaver is a SAP compilation of products that are presented as an integratedtechnology stack. NetWeaver allows for the development, modeling and
implementation of business processes that retain integrated data bound to
enterprise services, as they are executed across the enterprise. Within NetWeaver is
a component known as the Exchange Infrastructure (XI). XI has a number of
integration components to define, map, configure, describe and store the execution
process, its associated message formats, and how it will interface with other
applications. Once the order execution process is developed in ARIS, and mapped to
the business process objects in the Solution Manager, process execution is managed
through the XI as indicated in Figure 5. The integration builder component of XI is
used to build and map one message format to another for use among the various
application systems. The process is then configured for execution; i.e., this is where
the definitions for the routing of information occur.
Using our order execution example, information received in the customer order may
be relevant to several different parts of the organization, such as accounting,
manufacturing, or delivery. Appropriate routing of this information is stored in the
(XI) directory. This directory also adds additional configuration-specific information
needed for execution. If non-SAP applications are contained within the IT landscape,
SAP NetWeaver has the ability to use other industry-specific standards for
communicating business processes across the enterprise. As an example, different
messages from external customer orders can be mapped to internal SAP message
structures. In this way, when the order is received it is communicated accurately
within SAP components. Descriptions of the various messages and processes (bothby SAP and those from its partners and customers) are kept and drawn from the
integration repository. Through these configuration activities, our model becomes
customer specific.
It is the application server that performs the tasks involved in controlling the
execution process, binding data, and exchanging its XML-based services among
other connected systems. A key component in the server is the adapter framework
that enables different applications outside of XI to communicate. Adapters (recall our
8/10/2019 06wp02 Impl SAP From E2E Scenarios
18/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 18
discussion of wrappers) are used for applications within SAP, messaging systems
(e.g., SOAP), and other industry standards (e.g., RosettaNet), and non-SAP
applications (e.g., Oracle). So, if a partner in the order execution supply chain uses anon-XML format, then an adapter (that is built or procured) will enable a connection
to the XI.
How the order execution process is communicated and navigated through SAP and
non-SAP solutions is managed in the SAP Solution Manager (also a part of
NetWeaver), which manages the implementation and provides configuration
management control over those objects that are shared across the enterprise. As the
to-be execution process is configured, the complete development lifecycle is
managed within the SAP Solution Manager. Here, the order execution process
becomes testable and executable.
The SAP Web Application Server (SAP Web AS) is fundamental to both NetWeaverand the ESA approach to Web services. As the name suggests, SAP Web AS is a
server that communicates through the IP protocol. This is important to the final
development of our solution, which can now be extended as a service. Recall that the
ESA is a new paradigm for implementing enterprise solutions. The focus is not on
modules or applications, but on business processes themselves; and the business
processes need no longer be constrained to a single ERP domain. Rather, the
architecture is what enables an organization to extend its infrastructure on to the
Web and throughout the enterprise.
For example, the execution order may necessitate a special service from one of the
companys external partners (be it financial, manufacturing, or otherwise) this is
possible because NetWeaver runs on the SAP Web AS, and as long as outsideproviders follow the standards, external services may be stored for sharing inside the
SAP Enterprise Services Repository. This is critical to our process as it can now
operate end-to-end, and it truly operates across the geographical and functional
boundaries of the extended enterprise. Furthermore, new and composite solutions
can be either developed or created through re-used lower level business processes
and objects. The concept of sharing and reusable components as presented by van
de Loo (2005) is reproduced in Figure 6.
8/10/2019 06wp02 Impl SAP From E2E Scenarios
19/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 19
Models are a Key Element of the Platform
ISV
components
SAP
non-platform
components
Legacy/
3rd Party
Legacy/
3rd Party
EnterpriseServices
Repository
Process ComponentsProcess Components
OEM
platform
components
Business Suite
SAP Composite Apps
(incl. UI & analytics)
ISV / CustomerComposite Apps
(incl. UI & analytics)
Legacy/Partner
Services
Services
Events
Process snippets
Object models
Roles
UI patterns
The platform contains one consistent set of models
Contributed by any component
Used by any component
Slide taken from Kaj van de Loo, The SAP Business Process Platform, presentation at Burt on Group Catalyst, 2005
Figure 6: Object sharing across the enterprise is accommodatedby the SAP Business Process Platform
Although it may not be readily apparent, Figure 6 is key to understanding the value
proposition for the Enterprise Services Architecture and Service Oriented
Architecture as a general concept. The value of service orientation follows from re-
use. In this case, the re-use is from the sharing of services across the enterprise.
Hence, if service oriented enterprise solutions are implemented in stovepipes, and
the objects are not shared, the value proposition evaporates, just as it does with
traditional highly interfaced enterprise solutions.
8/10/2019 06wp02 Impl SAP From E2E Scenarios
20/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 20
CONCLUSIONS
We have shown, using a generic reference scenario and model, how management
can ensure a true business process orientation across a heterogeneous information
system landscape. This is in contrast to current approaches that interface existing or
new families of systems to achieve an implied process flow that is bound by the
nature of the interfaces. We accomplished this by bounding a composite process
with a reference process that is first presented in generic terms. The scenario is then
translated (through object mappings or interface service presentations) into an E2E
solution that can be implemented in a heterogeneous system landscape in the SAP
Solution Manager.
The intent of the methodology is to facilitate a companys understanding and
capacity to design integrated E2E business solutions using new technologies. The
E2E solution extends the functionality of an organizations systems in a complex
enterprise wide IT environment while remaining true to the real world business
processes that must be executed to obtain competitive advantage. The powerful,
new technologies used to develop these processes are rapidly emerging. Against the
backdrop of these new capabilities, novel applications can be modeled, automated,
implemented, and executed to achieve competitive advantage.
RELATED PAPERS
This and White Papers on other related topics can be downloaded from
http://www.eiisolutions.net/
8/10/2019 06wp02 Impl SAP From E2E Scenarios
21/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
Copyright 2008 Enterprise Integration, Inc. All Rights Reserved. 21
REFERENCES
Author Unknown (2001), mySAP Technology for Open eBusiness Integration, SAP White Paper,
Retrieved April, 2005 from [http://www.sap.com/solutions/netweaver/pdf/overview.pdf/]
Author Unknown (2005), iWay Universal Adapter Framework for SAP NetWeaver, iWay Software,
Retrieved April, 2005 from
[http://www.iwaysoftware.com/pdf/tech_brief/TechBrief_SAPNETweaver.pdf].
Author Unknown (2004), SAP XI 3.0 Adapter Framework. SAP AG, Retrieved April, 2005 from
[https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/xi/3.0/SA
P%20Exchange%20Infrastructure%203.0%20-
%20Adapter%20Framework%20Overview_0_.pdf].
Author Unknown (2005), ARIS for SAP NetWeaver: The Business Process Design Solution for SAP
NetWeaver. IDS Scheer AG. Retrieved April 2005 from [http://www.ids-
scheer.com/international/english/products/aris_implementation_platform/31291].
Chou, D. et al. (2004), Model-driven Business Process Integration and Management: A Case Study with
the Bank SinoPac Regional Service Platform.
[http://www.research.ibm.com/journal/rd/485/zhu.html]
Clemmons, S. and S.J. Simon (2001), Control and Coordination in Global ERP Configuration, Business
Process Management Journal, 7 (3), pp. 205-215.
Eisenberg, R. (2004), Open for Business, Retrieved April, 2005 from
[http://www.intelligententerprise.com/showArticle.jhtml?articleID=19502159/].
Enterprise Services Architecture - An Introduction (2004), Walldorf, Germany: SAP AG.
Fotis, R. (2003). SAP Exchange Infrastructure: An Overview of SAP Integration Technology, SAP AG,
Retrieved April, 2005 from [http://www.sap.co.il/ppts/Rico%C2%B4s%20XI%20Overview.pdf].
Gulledge, Thomas and Georg Simon (2005), The Evolution of SAP Implementation Environments: ACase Study from a Complex Public Sector Organization, Industrial Management & Data
Systems, 105 (6), pp. 714-736.
Gulledge, T.R., R.A. Sommer, and J.P. Vincent (2005), An Introduction to Basic Enterprise Resource
Planning Concepts, International Journal of Management & Enterprise Development, 2 (2), pp.
204-218.
Gulledge, Thomas (2005), What is Integration? Forthcoming in Industrial Management & Data
Systems.
Ho, C.F., W.H. Wu, and Y.M. Tai (2004), Strategies for the Adaptation of ERP Systems, Industrial
Management & Data Systems, 104 (3), pp. 234-251.
Hofreiter, B. and Huemer, C. (2004), Transforming UMM Business Collaboration Models to BPEL, Lecture
Notes in Computer Science, 3292, pp. 507-519.
Hurwitz, Judith (2003), Composite Applications: Leveraging Assets for New Business Models. CIO
Online, Retrieved April, 2005 from [http://www2.cio.com/analyst/report1726.html].
Jorns, C. Fit for SAP NetWeaver? Use the Potentials of Integrated and Innovative Processes in the Best
Way, IDS Scheer AG, Retrieved April, 2005 from [http://www.ids-scheer.com]
Leymann, F, Roller, D and Schmidt T. (2001), Web Services and Business Process Management.
[http://www.research.ibm.com/journal/sj/412/leymann.html]
Mecella, M. and Pernici, B. (2001), Designing Wrapper Components for e-services in Integrating
Heterogeneous Systems, The International Journal on Very Large Data Bases, vol. 10 (1), pp 2-15.
8/10/2019 06wp02 Impl SAP From E2E Scenarios
22/22
IMPLEMENTING SAP FROM END-TO-END BUSINESS
PROCESS SCENARIOS
C i h 2008 i i All i h d 22
Medaille, P. (2004), Using SAP XI to Integrate Heterogeneous Landscapes. SAP Labs, Retrieved April,
2005 from
[https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/xi/Use%20SAP%20XI%20to%20Integrate%20Heterogeneous%20Landscapes.pdf].
Okrent, M. and R. Vokurka (2004), Process Mapping in Successful ERP Implementations, Industrial
Management & Data Systems, 104 (8), pp. 637-643.
Schmitz, D. Lakemeyer, G. Gans, G. and Jarke, M. (2004), Using BPEL Process Descriptions for Building
Up Strategic Models of Inter-Organizational Networks. Lecture Notes in Computer Science, pp.
520-532.
Seebeyond.com (2005), Composite Applications and Service-Oriented Architectures, Retrieved April,
2005 from [http://www.seebeyond.com/resource/index.asp].
Volmering, T. and Scholz, T. (2004), A Shared Language for Business and IT, SAP AG, Retrieved April,
2005 from
[http://www.sap.info/index.php4?ACTION=noframe&url=http://www.sap.info/public/en/catego
ry.php4/Category-28943c61b1e60d84b/page/7/article/Article-1304740f658013176e/en/articleStatistic/].
van de Loo, K. (2005), The SAP Business Process Platform, Presentation at the Burton Group Catalyst
Conference, 13 July, San Diego, California.
Volmering, T. et al. (2004). BPM in Practice: Modeling Business Processes. SAP AG. Retrieved April,
2005 from [https:/.../documents/a1-8-4/ BPM251%20-
%20BPM%20in%20Practice%20Modelling%20Business%20Processes.pdf].
Waloszek, Gerd. (2005), Crossing Boundaries with Composite Applications, SAP Design Guild Online,
Retrieved April, 2005 from [http://www.sapdesignguild.org/editions/edition7/intro_article.asp].
Woods, D. and Word, J. (2004), SAP NetWeaver for Dummies. Wiley Publishing Inc.
END NOTES
Hofreiter, B. and Huemer, C. (2004) Lecture Notes in Computer Science, 3292, 507-519.
Mecella, M. and Pernici, B. (2001) The VLDB Journal The International Journal on Very Large Data Bases,
10, 2-15.
Schmitz, D., Lakemeyer, G., Gans, G. and Jarke, M. (2004) Lecture Notes in Computer Science, 3292,
520-532.