EERP: End-to-End Resource Planning

Transcription

1 EERP: End-to-End Resource Planning Dr. uan-chwen ou Dr. James Guo Beijing ebridgechina Technology Service Ltd. ovember 2007 Copyright 2007 Beijing ebridgechina Technology Service Ltd.

2 Table of Contents 1. Introduction SOA ESB QoS SLA BPM Convergence of BPM and SOA Complementarity of BPM and SOA Advantages of the BPM-SOA Combination EERP Example of Process Optimization Issues in business processes and services design Conclusion...11 References...11 EERP White Paper ovember 2007 ii

3 1. Introduction EERP: End-to-End Resource Planning Traditionally, Enterprise Resource Planning (ERP) systems were focused on optimization of the enterprise-internal processes, and not equipped with interaction possibilities with external parties. The key to remain competitive in 21 st century is the ability of an enterprise to describe, standardize, and adapt the way it reacts to the business activities, and how it collaborates with customers, suppliers, partners and competitors. Business innovation and collaboration will require dynamic end-to-end integration and runtime optimization of business processes across value chains. End-to-End Resource Planning (EERP) is initiated to serve this purpose. In a recent Gartner report, Jim Sinur predicted: Enterprises that aggressively begin their organizational and cultural transformation for business process management (BPM) in 2007 will double their chances of becoming industry leaders by Janelle Hill added: Starting in 2007, broader BPM initiatives will become the dominant force guiding the application architecture migration agenda; Service-oriented Architecture (SOA), vital to these initiatives, will be more directly tied to business strategy as a result of BPM's influence. [1] BPM on SOA is a discipline that combines software capabilities and business expertise to accelerate innovation and optimization of the end-to-end business processes. Therefore, BPM and SOA technologies are combined as the core technology for EERP. 2. SOA In SOA, services are wrapped as loosely coupled reusable web services. However, at implementation time, it is not practical to loosely couple a service or any other interaction between systems. The systems must have some common understanding between them to conduct an interaction. Instead, to achieve the benefits of loose coupling, consideration should be given to how to couple or decouple various aspects of service interactions, such as the platform and language in which services are implemented, the communication protocols used to invoke services, and the data formats used to exchange input and output data between service consumers and providers [2]. These can be carried out by an Enterprise Service Bus (ESB). 2.1 ESB The enterprise service bus is both a physical instantiation of an element of the SOA Foundation and a design pattern that is widely accepted throughout the industry. EERP White Paper ovember

4 In Figure 1, the ESB is depicted as a logical component in SOA. It acts as the mediator between the service consumers and service providers. The service providers and service consumers never interact directly. They always use the ESB as a mediator. The ESB provides services to resolve differences in protocol and format, and decouples the service consumer from the service provider. Figure1. ESB and SOA Source: [2] ESB is a powerful addition to an enterprise integration architecture. It enables faster, simpler, and more flexible integration, which allows your integration to respond at the speed of the business. It also shrinks the number of interfaces and improves the reusability of interface components to cut cycle time from design to deployment. An ESB provides capabilities that enhance both direct connection between applications and routing requests among applications. An ESB supports the concepts of SOA implementation by: Decoupling the consumer s view of a service from the implementation of a service Decoupling technical aspects of service interactions Integrating and managing services in the enterprise ESB can also provide the following functions to fulfill the needs such as security, mapping and transformation, etc.: Map service requests from one protocol and address to another. Transform data formats. Support a variety of security and transactional models between service consumers and service providers and recognize that consumers and providers might support or require different models. Aggregate or disaggregate service requests and responses. Support communication protocols between multiple platforms with appropriate qualities of service. EERP White Paper ovember

5 Provide messaging capabilities such as message correlation and publish/subscribe to support different messaging models such as events and asynchronous request/response [2]. In order to support service discovery, selection and composition for process optimization, quality of services (QoS) and service level agreement (SLA) are required to fully meet the business goal. 2.2 QoS Web service QoS usually is non-functional. It includes two aspects: technical and business aspect. Table1 gives some examples of the most frequently used QoS indicators. Quality name Availability Accessibility Integrity Performance Reliability Regulatory Security Pricing Billing Warranty policies Other aspects of quality of business Table 1. Some QoS Indicators[3] Explanation Technical aspects [3] Availability is the quality aspect of whether the Web service is present or ready for immediate use. Accessibility is the quality aspect of a service that represents the degree it is capable of serving a Web service request. Integrity is the quality aspect of how the Web service maintains the correctness of the interaction in respect to the source. Performance is the quality aspect of Web service which is measured in terms of throughput and latency Reliability is the quality aspect of a Web service that represents the degree of being capable of maintaining the service and service quality. Regulatory is the quality aspect of the Web service to insure conformance with the rules, the law, compliance with standards, and the established service level agreement. Security is the quality aspect of the Web service of providing confidentiality and non-repudiation by authenticating the parties involved, encrypting messages, and providing access control. Business aspects Pricing is your firm s ability to create profit by capturing and extracting some (or all) the value that your firm delivers to its customers. The total amount of business done in a specific period, such as by an advertising agency or a law firm An assurance by the seller of property that the goods or property are as represented or will perform as promised. Other quality indexes related to business requirements. EERP White Paper ovember

6 2.3 SLA A service-level agreement (SLA) is a formal contract between a service provider and a client guaranteeing quantifiable network performance at defined levels. SLAs can be either very general or extremely detailed, and generally include the steps that should be taken by the service provider and the client in the event of failure. Meanwhile, in each SLA, the service level must be precisely defined; otherwise, the parties will not have an agreement on what service or performance criteria the SLA is measuring and at what level [4]. The web services SLA is used to guarantee that the services ordered by an enterprise can provide the expected reliability, applicability and issues of service quality. Service level agreements have many different formats, not only in the network aspect but also in the business aspect. We use one example format to illustrate what the SLA is and how to describe its terms [5]. Parties SLA parameters: define monitoring of QoS metrics Service description Service operations: describe available operations Obligations Service Level Objectives (SLOs): QoS guarantee Action guarantees: specify what happens if SLOs are met or not met Table 2. Simple example of SLA[5] Service Level Agreement Parties Consumer C Provider P Service operations (OP1) float getstockprice(string stockame) SLA parameters (RT-OP1-C) Response time of operation OP1 measured at consumer C by consumer C SLOs (SLO1) For every OP1 invocation by C, RT-OP1-C will be less than or equal to 2 seconds Action guarantees (AG1) If SLO1 was met, C pays P price of US$0.20 per invocation; (AG2) If SLO1 was not met, P pays C penalty of US$0.10 per invocation 3. BPM BPM is a general term describing a set of services and tools that provide for explicit process management (e.g. process modeling, design, deploy, execution, monitoring, analysis, simulation and optimization), ideally including support for human and application-level interaction. It is possible to define and execute end-to-end business processes between people, systems and activities, independent of applications and infrastructure. BPM allows business analysts to model a business in terms of its end-to-end business processes that cut across traditional organizational and system boundaries. Processes and information technology (IT) system applications are built as a collection of atomic activities, connected and coordinated by an intelligence capable of selecting the right activity at the right time. EERP White Paper ovember

7 An end-to-end BPM solution must include a complete set of integrated capabilities offering both application to application (A2A) and business to business (B2B) integration, process automation and optimization services in order to speed critical decision-making, increase operational efficiency, reduce the overall cost, and improve customer satisfaction. Processes and underlying services should be tuned to their optimal level, so that they can react to issues before they become problems and identify opportunities with increased speed and agility, thereby maximizing the value delivered to customers. 4. Convergence of BPM and SOA 4.1 Complementarity of BPM and SOA BPM is fundamentally a top-down approach whereas SOA is usually bottom-up. Although there are some differences between BPM and SOA, they are complementary to each other. On the one hand, BPM can consume business services that are defined and managed using SOA. SOA is smoothing the path for BPM proliferation, helping BPM to deliver its agility promise through an SOA loosely coupled and agile enabling infrastructure. Thus processes modeled by BPM tools can be rapidly implemented by SOA. On the other hand, as SOA's killer application, BPM is providing SOA with a strong business-case, and is facilitating a closer alignment between business and IT. Furthermore, building useful high-level business services and composite applications in SOA often requires orchestration that is in the realm of BPM. 4.2 Advantages of the BPM-SOA Combination SOA provides orchestration of IT assets. BPM provides orchestration of business process assets. The two together provide a platform which offers: an IT infrastructure that is SOA-enabled, allowing the fast and simple assembly of IT systems to meet business needs as they arise, a process infrastructure that is likewise service oriented, allowing business processes to be quickly and easily built and optimized. The BPM-SOA combination allows services to be deployed as reusable components that can be orchestrated to support the needs of dynamic business processes. The combination of BPM and SOA enables business to iteratively design and optimize business processes that are based on services that can be changed quickly, instead of being 'hard-wired'. This has the potential to lead to increased agility, more transparency, lower development and maintenance costs and a better alignment between business and IT. In addition, BPM and SOA provide a new capability to orchestrate system components or services to meet new business requirements as they surface. 5. EERP EERP is a business-centric approach to end-to-end integration and optimization of business processes and services to increase business agility and adaptability to ever-changing environment, improve business performance, sustain competitive advantage, and ultimately create business value and accomplish the business objective. Within an EERP environment, the view of end-toend business processes includes how the business processes span lines of business, tapping into EERP White Paper ovember

8 functional tasks within each line of business and beyond the boundaries of the enterprise to trading partners and external service providers. The end-to-end business processes are the primary means of an enterprise defining its unique combination of business services and creating differentiating value. To keep these end-to-end business processes in line with the ever-changing demands of the market, the enterprise needs a deliberate, thorough approach to managing them. Figure 2 shows the elements of an EERP framework. Figure 2. EERP framework The system functions of an EERP framework include: Service publishing: make available the description of the capabilities and the QoS for a business service in a service repository. Service discovery: locate different services suitable for a given business task. EERP White Paper ovember

9 Service selection: choose the most appropriate and goal-satisfied services among the available ones. Service negotiation: automatically reach the service quality and measurement level (SLA) agreed to between service provider and consumer, including exception handling and compensation. Service composition: combine services to achieve the customer business goal. Mediation: solve mismatches among protocols, data, processes and applications so as to improve better integration. Business process simulation: to run the whole process by setting up parameters for simulation in the BPM layer before deployment and try to forecast any potential problems. The required data is obtained from historical records of services. This can help business analysts to rebuild process. Process execution: invoke services following programmatic conventions. Deal with exceptions dynamically by means of runtime service discovery, selection and negotiation. Runtime monitoring: control the execution process and runtime data gathering via business activity monitor (BAM) of the BPM layer. Compensation: provide transactional support and undo or mitigate unwanted effects. Service replacement: facilitate the substitution of services by equivalent ones by service discovery, selection and negotiation automatically. Auditing: verify that service execution occurred in the expected way. Business process optimization: try to find the most effective and appropriate business process and its composed services that maximize achievement of the business goal via analytic, BAM and simulation component of BPM layer. End-to-End Optimization via EERP Firstly, users specify their business goal before the corresponding business process is created. Subsequently, the EERP platform can automatically find the target tasks and services to produce the process according to the specified business goal. The services with functionalities and QoS that best match the goal could be selected for use by the consumer process, while other services are filtered out. At this time, process simulation is initiated to wait for the results. This can help business people to capture and create consensus on business process and provide visibility into bottlenecks. This would also foster communication on how to make the entire process more productive and reasonable. This is called model testing and optimization. During this time, outputs of the simulation can measure resource utilization and enable business analysts to modify and optimize the web services assigned. For example, the EERP platform provides ways to measure services-based and activity-based costs, simulation cycle time, waiting time, working time, work resource counts, queue sizes, response time, and business related results such as order cost, average time, service level and so forth. During the process execution, the negotiation between service providers and consumers is required to guarantee mutual SLA. When service exceptions occur, the service provider or service consumer will know how to deal with the exception and what the next step is. The EERP platform also provides web services management of business processes and mechanisms for exception handling. For example, after an unexpected event happens, the EERP platform can EERP White Paper ovember

10 automatically find another equivalent substitution service which meets the required QoS and SLA to guarantee the successful business process execution or stop due to exceptions to the rule. 6. Example of Process Optimization This is a scenario of purchase order process optimization. Upon receiving a purchase order from a customer, the order process engine checks inventory stocks to decide whether an accessory order is required. Subsequently, the business process engine invokes one of the manufacturing lines to produce the necessary products. Finally, different logistic ways (civil or oversea) will be taken according to the order. Purchase Order Receiving PO Check stocks Oversea logistic? Civil logistic Product Invoice shipped Accessory purchase Oversea logistic activity web services Figure 3. Purchase order process In this case, there are four web services in the purchase order process including check stocks, accessory purchase, manufacture, oversea logistic (sub-process) and civil logistic (subprocess). Meanwhile, the accessory purchase service and manufacture service have various service providers identified to provide required support. That is, for accessory purchase, suppliers A, B, or C can provide the same functionalities with different QoS/SLA and PL1, PL2 (product line) can support the same manufacture service. Table 3 and 4 show QoS of accessory purchase service and product line service in order for process optimization. Table 3.QoS and SLA for accessory purchase service. QoS Average Cost Response rate (h) Quality Level Service (Unit) A B C Average cost: cost of product per unit; Response rate: rate of delivery time per unit Quality factor: 1-9 quality level. Level 1 is the worst and level 9 the best. EERP White Paper ovember

11 Table 4. Qualities of product line service QoS Min/Max Duration Average cost Delay (ull) Service PL PL Min/Max Duration: Due time. Delay: waiting time to start. otice: all the parameters mentioned in the tables above are synthesized from historical and experimental data. Given that quality of purchase order is shown in Table 5. Table 5. Required QoS of purchase order Purchase Order (QoS) Quality name value Cost (priority) Deadline (h) 50 Quality level 3 (SLA) Quantity 200 ow process simulation starts to run all the possibilities. Outputs are as follows: {3000,4+2.5} {2400,6} A {10000, 24,>1} A {10000, 24,>1} A+PL1 : {13000, 30.5, >1} A+PL2 : {12400, 30, >1} {3000,4+2.5} {2400,6} B {12000, 30, >3} B {12000, 30, >3} B+PL1 : {15000, 36.5, >3} B+PL2 : {14400, 36, >3} {3000,4+2.5} {2400,6} C {14000, 40, >5} C {14000, 40, >5} C+PL1 : {17000, 46.5, >5} C+PL2 : {16400, 46, >5} Figure 4. Outputs of purchase order after process simulation at one time period EERP White Paper ovember

12 From the above simulation results, we can conclude that the best service composition selected is B + PL2. 7. Issues in business processes and services design The challenge is in agreeing to the granularity of the different levels and naming conventions adopted for each level. The simplest approach may be to have a clear separation between an end-to-end process layer and a services layer. But this design tactic can quickly become difficult to manage and does not lend itself to large scale deployment. Granularity is extremely important as it is possible to kill any project through bad service design. Therefore, getting the level of granularity right for he various services is critical. On one hand, IT developers will usually begin with fine grained services. SOA services with fine granularity make it very difficult for BPM designers to manage and use for building meaningful applications. On the other hand, the BPM project team will identify the need for business level components (coarse-grained services). Coarse-grained services are easier to manage since they can be located and reused appropriately through the associated meta-data. However, a coarse granularity reduces the degrees of flexibility in the resulting applications. As a result, the degrees of flexibility of the resulting applications are dependent on having the right level of granularity. Too small, and it becomes hard to build anything meaningful; too large, and it becomes unwieldy (i.e. it is already working as an application)[6]. A successful service is one that is re-used often and changes seldom. The meta-data need to include its inputs and outputs, as well as the QoS it will deliver. It may also need to include information on security and infrastructure requirements. Converging the BPM and SOA viewpoints towards a unified approach takes more than just bringing the associated two methodologies together. There is also a gap between the two viewpoints when it comes to using the same terminology to mean different things [7]. For instance, the same terms like business processes, businesses services, business practices, business components and business capabilities are often used to mean different things to the two communities. With the growing trend to adopt a unified BPM-SOA modeling and architectural approach, there will be more pressures to unify and standardize the technical terms to help create a unified mindset. Standalone BPM products (without SOA) have traditionally relied on design-time process modeling tools. For successful BPM-driven SOA solutions, it is also important to provide runtime process management tools that capture the actual state of the running system [8]. BPM (BPM standard) and BPEL (SOA standard) were not originally designed to work together [4]. This leaves some gaps that need to be addressed before processes can be modeled, optimized and executed end-to-end within a BPM-SOA unified framework. It is expected that big BPM-SOA players will use their weight in the various standards committees to further accelerate the acceptance and adoption of standards that best fit their BPM-SOA vision. Essentially, we need to think about how processes might be composed of a set of discrete services, and vice versa how a business service might be implemented as a set of processes. EERP White Paper ovember

13 8. Conclusion 2007 was a year of convergence for SOA and BPM [9]. This convergence allowed the IT and business world to align with each other to transform technical capability into business agility. EERP is a killer application of this convergent technology which provides a solution to support the end-to-end integration and optimization of business processes and services to improve business performance and accomplish the business objective. At the heart of these solutions are business process engines, enabling the separation of business logic and application logic, and allowing changes to rules and processes to be made without affecting underlying systems or interaction channels. In the near future, some standards for EERP will be developed to facilitate the integration and optimization of end-to-end business processes and services. The semantic technologies such as semantic SOA (SSOA) and semantic BPM (SBPM) will also be adopted to enable automatic service discovery, selection, composition and execution for dynamic business processes integration and optimization. References [1] S. Jim, H.B. Janelle, "Gartner Predicts 2007: Align BPM and SOA Initiative ow to Increase Chances of Becoming a Leader in 2010", Gartner Report, ov 2006, pp [2] Patterns: SOA Design Using WebSphere Message Broker and WebSphere ESB, IBM.com/redbooks, 2007, [3] Anbazhagan Mani, Arun agarajan, Understanding quality of service for Web services, IBM developerworks,2002, [4] Judith M. Myerson, Use SLAs in a Web services context, Part 1: Guarantee your Web service with a SLA, IBM developerworks, 2004, [5] Pierluigi Plebani, Quality of Web services, International Summer School on Service- Oriented Architectures, Collegno, Torino, August 29th - September 1st, 2006 [6] "Issues and Best Practices for the BPM and SOA Journey", Enix Consulting White Paper, 2006, pp [7] P. athaniel, "Transformation=SOA+BPM", Analysts Briefing, Delphi Group, bpm.com, Oct 2005, [8] F. Colleen, "Special Report: BPM Inside the Belly of the SOA Whale, Part 3", Web Services ews, June 29, 2006, pp [9] M. Joe, "2007: A ear of Convergence for SOA and Business Process Management", ebizq SOA in Action Blog, December 18, 2006, pp EERP White Paper ovember