Technology and Business Solutions Conference
Accelerating Requirements
with Process-Centric Prototyping
George Clark and Jamie Raut
Miami, FL • June 8 – 10, 2006
Produced by the Leading Edge Forum
11/5/2007 11:47:52 AM 4111-06_FMT 1

Speaker Introductions
• George N Clark
Principal 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 Raut
Senior 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 2

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 3

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 4

Existing Methodology
• Waterfall Approach used by bank was slow. Best case scenario (below) would lead to 14
month development cycles
• In reality, it ended up taking much longer than 14 months, with mixed levels of success
11/5/2007 11:47:52 AM 4111-06_FMT 5

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 6

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 7

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 8

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 9

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 10

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 11

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 12

Q&A
• Questions?
11/5/2007 11:47:52 AM 4111-06_FMT 13

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 14

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 15

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 16

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.
11/5/2007 11:47:52 AM 4111-06_FMT 17