Process Imple-Mentor

I've long been a True Believer in Process Driven Design (PDD)... and that's why I chose to work in the BPM arena. I truly believe that "The Process" should "Drive" most of the Application Development Efforts that are carried out on behalf of Businesses and Government Agencies.

My strong belief that PDD is "the way to go" stemmed largely from what I experienced while acting as a Technical Architect for a business that facilitates Loan Oriented interactions between Individuals, Private Companies and Federal Agencies... What transpires at that company was not unique, so rather than singling out the company by name I will refer to it as "QGC" (Quasi-Governmental Corporation).

QGC was (and is) doing a great job in accomplishing its mission, but developing and maintaining the software to support the mission was an ongoing herculean effort. The company had been in business for several years, and over time they had acquired a diverse mix of Mainframe applications, Java EE applications, and Packaged Applications to support the business. The business revolved around the Life-Cycle of Loans... Apply for Loan, Disburse Funds, Collect Payments, Arbitrate Disputes, etc.

All of QGC's "core" software in one way or another supported Loan Oriented Business Processes. Some applications directly supported the Borrowers, some applications supported Lenders, some applications supported Government Agencies. An underlying "System of Record" maintained the integrity of the Data common to all parties. Lots and lots of details spread over multiple systems... working together to implement the Processes of Applying for Loans, Disbursing Funds, Collecting Payments, etc.

QGC's "core" software assets functioned together as a finely-tuned machine... But that machine was incredibly hard to tune and it required a large team of highly skilled mechanics and technicians to keep the machine tuned and running well. Their business is not simple... but the complexity of the software was not proportionate to the complexity of the business.

I came to believe that there was one root problem with QGC's Software Architecture... The Business was centered on Process, but the Process Definitions were not central to the Software Architecture. The Software Architecture focused on specific audiences... Borrower, Lender, Agency. The code to implement the Processes of moving information between these Participants was scattered across Stored Procedures, cron jobs, daemons, etc.

The Process Definitions were not centrally managed... so any time we needed to change a Process (perhaps in response to a regulatory change), we'd have to comb through numerous systems to figure out "What Has To Change Where". Change is a very hard thing to accomplish when you have to track down a dozen programmers to figure out where a specific detail of a Process is implemented.

The Architectural approach towards Processes at QCG was one that I would now call "Process Implementation Through Discrete Integration". Build all of the Activities that are needed to perform a Process, and then use the most expedient technologies to Integrate each individual Activity with it's "neighboring" Activities. End result... the company has a Managed Business Process, but there are many "managers" and they are scattered all over the place and hard to coordinate (when the inevitable change is necessary).

My reaction to having to deal with the perils of this Integration focused Software Architecture was to loudly proclaim "There Must Be a Better Way!"

My search for a "Better Way" was timed perfectly: Service Oriented Architecture (SOA) was gaining mind-share, and the "Open" software technologies that had been spawned by "The Web" had ripened to the point where it was no longer necessary to build everything from scratch. The ability to build "Composite Service Oriented Applications" was finally at hand.

For me, the first key to PDD enlightenment was to start talking about "Services" instead of "Objects". In Business, you care about getting something done (getting a Service performed) more than you care about "Who" does it (the Service Provider). Objects are Service Providers, and should ideally be interchangeable... The Design Focus should be on the Services themselves.

The second key to PDD enlightenment was to surrender my creative freedom to the constraints of a Process Engine. To heck with preserving creativity and flexibility... As the saying goes: "Mussolini made the trains run on time in Italy", and process software absolutely positively must "run on time".

(Those of you who follow the above link will learn that Mussolini's claim was false, so I really shouldn't use it because it implies that claims by Process Engines are also false... but it's just such a great analogy (even though flawed) that I can't resist)

Those two keys, "Services" and "Process Engine", unlocked my awareness of "The Better Way" to architect process Software (and to implement Managed Business Processes). I'd arrived at the architectural approach for what's now commonly known as BPM (Business Process Management).

My belief in the value of BPM led me to quit my job and go to work for a BPM company, Lombardi Software. Lombardi's slogan is "Process Driven"... so the attraction was obvious (and they let me keep blogging).

Lombardi's BPM tools are great, and I'd hate to be without them... but from working with many clients on many BPM projects I've learned that tools, even great tools, are not enough. The Development Process is as important as the Tools, and the two must complement each other or the projects won't succeed.

The Process of Implementing a Process is equally as important as the Tools that you use to Implement a Processs.

Object-Oriented Design and Programming was as much about Philosphy and Mind Set as it was about OO Languages like SmallTalk, C++ and Java. Learning C++ and Java didn't make you an Object Oriented programmer, learning to "think in Objects" did. Process-Driven-Design is the same.

Those of us who develop Managed Processes will still build many of the same things that we've always built, but we are changing the way that we think about those things, and the way that we build them.

So that's why I keep sharing my thoughts about how to implement BPM solutions with developers... I want to help you start "thinking in Processes".