Recently in Workflows Category

There is a lot of talk these days about SOA, Web services, and workflows.  What is fueling this conversation?  As an engineer, I don’t have the vantage point to answer this question; however, in their book Web Services Platform Architecture, Weerawarana et. al. point out that the primary motivation is capitalism.

As businesses strive to survive in increasingly aggressive markets, they have seen that profits go hand in hand with the processes used to produce goods and services.  This awareness has shown companies that they needs to A) understand, document, and automate their business processes, B) monitor and analyze them, and C) optimize their workflows to be as efficient as possible. 

The need that businesses have to understand their processes is followed closely by a necessity to automate them.  This demand is what is fueling the push at the IT level for Workflow Management Systems.  In order to help in-house development teams and ISVs fulfill this need, toolkits such as Windows Workflow Foundation (WWF) have arisen as have standards such as BPEL4WS which are designed to facilitate interoperability between systems built on such frameworks.

Comprehension and automation are only the beginnings.  Once companies have understood and computerized their workflows, they need to analyze them.  By timing, trending, and monitoring procedures, companies have the information, reports, and facts necessary to hypothesize and theorize about better methods that they can use to gain completive advantages and to be more profitable.  This leads to optimization of their processes. 

In order to do so, companies outsource their peripheral activities to partners.   By using contractors, previously weak and poor performing tasks are completed more quickly and efficiently.  This consolidation means that the optimized processes are completed faster, resulting in higher profits.  Peak efficiency through outsourcing means that automated processes must flow through inter-company boundaries. 

In this increasingly federated business environment, companies can no longer depend on isolated, homogeneous information systems; instead they must move to heterogeneous ones that make no assumptions about the implementation technology used by their partners.  To achieve this, everyone must agree upon standards that insure secure, reliable communication that achieves the necessary QoS.  SOA and Web services facilitate this which is why they’re being touted so heavily.

In my opinion, the names that software engineers use to describe their work is very important.  Whether they refers to a variable in source code, an operation of a service, a component in a system, or a some other "thing", names are paramount.  As IT professionals, a lot of our job is centered around communication.  If we aren't using the same words or ones that aptly describe the ideas they’re indented to, we aren't doing our jobs to the best of our abilities. 

As Rozanski and Woods point out in their excellent book Software Systems Architecture, names are "sticky."  For this reason, they should be chosen carefully.  When considering names by which to refer to things, it is best to see if the same idea already has a name; if it does, it should be used.  While this advice may seem obvious, it isn't always followed, making miscommunication inevitable.  The primary reason that I've seen for misnomers is ignorance.  If you don't know a widget is a widget, you'll call it a gizmo. 

In a effort to avoid this in the domain of workflow managment, I'd like to share a collection of terms that I compiled while reading Workflow Management by van der Aalst and van Hee and the Workflow Management Coalition's Workflow Management Coalition Terminology & Glossary (PDF).

The compiled glossary (PDF) can be found in my stash.