Some thoughts on Agile software development and BPM

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)….

The software development landscape has changed a lot over the past few decades, or has it? Yes it has. A quick glance at the way programming languages have evolved will tell you how. We have moved on from hard to maintain bulky / monolithic applications written in low level languages to highly componentised, distributed applications (written in IDEs that take care of the dirty work for programmers) that we see today. Yes things have improved, it’s easier to be a programmer today than it was say 15-20 years ago. Those who are not from the JavaScript generation will know what I am talking about. But the aforementioned core problem still remains, as puzzling as ever. This is the good side of software development, with pretty pictures, slick interfaces etc etc….

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.

Advertisements

About ChanduSingh

I am an IT industry analyst with Ovum. The views expressed here are entirely mine, and do not reflect my employer's stance. On this blog I will talk about: IT buzzwords (such as Agile Development, BPM, cloud and so forth), events from around the globe (if I find the time), and movies.
This entry was posted in Things IT and tagged , , . Bookmark the permalink.

2 Responses to Some thoughts on Agile software development and BPM

  1. suryaatovum says:

    Touche! I agree with the premise. However, “If organizations create reusable high level software components, which can be strung together to create various applications as required…we get business agility in real terms” is a bit tricky. I think that there is a fine line between agility and insanity. Empowering the non-technical business user to reuse BPM components and create easy mashups is all fine, but it hasn’t really taken off in the enterprise context, where fault tolerance of applications is almost zero. Also, imagine an entire workforce creating random applications without the help of IT – isn’t that the nightmare of every IT administrator? I think the key here, as you mention later, is to better use “BPM products to rapidly create and deploy customer facing applications with a high degree of participation (not autonomy) from business users.”

    • ChanduSingh says:

      Thanks for sharing your thoughts Surya. I am not trying to say that development teams should be given a free-run. However, it’s well known that semi-autonomous, self managed development teams deliver better software faster. The whole concept of agile development is based on this – and agile development methodologies facilitate this transition. Developer skills is also an aspect that needs to be looked at – for agile to be successful, organizations need to invest in highly skilled developers who can work independetly.

      Again I can’t imagine business users creating apps for themselves all by themselves. They WILL NEED HELP. My point is simply that BPM tools can be used to dreastically reduce the time take to create and deploy web based customer facing applications.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s