In a fairly recent article, Keith Swenson, Vice President of Research and Development at Fujitsu Computer Systems Corporation, explained why BPM is not Software Engineering. While I tend to agree with the article’s provocative title, especially if one were to rephrase it as “BPM is not just Software Engineering,” I disagree with most of the article’s content. Keith’s definition of “pure BPM” as a discipline “where a business person draws a diagram, and it is implemented without any need for Software Engineering” would be considered as naive if it were given by someone who is new to the field of BPM. But coming from an expert like Keith Swenson, it’s truly misleading.

Keith’s core argumentation is slightly confusing, hence I won’t go through it thoroughly. Instead, I’ll simply refer to its strongest point, which is an analogy drawn between BPM and the spreadsheet, which I first introduced in 2000, and later got published through BPM: The Third Wave, a book I (sort of) co-authored with Howard Smith and Peter Fingar. While I still believe in this analogy, it should not be used in the over-simplified manner that Kaith Swenson made use of in support of his argument. Much like BPM systems, spreadsheet editors such as Microsoft Excel are extremely powerful pieces of software, and their use in a mission-critical environment for transaction processing purposes actually requires a fair amount of software engineering.

Originally (in 1979), the first spreadsheet editor (VisiCalc, developed by Dan Bricklin and Bob Frankston) was conceived as a tool that would allow non-programmers to develop financial models and run them on a micro-computer. It worked, and the lives of countless accountants were changed (mostly for the best) ever since. Nevertheless, these spreadsheets remained ‘models,’ and could not be used in the context of automated transaction processing initially. While primitive import-export mechanisms were later developed between second-generation spreadsheet editors such as Lotus 1-2-3 and mini computers or mainframes in the 80’s, it’s only during the 90’s that spreadsheet editors were integrated with real-time transaction processing systems. This work was lead by the Excel team within Microsoft, with significant input from investment banking firms like Morgan Stanley, and largely contributed to make Microsoft Excel the tool it is today. Needless to say, making the financial model transactionally executable required quite a bit of software engineering, both on the part of the Microsoft engineers who developed the Visual Basic language to support the development of complex macros, and on the part of Morgan Stanley’s IT staff to integrate such macros with a variety of back-office systems and message buses like MQSeries or Rendezvous.

If we are to follow this analogy, Keith Swenson’s vision of BPM is one were business people develop non-executable models, or models that are executed without any kind of integration with transactional systems. Granted, many processes fall into this category (although I doubt that many of these are handled by Keith’s software), and email (as Keith pointed out) is a pretty good vehicle for automating them. In fact, it is ‘the’ vehicle that Process Square (a company acquired by Intalio a couple of weeks ago) is using, creating user workflow tasks directly into Microsoft Outlook or Lotus Notes via the SMTP protocol. Nevertheless, such processes (Financial Close, New Product Development) cannot be integrated with transactional systems without the use of a much more comprehensive Business Process Management System (BPMS), and the application of strict software engineering rules, for obviously good reasons. Said another way, BPM is not just Workflow, it’s Workflow plus EAI (Enterprise Application Integration), and the EAI component requires strong software engineering, whether legacy workflow vendors like it or not.

Contrary to what Keith claims, BPM is not for business people. Or to be more precise, it’s not ‘just’ for business people. There is no product, system, or technology that would allow business people to draw a process, click on a button, and have that diagram turned automatically into an executable process that would support end-user interactions and system-to-system transactions. Such a thing does not exist today, nor will it exist tomorrow, for a very simple reasons: business people do not want to use such a tool. They do not want to take on the responsibility of building and maintaining transactional systems, or transactional processes integrated with transactional systems. BPM (2.0) is for business people and technical people working together. It’s a way to bridge the gap between business and IT, not by getting rid of IT people, but by providing a common language, implemented by a common set of tools, that can be used both by business people and IT people, working toward the common goal of making businesses run better though better business processes.

To be fair, BPM actually reduces the need for software engineering, by providing layers of abstractions that reduce the need for custom software development. Less software to develop means less software engineering skills to deploy. Nevertheless, BPM does not reduce the need for engineering. In fact, it increases it. With power comes responsibility, and BPM systems can be very powerful. The kinds of processes that can be automated with next-generation BPM systems tend to be very complex, highly transactional, and clearly mission-critical. Without them, the business cannot run. Should your email system go down, employees will use the phone system instead, and your business will keep running. Should your BPM system go down, your business will stop. Period.

So while BPM reduces the need for traditional software engineering, it actually increases the need for a new kind of engineering, which I would refer to as Process Engineering, or Business Process Engineering. It’s a discipline that requires the development of new engineering skillsets, in a more disciplined way than has been done so far. And for it to be trusted on the long term, like any other engineering discipline, it requires the development and adoption of industry standards. And this is what’s at stake here.

We are witnessing the last stand of legacy workflow vendors resisting the consolidation and maturation of an industry which time has come. For serious buyers to seriously consider BPM as a viable business platform, BPM vendors must seriously grow up, and apply the engineering principles that allowed other industries like aerospace or semiconductor manufacturing to grow into mature ones. In fact, such a maturation process is not only required for the BPM industry, but for the enterprise software industry at large. Because making a change to a line of code is a lot easier than changing the design of an aircraft’s wing or changing the layout of a micro-chip, software engineering lost the discipline it acquired in the early days of mainframes (when changing a ‘line’ of code meant rewiring a computer, or at the very least punching holes in a new punchcard, and waiting for the results to come back a day or two later), and is tragically amateurish today when compared to other engineering disciplines. This has to change.

While businesses certainly do not have the resources to develop large teams of disciplined software engineers, best-in-class BPM vendors do, and should do so today. Along the way, companies and governments that are serious about their processes must develop the Business Process Engineering skills they will need to take advantage of next-generation BPM systems today, and for years to come. Engineering this evolutionary process is what Intalio is all about. Welcome to the world of Business Process Engineering, where business and IT work together to make the business world a better place!