The Era of Process-Centric Design

If you follow my postings, then you won't be surprised to learn that I think we are at the dawn of a new era in programming. As with all previous eras... nothing is really new, it's just a point in time where existing good ideas rapidly ascend to a pervasive level of acceptance.

We are at the dawn of the Process-Centric Era

During the Object-Oriented Era, encapsulation, polymorphism, inheritance and reuse were king.... all excellent ideas... But not enough to insure the creation of agile applications... applications that can easily be adapted to meet changing requirements.

Quite frankly, adapting to changing requirements is tough and unless you set some limits and constraints it's never going to get easier... and that's where Process-Centric design comes in.

On our desktops, most of the applications that we know and love are not process-centric. Our word processors, spreadsheets, paint programs and games are marvels of ad-hoc creation where our own whims and preferences guide composition rather than any pre-ordained process. The Object-Oriented paradigm was perfect for creating these sorts of applications, because the OO paradigm sets very few constraints on the developer. Imagination and creativity are the OO developers only limitations.

Imagination and creativity are wonderful things... but a huge percentage of the applications that the world needs are not concerned with creativity and imagination... they are concerned with implementing mundane processes.

Implementing processes within the guidelines OO paradigm is not by itself particularly difficult to do... but the flexibility of OO does not force the developer to implement the process in a manner that will make it relatively easy to modify the process in the future.

Processes constantly change. As businesses grow, as business conditions change, as the whims of the population at large ebb and flow... processes need to change, and the applications that implement the processes are often the limiting factor in how quickly the processes can change.

Get a group of Java EE architects in a room, not the R&D infrastructure and product guys, but the ones who build applications for business groups, and listen to their war stories. We all seem to have the same story about the project from hell which required each developer to know half a dozen diverse technologies to simply modify a screen... JSP or JSF (with embedded AJAX) on top of Struts (but we're migrating to Spring) on top of EJBs on top of a Relational DB (except for the part that uses Hibernate) and the use of JMS at one point and Web Services at another... And by all means don't forget the custom rules-engine and half-a-dozen XML-to-Java-to-SQL libraries.

We've all implemented scores of business processes, but we've implemented them as a loose confederation of somewhat related "point" applications that each implement some aspect of the process (with ad-hoc mechanisms for passing information and process flow), or we have implemented them as uber-monolithic behemoths that are a mess to maintain.

That's where the Process-Centric paradigm "comes to the rescue". It's not a general purpose paradigm, like OO, but it's just as significant. The Process-Centric paradigm imposes order. It is a domain-specific paradigm that first and foremost establishes the Process as the leader. A project may still incorporate diverse technologies, but those technologies have to comply to the dictates of a Process-Centric architecture. If you won't play by the rules, then you can't play.

In the Process-Centric paradigm the Process Definition is decoupled from the Activities that are brought together to implement the Process. Communication between the Process and the Activities, and between the Activities themselves, is through well defined message-oriented interfaces. In essence, the activities are implemented as Services (as in SOA)... but some of the Services are automated, and others are human-powered. Once in the realm of Service implementation, programmer imagination and creativity can once again assert themselves to perform the task in the optimum manner... as long as this creativity doesn't try to short-circuit the process framework.

The end-result should be truly process-centric implementations that are primed for the inevitable process level changes. The programmers do give up significant freedoms, but they end up with fewer hassles down the road, and probably a much improved relationship with their business colleagues.

Both Business and IT folks are tired of the status quo where each side feels besieged by the other... By our very natures there will always be a disconnect between the two sides (we're very different types of people) , but hopefully by introducing an intermediary that we both understand (the process definition) life in the Process-Centric era will be better for all of us.