accelerating requirements with process-centric prototyping
Post on 14-Jun-2015
1.346 Views
Preview:
DESCRIPTION
TRANSCRIPT
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.
top related