SUCCEEDING IN SOA-ENABLED BPM A METHODOLOGICAL APPROACH FROM ORACLE

Transcription

1 SUCCEEDING IN SOA-ENABLED BPM A METHODOLOGICAL APPROACH FROM ORACLE [ NOTE: THIS DOCUMENT MUST BE ACCOMPANIED BY THE DOAG PRESENTATION BY THE SAME TITLE FOR COMPLETENESS] MARK WILKINS, MANAS DEB, MEERA SRINIVASAN - ORACLE INTRODUCTION With the advent of executable businesss process models in the newest revision of the BPMN standard there is a tendency to imagine that processes modeled by a business user can flow directly into production execution. In fact this is not entirely unrealistic; however, there is a need for both the checks-and-balances of an engineering method and an underlying architecture to support seamless interaction between the business and IT. The architecture that best supports cooperation between the business and IT is, of course, Service Oriented Architecture (SOA). To complete the picture, Oracle provides lightweight, pragmatic engineering methods for both SOA and BPM. While these complimentary methods are designed to function independently, their benefits are multiplied when they are combined. The presentation briefly describes the Oracle approach to combined SOA and BPM roadmap planning and then delves a little deeper into the methods for service and process engineering in order to highlight their synergies. The diagram below shows, at a high level, the relationship between BPM and SOA engineering. Business process automation generates the requirements to support tasks in the business process model and uses servicess that are defined by a service contract. Service construction, on the other side of the equation, uses requirements to identify service candidates and justified services are defined by service contracts. Success is measured by business KPIs and service engineering KPIs respectively. Nov

2 The business process engineering lifecycle is often seen in a simplistic form, similar to the phases of traditional (UP) software engineering process, covering analysis, design, implementation, and monitoring: monitoring replaces deployment in the traditional cycle emphasizing the greater role of monitoring and analysis in BPM and the reduced effort of deploying a composite business ss process application. In order to see how SOA supports the BPM method we need to look at the engineering approach in a little more detail. The diagram below shows the ten major activities in the Oracle business process engineering lifecycle annotated with key SOA touch points. SOA service engineering itself may also create business process services. While it is necessary to distinguish technical orchestration services from core business processes, it is important to appreciate their value as reusable business process fragments and the need to coordinate engineering practices and associated tooling. The diagram below shows the Oracle service engineering lifecyclee and the major BPM touch points of interest to this discussion. Nov

3 The two complimentary engineering processes are described in more detail in the accompanying presentation in order to show the benefits of coordinated SOA and BPM engineering ing strategies. Realization of these benefits demands fully capable tooling and so the brief tour of these strategies identifies the major products intended for this purpose. Oracle Business Process Analysis Suite and Oracle Business Process Management Suite (outlined below) are the major products involved in this discussion, although there are numerous others aligned with this architectural strategy that provide supporting capabilities. ENGINEERING METHOD PARTICIPANTS When defining a BPM/SOA method it is critically important to identify the (potentially new) roles required to support this new approach. The following paragraphs outline the core organizational participants required for a successful BPM Nov

4 project. While role names and granularity rity vary between organizations it is important to ensure that the responsibilities identified here are mapped appropriately to any given organization structure. There are a number of business and technical participants in the Oracle BPM Methodology and it is important to ensure coordination between these two major groups. The BPM Analyst and Process Architect, in particular, represent an important point of convergence between business and IT. Business Participants Business Leadership - Drives requirements by setting business goals, objectives, and priorities. The business leadership provides initial inputs, such as, business motivation definitions including high-level vision and mission statements. The business leadership provides funding for the BPM initiative and typically expects measurable return on investment. Business leadership might include the following more specific role names: Executive (C-level) Management Line-of-Business (LOB) Management Business Process Manager Unit / Division / Departmental / Branch Manager Business Service Owner Quality Manager Compliance Manager Nov

5 The business leadership uses BPM analytics in a broader Business/Enterprise Performance Management (EPM) context and determines the need for major business process change. A significantly large BPM initiative may identify a new executive role, perhaps called Chief Process Officer, who will be responsible for fostering a process-centric business culture, influencing the development of skills, systems, and behaviors, and championing an enterprise process architecture. Process Owner - Managing process flow, task assignments, policies, rules, objectives, and performance measurement, the Process Owner is responsible and accountable for the performance of end-to-end business processes. The process owner owns a specific process or processes, and is the primary authority for making decisions necessary to resolve conflict or overlap between processes. Process Owner is the subject matter expert (SME) for the business process(es). He is the business primary contact for the Business Process Analyst. People in this role however, specialize in a small number of processes and don't have the broader perspective of other the business leadership across the enterprise. Establishing the process owner role has emerged as a best practice for BPM since the key business processes cross organizational boundaries and typically have no single point of responsibility. Commonly, gaps (known as the white spaces) exist between the departmental silos of business process activity where ownership is undetermined and knowledge is sparse. The creation of the process owner role solves these problems by identifying individuals to be the experts responsible for the end-to-end flow of key business processes. While authority for departmental or divisional business process activities remains with respective managers, the process owner is able to take a holistic view and make better recommendations for enterprise-wide process improvement. Business process administration during runtime also requires considerable business knowledge and the Process Owner should be expected to support this key operational activity. Process Participants The participants (aka process performers ) in a business process perform the human aspects of the business process task. Commonly referred to as end users in software engineering, these participants provide task execution details to the process analyst and may be involved in acceptance testing. During analysis for process automation it is important to interview the end users and watch them work to see what they actually do (human activities are commonly more diverse than expected). Some more specific role names for users of the business process might be: Administrator Supervisor Worker Call Center Agent / Customer Service Representative (CSR) Clerks (Back-office processing) Business Partner Customer In addition to the end user performers of the business process work, the automated process commonly requires the support of additional participants categorized here as administrators and supervisors. While supervisors are responsible for overseeing the work performed by the end user participants at the process instance level, administrators are Nov

6 responsible for more general oversight including like role assignments, view management, etc. In addition, supervisors will be in charge of making sure the work is processed in a timely manner, managing exceptions, delegation and reassignment of work as needed. Process Analyst Also commonly known as Business Analyst (or Business Process Analyst), the Process Analyst is primarily responsible for capturing and managing the graphical business process models. The Process Analyst also captures related business process requirements, drives process optimization, recommends changes, and evaluates change requests from the business. The Process Analyst has business and modeling skills and liaises with the Process Architect for technical coordination. The Process Analyst has primary responsibility for making incremental process improvements (as opposed to major change from the business leadership). The Process Analyst also Identifies and codifies business rules Uses business objectives as input to determine KPI Provides business specification for new capabilities Directs UAT IT Participants Process Architect - Performs analysis and design of technical aspects of the process, taking the process specification from the Process Analyst for technical analysis. The Process Architect also specifies additional technical software requirements, such as application integration, UI development, etc. and works with the Business Analyst to design technical specifications for new functional requirements. The Process Architect may also be responsible for Defining technical integration strategies Technical specification for new IT capabilities Directing system & integration testing In an environment where SOA is fully implemented, discovery of services for functional requirements in the process model can be performed effectively by non-technical participants (typically the Business Analyst); in cases of less developed integration architectures however, the Process Architect would be required to identify the most suitable sources of application functionality and business entities. This is a specialized architecture role similar to solution architect in traditional software engineering, but with an emphasis on understanding business process modeling and the details of process implementation in addition to more general software architecture skills. Process Developer May also be called Process Designer, enhances the process model to make it executable in the IT environment by configuring data mapping and transformation of activity inputs and outputs, and defines external data required by the process, etc. QA Manager - Directs acceptance testing and validation. Operations Manager - Handle deployments and technical OA&M (Operations, Administration, and Management) Nov

7 Supporting roles Supporting roles provide security, data, enterprise architecture assistance along with traditional software and service development needs identified by the BPM project. The activities performed by these participants commonly follow their own methods and should be handled separately from the core BPM activities. These supporting roles include: Software / Service / UI Developers - Develops any required new or extended functional capabilities specified by the Process Architect. Traditional software development requirements may emerge from the BPM project including integration, SOA services, or enhancement to existing application functionality. In the case of human workflow a tasklist user interface (UI) or existing application UI may need to be developed to support the human interface to business process. Enterprise Architect provides oversight to ensure IT strategies and standards are applied. The Enterprise Architect works with the Business Leadership to Identify business architecture inputs to BPM (e.g. objectives for program, business motivation, strategy maps, etc.) Helps determine the need for major business process change Security Architect ensures corporate security policies are followed and provides input to the process design for authentication, authorization, and access between potentially silo d applications and departments. Data Architect provides support for information access in the process design and may be responsible for accepting process analytics feeds from the BPM system to support broader BAM/BI/EPM initiatives. The business analyst and process architect are critical roles in the automation of a business process (and are therefore drawn in the center of the diagram). These roles are categorized under business and IT respectively; however they are commonly interchangeable since their skills are very similar. While identifying tooling needed to realize the benefits of combining SOA and BPM, the brief tour of the Oracle engineering method also presents a an outline of the major stakeholders and their involvement in each major activity in the engineering process. The presentation first introduces the participant roles in the engineering process and then uses the RA(S)CI mnemonic (for Responsible, Accountable, Supporting, Consulted, Informed) to clearly indicate their involvement in each activity. THE ORACLE BPM METHODOLOGY KEY LIFECYCLE PHASES The following paragraphs briefly outline the ten major activities (or phases) in the Oracle Business Process Engineering lifecycle diagram. #1 Strategic Analysis and Business Process Selection Successful business process engineering ideally starts by taking business drivers from various potential sources of business motivation descriptions, including business plans, strategy maps, and associated value chains, etc. This approach enables us to identify core business processes and determine their business value alignment in the selection procedure. A tactical approach is also described by the Oracle method that allows selection to proceed when Nov

8 access to these sensitive business documents is not available or when business processes have been identified by some other means. The Oracle engineering methods for both SOA and BPM share a common approach in strategic analysis ensuring a common understanding of business drivers and vocabulary, sharing of assets, and early identification of service and process intersections. # 2 Process Discovery and Definition In this activity the selected business processes are subjected to discovery, in which many participants collaborate to agree upon a model describing the next level of detail for the business process as it is in its current state (i.e. the as-is state). The Process Analyst applies further detail to the business process model, elaborating the model and resolving inconsistencies. This step also defines the project that supports the engineering activity for the business process (or processes). A complete application and SOA service portfolio provide support in the definition of the as-is business processes. #3 Business Process Refinement Refinement refers to the improved version of the business process, also known as the to-be state and this is where the process enters the cycle of continuous business process improvement. On entering the loop for the first time (from the definition activity) changes should be kept to a level to strike a balance between the risk of over-ambitious change and demonstration of value through early wins. Subsequent iterations through the continuous improvement cycle bring greater intelligence about the business process and augmented simulation data from monitoring and analysis. Association of SOA services at this stage enables early alignment with IT capabilities, while detailed service contracts ensure a common understanding between the business and IT participants. #4 Technical Analysis and Business Process Design This next major activity in the engineering life cycle includes a feasibility analysis to ensure that the IT applications and systems are capable of supporting the automation as it is currently defined. A gap analysis is performed to specify requirements for extensions to existing IT capabilities needed to support the to-be business process model. Detailed SOA service contract and interface definitions enable the IT participants to quickly evaluate the completeness of services to support the business process tasks. This in turn, leads to effective reuse of services. #5 Business Process Application Composition The Business Process Application Composition activity completes the technical steps necessary to make the business process model executable. Implementation of the technical aspects of the business process include configuring business rules, Human Task definitions, and wiring Service Component Architecture (SCA) components to support integration and service orchestration requirements; User Interface (UI) applications may also be constructed. In this activity SOA Interface standards enable declarative and graphical assembly of services without the need for integration coding. #6 Integration Testing This activity takes a white-box testing approach to ensure the technical integration between the process engine and the underlying application functions, information services, and various other external data and systems, performs appropriately. Nov

9 #7 Deployment Planning Deployment planning packages the composite business application and all its supporting software components and describes the procedures necessary to transfer it out of development. The package also includes operational procedures and end user documentation and training. The first target for the deployment package, prior to production deployment, is user acceptance and potentially, performance testing environments. SOA enables the management of end-points for all target deployment environments. #8 Approval Next we entered the approval process. Here the QA team plans and manages the end user and performance testing. This step is commonly called user acceptance testing (UAT). Commissioning Once approved by QA the composite business process application moves into commissioning. This is where the business process transitions into full production operation and hence, the state changes to operational. The process is now, no longer a pilot, but is live in production. The SOA service registry supports runtime discovery and facilitates loose coupling of services in a production environment. #9 Commissioning Next we entered the approval process. Here the QA team plans and manages the end user and performance testing. This step is commonly called #10 Monitoring and Analysis Monitoring and Analysis support both Operational Administration and Management (OA&M) of the business process in the production environment and business process improvement. The analysis of data gathered from predefined Key Performance Indicators (KPIs) provides critical information to the business analyst to support continuous improvement and continue the engineering lifecycle by re-entering the refinement step. Web Services Management provides support for monitoring and administration of the underlying SOA and BPM infrastructure. ORACLE BPM TOOLS The following sections outline the primary Oracle products supporting BPM. Various additional products may be involved in the BPM and SOA lifecycles, but are not covered here. Oracle Business Process Analysis Suite Overview Oracle Business Process Analysis (BPA) Suite provides comprehensive modeling, analysis and simulation capabilities for enterprise wide business processes. Oracle BPA supports Enterprise Architecture, process improvement and change management initiatives and provides for alignment of BPM and SOA initiatives. In addition, the suite is innovatively integrated with Oracle SOA Suite to provide closed loop BPM capability enabling business analysts and developers to closely collaborate throughout the entire BPM life cycle using the best tools for their specific needs. Nov

10 Oracle BPA Suite is comprised of four components: Oracle Business Process Architect for modeling and simulation Oracle Business Process Server for storing and providing concurrent access to business process models and related artifacts. Oracle Business Process Publisher for role based presentation of process content to a web portal. Oracle SOA Extensions enable you to take business processes from concept to execution by sharing process blueprints with Oracle SOA Suite Comprehensive and intuitive modeling environment for business users Oracle BPA Suite provides a rich and intuitive graphical modeling environment tailored to business users for defining process maps and detailed process flows consisting of both human, automated and rule steps that spans across organizational boundaries. It has extensive support for modeling shared resources such as process-centric roles and organizational structures as well as data and IT systems landscapes. These resource models can be shared across business processes and aligns the BPM initiative with the Enterprise Architecture initiatives. The tool performs semantic validation of models and provides visual guidance on fixing errors. Collaborative development Promotes role-based development so that everyone in the organization can effectively contribute to every stage of the process life cycle. Process models and shared resources can be organized in to projects that can then be associated to one or more workgroups. The Suite includes a process portal that fosters collaboration among business users distributed across geographic locations. Nov

11 Process Blueprint Bridging IT and Business Gap The Oracle BPA Suite is innovatively integrated with Oracle SOA Suite (the process execution and monitoring components) through the shared meta model called as the Process Blueprint to enable complete lifecycle management of business processes. This unique value-generating approach enables both business and IT to work off a shared process definition. Automatic translation of business requirements in to BPEL processes: Once business decides that a process blueprint is ready for sharing, IT can access and edit it from within their environment. Rich process definitions get generated from the Blueprint promoting rapid and meaningful process automation and reducing the strategy to implementation gap by translating the business requirements directly in to almost ready to deploy BPEL process definitions. Alignment of business model and IT process: The executable process is always in lock step with the business process model. Business users can create and change business models in the Oracle Business Process Analysis Suite while IT users can view and modify these processes in parallel using the Process Designer component of the Oracle SOA Suite. Empowerment of both Business and IT: The Blueprint also supports bi-directional synching enabling both business and IT to work on the same process at the same time. Business level changes can automatically be merged with any changes done by the developers to ensure that the implemented process is inline with the expectations of the business users. Further, IT can make changes to the blueprint that then become visible to business users as proposals for improvement. Continuous Optimizations: Further, process metrics collected from the execution engine can be fed in to the simulation component of the Oracle Business Process Analysis Suite for performing analysis based on real-time data and for continuous process improvements. Nov

12 Robust simulation environment for process optimization Sophisiticated simulation for evaluating the performance problems of as-is processes and the potential impact of changes of to be processes. Extensive simulation capabilities that covers sub-processes, embedded rules and shared resources such as roles. Identification of problems in processes, organizational structure and to unlock improvement. Generation of rich cumulative and detailed results. Business Repository Holds business artifacts and business metadata such as process models, data models, organization model, IT systems model, and risk and control models. It promotes concurrent usage and simultaneous access of several users to the same model via implicit check-in and checkout capabilities. Oracle Business Process Management Suite Overview Oracle Business Process Management Suite is a complete product suite that combines leading standards for BPMN 2.0 and BPEL to execute in a unified engine removing complexity and enabling management of all types of processes efficiently and without compromise. It provides a complete process lifecycle, with modeling, management, simulation, optimization, and execution of business processes, across organizational divisions, systems, and applications. It provides advanced collaboration throughout the process lifecycle by integrating Enterprise 2.0 into the process management context. The suite provides greater business visibility and agility enabling more timely decisions and the subsequent change required. Oracle Business Process Management Suite 11g simplifies the achievement of process management success with a complete solution for all types of processes by providing a unified process foundation, user-centric design, and social BPM interaction. Oracle Business Process Management Suite 11g: Complete and Unified Unified Process Foundation Process management systems are tasked with integrating disparate systems that have a role in critical enterprise processes. It makes sense that a more integrated, or unified product to start with will simplify the task, reduce time-tomarket, and reduce costs. Oracle BPM Suite 11g includes a unified process foundation that simplifies and removes complexity from process development, deployment, monitoring, and execution with a unified process engine and preintegration of process subsystems. It is the industry s most unified, yet complete, BPM solution.. User-centric Design The business process management team includes a variety of users whose needs vary according to role and preference. User-centric design simplifies the process management lifecycle with tools for these participants with BPM Studio and Process Composer providing role-based client and Web-based modeling tools that leverage a unified what you see is what you execute (WYSIWYE) model. This model eliminates synchronization problems between design and run time. Nov

13 Social BPM Collaboration among IT, business, and all stakeholders is a critical component of managing change. Social BPM interaction simplifies collaboration providing new ways to simplify work by incorporating the latest in social computing technologies enabling a greater choice of communications channels. Oracle Business Process Management Suite 11g provides all that you need to innovate today and scale from simple to complex processes as your needs dictate. CONCLUSION BPM is the next step in the evolution of business computing, building on the success of SOA. In many ways SOA has been the catalyst for this new wave of BPM, allowing us to take another great stride toward closing the business IT gap. The IT industry has tried many times to support the business demands of BPM, but only now do see the convergence of new technologies truly capable of supporting a process-centric enterprise. Clearly there are many new, and variations on old, practices necessary to reap the benefits of SOA in support of successful BPM. As we have described in the foregoing pages, changes include extensions to engineering practices to support both the BPM lifecycle and to fully integrate it with existing SOA practices. Organizational changes may ultimately be mandated by business process re-engineering, but the first step must be clear identification of the roles and skills necessary to engineer and operate computerize business process. The Oracle Approach to BPM provides a comprehensive maturity model and accompanying assessment tools to help companies understand their readiness for BPM adoption. The lifecycle of business process engineering, from process identification and selection to operations, monitoring, and performance management, is not only supported by integrated end-to-end tooling and methodology, but developed directly from a SOA platform foundation. This means we have a unique opportunity to fully exploit this new wave of BPM, built on the foundation of SOA. Copyright 2010, Oracle. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular Nov

14 purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Nov