Business Process Management (BPM)

1. Business Process Management (BPM) What is BPM? Why should I care? SOA Brown Bag #4 SWIM Team February 9, 2011

2. Agenda • Introduction – why should I care? • Definitions • The benefits of BPM • Model-Driven Environment • BPMN and its challenges • DoD Primitives • Adoption Challenges • BPM and SOA • BPEL Orchestration • Key characteristics of BPM Suites • Tools • Getting Started

3. Business and IT are tightly connected;they either succeed or fail together • Business Process: The required steps to accomplish a specific business function. “Representation of what an organization does -- its work -- in order to accomplish a specific purpose or objective” source: BPMN Modeling and Reference Guide • Business processes that require automation are implemented and facilitated through IT. • As business processes change, IT has to change. Business Processes IT implementation

4. Processesdrive a “true” SOA • Myth: If you’ve implemented web services, you’ve implemented SOA. • Reality: An organization will reap the full benefits of SOA if it starts with its business process. The reward at the end of the journey

5. BPM, BPMN & BPEL defined

6. Additional elements

7. How does it all fit together? BPM BPMN BPEL Services Layer

8. What is the benefit of BPM? • To gain sight and control of the business process. • To provide a service orchestration layer in SOA implementation. • To enable business agility.

9. What is a model-driven environment (MDE)? • Model-Driven Environment (MDE): Models created based on today’s problem and tomorrow’s solution environments. • Models can be created with sufficient specificity to generate the necessary technical artifacts for execution, or can be executed directly in the appropriate run-time environment. • Business Process Automation engine (see next slide) • Business rules engine

10. How do we get to a model-driven environment? • A BPMN model captures business processes transfers them to a Business Process Automation engine in a BPMN-executable serialization format. • Depending on the tool, it may also be: • Transferred as an XML Process Definition Language (XPDL) format. • Translated into the BPEL specification. • Captured in one of the business rules languages.

11. Process and rule models in an MDE Source: DoD Federation Strategy

12. BPMN: different conformance subclasses for different uses

13. BPMN 2.0 Conformance Class

14. Challenges • There are too many options to accomplish the same results or to diagram the same processes. • Using tools interchangeably is nearly impossible.

15. Project: DoD Primitives • Using DoD Primitives is a way to establish standard format for diagrams and for data that represents the diagrams, and for data that moves within and between the reality that diagrams represent. • The Object Management Group selects DoD primitives as a BPMN conformance class.

16. Dictionary Source: DoD briefing

17. Adoption challenges • Thinking “Process” – True, executable BPM requires a new level of rigor and attention to business processes. • Managing cultural impact – Documenting processes with tools (as opposed to pictures) will illustrate issues with current processes. A socialization strategy is key. • Many popular BPM suites are ‘heavyweight’ and present a non-trivial learning curve.

18. BPM and SOA Process Flows Coarse-Level Web Services Best Case Scenario

19. A business-driven SOA, defined “SOA is a way of describing an environment in terms of shared mission and business functions and the services that enable them.”* *Source: DoD Net-Centric Data Strategy

20. BPM and SOA External Systems ESB WS Security UDDI Internal Systems BAM BPEL Trusted Enclave Internet DMZ

21. BPEL orchestration • A BPEL orchestration is considered a web service in the domain to which it belongs. • All BPEL processes provide a set of WSDL and schema definition files within the namespace that identifies the domain. • The BPEL WSDL file will provide the binding information and the endpoint of the location where it is deployed. • The orchestration is represented in a WS-BPEL standard representation that should be portable across BPEL engines. • BPEL orchestration service should follow web service invocation standards (WS-I).

22. BPEL orchestration, continued All orchestrations have one entry point and one response point. • The invocation/entry to the orchestration is marked with the receive block and delivers the message identified as the input parameter in the operation. • Response block must return a message identified as the output parameter in the operation. • A BPEL process may be synchronous e.g., a client needs to receive response immediately, or asynchronous e.g., a client will continue its operation and receive a response at a later time.

23. BPEL orchestration elements A BPEL orchestration consists of scopes, sequence, partner-links, variables, activities and fault handling. Scope: Identifies the unit of operation within an orchestration. This helps to avoid variable collisions, fault handling and ensuring transaction integrity. Sequence: Identifies a sequence of activities. Partner Links: External services are represented as partner links and they specify the WSDL file of the external service. Partner Links/Adapters: Some BPEL tools provide technology and application adapters that extend basic technologies i.e., databases, queues or applications i.e., CRM, ERP as web services through wizards. Variables: Data stores that hold the operational data within the life of the orchestration. Variables can be localized to a scope or set in the global scope. Activities: Transformations allow copying whole or sub trees of data across variables. Assignments allow specifying values for leaf nodes of an XML tree. Fault handling: Scope errors can be managed using fault handling for a graceful exit as well as for ensuring transactional integrity. Errors with partner link invocations must be handled using fault handling.

24. Key characteristics of BPM suites • A graphical modeling capability • Ability to simulate business process • Ability to create rules to drive flow and decisions • Ability to capture, present, and analyze process metrics • Standards-based

25. Getting started • Prototype/Pilot – an area for improvements! • Choose a small, but business-significant process. • Engage the vendor for training, preferably focusing on the pilot problem. • Identify business services required for process support. • “Prototype” the socialization process. • Engage stakeholders to assess feasibility of making candidate process changes illustrated by the modeling process.

26. For more information White Papers IBM Thought Leadership White Paper Lombardi Downloads Office of Information Technology – ATO BPMS Services Julie Flores-Kriegsfeld Jonathan Beams www.swim.gov Jim.Robb@faa.gov Paul.Jackson@faa.gov Dov.Levy@DovelTech.com

27. Discussion