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
scottsim@us.ibm.com
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
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
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)
• Technical Architect (1)
• Technical Architect (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
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
− Process Discovery
− Process Modeling as an iterative process
− 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?
− 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
− 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
− 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’?
− 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
− Business Semantics
− Scope and reusability
− Rule governance and lifecycle issues
− 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?
− 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
− Event usage
− Event scope
− Code complexity/dependencies
− 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 …)
− 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
− Integration patterns
− Toolkits and Advanced Integration Services
− 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?
− 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
− Usability
− Consistency
− Performance
− 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
− 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
− Nonfunctional Requirements (NFRs) e.g. Scalability, Availability, Security,
Portability, Reliability
− Optimize for Reuse, Usability, Extensibility, Maintainability, Legal/Regulatory
− 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?
− 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
− Development testing/runtime topology
− Interaction with key architecture aspects (e.g. NFRs)
− Manageability
− Monitoring
− Serviceability
− Source code management/SDLC aspects - Unit testing
− Packaging decisions
− 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?
− 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
− SDLC/Promotion Management
− Asset Management/Toolkits/Shared Services/Asset Reuse
− Dependency Management
− Service Registry
− Change Management
− 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?
− 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
− 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
 SOA governance and the prevention of service-oriented anarchy
 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

BPM Design Review Approach

More Related Content

What's hot (20)

Similar to BPM Design Review Approach (20)

More from Scott Simmons (8)

Recently uploaded (20)

BPM Design Review Approach