What is a process architecture ? My last post talked about a project manager tailoring a process or flexibly enacting a tailored process in a project. In this post I would like to zoom out and present how a typical process architecture looks like. Later I would share the litmus test that shows if your process architecture has been created correctly.

In a typical enterprise organization, the top layer in a process architecture consists of process elements. These are elements like roles, work products, activities that go on to constitute a process. These elements could belong to one or more commercial frameworks or could belong to different methodologies or frameworks. These could also include constitutional elements which the organization needs to define and declare in order to meet a internal or external control objective as part of regulatory or quality compliance.

The next layer would consist of process components that are fragments or clusters of related activities. These process components make it convenient to concentrate on specific aspects of a process. Depending on the business or compliancy objectives of the organization you could craft these components to achieve a certain result or describe a desired workflow. One or more components could be linked to create a larger component and eventually an end-to-end process.

Below the process element and process component layer you will have the process layer. This is where you will have the various sub-organizations or departments start crafting their processes in tandem with the software process engineering group. You would not only use elements from more than one packages but in all probability you will be working with other process authors in different time zones or geographical locations. This process layer also ensures that rather than relying on one monolithic process pushed by a vendor or consultant, teams can create processes drawing from different methodologies and process frameworks.

The next layer would make it convenient for the project management office to tailor the process for a category of projects. This domain layer makes it convenient for you to tailor processes for a technology or business domain. Some common examples I have seen in this layer are tailored processes for web applications or those for mobile applications. This domain specific tailoring makes it convenient for project managers to easily search and use processes in real projects. This takes us to the last and final layer, the engagement layer.

The engagement layer consists of processes that are tailored for a specific project. The project manager does not have to go any higher than the domain layer to look for a process that she can specialize for a project that is about to be initiated. Project managers already have their plate full with all the project start-up tasks and they don’t want any overhead associated with searching for and tailoring a process for their project. They want a tactical intuitive way to tailor a process for a project. If they end up spending more time than needed to prepare a process it is likely that this would end up costing more than the benefits accrued. So the litmus test for a successful process architecture is the time taken by a project manager to tailor and operationalize a process in a real project. The lower this transaction cost of tailoring and moving a process to enactment the higher marks you get for a well managed process architecture.

This entry was posted on Thursday, August 16th, 2007 at 7:19 pm and is filed under General, Processes & Methodologies. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.