First of all, what do all enterprise software products have in common, apart from being software? They claim to make life better for business folks. Clearly, something is not right or else this problem would have been solved ages ago. Many people that I keep running into call it the business IT disconnect; some say that the tradtional on-premise software delivery model has failed as it stretches the time-to-value for client organizations. Some blame it on technology and its inherent complexities. I think it’s a combination of multiple factors, but most importantly, it’s because IT and business aren’t on the same page. Very simply put, IT (including IT vendors) wants to make things better, whereas businesses just want stuff that works. In my opinion, the core of the problem is the inability to manage change (will dwell on this a bit more in due course)….
But have we been able to eliminate the really old stuff yet? Yes I am talking about mainframes. That fat ugly underbelly of IT environments the world over. Why not? Two reasons come to mind: firstly, many enterprise software vendors thrive on keeping the mainframes where they are, and it’s not in their interest to let go of this lucrative business; and secondly, organizations are scared. Of what you ask? Well, CHANGE. They are afraid that changing things will disrupt their business processes, which will negatively impact their business. And we don’t want that to happen, do we?
This brings us to the question of managing change. Everybody knows that managing change is essential in a business environment, many people make a living off it by helping organizations manage change and associated risks better. Putting this in perspective of software development, the biggest, scariest, and most in-your-face risk is building something that nobody wants. Or in business terms, not meeting business requirements. Even when projects meet their requirements they often run over budget and over schedule. The budget/schedule overrun problem is typical of waterfall style projects where everything is fixed in advance, and by the time you realise that meeting targets/deadlines isn’t feasible it’s already too late. Agile development methodologies promise to cut the elephant in bite-size pieces such that either you are on track, or you know how to get back on it. However, this doesn’t mean that Agile will solve all problems of the old order. Why? Because, what we’ve got here is a problem of human nature, speculation! Agile does help in reducing the magnitude of the errors, but can’t guarantee that there will be no errors whatsoever. However, it is the best we’ve got at this point.
Coming to the point of Business Process Management (BPM) and Agile development: first the basics or what these terms mean to me. At the heart of BPM is a high level abstraction of an organization, and it is the set of all business processes in that organization. Building on this abstraction, BPM enables end users to model, automate, and deploy business processes. Additionally it measures these processes against pre-defined performance indicators and reports on overall business performance. If coupled with business rules management systems and/or CEP systems it enables an organization to automate decision making to an extent.
Now is this really related to Agile development? It is, because the promise of BPM is business agility. Automated process instances are essentially multiple reusable software components acting in concert to provide a business service or implement a business process. But how is this related to agile application development? It is in a way. If organizations create reusable high level software components, which can be strung together to create various applications as required such that the applications thus created can be changed on the fly to suit dynamic business requirements, we get business agility in real terms. Agile teams in organizations should focus on creating such reusable components, which should then be made available to end users through the process modeler, to create/change their applications as they like. This is the ideal case, may never happen but who knows. However one thing that we already see happening is the use of BPM products to rapidly create and deploy customer facing applications with a high degree of participation from business users. Perhaps some day they’ll be able to create and deploy their own applications without IT involvement! This is more true for mid-market BPM offerings deployed in mid sized organizations than for large enterprises as there is no escaping red tape.
Bottom line: BPM is being used as an agile application development and deployment platform.