IDEF / IGOE

Goal

The technique serves a scoping decision: what falls inside the function, what stays outside and on what footing. A law, a directive, a piece of software, a supplier all become objects of the drawing, each in the place that carries its role.

Arrows carry constraints: "arrows do not represent flow or sequence", says FIPS 183, and the function receiving them is constrained by what is made available to it. The model buys governance and resources at the price of time, the order of the steps being read off the flowchart or off BPMN. The deliverable runs from the A-0 context diagram, a single box carrying the model's purpose and viewpoint, to the A0 decomposition and the node index.

You'll find more detail in our BPMN tutorial.

Usage

When to use it

• Bounding a function before a redesign: one box, four sides and the team agrees what goes in and what comes out.
• The question is what governs the work: laws, regulations, internal policies and contracts become drawn objects.
• The question is what resources the work: people, systems and suppliers appear beneath the function, structurally.
• An enterprise functional view to decompose: the node numbering holds traceability from one level to the next.

When not to use it

• The question is the sequence of steps and the hand-offs: there is no time axis here, take the flowchart.
• Two organisations exchange messages, or the model must run in an engine: take BPMN.
• The internal logic of one use case has to be pinned down, guarded branches and true concurrency: take the UML activity diagram.

Description

The box and its four sides

The box is a square-cornered rectangle in solid line, named with an active verb: "Run the monthly payroll" is a function, "Payroll" is a subject, and the standard refuses it. Its box number is written inside, in the lower right corner, from 1 to 6 and 0 on the context diagram. Arrow labels are noun phrases.

The four classes are defined by what the function does to them, and each belongs to a side. The input arrives from the left and is transformed or consumed. The control comes down on the top and specifies the conditions required for the outputs to be correct. The output leaves on the right. The mechanism rises from the bottom and supports the execution. Everything turns on one question: is the arrow consumed? Recorded hours are consumed by the payroll calculation, so they enter on the left; the AVS rate survives the payroll run and decides whether the result is correct, so it comes down on the top. Same shape on the page, opposite role. The same question sorts the mechanisms: the fiduciary performs the function without being consumed by it, and drawing it on the left is an error.

ICOM and IGOE: two sets of names, one geometry

Two vocabularies are in circulation, and it pays to know which belongs to whom. ICOM (Input, Control, Output, Mechanism) is FIPS 183's, so IDEF0's, and it is the BPM CBOK's. IGOE (Input, Guide, Output, Enabler) is Roger Burlton's, who renamed two classes for service processes: the guide describes when, why or how an activity happens, the enabler is the resource required to turn an input into an output. It is BABOK's vocabulary. The geometry is identical, four sides under two changed labels; the use differs, IGOE being drawn as a single box, the process in scope, at the front of a redesign, where IDEF0 decomposes over several levels.

The rules that hold the model up

The standard's most revealing rule is its shortest: every box carries at least one control and at least one output, inputs and mechanisms remaining optional. A function that consumes nothing, is still governed and still produces something is a legal box. The geometry is checkable: solid line, horizontal or vertical segments, bends as 90-degree arcs, ends touching the perimeter and attaching to a side, never to a corner. Outside the context diagram, a diagram holds three to six boxes: below that, the parent box did not need decomposing; above it, the level is wrong and the drawing takes on the cluttered look the BPM CBOK records as the failing of IDEF implementations.

The hierarchy is read off the node numbers, which carry no decimal point. That address makes the functional decomposition traceable, and the ICOM codes lock it: near the free end of a boundary arrow, C3 says this arrow is the third control, counting from the left, entering the parent box. The role of an arrow is relative to the function that receives it, a parent's control being able to be a child's input. The controls thus made visible are the organisation's business rules, and the model gives the inventory that business rules analysis takes up.

Running the model

1. Fix the purpose, the viewpoint and the context, before the first box. There is one viewpoint per model: two viewpoints produce two irreconcilable diagrams of the same function, and that is how a model drifts.
2. Draw the A-0 context diagram, a single box covering the whole scope, with the arrows that tie it to its environment. This is, in substance, Burlton's scope diagram and often the whole deliverable of an engagement.
3. Decompose into A0, three to six major sub-functions. That A0 diagram is the top of the model.
4. Detail each box: list everything orbiting the function, sort it by the four sides and check that the list covers the whole of the parent box.
5. Code the boundary arrows, which locks the correspondence between the child diagram and its parent box.

In a workshop, the scope diagram is built in one session with the redesign team: one box and you sweep the four sides. The discussion always hardens on the guides, because that is where the organisation discovers it does not agree on the rules that bind it.

What the notation expresses

A reader used to the other three process modelling notations starts by looking for the sequence, and the diagram hands them the inventory of what constrains the function and what performs it: constraints omit how and when, runs the title of one of the standard's annexes. The movement of data through a system, for its part, belongs to the data flow diagram.

AI considerations

Two uses hold. Classification: the raw list a workshop produces, everything orbiting the function, sorts into inputs, controls, outputs and mechanisms, which gives the session a version to argue with. Drafting the candidate controls from policies, regulations and contracts, because that is the side teams populate worst.

The consumption test cannot be delegated: knowing whether a thing is transformed by the function or governs it takes knowing how the business actually works, and the model rests on that distinction. A model asked about "the legal constraints on Swiss payroll" will return plausible article numbers and rates, out of date or wrong, and every control of legal origin is verified against its source. Purpose and viewpoint are stakeholder decisions.

Examples

The function Run the monthly payroll in a Swiss SME, box A1 of the payroll model. Every arrow belongs to one class only, decided by the consumption test.

The top side is the one to read. Six controls are named there, from four distinct orders: federal law for the Code of Obligations, the AVS/AI/APG rates and the LPP, a sector agreement for the CCT, a cantonal scale for the withholding tax, the individual agreement for the employment contract. A flowchart, a BPMN model or a UML activity diagram of the same function would all draw one box labelled "calculate the payroll" and consign those six sources to a comment, when they are precisely what the analysis exists to establish. The bottom side does the same for the resources: the function depends on an external supplier, the fiduciary, and that dependency reads as a fact of the model.

Visualizations

The geometry is the content. The side an arrow enters by is its role, so a mechanism arriving from the top would state something false and an arrow hooked to a corner would state nothing at all. The four sides are therefore distinguished visually, since the four roles are the whole point of the figure. The purpose and the viewpoint are written beneath the diagram, as the standard itself does, where they serve as its instructions for use. The node index is given as text, and it carries the hierarchy the diagrams only ever show one level at a time.

Cost

Tooling

A whiteboard is enough for the scope diagram, and that economy is a property of the technique: one box and four sides fit on a flipchart sheet, which is why the IGOE variant works in a workshop with people who never draw models. Generic drawing tools, Visio, diagrams.net or Lucidchart, carry IDEF0 stencils and produce correct diagrams; their contribution stops at the drawing, and the correspondence between a child's boundary arrow and the edge of its parent box then survives only in the author's head.

Enterprise modelling environments, ARIS or Sparx Enterprise Architect, hold the hierarchy, the node index and the ICOM codes as objects of a repository and absorb the renaming or the moving of a function without rework. The investment is justified as soon as the model passes two levels or has to outlive the engagement. Since the standard's rules are mechanically checkable, one capability is worth demanding of a tool: refusing a box with no control or no output and flagging an uncoded boundary arrow.

Sources

• NIST, FIPS PUB 183, Integration Definition for Function Modeling (IDEF0), 1993: the primary standard, carrying the box and arrow syntax, the four ICOM classes and the rules of the model.
• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.35 Process Modelling: IDEF notation and IGOE diagrams among the process modelling notations and the use of the technique for establishing scope.
• ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.6 IDEF: the ICOM vocabulary, the linking of processes across levels of detail and the acknowledged failing of its implementations.
• ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.2 Swim Lanes: swim lanes are a notational addition, not a distinct notation.
• Kathy A. Long, What is an IGOE?, Business Rules Journal, January 2012: the definitions of input, guide, output and enabler, adapted to service-sector processes.
• Paul Harmon, Deming, IT, and BPM IDEF0 Diagrams, BPTrends: the attribution of IGOE to Roger Burlton and its use as a scope diagram.