The Awesomeness of the Process

Hi,

It's been a while, but here's another blog post on IT Architecture and anything that comes close.
I remembered today while waiting on the train to go home, after a meeting in which we, a bunch of architects, came to the exact same conclusion as we've done several times in the past two or three weeks. Namely, it's all about the process if you want to do it right. Check my earlier posts and you'll find out that I actually think that the process is significant.

Anyways, I was waiting for the train and while reiterating what was said during that meeting and afterwards made me remember what one of my professors told us in either the 2nd or 3rd class on databases, or rather on Information Analysis:

"Always remember that you should only store in a database that what you want to get out".

Because we used NIAM as the modeling technology and this was in the earlier nineties, this made perfect sense because in those days reporting systems were the most important IT systems with SAP and BAAN dominating the ERP arena (I know I'm not doing any justice to either one of them) and NIAM is extremely about reporting. (Again, I know I'm not doing it any justice by stating it like this.)
Okay, so lets get back to our meeting today, well actually, let's get back to my opinion of processes. I'm honestly a big fan of Business Process Management, mainly because they define a business and they make IT worth our while... unless you love playing games because IT always makes computer games possible.

The main part about BPM are the processes. The interesting thing with processes is that they, when defined correctly do exactly define what the sequence of activities is to get something done, who is responsible for each single activity and who is accountable. And, and this is where it gets interesting in the context of this post, what is needed to start and do the activity and what the outcome is.
The beauty of this is that it allows you, if you keep this in mind, to ensure that any actor for any activity only gets the information she needs to perform her task. Especially in those activities where somebody needs to review, accept or verify something this is extremely valuable as it ensures that she is not overwhelmed with large complex documents.

I have worked in many organizations around the globe in a multitude of different verticals and markets. Always there was some sort of process in which one or more entities within the organization had to accept either a document, an architecture or some code if not an application that was to be put in production. The hardest part in these processes was to convince people that it was perfectly fine for them to receive more information than they needed and that you were relying on their expertise to filter out the information they were looking for. This because the document they were handed was a living document and as the process went on, it would grow and mature.

Of course this is complete bullshit, living documents don't exist and since they're written, or supposed to be written by a variety of people with different views and backgrounds the quality is poor at the best in most cases. But there're many reasons why we, including myself, are settling for the one big document. For one, it always does seem to be convenient. Just one document to be maintained, one template to be developed, one artifact to be communicated.

Then there is the reason that we're all very poor in defining requirements, even requirement engineers, so we find it very hard to define what we exactly need to do our job, how we need that delivered and in what format. So the document that holds everything is very suitable.

Working on a process and defining all activities,mother responsible and accountable actors as well as the input and output for every activity can be very boring or at least seem to be very academic. A paper exercise, and a since we all love the tangible, well all the sane people I know, we are easy to digress and move to the concrete with documents and diagrams. Letting go of the process and concentrate on the artifacts. Remember, we tend to fix problems in the infrastructure instead of the application, mainly because we can touch it and hold it and it is easy to budget and plan. Not because that's the best place to fix the problem.

This is more so for the managers of the departments that are impacted by such a process. When they're not aligned and don't define the areas of their responsibility and accountability, preferably without overlap and without gaps. Yup there's a challenge. It will be very hard to point out who is acting in what capacity during which activity.
Management buy-in is a prerequisite even to start working on the process. And with proper alignment of the management, it will become a simple as life exercise to define the process.

There is the problem of the man documents to be managed, or rather the many products to be managed. Some are input and some are output. But when you keep in mind that output always has to be input for some activity, you can state that there is always only input to be considered. But that brings with it, that you need a rock solid system for managing all these products. And no, a file-server or email system doesn't cut it. What you need, at the very very least is a collaboration platform that has document management in it, but preferably you have a Business Process engine that manages your process. In this context I don't mean a document management system that allows you to define a document flow. No sir, I mean a process engine that allows to attach products to the process.

Now forget about the bureaucratic formalities of a business process and documents and templates and responsibilities and accountability and actors and all that stuff. Instead think about your job. Your role in the organization you work for and the activities you're supposed to do. Wouldn't it be awesome if you would be provided with all the information and all as soon as somebody would ask you to do something? A situation in which you would know exactly what information you're supposed to dig up yourself to do your job and what information you need handed to you? At all times?
Well if your answer is "YES" than you want to experience the awesomeness of the process, because this is exactly what it is about.

And it's not just a hollow promise. No, it's something that comes out of the box when you define the process not based on the information that can be provided, but what has to be provided. When you ask the responsible person what he needs to complete an activity instead of just throw all you have at him and have her figuring it out herself.

One last thought on this topic before I conclude; You never define a process that is perfect, you perfect a process that is defined. So it is correct to think seriously about what the process should be and than adjust it as you apply it. Basically the idea behind Lean.

I hope you enjoyed reading this post and think you can benefit from it. Don't hesitate to comment. As always, different views paint a clearer picture.

Iwan