Using BPM for Software Delivery
Traditional Approach:
1. Software projects go through requirements analysis. This phase involves talking to business and get individual requirements in document fashion and then are converted into software design and implementation decisions.
2. These requirements together form complete picture.
3. In that sense it is bottom-up design approach. Which leaves a lot to interpretation when it comes to how business and IT “see” the complete picture of organizational flow of information.
BPM Approach:
1. Main way it differs from traditional approach is that, it is top-down approach. Meaning it should start with Business Analysts and/or Users creating block diagrams to describe their overall flow of information in complete manner.
2. These blocks can be as abstract or detailed as Business can provide or wants them to be.
3. Each of these blocks interact with others via various synchronous/asynchronous mechanisms there by enabling Service Oriented Architecture (SOA) in the design and foundational infrastrure of all business requirements.
4. This also will automatically make sure all the sides involved “see” EXACT same “big picture” and can agree on the same.
5. Corollary effect of that is to allow all levels to drill down , see interdependencies, and make whole organization flexible, and more responsive to changes/updates.
6. Increased ROI, Risk-mitigation, reduced cost and other benefits follow the above.
***** BPM tool is ideal for flows of information that can be depicted as individual tasks that are controlled by some business logic or rules and can in general be described as a “process”
Most, if not all business process can be described in such a manner,
***
Implementation methodology:
To achieve BPM enabled software delivery following steps should be taken.
1. Business users/Analysts will provide Block diagram describing the process in terms of individual steps, decisions and flows.
This is very much like the “flow-charts” that all are familier with. Any IDE based tool of BPM (Jboss JBPM Engine) provides an easy to use and quick to adapt designer (Eclipse based Graphical Process Designer (GPD)) that can be used for this purpose.
This tool will create a simple text (xml formatted) file. Please see attached diagram below for example of such an image.
2.These blocks are then filled with details of functionality that is represented by that block.This normally means business analyst and business users doing requirements analysis and create a simple document that will give following information.
a. Globally applicable rules for process flows.
a. – These might include details such as business units responsible and allowed to see this process.
b. What are global variables if any are there any rules or validation that apply when this process fits in bigger flow as a sub-process maybe. (for e.g. Create Employee Payroll process might be a sub-process to Hire New Employee Process and can only be run if new employee SSN is validated against legal dept’s validate SSN service”)
c. Global tasks needed which can be organization wide rules or task. (for. e.g. upon completion of each order above email may be sent to manager)
b. Each individual block should then be given detailed description with following pieces
a. What is the functionality? Describe actual task
b. Timers and notification info – Due date, (if any) escalation actions (might be emails to supervisors, automated DB updates) , Rules for sending emails on task start, completion, expiring of task due dates etc.
c. Assignment and management rules – What business roles should be able to start/complete/stop task. Is task automatically sent to some user or is there specific set of rule for doing so.
d. User Interface details – Does task have any specific screen that should be associated while performing that task.
e. Auditing information – What are the business Process measurement matrices that are needed. (for e.g. Number of Orders processed in a day? Total Orders not completed in time, How many employees have more than 10 tasks in their to-do list etc)
f. If there is existing application/code that already does a particular functionality depicted by a block it should be noted and it will be RE-USED in almost all cases.
g. After all the above are given, any other specific rules, details of tasks, out of ordinary requests etc should be noted in a separate section under each block details.
3. Block diagram and subsequent info then is sent to IT for analysis and IT will create design and solution.
a. After previous steps and input from them, IT basically has all the info needed. At this point IT will likely look for re-use, application integration of existing coded functionality, and custom coding of new or updated functionality. But even if individual step is missed or has bugs.. the “BIG PICTURE” will be exactly what business has in mind.
b. IT does not have to write code to follow business flow, BPM tools will automatically do that based on outcome of individual business steps.
c. Business performance matrices become automatically available. – For this BPM tool will integrate with outside monitoring tools as needed,
Wednesday, February 18, 2009
Using BPM for Software Delivery-The Process
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment