39,59 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
JBoss jBPM is a free, open-source, business process management solution. It enables users to create business processes that coordinate people, applications, and services.
A business process is a sequence of activities triggered by a certain input that results in a valuable output. Business Process Management is about analyzing those activities in a structured way and eventually supporting their execution with a workflow application. This allows for the following results:
Better management visibility of their business: improved decision making
Low cost of inputs: de-skilled labor requirements, less waste, standardized components
Better outputs: consistent quality, more customer satisfaction
Businesses have always tried to manage their processes, but software such as jBPM brings the methodology and management theory to practical life.
JBoss jBPM offers the following key features:
Graphical process definition
Flexibility to integrate code into the graphical process definition
A customizable web-based workflow application that runs the process you’ve defined
Easy programming model to extend the graphical process definition
A process-oriented programming model (jPDL) that blends the best of process definition languages and Java.
Easy to integrate with other systems through the JBoss middleware suite.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 261
Veröffentlichungsjahr: 2007
Ähnliche
Table of Contents
Business Process Management with JBoss jBPM
A Practical Guide for Business Analysts
Matt Cumberlidge
Business Process Management with JBoss jBPM
A Practical Guide for Business Analysts
Copyright © 2007 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, Packt Publishing, nor its dealers or distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: July 2007
Production Reference: 1190707
Published by Packt Publishing Ltd.
32 Lincoln Road
Olton
Birmingham, B27 6PA, UK.
ISBN 978-1-847192-36-3
www.packtpub.com
Cover Image by Vinayak Chittar (<[email protected]>)
Credits
Author
Matt Cumberlidge
Reviewers
Diego Naya Lazo
Dr. David Franklin
Sebastien Michea
Senior Acquisition Editor
David Barnes
Development Editor
Nikhil Bangera
Technical Editor
Ajay S
Project Manager
Abhijeet Deobhakta
Editorial Manager
Dipali Chittar
Project Coordinator
Sagara Naik
Indexer
Bhushan Pangaonkar
Proofreader
Chris Smith
Production Coordinator
Manjiri Nadkarni
Cover Designer
Shantanu Zagade
About the Author
Matt Cumberlidge is a business analyst working for a world leading FTSE 100 provider of information-driven services and solutions based in Oxford, UK. In this role, Matt has undertaken a very wide range of projects, but the common theme running throughout is that of business process. Over the last year or so Matt has extended his core capabilities in business process analysis and re-engineering into the realm of business process management and in particular an investigation of the JBoss jBPM implementation. Matt is delighted to be able to share his experiences and ideas about this exciting technology with a wider audience through the publication of this book.
I'd like to thank my wife, Cathy, for understanding why I wasn't always available to do my share of the housework while I was writing this book and for feeding the cats, who would otherwise surely have died of hunger. I'd like to thank Phil Wilkins from SeeWhy for going way beyond the call of duty in helping me. I'd like to thank my publishers, Packt, and in particular Dave Barnes for his encouragement. Lastly, I'd like to thank and pay tribute to the contributors to the JBoss jBPM community who have built a fantastic product that it was fun for me to write about.
About the Reviewers
Diego Naya Lazo is a Chief Enterprise Architect living in Buenos Aires, Argentina. He currently works for Argentina's biggest healthcare provider and has more than 10 years of experience in the IT industry. He participated in several projects as a hands-on software architect and performed the technical lead role in many companies. His interest in computer programming began with his desire to create the most vivid 3D animations as a graphic designer at the age of 15.
Dr David Franklin is an experienced hands-on software architect with more than 20 years experience with leading-edge companies and technologies.
Sebastien Michea is a J2EE software architect at Manaty (www.manaty.net).
After a PhD in Mathematical Physics at Université de Bourgogne (Dijon, France), he studied Quantum Statistical systems in Yonsei university (Seoul). Programming with Java since its first version, he joined Cap Gemini Telecom in Paris as a Java developer. He then worked at PSU (State College, USA) as a Lecturer and Researcher in the Computer Science and Mathematics department and simultaneously developed a trading system based on non-linear correlations.
In 2006 he founded Manaty, an open-source IT company which is closer to a freelancer community than a traditional company that create software using cutting-edge technologies like EJB3, Flex, and.NET.
His main areas of interest are software design, science, linguistic, and cooking.
Preface
This book shows business analysts how to model business processes in JBoss jBPM and use these models to generate a fully-functioning workflow application. It shows how business analysts can use the tools to build a solution without the need for Java coding expertise. It also introduces more advanced functionality that can be implemented by Java developers in partnership with the Business Analyst.
This book takes a practical approach, with step-by-step instructions for business process management, model creation, and implementation. It uses a typical BPM project lifecycle case study to explore and explain the process in a realistic situation.
What this book covers
Chapter 1discusses the background from which BPM has emerged, and how BPM fits into the wider scheme of enterprise application development. We define what BPM means for us, and look at the business scenarios where BPM is the right solution. Also, we introduce our suggested BPM project lifecycle, and see the tools that we'll put together as our open source-based BPM suite.
Chapter 2covers all the major tools in the process analyst's kit bag, with a view to creating a deep understanding of the process we are seeking to systematize in our BPMS.
Chapter 3 covers the software installations—Java, the JBoss application server, the jBPM engine, and the jBPM Designer. Also, we take a look at the fundamental concepts that underpin JBoss jBPM and put these concepts into practice by building our first process definition for our proof-of-concept system.
Chapter 4covers building the user interface that our proof-of-concept testers will use to interact with the process definition that we built in the previous chapter.
Chapter 5 covers putting the jBPM system on a server so our proof-of-concept testers can bash their test data into it and give us feedback on what they think. Also, how we can allow managers to prioritize tasks by design and on the fly. Most complicated of all, we see how our system can be integrated with other applications, both in house and external.
Chapter 6 looks at how we judge when we are ready to start planning to go live and also covers the essentials we need to consider when building an implementation plan. We show how the web console can be customized according to your own branding and we see how we can swap the default jBPM database for a more robust, enterprise-ready database server. We will also integrate and put to use the SeeWhy Business Activity Monitoring solution.
Chapter 7 covers how to assess our project and perform process analysis and ongoing improvement. We also put together business process documentation, and present ideas for further development of our BPM system.
What you need for this book
You will need access to an installation of the JBoss jBPM engine and the JBoss application server, along with the JBoss jBPM designer. There is a walk-through on how to install them in Chapter 3 of this book.
JBoss jBPM requires a working installation of the latest version of Java and a Java utility called Ant. Details about how to download, install, and configure them are given in Chapter 3 of this book.
You'll also need access to a MySQL installation in order to do some of the more complex pieces
Conventions
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
There are three styles for code. Code words in text are shown as follows: "We can include other contexts through the use of the include directive."
A block of code will be set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items will be made bold:
New terms and important words are introduced in a bold-type font. Words that you see on the screen, in menus or dialog boxes for example, appear in our text like this: "clicking the Next button moves you to the next screen".
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book, what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply drop an email to <[email protected]>, making sure to mention the book title in the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code for the book
Visit http://www.packtpub.com/support, and select this book from the list of titles to download any example code or extra resources for this book. The files available for download will then be displayed.
Note
The downloadable files contain instructions on how to use them.
Errata
Although we have taken every care to ensure the accuracy of our contents, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in text or code—we would be grateful if you would report this to us. By doing this you can save other readers from frustration, and help to improve subsequent versions of this book. If you find any errata, report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the Submit Errata link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata added to the list of existing errata. The existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Questions
You can contact us at <[email protected]> if you are having a problem with some aspect of the book, and we will do our best to address it.
Chapter 1. Introduction
Business Process Management is one of the hottest topics in the fast-moving world of business analysis and enterprise application development. Yet, it is curiously difficult to pin down as a defined field of work. You don't see job listings for "Process Developer" and there are few, if any, official courses that you can take in Business Process Management.
The answer to this conundrum lies in the almost accidental way in which BPM has come about, and in the speed with which the technology marketing machine swings into action these days: usually before the technology is properly understood. Business Process Management is at the start of the "hype curve" and it will be some time before its key concepts become common currency among enterprise managers.
We will try to cut through this hype and the resultant barriers to adoption by presenting a practical step-by-step approach to the successful implementation of business process management. We won't spend a great deal of time on theory in this book; instead we will concentrate on building something of value to your business. Having said that, we won't simply throw together any old business process management system, we will advocate a project lifecycle approach, so that we implement business process management in the right way.
So what is Business Process Management anyway? Well, hopefully you are coming to this book with some idea of the answer to that question. However, Business Process Management, or BPM as we shall call it henceforth, means different things to different people. Each person's definition probably has some element that falls in the intersection of a Venn diagram of definitions, at the centre of which is the truth. One of the first things we have to do is to define what BPM means for us, so that we may set expectations about what will be achieved by reading and implementing the suggestions in this book.
This introductory chapter will lay the ground work for the rest of the book. In it, we shall cover:
The BPM approach to software development
Business Process Management is the natural evolution and convergence of several powerful forces within the fields of software development methodology, enterprise application technology, and management theory. These underlying forces have all matured and converged at the right time for a productive fusion, which we know as business process management.
Evolution of software development methodologies
Traditional software development methodologies owe much to their engineering roots. The waterfall approach to software development was designed with the idea that building a piece of software is like building a bridge: the better your design and blueprint, the sturdier the end result. In reality, this approach falls very far short of perfection.
Developing enterprise application software is about delivering value to a business, and the business expresses that value as a set of business requirements. The problem with the waterfall approach, and the difference from bridge construction, is that unlike the laws of physics and the construction properties of metal and concrete, business requirements are subject to change. Businesses cannot afford to stay still: if they don't adapt to the marketplace then they will not survive. So business requirements are necessarily a shifting target.
Unfortunately, this is not the only problem with the traditional software development methodologies. There is also the problem of business requirements "dissonance". This is where the layers of end users, analysts, and developers create a chain of Chinese whispers, resulting in software that fails to resemble the original requirement. Each link in the chain puts its own interpretation on the requirement, until the end result is horribly different from what the business originally needed. This requirements dissonance can easily be visualized:
In recent years, the traditional waterfall approach to software development has been superseded by other, more adaptable methodologies. These methodologies attempt to break down the requirements dissonance by taking out the middle man as much as possible, and by creating prototypes early on, and then iterating them towards the final version. This allows for an iterative approach to software development, far removed from the "build a bridge" traditional approach:
The most prominent of these newer development methodologies is Agile. On the right project, there is no doubt that Agile development can deliver valuable software more successfully, and more quickly, than the waterfall approach.
Nevertheless, Agile development and its ilk do have serious drawbacks and limitations. The first and most obvious limitation is that the Agile development methodology does away with the Business Analyst. This is an important drawback, because often the BA's interpretation of the requirements is more logical and more far-sighted than that of the end user who specifies the original requirement. This can mean that the developer can be led up blind alleys by an end user who doesn't have the necessary perspective.
There is also the problem that although we are removing some layers of interpretation, the layer of interpretation that we are leaving in place is the one that causes the most significant dissonance: the developer still has to interpret what the end user means.
This can mean that time is unnecessarily wasted on honing a prototype that starts off a long way from what the business needs. Indeed, some Agile developments have turned into one extremely long prototyping process, with an end result never being reached. This is an expensive way to develop software.
So what is the ideal, and where is Business Process Management in relation to this? For some idealists, the best situation would be one where the business users can build the software tools they need for themselves, without having to rely on developers or analysts. Unfortunately, although programming languages are becoming simpler all the time, we are still light years away from them being abstracted enough for an end user to build their own software. Software development is still hard.
Nevertheless, BPM does go some way towards this ideal, and given the right scenario, it can successfully deliver valuable software in extremely short time scales. In a similar fashion to Agile, BPM relies on cutting out the middle man as much as possible, only this time the emphasis is on a strong partnership between the end user and the BA working on iterations towards the final software:
The reinstatement of the Business Analyst has several advantages:
Don't be tempted to think that this means developers are no longer required, however. The reality of BPM development is that it makes the working relationship between end user, BA, and developer much more symbiotic and productive, but does not make any of those roles redundant. BPM is a partnership approach to software development; on one hand between the end user and the BA, and on the other between the BA and the developer. The skills of a developer are very much still required to take a BPM system all the way to implementation. Where a business process calls for the integration of other systems, that integration work will almost certainly involve an interface built by a developer. And while the software that is generated by the BPM suite is good, it does still require some development to make it properly fit for purpose.
It would be foolhardy to suggest that the BPM approach is the right one in every software development scenario, but it is a formidable new challenger to other development methodologies. Later on in this chapter, we'll consider some of the scenarios where a BPM approach is the most appropriate.
The emergence of key technologies
Workflow software has been around since the early 90s, if not before. These systems were most often used in document management scenarios, where a document (for example, an insurance claim form) was passed between different departments as work was done on it. This worked well because the workflow system only had to maintain a pointer to the document in order to pass it down the process chain. Where things got more difficult was when the workflow system met other, task-specific systems.
Most mature processes involve the coordination of several systems. For example, we might have one system to record our insurance claim, another to work out what payment is due on the claim, and yet another to make the payment to the end customer. Before the advent of internet technologies, and specifically XML, it would have been a mammoth and fearsomely complicated task to integrate and tie together these task-specific systems and their proprietary programming languages and data formats within the context of a process. This was quite often attempted, however, and the result was usually a development and maintenance nightmare. More code ended up being written to handle the interfaces than was actually needed to process the work.
Thankfully, XML emerged from the internet revolution as a simple way for systems to talk to each other without them having to know about each other's proprietary data formats. Many task-specific systems now implement XML web services, making the task of integrating them into a process relatively simple.
As a result, business process management can certainly be viewed as a repackaging of the workflow software that was available in the 90s, but the reality is that those old tools could never have delivered the same value as BPM, because the technology landscape has fundamentally changed in the interim.
Meanwhile—management theory
The third leg of the tripod that has raised BPM up to its prominent position is the focus on process in management theory since the 1980s.
What is a business process and why do we want to manage it?
What do we mean by "business process"? We typically mean a collection of business activities that takes one or more kinds of input and creates an output that is of value to the business. It is the focus by management theorists on the elements of this definition that has led us to BPM. This quotation from W. Edwards Deming, founder of the quality movement, is illuminating:
"If you can't describe what you are doing as a process, you don't know what you're doing."
Any business process improvement project is an attempt to answer the fundamental question of "How do we organize our activities so that we can minimize inputs, maximize outputs, and maximize value?".
Business process improvement and re-engineering
There are several strands of management theory that are built around this fundamental question, and there are some striking examples where these theories have been effectively put into practice. Think of Jack Welch, who turned General Electric from a struggling manufacturing company to a highly profitable service-based company. Amongst other initiatives, this successful transformation can be attributed to radical business process re-engineering, and adoption of Six Sigma quality practices. Think too of Michael Dell, whose company of the same name changed the playing field of PC making and retail through a relentless focus on process improvement and ruthless process efficiency.
In business process re-engineering and improvement thinking, processes are viewed as organizational building blocks with as much (if not more) significance as functional areas and geographic territories. Business process re-engineering emerged in the 1980s with the idea that sometimes radical redesign and reorganization of these process building blocks was necessary to lower costs and increase the quality of service, and that IT was the key enabler for that radical change. The trouble with this radical approach is that it is too difficult to achieve in the real world. Mature organizations often simply cannot wipe the slate clean, and re-organize themselves without the instinctive memory of past processes and procedure creeping back in. Ultimately, business process re-engineering initiatives came to be viewed as nothing more than a cover up for downsizing efforts.
Business process improvement initiatives have been more successful, although they have been hampered by the lack of a comprehensive solution. Good-quality process design would be let down by sketchy IT support that couldn't be adapted. A business process would be designed around system constraints rather than systems doing exactly what the process required.
Nevertheless, many of the elements of business process improvement have proven to be useful and have not been discarded. Business process modeling has certainly increased businesses' ability to understand their operations and to make rational decisions about how best to organize their activities. Also, the definition and measurement of process metrics have given concrete, meaningful, and achievable targets for managers to work towards. The business is now more involved than ever before in the specification and delivery of IT programs.
From this convergence, BPM emerges
BPM is the final piece of the puzzle that allows business process initiatives to be fully successful. BPM espouses the incremental approach of business process improvement, but the IT delivery phase is supported by custom-designed tools that reduce the effect of requirements dissonance by allowing the delivery to be driven by the business.
In its simplest form, workflow software is generated from the process maps that are modeled by the Business Analyst. This workflow software is then the end user's "front end" to the process, and it controls the execution of the process in the live environment. Other software is then used to report on the operation of the process within the workflow software, allowing for dashboarding of key performance indicators. These dashboards can in turn be used to drive ongoing process improvement decisions.
Business process management isn't just one piece of software or one analysis technique: it is a suite of software, a framework of analysis techniques, and a defined project lifecycle. The Business Analyst, with their unique perspective on both business and technology, are in the happy position of having the right relationships and the right skill set to drive BPM initiatives in the enterprise.
Business process management: a definition
So now that we understand the background to BPM, it's about time we attempted a definition:
Note
Business Process Management involves the graphical modeling of a business process, from which workflow software can be generated, which in turn will control the live operation of the process, interacting with both humans and other applications. Further software measures the execution of the process in the live environment in order to permit ongoing analysis and iterative improvements.
Key benefits of BPM
The buzzwords and hype that are currently circulating around BPM are presenting serious barriers to adoption. What's needed is a clear expression of the benefits of BPM. BPM delivers efficiency, control, and agility to the business that implements it in the right way. These three key areas of promised benefit can be further broken down as:
