Autonomous vs embedded workflow - closing the gap

Workflow management systems define, track and manage business processes yet are differentiated through a multitude of approaches.  Two distinct categories or classifications, autonomous and embedded workflow, reside on either ends of the workflow scale, yet solutions are being developed which exist somewhere in the middle.  Mark Ehmke, managing director of Staffware SA discusses how autonomous and embedded workflows have evolved and analyses some of the solutions that have resulted from this evolution process.

Autonomous workflow originated from document management companies realising the need to route documents to individuals in order to assist in the completion of a business process. This resulted in the birth of departmental document routing.

Financial software system vendors also contributed to the development of autonomous workflow by automating financial functions such as proof of deliveries and procurement authorisations into business processes.

As soon as automated business processes were created, these needed to be integrated with other legacy applications, driving the need for a workflow co-ordinator or "glue" to bind the processes into a single co-ordinated solution. This resulted in the emergence of autonomous workflow products.

Operating independently of other application software (with the exception of database management systems and message queuing middleware), autonomous workflow solutions support different applications by accessing data through their own interfaces.   This independence allows for the flexible definition of business processes and for storing business rules and routing information separately to the participating applications. 

Following the 80/20 rule, 80% of development time of autonomous workflow is spent on integrating external applications and 20% of the time is spent on defining and deploying the workflow portion.

In parallel to the development of autonomous workflow, application vendors began embedding workflow components within their applications and providing graphical process definers, thus allowing their customers to store their business rules externally to the core product, but still to route work transparently through the vendor`s product set. Thus, applications such as ERP could justifiably claim to control a company`s business processes, provided the company had no aspirations to automate non-ERP processes.

This ensured that integration was no longer the issue, but gave rise to other problems.

The majority of embedded workflow functionality usually lies within the application suite as business processes are designed for the vendor`s products only.   These semi-open solutions offer proprietary interfaces for the integration of external systems such as office applications and messaging, but integration with external legacy applications is achieved with some difficulty, as usage outside of these proprietary environments is rare.   

In an attempt to solve this problem, many application vendors partnered with workflow vendors and requested to OEM their workflow functionality, which ultimately became "absorbed" into the product suite.  

Business processes are no longer internal within a company but are now deployed across a variety of delivery channels and partners, with the prime target being the Internet.  This has resulted in a demand for adaptable, browser-based workflow solutions that are scalable across both the front office and back office, with methods to drive front-end systems, such as Call Centres and CRM, and back-end systems, such as EAI and TP monitors.

This development could well spell the end of proprietary embedded workflows in an enterprise environment. In order to play in this new playground, standardised solutions have had to go one step further, with the workflow component within an application offering standardised interfaces for the integration of external applications, such as the Workflow Management Coalition`s (WfMC) Wf-XML and workflow application programming interface (WAPI) and EAI adapters. These interfaces offer workflow interoperability between independent workflow applications, acting as an over-arching end-to-end process automation mechanism between e-business participants.

A further development of enterprise workflow has seen the emergence of business processes being broken down into business objects or sub-processes, which are collectively stored within object repositories.  These are then embedded in the external or underlying application with business process management being handled from a higher, more strategic level.  This solution employs a combination of embedded and autonomous features to provide workflow functions that are intrinsic to the various applications.

In summary, the workflow industry offers many solutions for automating a company`s business processes, but it is important to understand that each implementation needs to be developed and designed around a specific set of processes.   This means that when considering a workflow solution, the surrounding factors need to be taken into consideration. For example, are your business processes contained within a single application or is enterprise integration required.