Back ... ... ... ... ... ... ... ... ... ... ... On Stream ... ... ... ... ... ... ... ... ... ... ... Forward

OntologyStream Inc.

Copyright: 2001

Agile Interoperable (AI) IDEF

The notions revealed in this White Paper were developed jointly by OSI and Intersect Technologies.

IDEF0 (process modeling) and IDEF1/1X (information/data modeling) are standard methodologies used by both the Federal Government and industry worldwide. Agile Interoperable IDEF is a concept created to integrate and utilize the benefits demonstrated by IDEF with other informational dimensions. AI-IDEF resolves the issues associated with quickly correlating IDEF objects and other information representations, specifically in circumstances where the context of model development dictates a high degree of maintenance actions.

The product is being developed in three phases:

1) An application that creates, modifies and maintains IDEF0 IDEF1X models

2) An application that opens a hyperlink-style information portal for each Active Object in the IDEF0 model

3) An application that provides Agile Interoperability to heterogeneous data sources related by, but not normally accessible from, the IDEF0 model.

IDEF is directed at modeling processes using a standard framework.

Figure 2: The standard life cycle for IDEF

The standard life cycle for IDEF (see Figure 2) produces an IDEF0 model depicting processes in a nested structured fashion. An IDEF1X relational diagram corresponds to a Entity Relationship Diagram (ERD) used sometimes to instantiate information into a relational database in Codd third normal form. The Objective World often represents a community's agreement as to business rules underlie the models.

A limitation of current IDEF0 practices is that additional information or alternative portrayals (which provide improved cross-functional understanding) are not correlated to IDEF objects, but must stand-alone.

A second limitation is that the world of natural processes is non-stationary and introduces novelty that exposes the ERD to fundamental design changes. A third limitation is that there is often not enough time to develop optimal IDEF0 models. A fourth limitation to the IDEF life cycle is that the community may have an intervening agreement about what the work process is that is not functional or that is based more on political issues as opposed to other types of functional issues.

Let us consider an abstract problem. Suppose that the X system is governed by the IDEF life cycle. Suppose also that the current X IDEF model shows business rules down to a program level and that there are 8273 such programs with average length of 725 lines. Each program, in theory, implements code that conforms to some part of the set of business rules.

In truth, the logic of business processes will deviate from the code. In one specific case, the X code took 30 years to evolve. During this period, there where often times in which design shortcuts where required by the contingencies of policy directed changes to the business rules. Part of the impacting contingency is the difficulty of updating an increasing complex relationship between older code and new code. The divergence between code and business logic now represents an intractable problem given known tools.

Suppose now that a 600-member team of specialists has been tasked to maintain the X System by developing a model. For the sake of this discussion, we will refer to this model as the "X Code Model". The body of the X Code Model is used to attempt to prove that transactions comply with a specific, and that auxiliary information and data resources are well formed and correct.

The challenge is not only in proving that the current X Code Model is well formed and correct. Continual change is introduced from Policy and Guidance authorities. In addition to reducing divergence between the code and the business logic, attempts are made to conform this business logic to what is intended by policy and guidance.

The X Code Model is produced by

1) reverse engineering application and

2) through discussions involving software engineers and specialists within the 600 member X team.

Figure 3 represents a view of the migration and update of IDEF models. The historical process (a, b, c) implemented code based in a three step process that starts with policy and guidance. To the degree necessary to keep the current X system operational, this historical process remains in place.

Process d was completed as an intermediate step whose final objective is to produce an IDEF0 model having active objects pointing to process logic, the programs that compute this process logic, and to other informational recourses. This intermediate step was accomplished primarily using a reverse engineering workbench. Some documentation of the code has been made that assist in the one to one correspondence between elements of the business logic seen in the IDEF model. A separate software tool accomplishes the production of IDEF models.

The relationship between the IDEF drawings and the collection of COBOL programs is managed by hand.

Figure 3: Current model of Process

Figure 3 represents a model of the current migration and update of IDEF models. Aside from unavoidable limitation of the standard IDEF practice, the model suffers from the complexity of the legacy system and the uncertainty of continuing alterations in business logic.

Figure 4: Desired next state model

Figure 4 depicts an idealized process whereby snapshots of the entire 6 million lines of COBOL code is encoded into a structural holonomy each day during a period of transition.

The archive deploys structural holonomy technology to compress the original data source (lines of COBOL code) into a data-warehouse.

To move a legacy system to this state we need the following milestones.

1) A transition process that has resulted in a provably complaint Code Generating IDEF Drawing Workbench.

2) A Code Generating IDEF Drawing Workbench that has demonstrated the prototyped ability to generate and maintain business logic and implementing code within a one-to-one correspondence.

3) A Code Generating IDEF Drawing Workbench that has demonstrated the ability to generate and maintain all business logic and implementing code in a one-to-one correspondence. (Equivalent to: prototype properly scaled and placed in an operational environment.)

4) During the transition a historical archive was created to give confidence that migration processes are reversible under the condition that the replacement system has a failure.

Given these milestones, one is ready to support the migration of centralized responsibility to the organization Q.

Figure 5: Final state of the system

The final state of the transition process leads to Q's control of implementation at distributed and situationally distinct systems. Q's responsibility is to implement policy and guidance and to preserve daily records of the entire state of many code generated IDEF0 drawing.

The real-world implications of the example given above include:

* Visible portrayals of process and data for improved cross-functional communication;

* One-stop shopping for information and reduction of database synchronization issues;

* Profiling of user-community needs so that information is pushed;

* Supply of information in the context of problem solution to approximate a knowledge system;

* Ability for user decision involvement allowing improved knowledge portrayals (a learning system).