The Mercator Group
Business Process Management Center of Excellence
A Practical Guide to BPMS/SOA Implementation
November 2008
Workbook III: A Practical Guide to BPMS/SOA Implementation
November 2008
Version 1.1
There are three workbooks/practical guides in The Mercator Group’s (TMG) series on process improvement:
Workbook I: Enterprise Portfolio Process Alignment
Workbook II:Business Process Improvement (this workbook)
Workbook III:BPMS/SOA Implementation
Workbook 1 (under development) provides guidance and instructions on ensuring that an enterprise-wide process improvement effort is properly aligned and supportive of organizational mission, goals and objectives. Workbook II provides guidance and instructions on implementing a major process improvement effort, including detailed instructions for conducting process improvement workshops. Workbook III provides a methodology for quickly implementing process improvements using a combination of Business Process Management Suite (BPMS) software and Service Oriented Architecture (SOA) techniques.
The workbooks can be used collectively in a top-down organization-wide process improvement/transformation effort, or independently to address the particular areas for which they are designed.
The workbooks were developed by The Mercator Group ( ) and are freely available for all who would like to use them. We only ask that if used in their entirety that attribution is given to the Mercator Group for material used. The Mercator Group is dedicated to the advancement of enterprise and process improvement methodologies and techniques; especially as they assist government and not-for-profit organizations dedicated to our common welfare. We also are committed to the sharing of knowledge associated with improving enterprise management as a discipline. Collaboration and feedback on material are welcome.
Prologue
The Practical Guide to Business Process Management (BPM)/SOA Implementation presents a model based methodology for building business software using a Business Process Management Suite (BPMS) supported by a service oriented architecture (SOA). The methodology is applicable to any fully functioning BPMS and SOA supported environment. It was developed by The Mercator Group and extended in support of the Federal Acquisition Service (FAS) IT modernization effort. The methodology is based on “hands-on” experience with multiple BPMS systems, as well as experience with leading practice rapid development techniques; including Agile Software Development.
The target audience for the workbook is a business or system analyst practitioner familiar with advanced Model Driven Architecture (MDA) concepts and BPMS in general. However, the methodology is accessible to people with general knowledge of system lifecycles seeking to becomefamiliar with BPMS and MDA.
What is BPMS?
Business Process Management Suites (BPMS) are commercially available software packages that provide a comprehensive and integrated platform for the collaborative design, build and operation of business software in support of business processes. A BPMS provides a non-technical business analyst with a workbench for modeling people-centric applications. Modeled applications can be easily prototyped and integrated in to a SOA environment and deployed on the BPMS vendor provided software platform capable of running mission critical applications. BPMS is relatively new technology that is quickly becoming a core component of enterprises requiring agile IT infrastructures.
What BPMS is not?
BPMS is a software tool that excels in supporting the human workflow and collaboration aspect of business software applications. It does not eliminate the need for complimentary computation intensive or business rules centric software that is critical to any complex business environment.
What is its value?
The primary values of BPMS are as follows:
Accuracy of functional and system requirements for application services increases by a factor of more than two over other development approaches to an accuracy of 95%.
Substantial reduction in BPMS based project risk over more traditional extended lifecycle methodologies based on the ability to iteratively develop and deploy new functionality in manageable “chunks.”
Ability to quickly deploy changes to business requirements and support a continuous process improvement effort.
Reduction in time and cost of software development of between 25% and 50%, depending on system complexity, organizational impediments, and scope.
How is this value achieved?
When implemented using modern software development practices BPMS fundamentally changes the software development process from a sequential set of poorly integrated disciplines and steps (business analysis followed by requirements definition followed by software development followed by maintenance) to an integrated and collaborative process that marries the end user, business analyst and IT professionals into a cohesive team that can quickly deliver target capabilities. The BPMS tool provides the capabilities to quickly generate software functionality in a language (BPMN) that allows for easy communication across the enterprise, including the very important end user and consumer of the generated capabilities. An effective approach and methodology that incorporates integrated project team fundamentals allows for the leveraging of the BPMS capability.
How does BPMS relate to Service Oriented Architecture (SOA)?
They are totally interdependent. The most reliable approach to identifying the services provided by an SOA is through process design validated through BPMS based modeling. Once services are identified they need a mechanism for orchestrating their use in support of a business process. For example, a service that provides for the validation of a credit card purchase requires software to orchestrate access and use of that service in the context of the business process it is supporting. There needs to be orchestration software that coordinates a sales person’s access to the validation service within the context of the transaction. It could be a retail clerk at a store, or a customer service representative on the phone. The use of that service needs to be managed by a layer of software, which is where BPMS excels.
What is Model Driven Architecture (MDA)?
MDA is an essential concept behind BPMS and achieving its value. The premise is that by modeling and simulating software supporting a business process one can more accurately and quickly arrive at the appropriate level of automation within a shorter timeframe. Modeling in a BPMS combined with simulating and/or piloting the processes provides a dynamic environment for “trying on new system capabilities before making a purchase.” The concept of MDA is a cross-industry best practice approach that has unquestionable payback.
Where do BPMS start and Business Process Improvement / Lean Six Sigma leave off?
BPMS is only concerned with the part of a business process requiring automation. Any implementation of BPMS should be an extension of a business process improvement effort as it extends to collaboration between a human and a system. Additionally, the Mercator Group BPMS methodology includes the establishment of a process performance baseline and post implementation measurements of performance improvements, a cornerstone of any process improvement methodology.
What is the role of the Business Process Management Center of Excellence (B-COE) in supporting BPMS?
The B-COE has worked closely with the FAS CIO and the GSA OCIO to identify the business requirements for a BPMS and to support the selection of an appropriate BPMS software package. The B-COE is equipped to support the roll-out and development of business line native capabilities in support of a model based and BPMS supported infrastructure that provides FAS with the agile business environment key to achieving customer business satisfaction. The B-COE services are further outlined in its charter.
How does BPMS relate to or integrate with the extensive level of modeling already performed in support of the FAS core acquisition process (API)?
BPMS will provide a platform for implementing the higher level API models as defined by the API Implementation Plan. The FAS CIO sponsored Enterprise Acquisition IPT, with the B-COE as a core member, will further elaborate on the API models to provide tangible end user functionality in the context of an overall seamless acquisition environment that incorporate both Agency customers and industry partners. BPMS will support the extension of the FAS acquisition environment beyond the enterprise boundaries. Furthermore, the BPMS will support the extension of the higher level Business Process Modeling Notation (BPMN) used in developing the Acquisition Process Improvement Plan to the system level; providing business people and system support staff with a comprehensive and unified language for communicating and establishing norms and standardized operating procedures.
Table of Contents
Workbook III: A Practical Guide to BPMS/SOA Implementation......
Prologue......
BPMS/SOA Method......
Transitions......
Project Organization and Staffing......
Scope......
Understanding......
Innovation......
Organization......
Outcome......
Model......
Prerequisites......
Activities......
Iteration......
Outcome......
Assemble......
Activities......
Outcome......
Execute......
Environments......
Deployment......
Outcome......
Measure......
User Feedback......
Outcome......
Analyze......
Expectations......
Process Improvement Opportunities......
Return on Investment......
Outcome......
Refine......
Minor Refinement......
Major Refinement......
Outcome......
The Practical Guide to Business Process Management (BPM)/Service oriented Architecture (SOA) Implementation presents a model based methodology for building business software using a Business Process Management Suite (BPMS) supported by a service oriented architecture (SOA). The methodology is applicable to any fully functioning BPMS and SOA supported environment. It was developed by The Mercator Group and extended in support of the Federal Acquisition Service (FAS) IT modernization effort. The methodology is based on “hands-on” experience with multiple BPMS systems, as well as experience with leading practice rapid development techniques; including Agile Software Development.
BPMS/SOA Method
The methodology for developing an enabled business process in a Business Process Management Suite is essentially a modified rapid application development process. A BPMS allows highly iterative application development and immediate deployment to production. The differences in SDLC are due to the Business Analyst becoming the primary developer of the application and an evolving production application hosted by the BPMS. There are 3 stages of development: Inception, Iteration, and Maturation/Evolution. The following describes each phase of the development of an enabled business process.
Stage / Phase / DescriptionInception / Scope / The requirements are defined for a discrete business process to be managed including high-level activities, system touch-points, and roles
Iteration / Model / The business process in the BPMS is defined using Business Process Modeling Notation. User interfaces, system interfaces, and basic data flow are implemented as part of the process model in the BPMS.
Assemble / The development team completes the data flow, external interfaces, and any required customization to make the managed business process production ready.
Execute / The managed process is live and accessible by business users in a test or production environment.
Maturation/
Evolution
Measure / Defined performance metrics are tracked to determine process efficiency.
Analyze / Metrics are compared to expectations and performance measures are realigned to business needs.
Refine / Adjustment to process and business rules along with process innovation yield potential improvement to business performance.
Table 1 - Development Phase Definitions
The BPMS/SOA methodology only addresses SOA to the extent that process based design is fundamental to identifying and defining effective SOA services. Further technical elaboration and deployment of SOA services are beyond the scope of this document.
Transitions
Each stage of the methodology represents an iterative multi-step development process. Iteration involves collaborative process modeling between the Business Analyst, IT Support, and the Process Stakeholders. During this stage, many versions of an enabled process are cycled through the Model, Assemble, and Execute phases. The enabled business process is promoted to production when the Process Stakeholders and the Executive Sponsor have accepted the business process.
Stage / Phase / Status / Next PhaseInception / Scope / Executive sponsor approval / Model
Iteration / Model / Process model executable / Assemble
Assemble / System abstractions implemented / Execute
Execute / Modeling or system integration still required / Model
Maturation/
Evolution / Process stakeholder acceptance, Executive sponsor approval / Measure
Measure / Business activity data recorded / Analyze
Analyze / ROI calculated, potential process improvements identified, / Refine
Refine / Only rule or reporting changes required / Execution
Process model changes required / Model
Table 2 - Transitions from Phase to Phase
Enable business processes in production are in the Maturation/Evolution stage. These processes are constantly measured, analyzed and refined for optimal performance. Business processes requiring significant change to their process model reenter the Iteration stage for collaborative adjustments before promotion back to production. The following diagram represents the stages and phases of the BPMS methodology.
Project Organization and Staffing
It is recommended to use an integrated project team (IPT) to provide structure and leverage the correct expertise in each step of the process enablement. A combination of executive leadership, business analysis, software development support, and end-user buy-in will ensure project success. The diagram below shows the team structure and the following table describes each role and their responsibilities throughout the process.
Role / Definition / Responsibilities / Phase
Executive Sponsor / The Executive Sponsor is responsible for championing the goals and objectives of the BPM project. This person makes sure the process complies with the strategic and business objectives of the organization and that the scope aligns with overall FAS strategy. The Executive Sponsor also approves change management issues, handles issue escalation, and monitors budgetary concerns regarding the project / Scope, Execute, Refine
Project Manager / The Project Manager monitors the planning and execution of the project schedule, assigning resources, and the budget during the course of the project. The Project Manager will liaise with the Executive Sponsor concerning status and issue escalation with regard to resolution, resource allocation, budget, and/or scope creep. / Scope, Model, Assemble, Execute
Business Analyst / The Business Analyst is a full-time resource for the lifecycle of the enabled process. The Business Analyst is responsible for:
Defining requirements with the Process Stakeholders and interpreting those requirements into BPMN.
Working with the Systems Analyst to implement customization, external interfaces, and a deployment plan
Developing reports, dashboards, and performance measures based on the requirements of the enabled process
Analyzing performance data and determine potential for process improvement during the Maturation/Evolution stage / Scope, Model, Assemble, Execute, Measure, Analyze, Refine
Systems Analyst / The Systems Analyst is a part-time resource who supports a variety of technical details required for successful enablement of a business process. The Systems Analyst is responsible for:
Identifies existing adapters and interfaces during the Model phase to support the enabled process
Develops additional system collaboration and a deployment plan during the Assemble phase
Performs quality assurance from an IT architecture standpoint
Works with service providers to maintain service level agreements with consumed services / Model, Assemble, Execute
Process Stakeholder / The Process Stakeholder works closely with the Business Analyst to define process requirements and then to iteratively build an enable business process in the BPMS. The Process Stakeholder is mostly likely a manager or end-user of the enabled business process and the first line of user acceptance. / Scope, Model, Execute, Analyze
Table 3- Project Roles
Scope
The scoping phase is essential for establishing expectations and a foundation for success in enabling a business process through BPM. There are three crucial elements to scoping a BPMS project: Understanding, Innovation, and Organization.
Understanding – The IPT must understand the business process explicitly including core activities, actors, and system interfaces.
Innovation – The enabled business process must return value through automation, improvement, transparency, and/or integration.
Organization – The IPT must define how the enabled process will fit into the organization and how the organization will adapt and improve using the enabled process.
Understanding
The IPT defines the high level business process initially to scope the business process from end-to-end. This exercise is a combination of gathering existing process collateral and interviewing subject matter experts. Purely manual processes may have never been addressed from a process modeling perspective and require extensive research by the Business Analyst to define the target process. Conversely, processes identified by either Lean Six Sigma or Acquisition Process Improvement will have well-defined process models nearly ready for implementation. Gathering existing collateral is the most productive step for the IPT. Most processes targeted for enablement have already been modeled in some way. Existing process diagrams do not need to be in Business Process Modeling Notation (BPMN). The execution model in a BPMS is enough of a deviation to offset any advantage of importing process models into the BPMS environment.
An enabled process in a BPMS is more than just the process itself. The monitoring and management of the process is just as important. Within the scoping phase, the IPT will also define the requirements for measuring, monitoring, and reporting process activity to the relevant actors. This is achieved through Business Activity Monitoring (BAM) which is made up of a combination of performance metrics, reports, and dashboards. The enabled business process can also be important to enterprise business intelligence and the IPT will identify potential process data for inclusion in an enterprise data warehouse.