I’m sitting in a meeting typing a blog.  Shoot me.  However, there is a discussion going on about how a process may flow differently depending on the level of information that may be made available. 

Earlier I described different levels of abstraction in workflow.  Recap: Business Unit View is high level-Unit-to-Unit.  Very document and message based.  Business Process View is mid level: items move from stage to stage based on conditions, and Work Step View, which is describable at the technical level (petri nets and workflow diagrams that techies tend to wrap themselves up in).

The problem comes when there are a set of steps that need to occur in a workflow where the workflow has Business Unit implications, but where one unit doesn’t want to expose the Process View details.  In other words, if group 1 sends a request to group 2, and then calls three weeks later asking about the status of the request, they shouldn’t get detailed information about the person in group 2 who is stuck.  In a B-to-B scenario, for example, a hospital may send an insurance claim to a payer, and then call up in a few days asking if the claim will be paid.  Should the payer respond that there is a data or systems issue, or should they respond in the generic: “we are working on it.  Should be done in 10 days.”

The latter is more useful to business. 

This only works if our systems allow for us to actually drive these levels of abstraction into our workflow execution systems.  Literally, an process should live within a “container” that provides information to external requesters.  That way, if the process changes within the container, or a particular step represents a process that is of strategic value, those process steps are not exposed.

It’s data hiding at the workflow level.  It’s useful.  It is uncommon.  Let’s fix this.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

One thought on “Workflow visibility: driving levels of abstraction into functional requirements”
  1. Levels of abstraction applied to a workflow for greater usefullness in business; like a scratch and sniff flow chart telling you when a flower is in full bloom. I appreciate this blog. thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *

9 − 8 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.