Among the holy grails of enterprise software is the ability for business analysts to write executable software via graphical process design tools. After all, analysts spend their waking hours analyzing business processes. Thus, who better than analysts to transform the wisdom thus grained directly into software?

Indeed, an overarching XP goal is to minimize friction between the business analyst and the developer, realizing that much bad software is written when the two fail to communicate. And what better way to reduce that friction than to erase the difference between analysis and implementation, and to allow the analyst to implement his or her ideas directly via appropriate tools?

Enterprise software vendors, in turn, tout "enabling the user" among the key features of their wares. Enabling often means giving end-users direct access to features that enable customized behavior of the software. Excel and Word macros pioneered this approach on the desktop, and one can argue that Visual Basic enables a skilled analyst to create and distribute fairly complex business applications in an enterprise.

More recently, business process management (BPM) emerged as a software discipline that promises analysts the ability to tinker with major building blocks of an enterprise software architecture. BPM tools often come with graphical "designers," allowing an end-user to tie together existing functionality in a workflow, each step invoking software components on the network based on conditions the analyst specifies.

In a recent blog entry, About BPM miracles and what you can expect in real life, Tom Baeyens, one of the creators of JBoss' Java-centric jBPL, dissects the relationship between analysis and implementation, and declares that the two are sufficiently different activities to warrant different development models.

For instance, business process modeling tools must employ process languages, something distinct from a general-purpose programming language:

Process languages have 2 key features which are not available in programming languages like Java: support for wait states to express long running executions and a graphical view of the execution flow. Process languages targeted at simplifying BPM automation should focus on those two key features and leverage plain programming languages for what they are good for. Looking at most process languages, the process constructs are mostly configurable versions of some API usage where the API offers more flexibility.

Analysis and implementation differ not only in the languages they use, but also in the way they approach a problem and distill insight into some artifact:

Analyzing means searching for the way things work. You're concerned with understanding the problem domain and describing it as good [sic] as possible. Creating an implementation means that you are creating an algorithm in terms of primitive constructs. Executable process languages provide a different set of primitive constructs than a plain programming language like Java.

Baeyens argues that many BPM vendors confuse analysis with implementation, and promise to deliver a solution that provides both. Understand the utility and limitation of each, by contrast, can yield a more realistic understanding of how BPM tools can help in enterprise development.

What's your experience with BPM tools and techniques? Have you used such tools in your projects, or are you planning to?