I was a bit of a PhiSci (that's Philosophy of Science) geek in college--having a double major in Physics and Philosophy will do that to you. One of the seminal works in the field is Thomas Kuhn's The Structure of Scientific Revolutions.
Kuhn theorized that great changes in science happen across transformational boundaries. Prior to a scientific revolution, practitioners of normal science work under an accepted paradigm, testing and validating the theories of that paradigm, until the theories begin to prove inadequate. What follows is revolutionary science, as forward-thinkers re-examine the holes and failures of the current paradigm and advance a new a paradigm to replace it. Eventually, the new paradigm assumes dominance as a paradigm shift occurs and normal science resumes under the new paradigm. While it may be cliche to call Business Process Management a "paradigm shift," as we enter the revolutionary phase of BPM growth, examining BPM through the lens of Kuhn's ideas can provide some insights into what the BPM revolution might look like.
Since the publication of Kuhn's book, the term "paradigm shift" has come to be used as short-hand for any transformational change from one way of thinking to another. The growth of Business Process Management certainly fits this model, and analysts, vendors and end-users are thinking of BPM in these terms: a Google search for "BPM Paradigm Shift" returns almost 20,000 results. And indeed, after decades of the "normal science" of traditional programming, the holes in the theory have started to become clear: a long requirements-design-code cycle that results in projects that are outdated the day they go live, unsatisfied business users who lack the tools to collaborate effectively with IT, an expensive lack of agility, business policies and procedures buried in unreadable code, etc.
With the emergence of BPM, we are beginning to practice "revolutionary science" and challenge the existing paradigm. When the BPM paradigm shift comes, the practitioners of traditional programming won't be able to see it. Kuhn viewed competing old and new paradigms as incommensurable, making it impossible to validate a new paradigm empirically from within the context of the old. The terms no longer equate.
The key concepts, theories and day-to-day activities the old paradigm no longer apply. The ideas of Copernicus, Galileo and Newton simply couldn't be explained under Ptolemaic or Aristotelian science. The concepts of General Relativity and Quantum Mechanics cannot be proved using Newtonian physics. There is no way to explain or justify the new paradigm from within the old, but because it solves problems better than the old approach, savvy scientists move to working under the new paradigm. Those that don't eventually just wither away. There are those who refuse to see the paradigm shift that BPM represents. They tie BPM products to traditional software development, assured that BPM is simply another tool that software developers can use to do the "normal science" of code-based engineering, a useful "model" that feeds the work still done in traditional development tools.
They use these traditional coding approaches to build their BPM tools, because they don't believe BPM can be powerful enough to build its own tools. But they are wrong. BPM is "revolutionary science." It represents not merely an improvement to our existing way of building business applications, but a true "paradigm shift" to a new approach. The old methods--requirements documents, design specifications, coding--no longer apply, in fact, they are incommensurable with everything that BPM represents.
The revolution of BPM will be led by those who understand that the game is irreversibly changing. It will be led by BPM tools that are themselves built using BPM technology and understand the building a business process is itself a business process that can be managed and automated. It will be led by those that understand the "normal science" of traditional development is broken beyond repair and that a true paradigm shift is required.