True Process Automation

At the DHA the framework is helping with efforts to align business models with IT development models. Brookes says the theory is that if they can create the right interfaces, changing just part of a process will lead to the automatic creation of an application development template.

"That will require a lot of resource, and a lot of detail, so we're not saying we'll be able to magically do it, but that's the peg in the ground. [If we can achieve it] that's pure alignment, because then you're automating that development part of it. Now there's a lot more to it, and that's taking a very simplistic view, but even if we get part of the way there, we're going to dramatically speed up that application development process," Brookes says.

"That whole process of IT change that many businesses go through, which is fairly costly, fairly time consuming, we can speed that up, and that's going to bring a lot of bonuses just by doing that."

In the meantime he says the DHA has learned that getting a handle on process is a process of discovery in itself.

"Most find that a lot of processes within an organisation are really implicit within that organisation," Brookes says. "We have a legacy systems architecture. Whenever they were installed there were probably good intentions, and it was all fairly well documented. But as time goes on, policies change, procedures change, and then those policies and procedures become ingrained within an organisation, and you then sort of don't have that visibility. You lose it, and you start doing things because that's the way it was always done.

When you really discover where all those processes are - and ask the question: 'Why are we doing that?' - you really can come up them with a set of processes that you know are essential, and you've really got justification for them," he says.

"You have a lot of quick wins just by that process of discovery and looking at where you have kinks in your processes," Brookes says.

Business Process Modelling Is Gaining Speed

SIDEBAR: Analyst View | By Carl Zetie, Forrester

The most important question to ask in selecting a business process modelling (BPM) tool is: What will you do after modelling?

In the past, BPM was often unfairly tagged as an abstract or esoteric discipline conducted by business analysts in pursuit of some higher goal: In the 1980s, for example, it was "quality improvement"; in the 1990s, "business process re-engineering". Today, BPM has a far more widespread role to play in many more enterprises. Increasingly, organisations are adopting business process modelling as a precursor to some other activity, such as business process integration. Pragmatically, BPM is now more widely understood as a means to an end, essentially as a higher-level model of some other activity, and that end goal will be critical in selecting the right tool.

The purest (and most traditional) use of a BPM tool is still by people who are "true" business analysts, sometimes with little or no IT knowledge. They build models of both the "as is" business flow and the "to be" business flow, largely or entirely free of implementation details in the IT sense (and at the highest level, even the assumption that a process is necessarily automated). The modeller works with line-of-business managers and others who understand the operation of the business to develop models not only of processes but also of assets, organisations, roles and hierarchies. The models are usually enriched with information about associated costs (both in time and money) to identify the value of potential improvements. Sometimes, the lowest level model that this person creates resembles the highest-level models of a traditional systems analyst, but not always. The purposes and objectives of this kind of modelling include identifying potential organisational efficiencies and modelling and testing potent ial cost savings.

The second use of BP models is as a precursor to some other, often IT-related, activity, to gain a better understanding of the true business requirements before embarking on implementation. One common objective of BPM in this sense is building higher-level models before embarking on design models; for example, in Unified Modelling Language (UML) use cases and essential class models. These users are really doing what used to be called systems analysis; many of the better tools for this purpose are direct descendants of former CASE tools.

Most recently, BP models have gained attention as a means to visualise application integration such as EAI and BPI. It is essential to understand integration flows at a business level before trying to automate them. BP models are often a more business-centric way to do so than the lower-level, more implementation-centric models often incorporated in the EAI tools, which are often more focused on the physical rather than the conceptual integration.

There is also growing interest in the promise of "automatically" transforming from BP models to application integration models and thence to implementation, and a number of proposed standards are emerging to support this aim. However, organisations should be very wary of any promise of totally automated transformations. Database administrators apply essential physical optimisations to the design before implementing the data model created by an analyst, and the same is true of business processes. Both the business analyst and the system designer have an essential role to play, but at least they increasingly have a common language.

Carl Zetie is a vice president and analyst in Forrester's Application Development & Infrastructure research group (US)