Originally developed and research funded by the US Air Force, Integration Definition, or IDEF, refers to a family of modelling languages that are used in the fields of system and software engineering. The key aim of IDEF was to devise a method for modelling data subsystems in a generic fashion; a way of sharing information and defining business processes between associated agencies and suppliers. The first language of this form, IDEF1, was initially concerned with data storage systems, and the ability to represent data regardless of how it is physically stored and used. Other IDEF languages were soon developed - 0, 1X, 2, 3 and 4 are considered developed in full (a further 10 exist no more than beyond initial definition), and focus on applying the same methodology to all aspects of business process modelling (BPM), such as business operations, functional modelling, and process flow descriptions.
Since the late 1960's, Douglas T. Ross had been developing a systems engineering and software engineering methodology called the Structured Analysis and Design Technique (SADT), with its intention being to describe a system as a hierarchy of functions. With backing from the US Air Force, this would eventually be formalized as IDEF0, a function modelling language capable of analyzing and communicating the functional perspective of system.
The methodology identifies the prime function, and displays it on the 'Top Level Context Diagram' using a standardized set of symbols. From this diagram, diagrams for lower level processes can be produced. The language is now established enough to be used by a wide variety of businesses and organisations to show data-flow and business process using precise and strictly defined diagrams and graphical notations.
These are several communicative concepts to be followed when creating an IDEF0 diagram:
• Diagrams based on simple box and arrow graphics. • English text labels to describe boxes and arrows and glossary and text to define the precise meanings of diagram elements. • The gradual exposition of detail featuring a hierarchical structure, with the major functions at the top and with successive levels of sub functions revealing well-bounded detail breakout. • A "node chart" that provides a quick index for locating details within the hierarchic structure of diagrams. • The limitation of detail to no more than six sub functions on each successive function.
Acting as a complement to IDEF0, the IDEF3 process description method records specific knowledge of behavioral aspects of a system or process.
- Process Flow Descriptions, to capture the relationships between actions within the context of a specific scenario.
-Object State Transition, to capture the description of the allowable states and conditions.
Whereas IDEF0 describes an idealized model of a system or process, an IDEF3 diagram provides a description of actual process flow within an organization or business, or the changes that occur to an object within that system. This method of knowledge capture is recorded in two different perspectives - users are able to create both process schematics and object schematics using the IDEF3 schematic symbols.
IDEF methodology is suitable for almost any form of business, and for anyone who needs to record enterprise architecture in a process driven manner.