11/5/2007 11:47:52 AM 4111-06_FMT 1

Technology and Business Solutions Conference

Miami, FL • June 8 – 10, 2006Produced by the Leading Edge Forum

Accelerating Requirementswith Process-Centric Prototyping

George Clark and Jamie Raut

11/5/2007 11:47:52 AM 4111-06_FMT 2

Speaker Introductions

• George N ClarkPrincipal Consultant, Denver Delivery Services, Consulting Group

Senior Business Process Specialist. 8+ years with CSC Consulting working in Project Management, Business Architecture, and Business Process roles.

• Jamie RautSenior Consultant, San Francisco Delivery Services, Consulting Group

Architectural Specialist. 6+ years with CSC Consulting and CSC Australia. Application Architect and Developer specializing in JavaEE technologies.

11/5/2007 11:47:52 AM 4111-06_FMT 3

Presentation Overview

• Project(s) background

• Methodology

• Process-centric approach

• Lessons Learned

• Q&A

• Appendix: Supporting Tools

11/5/2007 11:47:52 AM 4111-06_FMT 4

Project Background

• Project inception January 2005

• Segment-leading Financial Services company

• Industry leading performance by key business metrics

• Three distinct processes being addressed, ranging from commercial real estate origination through to loan servicing:

– High-value, low volume commercial real estate origination

– Medium-value, medium volume commercial real estate origination

– High-volume commercial real estate loan servicing

• Prototype applications developed for each process by small,high-performance teams to:

– Sell the vision, gain stakeholder acceptance, build momentum

– Validate and further develop stakeholder requirements

11/5/2007 11:47:52 AM 4111-06_FMT 5

Existing Methodology

• In reality, it ended up taking much longer than 14 months, with mixed levels of success

• Waterfall Approach used by bank was slow. Best case scenario (below) would lead to 14 month development cycles

11/5/2007 11:47:52 AM 4111-06_FMT 6

Process Centric Prototyping• An abbreviated Requirements phase is followed on by a series of Solution Demonstration

Lab sessions where actual screens and functionality are developed and reviewed

SDL 1 SDL 2 SDL 3

11/5/2007 11:47:52 AM 4111-06_FMT 7

Requirements Definition

• Started with the definition of the high-level process.

• 100+ interviews and other materials allowed initial process model, which was collaboratively developed by business and IT

• Swim lane view of the process constructed, roles defined, activities identified (human-to-system and system-to-system)

Identify roles

Identify activities

for each role

11/5/2007 11:47:52 AM 4111-06_FMT 8

Initial Design and Development

• Human-to-system activities earmarked for development of screens; identification of fields on screens allowed attributing of process model and beginnings of the data model

11/5/2007 11:47:52 AM 4111-06_FMT 9

Solution Demonstration Lab

• SDLs further refined definitions of individual screens, fields, processes and sub-processes as participants were given the view of the process and led through the enabling activities.

• Prototype was tailored to each project’s process requirements/attributes, e.g. high-touch, high-value, low volume commercial real estate origination process required more flexibility than loan servicing. The process application was developed accordingly.

11/5/2007 11:47:52 AM 4111-06_FMT 10

Lessons Learned

• Moving from a Waterfall Approach to an Iterative Development Process

– Client Organizational Issues - IT

• While most people who work in IT talk to an iterative development process, few understand what it truly means

• Working with less than complete documentation is uncomfortable for many who have been working in IT a long period of time

– User Community

• Users who have been exposed to IT projects are eager to embrace an iterative approach where there feedback is solicited in a regular manner

• Maintain involvement of user community. Have IT management regularly report to the community and take responsibility for delivery.

– Small High Performance Cross-Functional Team

• The ability to create a dedicated, high quality, cross functional team is absolutely necessary to making an iterative development process work. Iterative development requires a strong, seasoned technical team to result in a quality product at release n.

11/5/2007 11:47:52 AM 4111-06_FMT 11

Lessons Learned (continued)

• Start High Level with a Large Audience

– The User Community will want to understand the high level process before diving down into the details

• Move to Smaller Sessions with a Narrow Focus

– After laying out the high level process and functionality, move to smaller groups with a very narrow focus on detailed functionality

– Ensure there is a designated decision-maker included who can make a call on an issue and move on

– Maintain momentum by holding to a regular schedule or work sessions and updates

– Have developers quickly prototype ideas that come out of work sessions that perhaps aren’t clear to the whole group. Experiment!

11/5/2007 11:47:52 AM 4111-06_FMT 12

Lessons Learned (continued)

• Determination of a Tool is Critical

– IT involvement from the beginning is necessary to pick an appropriate tool

– Tool must be Business Analyst and End User friendly, to get appropriate feedback and buy off on the process

11/5/2007 11:47:52 AM 4111-06_FMT 13

Q&A

• Questions?

11/5/2007 11:47:52 AM 4111-06_FMT 14

BPM Tools Used on CG Projects in San Francisco

• BEA AquaLogic BPM

• BEA WebLogic Integration

• ProActivity

• Savvion

• Intalio

BPM Tools Evaluated for CG Projects in San Francisco

• TIBCO Staffware iProcess Suite

• Action Technologies

• Microsoft Biztalk

11/5/2007 11:47:52 AM 4111-06_FMT 15

Supporting Tools

• ProActivity used for initial process modeling

• BEA AquaLogic Business Service Interaction (formerly FuegoBPM) selected by project team as a platform for the prototype build

• Process model refined within BEA, UI built out in response to SDL feedback

8:00am SDL

5:00pm Develop

11/5/2007 11:47:52 AM 4111-06_FMT 16

Supporting Tools (continued)

• Process model made use of common modeling techniques: sub-processes, conditional transitions et cetera.

• Format was XPDL to capture notion of ‘roles’ absent in BPEL.

• Actual execution model shown in SDLs.

• Use of BEA AL BPM for exposing UI: JSP, Struts Tiles, AJAX

• Process flexibility quickly built using proprietary BEA feature

11/5/2007 11:47:52 AM 4111-06_FMT 17

Supporting Tools (continued)

• Several other generic, JSP-based web application prototypes were built for the other business processes.

• These prototypes were based on the one constructed using BEA AL BPM but did not use that tool.

• Required due to inability to use the BEA tool for non-technical/political reasons.

• Processes for these prototypes were modeled and presented using MS Visio.