RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Managing Rules (and Achieving Agility) with Business Process Management

While agility is inarguably a higher objective that nearly always pays dividends for IT, there is confusion in the industry about how to achieve it. Deconstructing business process management, to make sure you understand what you should expect, may get you to the finish line faster.

he pressure is on for IT to deliver applications that can change on a dime—evolving as quickly as the business evolves even in the face of uncertain requirements. To address these challenges, new programming models—such as extreme programming and iterative development—have emerged. The primary goal of these new models is the same: shorten development cycles with more constrained requirements and then enhance the requirements under the same model. At the same time, new technology architectures are emerging around the ideas of services and processes. Service-oriented architecture (SOA) and business process management (BPM) are gaining momentum as they too hold the promise of increased agility.

Unfortunately, in many cases, the promise of agility is not being delivered. In the face of reduced resources and an ever increasing backlog of requests, many IT organizations are struggling to keep their heads above water let alone deliver agility. The problem is not that developers aren't up to the task technically—it is that the most common application development (and enhancement) models don't work in the modern business environment.

Think about it. Traditional application models are built around gathering requirements from users, finalizing those requirements, implementing them, and then using a structured change order approach with structured release cycles to make adjustments. These models cannot succeed in an environment where business users:

  • Cannot define their requirements concretely—they change at a moment's notice (often not because the business user wants to change them, but because the business environment is forcing the change).
  • Want to change the system, even before it's deployed.
  • Request that things be changed out of regular cycles due to urgency.
  • Cannot afford the extra design time and planning to create more parameter-driven systems that would enable them to tweak the systems without requiring help from IT.
In fact, the biggest source of this tension is the increasing focus on "processes." Everyone seems to want systems that automate and improve business processes, whether embedded in traditional applications or as a custom system focused on one process area. But processes are frequently reactionary, and that's wherein the trouble lies.

Processes are inherently volatile. Most processes became part of the business environment not through careful planning, but in reaction to a need to get things done. Processes typically flow across systems, filling the gaps between them and the people in the company. And they change on a regular basis to address new customers and new business situations. Often those changes are not as simple, to a developer, as changing the fields returned from a database query. Instead, they may be about changing the order in which things are done and who does them. In fact, the focus on processes has given rise to the market area known as BPM.

BPM is one of those "TLAs" (three-letter acronyms) that mean different things to different people. Some people consider BPM to be purely a business approach—it's all about the business organizing around their key processes. Others consider it technology—software that enables processes to be modeled, automated, managed, and optimized. The reality is that BPM is actually a combination of both of these areas and one more: BPM represents a new way for IT to partner with business teams to deliver agile process applications. In other words, when properly utilized, BPM can help prevent issues involving changing requirements from the bulleted list above from negatively impacting your project. Understandably, this last point is the key to broad BPM success. And it's a key that has been largely ignored to date.

Some organizations gravitated to it through visionary leadership or luck and have been very successful, implementing lots of high-value processes that are highly adaptable. Others have implemented BPM under more traditional models of IT and business interaction and had project failures or limited success. And the effort to change has been as great, or greater, than with traditional applications. To understand the challenges, a closer look at BPM technology is required.

Editor's Note: The author is an employee of Ultimus, a vendor of business process management products. Information about Ultimus BPM is provided herein as an example of BPM benefits. We have selected this article for publication because we believe it to have objective technical merit.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date