Enterprise level workflows require Enterprise level technologists.

All too often I hear fellow techies getting it wrong while implementing integration projects. We seem to try and immediately go after “the low hanging fruit” that is getting two or more systems to exchange data. Too bad that exchanging data has become the mundane part of an integration project, thanks to current standards. Techies and other project participants need to take a step back and work with the business owners to document the “as-is” workflows, data schemas, taxonomies, and all other boundary items to validate the business feasibility of implementing the workflow. There are way too many boundary items in many workflows that are not considered until the end of the project’s process. Let’s look at a simple example workflow in a picture, because we can.

An Accounts Payable department requests for IT to build some automation for on-boarding a new Vendor. This is what the IT department in conjunction with the AP department builds.

A new vendor gets added to you Vendor Management application. Some data is exchanged to the AP system. Some data entry happens in the AP system and is promoted to an active Vendor. A nightly cron (read: batch script) runs that sends the new active vendor information to the Enforcement application. AP is assures that the requirements are implemented. This is the end of the AP project.

However, the workflow continues because of previously built requirement. An exchange of data between the Vendor Management application and the Enforcement application was built by others in the IT department.

An automatic generic Policy is assigned to the new Vendor, as part of the new vendor rules in the Enforcement application. The problem is that the Vendor hasn’t finished the original contract and gets immediately flagged by the Enforcement application’s new default policy for underperforming in their SLA. The negative data gets sent to the Vendor Management application and alerts Sr. Management as to the negative performance of the new Vendor.

The project team that approved the project artifacts and built this integration missed some important steps. The integration/workflow designers missed a human/manual phase gate that is installed in the process at the #2 arrow. There is a wait task; an enforcment application administrator used to wait for a phone call from the Business Owner of the Vendor Management application for authorization to input the vendor into the Enforcement application with a specific custom Policy.

his is a simple example of how not watching the true enterprise workflow is dangerous. This happens in not just integration projects but also in content life cycle workflows. A piece of content can easily move to a published state without all the right people and groups being allowed to review the content. We all know that some content, when published, can become highly visible, to not just customers but regulators as well. So it is important to know, not just some, but all the rules and tasks of the complete workflow before process are computerized.