BPM Voices: Evaluating BPM applications: BPM design reviews and Rubik's Cubes

In this column, I'll focus on the objectives of performing BPM design reviews, the key preparation steps for an effective review, and an overview of the key dimensions to assess as part of a BPM solution. I'll introduce the basic covenants for conducting a BPM design review and offer some suggestions on where clients should focus in the process. In addition, we'll take a look at the IBM® BPM playback methodology, because I believe the convergence of a design review strategy with IBM's playback approach is key to developing optimized BPM solutions. So how does all this relate to Rubik's Cubes? Read on and find out! This content is part of the IBM Business Process Management Journal.


Scott Simmons, Executive IT Architect, IBM  

Scott SimmonsScott Simmons is the Banking Solutions Architect for IBM’s North American Business Process Management Solution Architecture Team. Scott specializes in design, development and implementation of BPM solution architectures for banking and financial markets customers and key ISVs. Previously, Scott was the Lead Banking Solutions Architect for IBM’s WW Banking Center of Excellence for 3 years. Scott also held the position of Principal Architect for IBM’s Worldwide SOA Technical Architecture team for 2 years. In both of these positions, Scott has represented a key leadership role for the development of the SOA-based solutions in the Banking and Financial Services Industries. Scott is an IBM Senior Certified IT Architect and Distinguished IT Architect with the Open Group. Scott is a co-author/contributor on multiple IBM Redbooks and has been published in numerous periodicals including the IBM BPM Journal, WebSphere Developer Technical Journal, Web Services Journal, XML Journal and WebSphere Journal.

13 February 2013

Also available in Chinese


Rubik's Cube I can hear you what you're saying loud and clear -- BPM reviews and Rubik's Cubes? What's next, PacMan and Facebook? You're undoubtedly asking, "Scott, what is the relationship between BPM design reviews and Rubik's Cubes?" Well, let me first provide some background. Over the 15 years that I've worked with BPM technologies, I've come to the conclusion that reviewing BPM applications is similar to solving a Rubik's Cube. BPM solutions present themselves via a multiplicity of patterns and application types. More importantly, a given BPM solution manifests many different dimensions even within a single application. When you review a BPM solution, you have to take into account all of these dimensions and ensure that they're appropriately aligned with one another. In a similar fashion, the objective to solving Rubik's cube is based on the ability to align colors on each separate side of the cube. As a result, there is a relationship between BPM design reviews and Rubik's Cubes – both require a technique where multiple dimensions need to be evaluated as part of the end-to-end process.

Last year, I was asked by a client to develop a BPM review process to support their development efforts. Initially, this seemed like an easy exercise and yet, as I got further involved with the assignment, I realized it was more difficult than I had originally imagined. The complexity of designing a BPM review process relates to the multiple characteristics that a BPM application comprises, or exposes, and the need to evaluate each of these areas to develop approaches to optimize the evolving solution.

So let me answer your question about the relationship between BPM Design Reviews and Rubik's Cubes - in BPM (as with solving a Rubik's Cube), you have multiple dimensions, or colors, that need to be aligned to "solve" the requirements at hand, and these dimensions need to be addressed in the right order to review a BPM solution.

A key tenet across BPM applications is the need to combine multiple BPM patterns and application types to develop a complete BPM strategy. These patterns and application types range from straight-through processing to ad hoc to rule-centric patterns to traditional workflow. All of these patterns exploit different factors; as a result, we need to be flexible as we review BPM applications and factor in these variations. As I discuss BPM design reviews in this column, I'll take a broad approach to describing multiple characteristics (the different colors of Rubik's cube) to provide a set of guidelines so that readers can adopt a set of review techniques appropriate for their needs.

In this column, I'll describe a methodology for conducting BPM design reviews based upon general principles and an approach that I've used with multiple strategic clients. I should note that every organization is different and, as a result, you'll likely want to customize these techniques for your organization.

Design review goals and objectives: it's more than just lining up colors

If you look at Figure 1 (generally referred to as the "wedding cake" or the SOA layer diagram), it's clear that process applications do not exist in isolation. Business process applications provide the key layer between consumer applications (such as user interfaces) and underlying business and technical services. Normally BPM involves the "orchestration" of multiple business and technical components to provide composite business services, which often require state management capabilities, although simple BPM applications may just reflect traditional workflow, such as automating manual tasks. In addition to orchestrating services, BPM applications need to interact with cross-cutting concerns such as integration, nonfunctional requirements, data architecture and governance. And this is precisely why doing a BPM design review requires more than just "lining up the colors" –- doing a review is complex and must address a number of different and sometimes conflicting dimensions). Furthermore, the design reviews normally require the participation of multiple constituencies, both business and technical, and they need to ensure alignment between business and IT in BPM application design and development.

Figure 1. SOA layers
SOA layers

Perhaps the best place to start is to define the key objectives of BPM design reviews. Based on my experience, these objectives are:

  • Confirmation of design assumptions and requirements between business and IT.
  • Ensuring that business and IT stakeholders are aligned on scope and requirements.
  • Promotion of a collaborative development approach.
  • Acceleration of development.
  • Perhaps most importantly, reducing the level of exceptions prior to deployment.

BPM design reviews: Where to start

What is a good BPM application? Actually this is a tough question; there's not a simple answer. Many factors contribute to a good BPM solution. From my perspective, the key measure of "goodness" is how well the solution satisfies the business users' expectations. This aspect underlies the requirement for business stakeholder involvement in the design review process. Although there may be additional technical reviews, business stakeholder involvement in design reviews is essential to ensuring the solution matches stakeholder intentions. To be successful with BPM, a collaborative approach between business and IT is critical.

Let's set the stage with some basic guidelines for how to conduct a design review. My basic tenets for success with design reviews are pretty simple:

  • Prepare … prepare … prepare!
  • Ensure all key business and IT stakeholders attend and participate. If they can't make it, the review should be rescheduled.
  • Schedule and execute design reviews early and often.
  • Use playbacks as a key technique to enable BPM review.
  • Continue to refine the review process and align it to your organization.
  • Plan and circulate the agenda for the review session in advance and ensure participants understand the goals and objectives.
  • Don't criticize, recommend. Ensure that teams leave their egos at the door!

The most important bullet is "prepare … prepare … prepare." I'm a firm believer in the adage that "failing to plan is planning to fail." In the execution of design reviews this is quite evident because reviews normally require the time and dedication of multiple roles to ensure an effective session. In the absence of planning, the constituencies will not be engaged and the review process will fail to deliver the expected results. It's critical that the review process be viewed as a valuable exercise by the participants.

So, what are the key steps to prepare for a review?

  • First, the drafting and circulation of an agenda for the review session is vital. A typical agenda includes the following topics:
    • Brief overview of the review agenda and objectives.
    • Quick synopsis by the business stakeholder or process owner of requirements and progress.
    • Update by the project manager or development lead on the development plan.
    • Description of the focus areas appropriate for the BPM solution, such as process model/design, architecture, integration, user interfaces, and so on.

    A typical review session should normally be 2 to 3 hours long depending on the schedules of the participants. Although shorter review sessions might be appropriate for small applications, we've found that 2- to 3-hour sessions work best. Don't forget to schedule a break in the longer sessions!

  • Second, the review leader needs to ensure that all logistics are in order. Logistics requirements include ensuring an appropriate location with sufficient space for all participants, as well as necessary equipment such as whiteboard, internet access, projector and other materials required to satisfy the agenda.
  • Third, the leader or the development team should aggregate and circulate key artifacts for review prior to the session. These artifacts normally include business requirements, process design diagrams, data models, user interface mock-ups and, if available, process documentation generated from the tooling. The IBM Process Center can generate a detailed report of the process application. By disseminating these materials in advance of the session, participants can review these artifacts and have questions prepared to support the review session.
  • Fourth, the selection of appropriate participants for the review session is essential and often challenging. When we do a design review, there is no magic number for how many people should attend. That said, we find that having more than 10 participants is normally a distraction. The key factor in participant selection is ascertaining the value each participant brings to the exercise. Additionally, selection of potential participants may be shaped by the norms of the organization. All things being equal, we find that there are some key roles that need to be satisfied as part of the overall review session:
    • Session facilitator
    • Key stakeholders, including process owners, business stakeholders or end users, business SMEs and key project sponsors
    • Note-taker or scribe
    • Project lead or project manager
    • Enterprise architect
    • Development or technology manager
    • Process or rules architect
    • Appropriate development resources (given that they provide value to the process)

    The key success factors in this area are to (1) ensure that you have not overloaded the session with nonessential people and (2) that key business and technical stakeholders are appropriately represented. If there is a BPM Center of Excellence, it may be appropriate to have the representatives attend this session as well (especially if the project has strategic or cross-organizational requirements/concerns).

BPM design review guidelines: Rules for solving the cube

Before I discus the method for conducting a BPM design review, it is useful to call out some general principles:

  • Not every project needs a detailed review; it will overwhelm you and your staff if you try.
  • There are different types of BPM reviews depending upon the solution implementation, such as IBM BPM Standard, IBM BPM Advanced, hybrid solutions (like Operational Decision Manager/BPM solutions).
  • Review procedures and flow will differ based upon audience (such as technical and business audience).
  • Reviews should be ongoing. Multiple review sessions are essential.
  • The review process should provide consensus and detailed steps for optimization.
  • Reviews should always involve business stakeholders from the onset -- business and IT collaboration and alignment is mandatory for BPM success.
  • Finally, and probably most importantly, there is no magic formula to doing BPM design reviews. I'll discuss basic objectives and guidelines, but you need to determine how to customize and align these to your organization and situation.

Although there are other guidelines, simply following the above points will help ensure BPM design reviews are constructive and valuable exercises that lead to more optimal BPM solution deployments.

Playbacks: Converging playbacks and BPM design reviews

Although there may be a requirement to perform BPM design reviews in isolation, we find that most organizations use the IBM BPM playbacks in conjunction with their BPM design reviews. A key point I'd like to make about playbacks is that, contrary to popular belief, they should not be show-and-tell sessions, instead playbacks should be interactive sessions with key stakeholders to review the solution and evaluate the functionality over time. By blending the playback session with a review of the key BPM focus areas, organizations will derive a higher level of structure for the individual playback sessions.

I highly recommend the IBM Redbook Scaling BPM Adoption: From Project to Program with IBM Business Process Manager for a detailed description of the playback approach. In this column, I'll briefly summarize the playback approach and methodology. Figure 2 depicts the basic steps in a BPM development process. As you can see, there are four key playback phases – Playback 0, Playback 1, Playback 2, and Playback 3. Each of these phases normally contains multiple iterative playback sessions, ensuring completion of the goals and objectives for that specific phase. Figure 2 also shows the key roles normally involved at each stage of development and the associated deliverables for each playback phase.

Figure 2. IBM BPM playback methodology
IBM BPM playback methodology

One question we often hear is "How many playbacks and how frequently?" The number and frequency of playbacks depends on multiple factors, such as the strategic importance of the application, solution complexity, BPM maturity, and overall recommendations by business and IT stakeholders. We find this varies by organization, but having a set of guidelines for playback scheduling is fundamental to a successful BPM strategy and helps align the playbacks with the associated BPM review processes.

It's useful to quickly summarize the four playback phases. The abbreviated points listed here are taken from the Redbook:

Playback 0

  • Focus: High-level process flow (requirements definition and process discovery)
  • Goals:
    • Discovery and definition of key business processes
    • Define the implementation scope and project plan
    • Alignment of expectations, KPIs, and metrics from sponsors
    • Transfer context and responsibility from analysis to development
  • Deliverables:
    • An executable business process definition (BPD)
    • A participant and user group model (for example, swim-lanes/roles)
    • A basic data model using BPM variable types
    • Mocked-up reports to demonstrate visibility, analysis, and control
  • Out of scope
    • Implementation of user interfaces (use stubs or mock-ups)
    • Implementation of process activities (use stubs or mock-ups)

Playback 1

  • Focus: User interface design and implementation
  • Goals:
    • Implementation of BPM user interfaces
    • Extend data model to support user interfaces and decisions
    • Define human tasks, ad hoc interfaces, and reports, dashboards, and scoreboards to support visibility and control
  • Deliverables:
    • User interface implementation
      • Definition of validation to ensure and maintain data and decision integrity
      • Appearance (styles, themes, headers, consistent layout)
    • Updated data model for process and date captured via human tasks and interfaces
  • Out of scope:
    • Integrations, reference data or system-of-record population

Playback 2

  • Focus: Integrations to external systems (applications, infrastructure components, such as email, B2B)
  • Goals:
    • Implementation and exception handling for all integrations (external integrations and any system of record (SOR))
    • Definition and acceptance on service level agreements (SLAs)
    • Alignment with owners of external systems
  • Deliverables:
    • Definition of interfaces required for each integration point
    • Definition of the data transformation between systems
    • Definition of exception handling and fault codes arising via integrations
    • Definition of validation to ensure and maintain data and decision integrity
  • Out of scope
    • The solution is not a complete or functional solution; it is not ready for user acceptance testing at this point

Playback 3

  • Focus: Consolidation and finalization of the end-to-end solution
  • Goals
    • Completing details to consolidate and finalize the solution, such as process automation, user interfaces, and integrations
    • Delivery of a fully deployable and testable solution that is ready for user acceptance testing
    • Key point: This playback should not introduce any new functionality to the solution -- the focus is strictly on completeness, refinement, and stability
  • Deliverables:
    • An end-user solution that is ready for user acceptance testing environment
    • Implementation of required functionality necessary for an end-to-end solution
    • Documentation (beyond defaults in the BPM product) to enable end users, administrators, and system-level developers to understand the solution
    • Description and prioritization of all functionality to defer to the next version of the project (the "parking lot" for new features/functions)

Design review guidelines and focus areas: Aligning the colors

Now let's take a look at the key focus areas for business process reviews. I consider these to be the factors for BPM "goodness". From the perspective of solving the cube, these areas represent the colors on each side of the cube -- no color is more important than another and all colors need to be in alignment to solve the puzzle. We'll approach each focus area or dimension in a similar format:

  • Specify the key aspects of this dimension that should be reviewed
  • Key questions that should be raised with respect to this dimension
  • Define the leading practices that we see successful solutions built upon
  • Review some of the common anti-patterns related to this dimension

In no particular order of importance, the key factors that to assess in a BPM design review are:

  • General BPM solution design and implementation
  • Process modeling and design
  • Process data and information modeling
  • Decision services
  • Event management
  • Integration services and interfaces
  • User interface design and development
  • Architectural aspects
  • Infrastructure and deployment considerations
  • Governance aspects

It should be noted that many factors are not visible (and require some probing questions to determine); however, if key factors are not satisfied early in design and development, they will likely cause challenges over the long term. Although this is not just a BPM issue, the fact that BPM applications are normally business consumer facing means that the effects tend to be more visible and, as a result, reflect more negatively on the development team. As a final point before reviewing the ten areas, it's important to note that architectural decisions may actually make an anti-pattern an "acceptable" option (though possibly not preferable) when analyzed as part of the overall solution.

General solution design and implementation

This area focuses on the aspects of business architecture, project management and tool selection.

Criteria and focus areas

  • Strategic alignment with business and IT, business involvement, and business architecture
  • Project management including use of playbacks, review sessions, and continuity of activities
  • Product and tooling selection based on requirements
  • "Agile BPM" techniques, including blueprinting, process discovery, playbacks, discovery workshops, agile-oriented development

Key questions

  • What was the involvement of the business users is the design process?
  • Has a process owner from the business been specified? If not, when is this planned to occur?
  • Have all key risks and challenges in the project been identified with appropriate mitigation steps?
  • How will you optimize the next release of the application? What are the lessons learned based on efforts to date?
  • What is the overall project timeline? If the BPM application has been completed, how long did the process take to implement (in person days)?
  • How did the team estimate the scope of the project? Is it a do-able project?
  • What are the key risks or challenges in the project?
  • Do you plan to implement the entire business scenario? If not, what will be omitted and why? Are you implementing more than initially planned?
  • Why did you select the specific development tool(s) and approaches, such as BPM Standard versus BPM Advanced?
  • How have playbacks been used? What is the frequency of playbacks? Who is normally invited to playback sessions?
  • Is an agile BPM approach being followed? If so, which components are being exercised (blueprinting, process discovery, playbacks, discovery workshops, agile-oriented development approach)?

Leading practices

  • Collaboration and IT and business alignment is critical and must be ongoing and active.
  • Enforce process discovery as the first step in BPM development.
  • Process ownership is mandatory -- without a process owner, chaos awaits.
  • It's important to define and document project scope to ensure alignment and the ability to complete on time and within budget.
  • Choose the appropriate tool (BPM Standard versus BPM Advanced).
  • Use IBM Operational Decision Management to support enterprise-level decision services.
  • Move away from a waterfall approach, which will lead to a non-optimal results.
  • Agile BPM speeds solution delivery.

Common anti-patterns

  • Lack of business involvement or alignment.
  • No process owner.
  • Infrequent or inconsistent reviews.
  • No consideration of external project dependencies.
  • No risk analysis or recognition of challenges or dependencies.
  • Project scope is too large (or, worse yet, undefined).
  • Choosing the wrong product or tool for development.

Process modeling and design

This area focuses on the process discovery, modeling and design aspects of the solution with a focus on BPMN solution design and collaborative discovery and modeling.

Criteria and focus areas

  • Process discovery
  • Process modeling
  • Process design
  • Process monitoring
  • Process roles and swimlanes
  • Best practices in BPM solution modeling

Key questions

  • How was process discovery done and how was business involved?
  • How many process instances are there per day? How many users or consumers? How many concurrent users? What is the worst case?
  • What is the average process duration (as well as the minimum and maximum)?
  • Did you use (formal) business modeling? Visio, Blueworks Live, WebSphere Business Modeler?
  • Did you use simulation on the model? Did you identify how to optimize the process after simulation?
  • Did the team use a collaborative approach to develop the business model?
  • How was process discovery aligned with process design, for example, is Process Designer subscribing to Blueworks Live?
  • How is the process initiated (for example, scheduled, manual, event-trigger)?
  • Does the process maintain clean separation between BPM and SOA and integration functions?
  • How is exception management provided for both technical and business exceptions?
  • How are common functions reflected in the solution? Are they provided via a centrally maintained subprocess or function?
  • Have you followed good BPMN coding and design practices?
  • How do you measure or monitor the business process (for example, dashboards)?
  • What are the key roles in the solution? Do these map directly to swimlanes in the process?

Leading practices

  • Process discovery is a critical and distinct step in BPM design.
  • BPM design needs to be top-down, as well as meet-in-the-middle (not bottom-up).
  • Process decomposition and granularity is key to development/maintenance.
  • Ensure that the design provides for optimization and adaptation over time.
  • Complexity is inversely proportional to maintainability (KISS principle).
  • Focus on modularity (for example, nested processes, facades, component-based).
  • Standardize the process and activities to maximize scale and flexibility.
  • Remove activities that add no value.
  • Compress time by processing in parallel.
  • Automate manual steps wherever possible.
  • Use toolkits where possible to support reuse and to maximize scalability.
  • Model roles and swimlanes to specify task responsibilities.
  • Model exception management early in the process based on established conventions.
  • Practice good JavaScript practices (refer to JavaScript best practices.
  • Practice good naming standards – see Best Practices Recommendations in the Blueworks Live BPM community.

Common anti-patterns

  • No (or minimal) process discovery.
  • Discovery and design is constrained by the as-is BPM implementation versus building an optimal process implementation.
  • Process design is done entirely by IT (usually based on a business requirements document).
  • Minimal or nonexistent naming standards.
  • BPM design reflects "happy path" with limited attention to exception handling.
  • Absence of metrics or monitoring (no SLAs).
  • Bottom-up SOA or IT-based approach versus top-down approach.
  • Basic modeling anti-patterns..
  • User interface drives design decisions rather than the actual process.
  • Limited process decomposition (everything is at Level 1).
  • Limited use of subprocesses to modularize the process components.
  • Milestones with only one or two activities (each milestone should have 4-7 activities).
  • Process activities vary broadly in size and scope.
  • Process activities that have multiple activities for the same role (for example, a "string of pearls' pattern).
  • Flows that loop back to previous steps to repeat activities (for example, BPM's Go To command).
  • Poorly implemented parallel gateways leading to race conditions.
  • Implementation of multiple system swimlanes.
  • Poor recognition and identification of key BPM roles and swimlane definition.

Process data and information modeling

This area focuses on the design and runtime behavior of the data components within a specific BPM application.

Criteria and focus areas

  • Data model definition, such as key entities
  • Consistent data management and usage, such as persistence of process data and source and target data
  • Consistent scoping of variables (for example, input/output versus private)

Key questions

  • What are the process inputs and outputs?
  • Does the arrival of information cause process instances to (re)start?
  • What kind of information does the process use? Structured data, unstructured data, specific documents, and so on?
  • Are custom data types used to support extended data types such as customer, address, and other compound data types?
  • Are data objects defined to support requirements for process monitoring and management?
  • Where is the process data stored? How does the BPM application interface with "sources of record" (SORs)?
  • How is data quality managed in the process?
  • Does the process pass only required information between activities?
  • Is the naming and data typing for entities and attributes intuitive and consistent across similar processes?
  • Is document management a required aspect of the solution? If so, where is the content stored and through what mechanism (for example, CMIS)?

Leading practices

  • Understand that you may use different data models for different needs.
  • Ensure consistency in data design (names and data types) between BPM applications.
  • Manage data quality at source of entry. Validation rules are key for this.
  • "If you can't measure it – you can't manage it." KPIs and SLAs need to be defined and in scope.
  • Design data objects with a view towards performance and reuse.
  • Protect internal and external data (private variables enable "hiding").
  • Pass only the data that is needed, no more, no less.
  • If you need to integrate with content repositories, use standard integration patterns such as CMIS to accomplish this.

Common anti-patterns

  • Designing data objects based on XML Schema or forms versus defining them based on actual process requirements.
  • Redundancy and inconsistency of data objects within and across process applications.
  • Lack of standards and consistency in data objects, such as naming, type assignments, usage.
  • Unnecessary data being passed into activities.
  • Inconsistent and redundant objects within the applications.
  • Passing large data objects into or between subprocesses and activities.
  • No design and development of data objects to support process monitoring aspects.
  • Custom integration into document repositories.

Decision services

This area focuses on the integration of decision services (business rules) within the BPM application.

Criteria and focus areas

  • Rule design
  • Rule semantics and business vocabulary
  • Scope and reusability of common rules
  • Rule governance and lifecycle issues
  • Note: Review of IBM Operational Decision Manager (ODM) applications is not in scope of this column

Key questions

  • Do you have business rules in the business process? How many? What types of rules (data checking, validation, complex decisioning, and so on)?
  • How are the rules implemented (in code, within BPM rules, or within BRMS, and so on)?
  • If you are interfacing to an external BRMS solution, such as IBM ODM, how is this being accomplished?
  • Do the business users require access to and update permission for the business rules?
  • Do similar rules exist in other process applications or external applications?
  • How are rules persisted, changed, and governed over time?

Leading practices

  • Rules normally should apply to a single business entity.
  • The standard BPD pattern: decision task prior to Gateway.
  • Clear understanding and implementation of process rule usage practices vs. business rules (BRMS) usage practices.
  • Design of compound decision activities with multiple decision steps.
  • Common rules for multiple process applications managed via BPM toolkit.

Common anti-patterns

  • Limited standards in how rules are implemented and executed leading to inconsistency in usage.
  • Implementing a string of decisions as separate activities versus a more modular design.
  • Embedding rules in code (either JavaScript or externalized code).
  • Surfacing rules in BPM application when a BRMS would be a better solution due to complexity of rules, business user requirements, governance aspects, or requirements for similar rules in other applications.
  • Redundant rules (both within the same application and in related process applications).

Event management

This area focuses on the BPM aspects of event management specifically how processes can be activated and how they provide event and notification functions internally, with other processes and with other external agents.

Criteria and focus areas

  • Event usage
  • Event design
  • Event scope
  • Note: Review of IBM ODM applications is not in scope.

Key questions

  • What types of events are supported in the application (notification events, ad-hoc events, exception handling, and so on)?
  • How do you currently implement events (undercover agents (UCA), JMS)?
  • How are events initiated (at process level, by timing, scheduling, other)?
  • Are the event implementations defined in terms of average and maximum number of events per time period to support sizing needs?
  • Do you use new data models for the same types of events or do you develop reusable models based on complex types?
  • Does the application support external events (inbound or outbound)?
  • Is the event scope well defined (for example, having defined sources and targets)?

Leading practices

  • Pragmatic use of events. Remember that JMS is used to support event interactions and entails performance considerations as a result.
  • Event scalability requirements are factored into solution sizing determination.
  • All key event conditions are tested within the overall SDLC.

Common anti-patterns

  • Redundant event functions between processes as well as within the same process.
  • Poor design or non-modular event data models.
  • Sizing or scaling issues due to lack of definition of event characteristics and impact on sizing.
  • Bad event design can lead to "event storms" and infinite looping patterns.
  • Multiple inbound events for a given process or activity (more than 3 or 4 events).

Integration services or interfaces

This area focuses on the interactions between the BPM application and external systems, such as databases, applications, non-BPM technologies, and so on.

Criteria and focus areas

  • SOA or technical implementation aspects
  • Use of standard integration technologies (like adapters) and patterns
  • Use of toolkits and Advanced Integration Services (AIS)

Key questions

  • Are you interacting with external databases or applications? If so, is the interaction read-only or read-update?
  • Are you interacting with partner systems or external data feeds? If so, how are you accomplishing this? Is this interaction read-only or read-update?
  • Have you established SLAs with the providers of the external systems to ensure solution viability?
  • How do you access external services? Direct coupling, ESB, custom?
  • Are you using BPM Advanced or other technologies to support integration requirements?
  • What is your integration approach – standards-based or other?
  • Are data canonicals used to access business objects from the enterprise applications?
  • What are the key integration standards being used (web services, REST, other)?
  • Do you need to support transaction scope across multiple transactions? If so, how are you accomplishing this?
  • Are BPM toolkits being used to support common integration requirements?

Leading practices

  • Designing integration in a modular fashion (facades, patterns, nested processes) leads to a more flexible solution.
  • Use of ESBs to enable information hiding and common transformation for both package integration and custom integration.
  • Use of façades to enable high maintainability. Do not hardcode endpoints.
  • Requirements for managing transactional scope are managed using BPM Advanced, or ensuring transactional consistency is managed by the service container performing the update action.
  • Factor common integration services into toolkits; reuse is key for maintenance.

Common anti-patterns

  • Integration implementation in Process Designer versus other tools.
  • Limited involvement by IT SMEs and architects for the external systems.
  • Lack of knowledge of SLA for external systems.
  • Poor interface design with external systems (limited use of standards, multiple data models, and so on).
  • Redundant integration services leading to management issues.
  • Failure to consider transactional scope issues.
  • Race conditions.
  • Deployment of large numbers of EARs/JARs to IBM Process Server.
  • Additionally, there are a number of anti-patterns specific to BPM Advanced that are beyond the scope of this column.

User interface design and development

This area focuses on the user interface aspects of the solution in terms of standards, usage characteristics and functionality.

Criteria and focus areas

  • User interface design
  • Interface intuitiveness and usability
  • Interface consistency.
  • Performance

Key questions

  • How did the team design the user interface (for example, business user collaboration like playbacks, storyboarding, formal use cases)?
  • What technology was used for developing the user interfaces ( Coaches, eForms, HTML, Dojo, JSP, portlets, Business Space widgets)?
  • How many different "screens" or Coaches are there for the specified BPM application or process?
  • What is the nature of the interaction between the user interface and the BPM application (SOAP/WS, REST, Process Portal, other)?
  • What is the testing approach for the user interface in terms of usability, applicability, and performance?
  • Are there standards being used in the user interface in terms of navigation, field appearance, menu formats, and so on?
  • Are toolkits being used to manage the reuse of common components for user interface development?
  • Has the user interface been designed with appropriate standards and leading practices (web application guidelines, accessibility standards, and so on)?

Leading practices

  • Let the server do the work (using server-side scripts, stored procedures, and so on). Don't overcomplicate the user interface -- simple is best!
  • Basic Coaches provide a great staring point; successful BPM practitioners often use basic Coaches for prototyping and initial playbacks, and these initial interfaces are extended through development.
  • Use standard Dojo widgets to enhance user interfaces.
  • Factor common UI components into toolkits and reuse these components accordingly.
  • Use documented approaches to integration with an external portal, such as WebSphere Portal.
  • Follow accessibility standards. Refer to the Web checklist.
  • Designation of the key user interface guidelines and standards for UI development. Refer to Design principles.

Common anti-patterns

  • Lack of business focus or participation in UI design resulting in technical UIs rather than business UIs.
  • Lack of user interface standards within and across BPM applications.
  • Limited user interface consistency within and across applications.
  • Designing overcomplicated interfaces based on the current as-is solution (for example, rebuilding a multi-page form into an user interface).
  • Redundant UI components versus creating sharable components and reusing as appropriate.
  • Poor BPM start-up performance due to excessively complex or large UIs.
  • Interface design is constrained based on current process behavior and user perspectives.

Architectural aspects

This area focuses on the basic architectural aspects, such as overall solution architecture and non-functional requirements like availability, scalability, security, and so on.

Criteria and focus areas

  • Architectural design
  • Nonfunctional requirements (NFRs) such as scalability, availability, security, portability, reliability
  • Optimize for usability, extensibility, maintainability, legal and regulatory

Key questions

  • How well does the solution interact with other dependent external components?
  • Have you considered all parts of the solution in terms of NFR decisions?
  • How have availability and SLA been defined at the application level? Has this definition take into account the external systems and components?
  • What do you do when something goes wrong in the process ( recoverability)?
  • Have the performance characteristics been defined? How has performance analysis and testing been built into the project timeline?
  • Have all necessary legal and regulatory issues been addressed? This is especially important for regulated industries.
  • Has a security audit of the application been provided? Has the solution defined the key security requirements based on internal and external consumers as a solution topology (for example, DMZ restrictions)?
  • How is user authentication being managed (LDAP or BPM-based)?
  • How have you designed for solution evolution and flexibility (for example, loosely coupled)?

Leading practices

  • Nonfunctional requirements (NFRs) are defined early and revisited throughout design.
  • Adoption of techniques to support rapid refactoring and flexible modification, such as separation of concerns, agile BPM, loose coupling.
  • Good architectural design normally leads to good performance.
  • Use LDAP as the single centralized user management authority. Don't try to build a custom profiling or authentication service unless it's absolutely necessary.
  • Design for change and flexibility both in the physical topology as well as the logical architecture.

Common anti-patterns

  • Consideration of NFRs is secondary (or non-existent).
  • Limited definition of recoverability requirements and associated functions to mitigate.
  • Availability and SLAs are not effectively defined or scoped.
  • Limited definition of scalability aspects leading to performance deficiencies following deployment.
  • Security and entitlements are an after-thought (and IT security has not been contacted for support).
  • Limited adherence to architecture design goals, such as loose coupling, resulting in non-flexible solutions.

Infrastructure and deployment considerations

This area focuses on the actual platform and deployment aspect of the BPM solution.

Criteria and focus areas

  • Definition of the development testing and runtime topology
  • Performance and load testing
  • Operational management
  • Source code management

Key questions

  • What is the IT configuration for the development, test, and production environments (platforms, number of machines, clustering, virtualization, network load, HTTP servers, and so on)?
  • What influenced the choice of platform and operating system?
  • Did you implement an HA or DR CDR: High Availability or Disaster Recovery? environment?
  • Is a complete end-to-end performance stress test in the project plan?
  • How will new versions of the BPM software be deployed over time?
  • How will new versions of the BPM application solutions be deployed over time?
  • What is the process for managing and monitoring the BPM application over time? Is there a process for assessing the performance of the associated databases and application server?
  • How was sizing done? Did you work with internal or external (IBM) experts to assist you? Are you confident that sizing is correct? Note: Sizing is a critical deployment consideration, and it is beyond the scope of this column to discuss this area in depth. It should be noted, however, that even though nearly all organizations do sizing, it's often based on inaccurate assumptions and often without the consideration of potential scalability challenges.

Leading practices

  • Use standard deployment patterns for deployment based on requirements (such as Gold Topology).
  • Cluster the Process Center and Process Server to maintain support for scalability, failover, high availability, and redundancy.
  • Assess and evaluate shared services, external applications, and database SLAs as part of overall operational management.
  • Optimize the Process Server database and application server, and maintain them over time.
  • IT developers use the UTE (unit test environment) for unit testing (not the Process Center).

Common anti-patterns

  • Limited definition of development, test and production topologies.
  • Lack of end-to-end system testing.
  • Lack of collaboration with external system stakeholders to ensure end-to-end operational management and timely root-cause problem diagnosis.
  • Failure to consider network latency (especially in highly distributed implementations).
  • Deployment and installation on a poorly sized configuration.

Governance aspects

This area focuses on the key aspects of BPM governance. Although related to SOA governance, this area should be reviewed separately from SOA governance aspects.

Criteria and focus areas

  • Governance standards, policies, and methods
  • Center of Excellence or Center of Competency
  • Asset management, toolkits, shared services, asset reuse
  • Interaction with SOA governance (for example, Service Registry)
  • BPM development, SDLC promotion management, change management
  • Process optimization and review

Key questions

  • Does the project adhere to the organizational BPM governance standards, policies, and methods?
  • How has the organizational BPM Center of Excellence (if one exists) been involved in the overall project?
  • How are the common assets in the BPM solution being managed, tracked, and monitored?
  • Are BPM toolkits being used within the process? Why or why not?
  • Where is the catalog or registry for the business and technical processes and services (for example, process repository or service registry)?
  • How do you manage service and rule lifecycles, service currency, service selection, and versioning?
  • Is a source code management system being used in addition to the Process Center? If so, what are the synchronization points between the SCM tool and the process repository?
  • How will the specific BPM solution be versioned over time? How will recovery to a former version be accomplished from an operational perspective?
  • What's the perceived and actual value from implementing the process with BPM technology? How was cost saving or value derived?
  • How will the BPM solution be monitored for future optimizations?

Leading practices

  • Implement a BPM Center of Excellence (CoE) to develop and enforce formal governance policies.
  • Develop and enforce a policy for shared service components, such as processes and toolkits as part of a comprehensive reuse strategy and guidelines.
  • Formalize the engagement process, review, and ad hoc project audits by the CoE.
  • Maintain documentation (use cases, system context, architecture diagrams, operational architecture, architecture decisions). BPM does not alter this need.
  • If using an external SCM tool, develop formal guidelines for usage and ensure that the components are sourced from SCM.

Common anti-patterns

  • No governance standards, policies, or methods.
  • SOA and BPM governance is identical.
  • Lack of an approach to maximize reuse, such as using BPM toolkits.
  • Shared components are not actively managed and audited (for example, toolkit sprawl).
  • Limited monitoring of BPM application usage and limited progress towards optimization.

Executing design reviews

Assuming that you've developed an agenda acceptable to the review participants, you'll find that executing a review is a straightforward process. I've developed a spreadsheet work product to assist organizations in conducting and evaluating BPM projects. I have intentionally not included this tool with this column because it's still in a draft format. However, if you'd like to use this tool in your reviews, you can contact me directly. The spreadsheet is a non-supported accelerator to assist you in the review process.

The guidelines for running a BPM design review session are pretty basic. Most importantly, the session facilitator needs to ensure that the review stays on track and does not waste the valuable time of the participants. Oftentimes, review participants may initiate side topics that are not germane to the review. In these instances, the session facilitator should document these topics for future review. In addition, the facilitator often plays the role of coach and companion, making sure that everybody behaves, making sure that everybody participates, and making sure that the review delivers recommendations and action steps to create an optimal BPM solution. Finally, it should be noted that occasionally the facilitator or review leader needs to think on his or her feet and be prepared for the unexpected, but with a solid agenda, the right participants and effective preparation, this should be the exception.

The key litmus test for determining the success of the session is to ensure that the objectives for the review have been met and that the session has moved the BPM solution forward in a positive way.

Finalizing the deliverables

It is my fervent belief that an effective review session requires a deliverable, even if it is a basic text document or an email. The deliverables should act as a set of action steps to resolve potential deficiencies or optimize the overall solution based on recommendations generated during the review.

The format of the review session deliverable depends on the organization. Many of my clients have never engaged in this type of design review and, as a result, have no standard in place for a post-review deliverable. In these cases, the deliverable is often as simple as a record of the minutes from the scribe. In other organizations, this process may be more formalized and require a standard document to record next steps and actions. As a final point, creating the post-session deliverable is meaningless unless the development team and business stakeholders provide a process to ensure that the action items are completed within an appropriate amount of time. Many clients who utilize the IBM playback approach already have a mechanism for capturing required actions, and a process in place to manage the review recommendations. The bottom line is to ensure that the post-review activities mesh with current design review processes in place within your organization.


This column has focused on the objectives and key guidelines for developing a BPM design review approach. I've tried to point out the high-level best practices for developing and executing a successful BPM design review. Organizations that adhere to the key guidelines for BPM adoption (such as agile BPM, the use of playbacks, and consistent alignment with business and IT on a continual basis) will find the BPM design review process easy to implement.

Although I'm sure that I've missed review criteria in this discussion, I hope this column has given you ideas to take forward and implement a design review approach for BPM. A a final word to the wise for facilitators of BPM design review sessions -- understand that designing software is similar to creating a song or a work of art. People don't like their creations criticized, so be careful how you position and recommend changes. The review participants should try to drive discussions as well as recommendations from a position of fact and experience.

Perhaps the key challenge in executing design review is to ascertain the key focus areas to cover. This column highlighted ten specific areas that should be reviewed:

  • General BPM solution design and implementation
  • Process modeling and design
  • Process data and information modeling
  • Decision services
  • Event management
  • Integration services and interfaces
  • User interface design and development
  • Architectural aspects
  • Infrastructure and deployment considerations
  • Governance aspects

As I mentioned at the beginning of this column, there are many different types of BPM applications and related patterns. Coupled with the requirement to ensure business alignment and collaboration, BPM solutions are, by their very definition, complicated. This point alone illustrates the urgent need for organizations to develop BPM design reviews. But lest you not forget, in many ways, you'll find conducting a BPM design review is like a Rubik's Cube – although there are many ways to solve the puzzle, it requires a honed set of techniques and skills to master the process and solve the cube!


I want to acknowledge the authors of Scaling BPM Adoption: From Project to Program with IBM Business Process Manager for the material used in the section on playbacks. This Redbook is one of best documents I've found on BPM Adoption and I urge you to download a copy and read it.

I'd also like to express my thanks to the IBM North America BPM Solution Architect team for their ongoing usage of this methodology (and just "putting it through the paces"), and for their advice and comments on the BPM Design Review spreadsheet that I've created. I work with an incredible team and the best part of my job is being able to partner and collaborate with some of the best technical folks in the industry. Thanks to an awesome group of people!



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Business process management on developerWorks

Zone=Business process management, WebSphere
ArticleTitle=BPM Voices: Evaluating BPM applications: BPM design reviews and Rubik's Cubes