News Stay informed about the latest enterprise technology news and product updates.

Workflow and orchestration tools reduce risks, enforce corporate policy in business automation

The article explains what creating a workflow entails and how workflows streamline business processes and bring value to the organization. The article also includes specific examples of code involved in scripts versus workflows, and explains how workflows function as all-encompassing tools for the enterprise.

Guest Commentary
Workflow and orchestration tools reduce risks, enforce corporate policy in business automation
By David Kumhyr, Master Inventor and Engineer at IBM

The notion of workflow is a powerful but misunderstood concept. At its base level, a workflow is a formal definition of the steps required by a process and the sequence in which the steps occur.

Historically, all aspects of a process were manual, people-based activities. In the industrial era, machines began to automate parts of the process. Today, computers have the ability to automate both the steps and the sequencing of steps for workflows in the business world. In business today, the workflow designer has four goals: to define a business process, to encapsulate the data required by the process, to automate the process, and to enforce business operational control over the process.

Consider the origins of computerized workflow: mainframe operators stringing together jobs with languages as EXEC2, REXX, and JCL. Scripts and job-control languages became the solutions of choice because they allowed quick manipulation of the data between different systems. The IT staff understood the concepts of scripting and automation, so naturally, they were the pioneers of workflow automation in business.

But in 2004, scripting is no substitute for a formal workflow definition generated by workflow designers.

The steps involved in workflow definition.

A goal of workflow design is to enforce business operational control over the process. Unfortunately, this is a goal not met by programmers writing data-conversion scripts, especially when the data contains credit card numbers.

There are other problems when the IT shop drives workflow implementation:

  • The programmer of a script may not possess the necessary broad knowledge of the workflow definition. He may solve a point problem, but it can be limited by the programmer's view of the data and the tools he uses to construct the solution. Ad-hoc solutions are more likely to be imperfect, limited, and could violate the intent of the business process it was meant to automate.
  • The programmer may be eager to code a quick fix. The old joke, "You start coding, I'll find out what they want," typifies this problem.
  • The programmer assumes control over data and assets. The programmer's role in automating the process makes them a part of the process and gives them deep knowledge of the data. This subverts corporate control and creates privacy and disclosure risks to corporate data.
  • A programmer's view may lack sufficient abstraction to create general-purpose, reusable tools. Most programmers copy scripts from existing scripts then modify them for a single purpose. This approach lacks abstraction and dims the hope of reuse. It leads to cycles of rework to maintain slightly modified versions of existing tools.
  • Scripts lack deep integration; thus, they lack choreography with other business processes. The programmer becomes the de facto executor of corporate intent.
  • Workflow design tools exist that address these problems. The workflow designer defines a particular process and encapsulates the programmers' development effort. The programmers become business process consultants as they contribute routines and tasks to libraries managed by the workflow tools.

    The workflow designer can assemble a workflow by selecting reusable tasks stored in libraries. The entire assembly is subject to the constraints of established business policies. The tools offer source code control and versioning for the code and the workflow itself. Once created, it is the workflow orchestration engine that will execute the workflow as a job.

    Workflow Role in Enforcing Corporate Intent In Business Automation

    Previously we discussed the quite fundamental differences between scripting and workflows and the reasons that workflows are a superior business automation tool. The key factor is that workflows enforce businesses policies, where scripting may not.

    Some workflow tools support this directly. There is one in particular that ships with a set of defined workflow elements that the workflow designer can apply to a particular business process. Business process consultants can also contribute new workflow components and tasks to libraries managed by such tools. All of these sub units encapsulate the programmers' development effort.

    The assembly of a workflow by selecting reusable tasks in the workflow tool is subject to the constraints of established business policies. The output of this workflow development process is by default enforcing the business policies that are core to operation.

    So what does workflow mean to business? At the outset it means greater business agility and increased responsiveness, improved asset management and the ability to manage costs through code control and reuse and also by spending on resources as needed. These are reasons that are meaningful to the IT management team.

    However, deeper reasons for moving to workflow exist, those of service to the core business of business, not simply managing information, but putting that information to work to achieve business objectives.

    Key reasons that matter to the executive management are:

  • Business service management to monitor, integrate and manage business services to conform to the current strategy and objectives.
  • Orchestration to proactively identify problems, associate forecasted resource demand to manage operational load in real time.
  • Monitoring of business processes to ensure that the appropriate functions take precedence. (Possibly invoking immediate action to maximize revenue or minimize cost in near real time.)

    So for automation at this level where is the sale to be made? Who's pain is it? Who will drive the buy decision? Since workflow isn't an IT tool, but a "business control over IT tool," is a sales message focused on the IT buyer effective?

    Managing by policy

    We've seen the value that workflow technology brings to the business leaders. These reasons are the prime motivation for leaving the current programming model and moving to a new operational paradigm. They give executive management freedom from the dominion of IT and return domination of business process to the executives.

  • Greater direct control over business process
  • Direct reporting of deviation from business control

    What will workflow bring to the genesis of business and it's relationship with IT; coupled with utility computing?


    Here is some sample pseudo code that a typical IT Programmer would write if he were assigned the task of programming the code for the automated ticket check-in process for the ticket kiosk.

    Now you cannot blame him for the shortcomings of the system since he doesn't understand the task from a business process level; but simply as a process to automate with a set of hardware and input constraints.

    Pseudo code script


    verify terminal is operational

    verify blank ticket stock is loaded

    verify blank bag tag tape is loaded

    wait for customer loop

    identification swiped

    is it a valid type of identification

    validate identification

    check to see what flight the passenger is on

    allow passenger to select open seats

    ask how many bags

    if number of bags is less than or equal to total allowance

    print bag tags

    print boarding passes for correct seats

    end transaction

    end wait for customer loop


    Now what are some business process problems with the simple script that could be solved with workflow technology?

    In accepting an identification, does the business have a privacy policy in place? Is there a provision for notification to the user of the kiosk, some assurance that the credit information is not being used or stored for other purposes?

    No provision is made to check the status of the connecting flights that the user may have pending and make offers of alternates. Tying into the dispatch flow control of the airline could reroute the passenger earlier in the day to prevent a larger missed connection problem later in the day (or initiate flow control to spread the load for the days traffic).

    The passenger may be capable of meeting the FAA standards of sitting in an exit row. He could be assigned these seats.

    The passenger may exceed the baggage allowance on this leg he is checking in for but may meet the requirements of the overseas leg. How would this be resolved?

    If this operation were being addressed with workflow technology the workflow process builder would be creating the process with sub-components that encapsulated the business conditions within the units to address the constraints that legal and business operations place upon these operations.

  • Dig Deeper on Topics Archive

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.