BPM Design Review Approach

© 2014 IBM Corporation

Smart Work for a Smarter Planet

BPM Design Review

BPM Design Review – Overview and Approach

Scott Simmons – Lead Banking/Financial Markets Solution Architect [email protected]

IBM BPM



BPM Design Review

Why BPM Design Reviews Are Essential ...

Didn’t you read the business requirements …. Don’t you

understand that this solution does not match… grrrrr … IT techies!!

You business folks – you just don’t know what you want … first one thing … and then something else

… grrrrr … users!!!

Bridging the Gap … Process Discovery/BWL

Discovery Workshop Agile BPM/”Playback”



BPM Design Review

Agenda

BPM Design Review – High Level

Key Considerations for Design Review

Agile BPM – Playbacks and Iterative Development

Design Review Focus Areas



BPM Design Review

Key Guidelines/Leading Practices for BPM Development/Implementation

Reviews should be ongoing and provide consensus

and steps for optimization

Involve business stakeholders from the onset –

collaboration and alignment is mandatory for success

Process discovery is critical – without a clear direction,

success cannot be achieved

Define and document project scope to ensure

alignment

Practice “Agile BPM” e.g. “Blueprinting”, BWL,

Process Discovery, “Playbacks”, Discovery Workshops



BPM Design Review

Maybe a good question is ... What is a “Good” BPM application?

Actually this is a tough question … and there is not a simple answer − Many factors contribute to a good solution (BPM or otherwise)

− Perhaps the key component is satisfying (or exceeding) the business user expectations

− And … as a result … it requires a collaborative and agile approach to realize success

Key focus areas for Business Process “Goodness” (in no order of importance …) − General BPM Solution Design (including Business Architecture, Process Ownership)

− Process Modeling/Design Approach

− Information Modeling

− Decision Services

− Event Management

− Integration Services and Interfaces

− User Interface Design

− Architectural Aspects (such as Nonfunctional Requirements)

− Infrastructure and Deployment Considerations

− Governance Aspects

Many factors are “invisible” and can cause considerable re-work over the long

term if they are not addressed early in design (… this is not just a BPM issue)



BPM Design Review

How to Conduct a Successful Design Review

1. Prepare … prepare … prepare (More on this in a minute)

2. Ensure all roles attend AND participate – if not … cancel/re-schedule the review

3. Review early and often … and use “Playbacks” as a key technique (more on this shortly)

4. Continue to learn, refine and align the Review method and align to your organization

5. See the solution in action …. “playbacks” are a key way to drive the process

6. Coordinate the Agenda/Logistics for the review session

7. Do not criticize – but recommend – and get the teams to leave “egos” at the door



BPM Design Review

Who Needs to Participate in the Review

Session Facilitator

Key Stakeholders − Process Owner

− Business Stakeholders/End Users

− Business SME (Subject Matter Experts)

− Key Project Sponsors

Note-taker/Scribe

Project Lead/Project Manager

Enterprise Architect

Technology Manager

Process/Rules Architect

Solution Architect

Process/Rules Development Lead

Center of Excellence Representative (optional)



BPM Design Review

How to Prepare for a Design Review

Key artifacts to review − Business requirements

− Processes Design e.g. BPDs

− Data models/Process Information ModelS

− User interfaces e.g. coach, business space, portal

− In 7.x – Process documentation generated via PC

Playbacks define many of these artifacts as part of agile

BPM process (and we will cover this in a minute)

Additionally … prepare for the actual review “event” − Logistics – Location, Whiteboard, Web Conference, Projector etc

− Identify and ensure all key roles are represented

− Prepare an Agenda and distribute in advance



BPM Design Review

Deliverables from the Design Review

This depends on the organization − Many organizations already have a Design Review method in place with deliverables

− It is recommended to take this method and merge it with the current process

Key deliverables include: − At a minimum – the review session should detail session findings with next steps

− Optionally, the team can develop slides/report with key recommendations/next steps

− Additionally – if using playbacks – results/findings are inclusive in the playback process



BPM Design Review

Agenda







BPM Design Review

BPM and SOA – Mapping BPM/ODM to the SOA Solution Stack Coaches Business Space External Portal Process Portal

Process Server Decision Server BWL

Service Interfaces Message flows

Web Services Custom Interfaces Adapters

Key Enterprise Applications Infrastructure components

ESB Transformation Message Bus/JMS/MQ

Process Center Decision Center Process Events

Process Data/Events ODM Events

Process Center Decision Center Service Registry



BPM Design Review

Foundation Considerations for Solution Evaluation

Process discovery needs to be a distinct analysis phase

Complexity is inversely proportional to maintainability (KISS principle)

Modularity leads to a flexible solution e.g. facades, patterns, nested processes

If you can’t measure it – you can’t manage it … KPIs/SLAs need to be in scope

Collaboration and IT/Business alignment is critical – it needs to be ongoing/active

Process ownership is mandatory – without a process owner, chaos awaits you …

BPM Design needs to be top down as well as meet-in-the-middle (not bottom up)

Move away from a waterfall approach – it will lead to a non-optimal results

Let the “Server” do the work e.g. server-side scripts, stored procedures, etc



BPM Design Review

Agenda







BPM Design Review

1 to 3 Weeks 8 to 10 Weeks 2 to 3

Weeks

1 to 2

Weeks

Test Go

Live

•BPM Analyst (1) • Engagement Mgr (1) • Infr. Specialists (1)

•BPM Analyst (1) •BPM Developer (2) • Engagement Manager (1)

•BPM Analyst (1) •BPM Developer (2) • Technical Architect (1) • Engagement Manager (1)

•BPM Developer (1) • Technical Architect (1) • Engagement Manager (1) • Infrastructure Specialists (1)

Development

Infrastructure

• Environment Install / Config • LDAP integration

Training/ Mentoring

• Deployment scripts/playbook • Production Tuning

•Model Process and Service Flows

•Build UI shells •Create Business Data

model •Prototype Integrations

and DB Design •Mock up Reports

•Develop Process to specification

• Implement Services with Data Flow and DB layer

• Incorporate integrations •Generate data to build

reports

• Finish remaining 30% of UI functionality with look and feel

•Complete metrics and reports

• Implement exception handling and error proofing

• Goals, Critical Success Factors • As-Is Process Maps • Process Analysis • To-Be Process Maps • Executable BPD • Forms and Custom Reports • KPIs and SLAs • Business Data Model • Simulation

Definition

Agile BPM and Playbacks – SAMPLE Schedule/Roles

How many playbacks … how frequently … what are criteria …. This will vary by organization and process --- but having a representative structure is

the key – often you will iterate over a given playback a number of times



BPM Design Review

Playback 0

Focus: High-level process flow and business alignment

(Requirements and Process Discovery)

Goals: − Discovery/definition of key business processes

− Define implementation scope and project plan

− Alignment of expectations, KPIs, and metrics from sponsors

− Transfer context/responsibility from Analysis to Development

Deliverables: − An executable process definition (BPD)

− A participant and user group model (e.g. swimlanes/roles)

− A basic data model using BPM Variable types

− Mocked-up reports to demonstrate visibility, analysis, control

Out of scope − Implementation of user interfaces (use “stubs” and/or “mock-ups”)

− Implementation of process activities (use “stubs”/”mock-ups”)



BPM Design Review

Playback 1

Focus : User interface design/implementation.

Goals: − Consensus/implementation of BPM user interfaces

− Extend data model to support user interfaces/decisions

− Define human tasks, ad hoc interfaces, and reports, dashboards,

and scoreboards to support visibility and control

Deliverables: − Implementation of user interfaces

− Definition of the data model for process and date captured via

human tasks/interfaces

− Definition of business actions that need to be enabled and the

next steps for each action

− Definition of validation to ensure/maintain data/decision integrity

− Appearance (styles, themes, headers, consistent layout)

Out of scope: − Integrations, reference data or system-of-record population



BPM Design Review

Playback 2

Focus: Integrations to external systems (applications,

infrastructure components e.g. email, B2B aspects)

Goals: − Implementation and exception handling for all integrations

(external integrations and any System of Record (SOR) )

− Definition/acceptance on service level agreements

− Alignment with owners of external systems

Deliverables: − Definition interfaces required for each integration point

− Definition of the data transformation between systems

− Definition of exception handling/fault codes arising via

integrations

− Definition of validation to ensure/maintain data/decision integrity

Out of scope − This is not a complete/functional solution

− Not ready for user acceptance testing.



BPM Design Review

Playback 3

Focus: Consolidation/producing an end-to-end solution.

Goals − Completing details to consolidate the solution e.g. process

automation, user interfaces, and integrations

− Delivering a fully deployable/testable solution ready for user

acceptance testing

− This playback should not introduce any new functionality to the

solution - focus on completeness, refinement, and stability

Deliverables: − An end-user testable solution, 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)

− Description and prioritization of all functionality that has been

deferred to the next revision of the project



BPM Design Review

Agenda







BPM Design Review

Key Focus Areas

General Solution Design/Implementation

Process Modeling and Design

Process Data Architecture/Information Modeling

Decision Services

Event Management

Integration Services/Interfaces

User Interface Design/Development

Architectural Aspects (such as Nonfunctional Requirements)

Infrastructure and Deployment Considerations

Governance Aspects



BPM Design Review

General Solution Design/Implementation

Criteria/Focus Areas − Strategic alignment/Business involvement/Business architecture

− Render enhancements on the solution between reviews

− Product and tooling selections

Common Anti-Patterns − Lack of business involvement/alignment

− Infrequent and/or inconsistent reviews

− Choosing the wrong product

− Choosing the wrong project

Key questions − How to “optimize” the next release? What are the “lessons learned”?

− How long did the process take to implement (person days)?

− Did you implement the entire business scenario? What was omitted and why?

Did you implement more than initially planned?

− Did you use (formal) business modeling? Visio, 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?

Leading Practices − Enforce Process Discovery as the first step in BPM Development

− Choose the appropriate tool: Standard versus Advanced Integration Aspects – Transactionality, Transports, Transformation

Web Service Standards

XML Schema Standards (Basic versus Extended)

− Use WODM/BRMS to support enterprise-level decision services



BPM Design Review

Process Modeling and Design

Criteria/Focus Areas − Process Discovery

− Process Modeling as an iterative process

Common Anti-Patterns − Basic modeling anti-patterns (more on this in a minute)

− Process Decomposition

− Complexity/Dependencies

− Absence of Metrics/Monitoring

− Bottom-Up (SOA/IT)-based approach versus top-down

− Parallel gateways can lead to race conditions

Key questions − How was process discovery done and how was business involved?

− How do you measure/monitor the business process e.g. dashboards?

− Does the process always use the same set of services? Can you select

different services based on process context?

Leading Practices − Process Decomposition/Granularity is key to development/maintenance

− Ensure the design provides for optimization and adaptation over time

− Standardize the process and activities to maximize scale and flexibility

(e.g. Remove activities that add no value, Compress time by processing in

parallel, Automate manual steps wherever possible)

− Toolkits – use where possible to support reuse and maximize scale

− Model Roles/Swimlanes to specify task responsibilities

− Model Exception Management and Event Management

− Focus on Modularity e.g. Nested processes, facades, component-based

− Focus on loosely coupled solution process design aspects



BPM Design Review

Example of a bad Process Model

Click button to

add a new line

item.

Select Company

in dropdown

Click OK



BPM Design Review

Example of a bad Process Model

Four System

Lanes

“Constellation”

Pattern

No

Milestones

Defined

“String of

Pearls”

Pattern



BPM Design Review

Process and Activity Granularity Anti-Patterns and Resolution

Anti-Pattern: Large/Small numbers of activities at each process “level” − Milestones with only one or two activities

− Resolution: “Rule of Seven” at each level (level 1, 2, 3, etc.) –milestones should have 4-

7 key activities.

Anti-Pattern: Fine-grained activities − Process activities range broadly in size and scope

− Resolution: Activities should be Similar in Scope at each level – you need this detail later

… just not now

Anti-Pattern: String of Pearls pattern − May indicate too much detail (e.g. fine granularity), misalignment in scope or missing

participant

− This pattern will really cost you in performance in system swimlane

− Resolution: Consolidate into fewer (or one) steps

Anti-Pattern: Constellation pattern. − Tight groups of activities across 2-3 swim lanes

− Single flow line in & out of the group

− Resolution: Rethink the modularity of the processes/activities

Anti-Pattern: Flow Line Patterns − Generally should not flow backward to a previous milestone.

− Generally should not skip a Milestone.

− Avoid looping back to previous steps to repeat activities/sub-process)

− Resolution: Repeat/re-use activities versus “spider webs” – activities may be misplaced



BPM Design Review

“Server-side Javascript” Best Practices

Use easy, short and readable variable/function names

Stick to a strict coding style (style is important … especially for those after you)

Comment as much as needed but not more

Modularize — one function per task

Do not feel you have to do everything in a single script – BUT understand each

script involves a round trip to the server (so use wisely)

Enhance progressively – experiment until you get it right

Allow for configuration and translation

Avoid heavy nesting – it enhances readability

Optimize loops – do timing tests as appropriate

If possible – develop server script is isolation and debug in a step-wise function

Add functionality with JavaScript, don’t create too much content

“Build on the shoulders of giants” – lots of great information on the web

Development code is not live code – test and develop with this in mind

Credits to Christian Heilmann – http://dev.opera.com/articles/view/javascript-best-practices/



BPM Design Review

Naming Standards

Key – Consistency across implementation (similar to DBMS considerations)

BPD − 54 Alphanumeric

− Have a standard (TO DO -- see if there are any recommended approaches)

Activities − 580 Characters

− Activity Name = Action + Entity/BO e.g. Set Customer Status, Approve Contract Status

− Avoid vague action verbs such as Process and Perform [Step]

− Use terms recognizable by the business and describe/define terms in the description

Variables/Tracked names − Consistent and meaningful

− Standard is normally first word lowercase with subsequent words capitalized (unitPrice)

Event names − Consistency is key – make name appropriate to event context and share event variables



BPM Design Review

Process Data/Information Modeling

Criteria/Focus Areas − Consistency of data management and usage

− Scoping of variables (e.g. input/output versus private)

− Persistence of process data and source/target data

− Data model - Key entities and mapping to database

− Design data objects with a view towards performance and reuse

Common Anti-Patterns − High numbers of large objects being passed between activities

− Unnecessary data being passed into activities

− Inconsistent and redundant objects

Key questions − What kind of information does the process use? Structured data,

unstructured data, specific documents?

− Where is information stored?

− What are the process inputs and outputs?

− Does information arrival cause process instances to (re-)start?

− How has the BPM implementation changed information ‘handling’?

Leading Practices − Protect internal and external data (Private variables enable “hiding”)

− Understand that you may use different data model for different needs

− Use what is needed – “No more – no less”

− Manage data quality at source of entry (Validation rules are key for this)

− Only pass what is needed – otherwise memory and complexity issues



BPM Design Review

Decision Services

Criteria/Focus Areas − Decision Services

− Business Semantics

− Scope and reusability

− Rule governance and lifecycle issues

Common Anti-Patterns − Linked activities with string of diamonds may be decisions

− Using BRMS rules when the rule management is a key consideration

− Exposing the wrong rules to the wrong audiences (internal/external rules)

Key questions − What are the main decision points within the process?

− Do you have business rules in the business process? How many? What

types of rules? Data checking, validation, complex decisioning,

− How are the rules implemented?

− How are rules persisted, changed, governed?

Leading Practices − Rules normally apply to single business entity

− Recognize the difference between process rules and business rules

− The standard BPD pattern: ‘decision task’ prior to Gateway

− For naming – use action verb such as “determine”, “check”, “calculate”,

− Decision points can be combined in one activity in the process, but still

supported as two operations in the service layer



BPM Design Review

Event Management

Criteria/Focus Areas − Event usage

− Event scope

− Code complexity/dependencies

Common Anti-Patterns − Redundant event functions

− Poor design/non-modular event data models

− Bad design can lead to “event storms”

− Beware of infinite loop scenarios

Key questions − How do you currently implement events e.g. notification events, ad-hoc

events, exception handling, etc

− Do you use new data models for the same types of events?

− How are events initiated (at process level, by timing, scheduling, other …)

Leading Practices − Be pragmatic in the use of events – remember you are using JMS to

support event interactions

− Include event aspects in sizing determination

− Test ALL key event conditions (test harnesses help here)



BPM Design Review

Integration Services/Interfaces

Criteria/Focus Areas − Integration patterns

− Toolkits and Advanced Integration Services

Common Anti-Patterns − Lack of knowledge of SLA for external systems

− Redundant integration services leading to management issues

− “Reinventing the wheel” (“Service Anarchy”)

− Limited involvement by IT SMEs/Architects

− Integration implementation in Process Designer versus Integration Designer

− Deployment of large numbers of EARs/JARs to Process Server

Key questions − Are you using BPM Advanced to support your integration requirements?

− Characterize your integration approach – Standards-based or other?

− How do you access the services? Direct coupling, ESB, custom ….

− Are canonicals used to access business objects from the enterprise apps?

Leading Practices − Factor common services into toolkits – reuse is key for maintenance

− Use façades to enable high maintainability/Do not hardcode endpoints

− ESBs can provide information hiding as well as common transformation for

both package integration and custom integration

− Snapshot considerations are key especially when using Integration Designer



BPM Design Review

User Interface Design/Development

Criteria/Focus Areas − Usability

− Consistency

− Performance

Common Anti-Patterns − Lack of standards/consistency across applications

− Lack of business focus and/or participation

− Technical UIs versus Business UIs

Key questions − What technology was used for the user interfaces? Coaches, eForms,

HTML, Dojo, JSP, Portlet, Business Space widgets… ?

− What is the nature of the interaction with the process e.g. SOAP/WS,

REST, Process Portal, other?

− How many different UIs are there for the process?

− How was UI development done?

− How did the team design the UI? e.g. business user collaboration e.g.

playbacks, storyboarding, formal use cases

Leading Practices − Basic Coaches are a great staring point – use for initial playbacks and

then extend as you iterate the implementation

− Edit the Process Portal JSPs to display the banners conditionally

− Many leading practices for integrating with external portal integration

− Use Dojo to extend UIs – there will be a number of UI enhancements

in the upcoming releases (IBM OneUI initiative)



BPM Design Review

Architectural Aspects/Nonfunctional Requirements

Criteria/Focus Areas − Nonfunctional Requirements (NFRs) e.g. Scalability, Availability, Security,

Portability, Reliability

− Optimize for Reuse, Usability, Extensibility, Maintainability, Legal/Regulatory

Common Anti-Patterns − Design of NFRs is secondary (or non-existent)

− Security/entitlements is an after-thought

− Sizing is not done correctly

− Availability is not effectively scoped

− Too many “happy path” – and not enough thought to exception handling

Key questions − Recoverability – What do you do when something goes wrong in the process?

− How many process instances per day? How many users? How many concurrent

users? What is the “worst case”?

− Have you considered ALL parts of the solution in terms of NFR decisions?

− What is the average process duration, min, max?

− Do you have any timeout/notification implemented?

− How have you design for solution evolution e.g. loosely coupled?

Leading Practices − Define NFRs early and revisit throughout design

− Risk identification and mitigation

− Adopt techniques that support rapid refactoring and flexible modification

− Maintain Documentation (Use Cases, System Context, Architecture Diagram,

Operational Architecture, Architecture Decisions) – BPM does not alter this need

− Use LDAP as the single centralized user management console – do not rebuild

− Enable process isolation so that processes can be moved around



BPM Design Review

Sizing considerations

Sizing is critical and needs to be approached with care

“Rules of thumb” − The average number of screens is generally not equal, but lower than the total number

of coaches that you anticipate having in the process Not all coaches will be executed for every instance

Think of a typical process execution, not of the worst case scenario

− This applies to the number of integration calls and number of events/decision points

− The number of interactions with the task list is about same as the number of screens Generally, it’s smaller, because each task may involve navigating multiple screens

In some cases, users may access the portal more frequently (visibility, queries, dashboards)

− Guidelines Expect anywhere between 25 to 100 concurrent users / 100 PVUs -- Roughly, 80/120 PVU

correspond to one CPU core

But there is a wide range of variability is due to differences in Process structure and composition

(simple vs. complex tasks), Intensity/frequency of user interactions

Given the variety of workload types/scenarios with BPM Advanced, it is tough to define guidelines

Involve IBM as needed to support complex requirements

Bad design normally leads to bad performance

Design for change – use clusters (even if only a single member)



BPM Design Review

Infrastructure and Deployment Considerations

Criteria/Focus Areas − Development testing/runtime topology

− Interaction with key architecture aspects (e.g. NFRs)

− Manageability

− Monitoring

− Serviceability

− Source code management/SDLC aspects - Unit testing

− Packaging decisions

Common Anti-Patterns − Lack of end-to-end system testing

− Lack of collaboration with external system stakeholders

− Failure to consider network latency (esp in distributed implementations)

− Constant connectivity may not be assured

− Installation on a poorly sized configuration

Key questions − What is the IT configuration for the implementation?

− Platforms, # machines, clustering, …

− What influenced the choice of platform?

− Did you implement an HA or DR environment?

Leading Practices − Assess/evaluate Shared Services, External Applications, Database SLAs

− Cluster the Process Center and Process Server – maintain support for

scalability, failover, high availability, redundancy.

− Optimize the Process Server database – and maintain over time

− Install Integration Designer with the local Process Server UTE

− Encourage IT Developers use the UTE not Process Center for unit testing



BPM Design Review

Governance Aspects

Criteria/Focus Areas − SDLC/Promotion Management

− Asset Management/Toolkits/Shared Services/Asset Reuse

− Dependency Management

− Service Registry

− Change Management

Common Anti-Patterns − Lack of an approach to “maximize” reuse

− Asset Management of shared components e.g. Toolkit “sprawl

− Limited monitoring of solution usage

− Limited tracking of BPM development and implementation at enterprise level

Key questions − How is asset management tracked/monitored?

− Where are the services catalogued?

− How do you manage service and rule lifecycles, service currency, service selection, versioning?

− What’s the perceived and actual value from implementing the process with BPM technology? How

was cost saving/value derived?

Leading Practices − Implement a center of excellence to develop and enforce formal governance policies

− Develop a policy for shared service components e.g. processes, toolkits, etc

− Develop reuse strategy and guidelines

− Initiate formalized engagement process review and ad-hoc project audits

− SCM aspects Remember that work spaces are caches – the use of SCM is recommended esp for BPM Advanced

Ensure you first commit you project to PC, then share it with SCM

If using a SCM tool – ensure that the components are from SCM not PC

− Track and manage approved initiatives in a pipeline Use BPM to cross divisional collaboration/convergence initiatives



BPM Design Review

Summary

There are a number of high level review aspects to cover in a Design Review

Key “leading practices” include Agile BPM, the use of Playbacks and alignment

with the business on a continual basis

There are a number of key focus areas in the Design Review − General BPM Solution Design (including Business Architecture, Process Ownership)

− Process Modeling/Design Approach

− Information Modeling

− Decision Services

− Event Management

− Integration Services and Interfaces

− User Interface Design

− Architectural Aspects (such as Nonfunctional Requirements)

− Infrastructure and Deployment Considerations

− Governance Aspects



BPM Design Review

References

Evaluating BPM applications: BPM design reviews and Rubik's Cubes http://www.ibm.com/developerworks/bpm/bpmjournal/1302_col_simmons/1302_col_simmons.html

Synchronicity: An agile approach to business process management http://www.ibm.com/developerworks/websphere/bpmjournal/1202_col_simmons/1202_simmons.html

Successful BPM takes a true team-oriented approach http://www.ibm.com/developerworks/websphere/techjournal/1108_col_simmons/1108_col_simmons.html

Don't let the greatest benefits of SOA elude you http://www.ibm.com/developerworks/websphere/techjournal/0706_col_simmons/0706_col_simmons.html

SOA governance and the prevention of service-oriented anarchy http://www.ibm.com/developerworks/websphere/techjournal/0609_col_simmons/0609_col_simmons.html

Scaling BPM Adoption: From Project to Program with IBM Business Process Manager http://www.redbooks.ibm.com/abstracts/sg247973.html

Combining Business Process Management and Enterprise Architecture for Better Business Outcomes http://www.redbooks.ibm.com/abstracts/sg247947.html?Open