The PIF Process Interchange Format and Framework

Jintae Lee, Gregg Yost and the PIF Working Group[1]
Version 1.0
December 22, 1994

Table of Contents
1. Abstract
2. Introduction
3. History and current status
4. PIF
5. Alphabetic Class Reference
6. Extending PIF
7. Appendix A: PIF Syntax
8. Appendix B: An Example PIF File
9. References

2. Introduction

More and more companies today are attempting to improve their business by engaging in some form of business process redesign (BPR). BPR focuses on a "process view" of a business and attempts to identify and describe an organization's business processes; evaluate the processes to identify problem areas; select or design new processes, possibly radically different from those currently in place; predict the effects of proposed process changes; define additional processes that will allow the organization to more readily measure its own effectiveness; and enact, manage and monitor the new processes. The goal is a leaner, more effective organization that has better insight into how it does business and how its business processes affect the organization's health. Successful BPR projects involve the cooperation of many people over extended time periods, including workplace analysts, systems engineers, and workers at all levels of the organization.

Computer applications that support one or more aspects of BPR are becoming increasingly common. Such applications include

Modeling tools that help a workplace analyst identify and describe an organization's processes.
Process library browsers that help organizations find new processes that might better meet their needs.
Process animators and simulators that help organizations visualize the effects of existing processes or potential new processes.
Workflow management tools that help workers follow business processes.
Outcomes analysis tools that help organizations monitor the effectiveness of their processes.

No single application supports all aspects of a BPR engagement, nor is it likely that such an application will ever exist. Furthermore, applications that do support more than one aspect rarely do them all well. For example, a workflow tool may also provide some process simulation capabilities, but those additional capabilities are unlikely to be on par with the best dedicated simulation applications. This is to be expected -- building an application that supports even one of these aspects well requires a great deal of specialized knowledge and experience.

Ideally, then, a BPR team would be able to pick a set of BPR-support applications that best suits their needs: a process modeling tool from one vendor, a simulator from another, a workflow manager from another, and so forth. Unfortunately, these applications currently have no way to interoperate. Each application typically has its own process representation (often undocumented), and many applications do not provide interfaces that would allow them to be easily integrated with other tools.

Our goal with the PIF project is to support the exchange of business process descriptions among different process representations. The PIF project supports sharing process descriptions through a description format called PIF (Process Interchange Format) that provides a bridge across different process representations. Tools interoperate by translating between their native format and PIF.

Any process description format, including PIF, is unlikely to ever completely suit the needs of all applications that make use of business process descriptions. Therefore, in addition to the PIF format, we have defined a framework around PIF that accommodates extensions to the standard PIF description classes. The framework includes a translation scheme called Partially Shared Views that attempts to maximize information sharing among groups that have extended PIF in different ways.

The PIF framework aims to support process translation such that:

Process descriptions can be automatically translated back and forth between PIF and other process representations with as little loss of meaning as possible. If translation cannot be done fully automatically, the human efforts needed to assist the translation should be minimized.
If a translator cannot translate part of a PIF process description to its target format, it should:
- Translate as much of the description as possible (and not, for example, simply issue an error message and give up)
- Represent any untranslatable parts in a way that lets a person understand the problem and complete the translation manually if desired
- Preserve any uninterpretable parts so that the translator can add them back to the process description when it is translated back into PIF.

These requirements on the translators are very important. We believe that a completely standardized process description format is premature and unrealistic at this point. Therefore, as mentioned earlier, we have provided ways for groups to extend PIF to better meet their individual needs. As a result, we expect that PIF translators will often encounter process descriptions written in PIF variants that they can only partially interpret. Translators must adopt conventions that ensure that items they cannot interpret are available for human inspection and are preserved for later use by other tools that are able to interpret them. Section 4 describes PIF's Partially Shared Views translation scheme, which we believe will greatly increase the degree to which PIF process descriptions can be shared.

The PIF Process Interchange Format and Framework

2. Introduction

3. History and Current Status