IDEONTM: An extensible ontology for designing, integrating, and managing collaborative distributed enterprises

  • Published on

  • View

  • Download


  • IDEON: An ExtensibleOntology for Designing,Integrating, and ManagingCollaborative DistributedEnterprisesAzad M. Madni,* Weiwen Lin, and Carla C. Madni

    Intelligent Systems Technology, Inc., 2800 28th Street, Suite 306, Santa Monica, CA 90405


    Received July 22, 2000; Accepted September 28, 2000


    An organizations ability to achieve and sustain competitive advantage in the face of continualchange depends, to a large extent, on the adaptability, interoperability, and maintainabilityof its enterprise management approach and supporting software implementation. In thisregard, the major challenges facing organizations are: (a) achieving seamless integration ofenterprise design, management and control processes and supporting applications; (b)ensuring interoperability between new and legacy business applications; and (c) adaptingbusiness strategies and ongoing operations to changes in the external and internal environ-ments. The latter requires integrated planning and execution of enterprise processes. This paperpresents IDEON, a unified, extensible enterprise ontology that has been designed in responseto these needs. Two specific applications of IDEON are presented along with the specificextensions for each application. 2001 John Wiley & Sons, Inc. Syst Eng 4, 3548, 2001


    Today, there are several information technology (IT)trends and market dynamics that are driving enterprisemanagement and control requirements. Among these isthe fact that IT is expanding from a back-office resource

    (e.g., manufacturing resource planning/enterprise re-source planning) to a front-office (e.g., sales force auto-mation, customer relationship management) enabler ofcompetitive advantage. Change, once viewed as a shortperiod of relative instability, is now a continuous proc-ess. At the same time, monolithic enterprises that totallyown all of the products, services, and channels requiredto serve a customer are rapidly being replaced by stra-tegic partnerships, virtual enterprises, and integratedvalue chains. The need to operate in a rapidly changing

    Regular Paper

    *Author to whom all correspondence should be addressed.

    Systems Engineering, Vol. 4, No. 1, 2001 2001 John Wiley & Sons, Inc.


  • business and technical environment is driving the needfor technology infrastructures and application architec-tures that are increasingly more flexible, interoperable,extensible, and maintainable. In the light of these dy-namics, an organizations ability to achieve and sustaina competitive advantage depends, to a large extent, onthe flexibility, interoperability, and maintainability ofits enterprise management and control capability. It isin this area that enterprise ontologies have the highestpayoff.

    Interest in ontologies has surged as researchers andsystem developers have become increasingly more in-terested in reusing and sharing knowledge across sys-tems (i.e., software applications). However, today thereis a major impediment to knowledge sharing given thatthe different systems use different concepts and termsfor describing domains [Schlenoff et al., 2000]. As aresult, it is difficult to take knowledge out of one system(e.g., a planner or process modeler) and use it in anothersystem (e.g., a workflow system).

    The foregoing problem can be alleviated by devel-oping ontologies that could be used as a foundation formultiple systems (e.g., planning system, workflow sys-tem). Such ontologies would ensure that the differentapplications shared a common terminology, which isthe essence of knowledge sharing and reuse. It is notsurprising, therefore, that the two major thrusts in on-tology research are the development of (a) reusableontologies that span multiple systems and (b) tools thatenable the merging of ontologies and/or translating oneto another. The former assures correct interpretation ofthe knowledge and facilitates the information creationand retrieval process. The latter assures knowledgesharing in a heterogeneous systems environment.

    But there is more to ontologies than successfulknowledge sharing and reuse. Ontologies fundamen-tally change the way in which systems are constructed.Today knowledge bases are created from scratch with-out focusing on sharing or reuse. As a result, it generallytakes much too long to create and verify the complete-ness and traceability of the knowledge contents. How-ever, with an ontology focus this can all change. Onecan envision a tomorrow in which ontologies in persist-ent, reusable form are used to effectively and compactlyorganize the knowledge content of databases. The bene-fits of this strategy are dramatic reduction in knowledgebase development time as well as the creation of robustand reliable knowledge bases from pre-existing, veri-fied components.

    It is this thinking that drove the creation of IDEON,a unified enterprise ontology specifically designed tosupport integrated planning and execution of enterpriseprocesses. While other enterprise ontologies have fo-cused on enterprise analysis and re-engineering,

    IDEON is focused on integrating and managing plan-ning and execution within collaborative distributed en-terprisesa key requirement for supply chainmanagement, command and control, collaborative sys-tems engineering, emergency management, and crisisaction planning and execution. IDEON has been suc-cessfully employed on two key applications which arepresented in this paper. The first application is crisisaction planning and execution. The key challenge onthis application was to create an ontology that supportedplan execution with replanning capabilities in the faceof change events. The second application is IntegratedProduct-Process Development (IPPD). The key chal-lenge on this application was to create an ontology thatwould support (a) the design and tailoring of systemsengineering processes from an IPPD and standardsperspective and (b) the execution and management ofcollaborative systems engineering processes in a dis-tributed environment. What is common to these appli-cations is the integration of model building activitiesand model-based execution capabilities. IDEON wascreated to support this class of problems with appropri-ate domain-specific extensions when needed.

    The outline of this paper is as follows. Section 2defines the term ontology and briefly presents thegoals and current themes in ontology research. Section3 reviews the major organizational ontologies in termsof their goals, scope, organizational components, andstatus. Section 4 presents the origins, objectives, andpayoffs of IDEON. Section 5 presents the key designconcepts underlying the development of IDEON. Sec-tion 6 presents and discusses the four complementaryIDEON perspectivesenterprise context view, the or-ganizational view, the process view, and the re-source/product view. Section 7 presents two specificapplications of IDEON: crisis action planning and exe-cution; and IPPD-enabled complex systems engineer-ing. For each application, specific IDEON extensionsare discussed. Section 8 summarizes the IDEON valueproposition for designing, integrating, and managingcollaborative distributed enterprises.


    The Webster dictionary [Woolf, 1981] defines an ontol-ogy as a particular theory about the nature of being orthe kinds of existents. Intelligent systems from thefield of computer science are responsible for formallyrepresenting these existents, whereas conceptualizationprovides the basis for formally representing a body ofknowledge. Conceptualization consists of a set of con-cepts (e.g., objects), their inter-relationships, as well asother relevant entities about which knowledge is being


  • expressed. Every knowledge model employs someform of conceptualization, implicit or explicit. An ex-plicit specification (or representation) of this conceptu-alization is called an ontology [Gruber, 1993].Formally, an ontology consists of a set of terms, theirdefinitions, and axioms that inter-relate them [Grunin-ger and Fox, 1995]. The set of terms is normally organ-ized as a taxonomy.

    From a domain perspective, an ontology is a formaldescription of the entities within a given domain: theproperties they possess, the relationships they partici-pate in, the constraints they are subject to, and thepatterns of behavior they exhibit. It provides a commonterminology that helps to capture key distinctionsamong concepts in different domains, which aid in thetranslation process. An ontology consists of a core andextensions to express information involving conceptsthat are not part of the core. The main idea behind a coreand extensions is not to clutter the core with everyconceivable concept that might be useful in specificapplications. Rather, the idea is to provide modularextensions to the core thereby allowing a user to tailorthe ontology to suit his/her application needs.

    Current goals of ontology research are to: (1) makeontologies sharable through common formalisms andtools; (2) develop ontology content (also called ontol-ogy design); (3) compare and translate ontologies; and(4) compose new ontologies from existing ones. Recentwork in ontology design spans ontologies that representgeneral world knowledge, domain-specific ontologies,and knowledge representation systems that embodyontological frameworks. The ontology engineeringcommunity agrees on the key benefits of integratingontologiessharing and reuse of knowledge. Makingontologies interoperable is highly useful but also chal-lenging. The key to achieving a reasonably high degreeof interoperability is to: (a) compare and contrast exist-ing ontologies to see how they represent the basic typesand aspects of knowledge; and (b) use the results of thisanalysis to identify and resolve the critical issues inintegrating the different ontologies.


    A number of ontologies for modeling organizationsexist in the ontology literature. While the design goalsof these various ontologies are quite different, each ofthem provides valuable insights for identifying andvalidating key enterprise concepts. The relevant organ-izational ontologies include: TOVE [Fox, Chionglo,and Fadel, 1992; Gruninger and Fox, 1995], KIF [Gene-sereth and Fikes, 1992], Enterprise Ontology [Uscholdet al., 1998], Open Information Model [Meta Data

    Coalition, 1999], and CIMOSA [Kosanke, 1995]. In thefollowing paragraphs, each of these ontologies is re-viewed with respect to the goals, scope, accomplish-ments/status, and organizational componentsaddressed.

    3.1. TOVE[]

    The Toronto Virtual Enterprise (TOVE) project is aproject at the Enterprise Integration Laboratory, Uni-versity of Toronto. The goal of TOVE is to construct adata model that is expressive enough to represent allaspects of enterprise knowledge at both the genericlevel and the application level. Specifically, the datamodel is intended to: (1) provide a shared terminologyfor the enterprise that each agent can jointly understandand use; (2) define the meaning of each term as pre-cisely and unambiguously as possible; (3) implementthe semantics in a set of axioms that enable TOVE toautomatically deduce the answer to many commonsense questions about the enterprise; and (4) define asymbology for depicting terms and concepts graphi-cally. Table I presents the concepts and their subclassrelations (subclasses) included in the TOVE ontology.

    The TOVE project was unique in that it employed aformal approach to ontology design and evaluation.First, ontology specialists collaborated closely withadministrative and engineering personnel from varioustypes of industrial firms (e.g., IBM, Canada; BHP Steel,Australia; Toyo Engineering, Japan) to identify specificproblems that arise in actual enterprises. Because theontology was expressed in KIF, it allowed automateddeduction. So analysis was done in terms of deducingfacts from the ontology represented in KIF. Specifically,the problems identified were used as a guide to create acomprehensive set of competency questions that anenterprise ontology should be able to answer. The com-petency questions identified were then used to guide theselection of concepts and relations that were includedin TOVE. Next, the competency questions and all con-cepts and axioms were formalized in first-order logic tocreate an initial version of the ontology. Finally, theformalized competency questions were used to validateand finalize TOVE.

    It should be noted that TOVE is not a single ontol-ogy, but a set of several individual ontologies that linksthe various logical parts of an enterprise model throughappropriate relations. These ontologies represent activi-ties, states (including time), products, organization, andactivity-based cost management. Within each of theseontologies, a number of hierarchical structures (two orthree levels deep) are used to represent clusters of


  • knowledge. Finally, axioms and relations are used tolink knowledge between the various clusters.

    The TOVE project employed a more formal ap-proach to ontology design than was used by the otherontologies described in this paper. Therefore, it is morerelevant than the others to this paper. There are, how-ever, some important gaps in the TOVE ontology,which may well be a result of the ambitious scope ofthe TOVE project.

    3.2. Knowledge Interchange Format[]

    The Knowledge Interchange Format (KIF) is an exam-ple of an ontology definition language. KIF providesfacilities for defining objects, functions, and relations.KIF, which has declarative semantics, is based on first-order predicate calculus. It provides for the repre-sentation of meta-knowledge and nonmonotonicreasoning rules. KIF could be legitimately consideredan ontology in that it does contain a certain view of theworld. While its representation is far from being at thelevel of detail of the other ontologies, KIF does axioma-tize microtheories of numbers, sets, and lists.

    3.3. Enterprise Ontology[]

    The Enterprise Ontology is an outcome of a project atthe University of Edinburgh, AIAI Institute. It has asimilar motivation as TOVE. Its goal is to obtain anenterprise-wide view of an organization which can thenbe used to provide a method and computer tools thathelp capture aspects of a business and analyze these toidentify and compare options for meeting the businessrequirements. The main motivation behind the Enter-prise Ontology is to facilitate enterprise design andanalysis by supporting communications among humansas opposed to machines. Table II presents the majorconcepts used in the Enterprise Ontology.

    Because the primary objective of this project was tofacilitate communications between humans, there wasless of an attempt to precisely formalize the concepts.In contrast to the TOVE, the semantics of many of theconcepts in the Enterprise Ontology are limited to thespecification of their superclass or the relations thatthey participate in, with no attempt at axiomatization.On the other hand, Enterprise Ontology developershave made a painstaking effort to specify the intendedmeaning of each term in a way that would enablenon-technical users to easily understand and agree onthe meaning of the different terms.

    The Enterprise Ontology researchers worked withIBM in the United Kingdom and Lloyds Register, onprojects where re-engineering was the focus. Given theless formal nature of this ontology (in comparison toTOVE), the Enterprise Ontology was successfully usedas a knowledge capture tool. Specifically, it was used tomediate the different intuitions of people on a re-engi-neering team.

    3.4. Open Information Model[]

    The Open Information Model (OIM) is a project spon-sored by Meta Data Coalition, a nonprofit consortiumof vendors and end-users whose goal is to provide avendor-neutral and technology-independent specifica-tion of enterprise meta-data. The goal of OIM, in par-ticular, is to define a meta-data specification in theapplication development and data warehousing do-mains. Its main uses are: modeling the structure, proc-esses, and rules of a business; designing and managingprocess libraries; animating and simulating businessprocesses; and interchanging business modeling infor-mation between tools and enterprise resource planningsystems. The major components of the OIM are: Analy-sis and Design Models, Objects and Components Mod-els, Database and Data Warehousing Models,Knowledge Management Models, and Business Engi-neering Models. Table III presents the major conceptsincluded in the Business Engineering Models compo-

    Table I. Toves Mini-Theory on Organization


  • nent of the OIM, which deals with the organizationalaspects of enterprise models. As shown in the table, theconcepts are subdivided into four major categories:Business Goals, Organizational Elements, BusinessProcesses, and Business Rules.

    The Open Information Model provides a somewhatodd mixture of organizational-level and system-levelconstructs. The design rationale is unclear and, despitethe attempt to precisely define the meaning of eachconcept, the concepts are not formally defined. Despitethese apparent shortcomings, Microsoft is backing thisproject. Consequently, the ontology used in the OIMneeds to be considered in a review of the literature.

    3.5. CIMOSA (Computer IntegratedManufacturing Open System Architecture)[]

    CIMOSA is a project sponsored by a number of Euro-pean ESPRIT projects. Its primary focus is to provide

    a framework for analyzing the evolving requirementsof an enterprise and translating these into a systemwhich enables and integrates the functions which matchthe requirements. In particular, it is intended to provideunambiguous terminology that could serve as a com-mon technical base for Computer Integrated Manufac-turing (CIM) users, CIM system developers, and CIMcomponent suppliers.

    The CIMOSA reference model is represented as acube, with the three dimensions being: generation ofviews, instantiation of building blocks, and derivationof models. CIMOSA also defines four different viewsfor building models: Function, Information, Resource,and Organization. These views are designed to allowthe user to work with a specific subset of model ele-ments, i.e., to reduce the complexity of the model byfocusing on one aspect of the model at a time. CIMOSAhas been used in the ESPRIT projects by independentorganizations, and by AMICE member organizations.A few CIMOSA related modeling tools have now be-come available. The CIMOSA constructs involved in

    Table II. Key Concepts in Enterprise Ontology

    Table III. OIM Model of Organization (Business Engineering)


  • the organizational view are organizational unit, organ-izational cell, authority, and responsibility.

    CIMOSA has limited expressiveness in support ofthe organizational view. In addition, its constructs arenot formalized to offer precise characterization. Despitethese deficiencies, the ontology used in CIMOSA hashigh visibility due to its use on a very large projectsponsored by the European community.

    3.6. Process Specification Language[]

    Process Specification Language (PSL) is an ongoingproject at the National Institute of Standards and Tech-nology. This project is concerned with the developmentof a neutral, standard language specification for proc-esses. PSL is intended to serve as an Interlingua forintegrating multiple process-related applicationsthroughout the manufacturing life cycle. As an inter-change language, PSL is unique due to the formalsemantics that underlie the language. The use of ex-plicit, unambiguous definitions in PSL enable informa-tion exchange without having to rely on hiddenassumptions or subjective mappings [Schlenoff et al.,2000]. The motivation for the PSL project was therecognition that manufacturing engineering and busi-ness software applications both use process informationbut in uniquely different ways. For example, processinformation is used by manufacturing process planning,production scheduling, product realization processmodeling, workflow control, and project managementapplications. However, the underlying process repre-sentation varies from one application to the next. Com-pounding the problem is the fact that the same termsused in different applications often mean differentthings. For example, in a conventional workflow sys-tem, a resource is primarily thought of as informationneeded to make the necessary decisions whereas in aprocess planning system, a resource is primarilythought of as a person or a machine. Integrating thesetwo systems can produce nothing but confusion, if onewere to ignore the differences in semantics of theseapplications when translating to a neutral standard. ThePSL project directly attacks this problem.

    3.7. Other Relevant Ontologies

    Two additional ontologies developed for very specificapplications are worth mentioning because they containcertain relevant concepts. These are CYC [Lenat,1995], which was developed for creating a commonsense knowledge base, and PLINIUS [van der Vet andMars, 1993], which was developed for use in ceramicsresearch.


    IDEON is a unified enterprise ontology that provides acommon foundation for designing, reinventing, manag-ing, and controlling collaborative, distributed enter-prises [Madni and Lin, 19971998; Madni, Madni, andLin, 1998]. It consists of: (a) a set of business objectsthat represent common entities within an enterprisecontext; (b) relations that link these objects in specificways to establish business configurations; and (c) busi-ness rules that govern the behavior of various businessconfigurations. The design of IDEON was inspired bythe recognition that a conceptually unified ontology canmake: (a) enterprise applications development morestraightforward; (b) enterprise integration more sys-tematic; (c) enterprise process management more effec-tive; and (d) enterprise software maintenance muchsimpler. IDEON is readily extensible to vertical appli-cation domains. IDEON is compliant with the NISTProcess Specification Language (PSL) [Schlenoff et al.,2000] requirements and can be directly mapped topopular implementation models such as CORBA IDLs,KIF, and DCOM. IDEON-based systems can poten-tially provide several benefits including:

    a. Promoting common understanding between sys-tem developers and users of enterprise manage-ment applications.

    b. Providing users with requested information aboutthe enterprise and its environment.

    c. Answering complex queries by navigating appro-priate links.

    d. Supporting different types of analyses such assyntactic correctness checking, Activity-BasedCosting (ABC), Critical Path Analysis (CPA),inter-process mismatch analysis, enterprise-process mismatch analysis, and requirementtracking.

    e. Supporting process streamlining as well as organ-izational and process reengineering.

    f. Guiding enterprise application integration.g. Providing decision support in virtual/traditional

    enterprise integration, resource planning, re-quirement/performance review, and process con-trol.

    h. Supporting collaborative work, adaptive work-flow execution, progress tracking, and automatedor mixed-initiative process management.


    IDEON is based on the following four high-level designconcepts that collectively satisfy the requirements of a


  • flexible, interoperable, and maintainable enterprisemanagement and control solution:

    1. Neutrality. Since IDEON is an ontology (i.e., itdescribes concepts and their inter-relationships),it is notation-independent and implementation-neutral. In this paper, IDEON is represented asan object-oriented model using the Unified Mod-eling Language (UML) notation. IDEON canalso be represented as CORBA IDLs (an inter-face definition language from the Object Man-agement Group), or in Knowledge InterchangeFormat (KIF), or any other modeling languagenotation.

    2. Extensibility. The IDEON core is readily exten-sible to various application domains such asproduct design, manufacturing, health care, fi-nancial services, and military command and con-trol. The IDEON core also provides the basis forestablishing compatibility with other relevant en-terprise ontologies that address one or more spe-cific aspects of an enterprise.

    3. Complementarity. IDEON is based on the recog-nition that multiple complementary enterpriseperspectives are needed to model the variousaspects of an enterprise and to understand, de-sign, manage, and control enterprise operations.

    4. Interoperability. IDEON is designed to interop-erate with other special-purpose enterprise proc-ess or plan ontologies and modeling notations.


    IDEON employs four complementary perspectives (orviews) to capture the key concepts and relationshipsthat characterize an enterprise. Each perspective is de-scribed below.

    6.1. Enterprise Context View

    The enterprise context view (Fig. 1) represents theinteraction between an enterprise and its external envi-ronment. In this view, an Environment is composedof multiple related Enterprises. Enterprise has threespecial relationships with other organizations: Part-nerOrganization, Customer, and CompetingOrganiza-tion. Allowing these three objects to inherit attributesand relationships from the Enterprise class enables thedevelopment of a detailed model of the external organi-zations. This feature makes it easier to study the impactof changes in other organizations and makes it easier toform virtual enterprises dynamically. This repre-sentation allows us to study the behavior of a virtualenterprise (i.e., an enterprise which is composed ofseveral cooperating organizations that come togetherover a finite time window to accomplish an objective).However, this representation does not mandate a de-tailed model of each subject. The importance of eachsubject and the available knowledge should be used todecide the level of modeling detail. This representationalso makes it possible to combine multiple models intoan aggregate model that can be analyzed and controlled.

    Each Enterprise (organization) employs sensors toobserve the Environment. The observed information

    Figure 1. IDEON ontologyenterprise context view.


  • (e.g., customer survey, customer analysis) is used by theenterprise to assess the state of the Environment.

    Based on the Assessment of the Environment (con-text), the Enterprise can perform certain processes/op-erations (e.g., develop new product) with the goal ofachieving a specific effect on the Environment (e.g.,increase market share). It should be noted that mostsuch operations can be expected to have an impact onthe Enterprise itself as well as on other organizations.In certain special cases, the operation of an Enterprisemay only have internal impact without any externallyobservable effect. This observerespond cycle contin-ues indefinitely in the life of an enterprise until theenterprise ceases to exist.

    6.2. Enterprise Organizational View

    The enterprise organizational view (Fig. 2) is a struc-tural view of the enterprise which complements theenterprise context view. An Enterprise may be com-posed of multiple, smaller sub-Enterprises with poten-tially the same structure as the parent Enterprise. Thisrecursive definition of Enterprise allows the study of anorganization at any level using the same analysis ap-proach. Each Enterprise has specific Goals to accom-plish in a particular environment (e.g., manufacturing).Based on the Assessment about a particular environ-ment, an Enterprise could adopt/set up the right Strate-gies to achieve its Goals. These strategies areimplemented through the selection, sequencing, andexecution of appropriate Processes that collectivelyachieve detailed Objectives that are sub-goals of theoriginal Goals. To perform these Processes, an Enter-prise must own or have access to appropriate Resources,which may require collaboration with another enter-prise.

    There are several relationships that are possible be-tween Enterprises. A Single Enterprise may consist ofseveral smaller organizations. This parentchild rela-tionship may occur recursively to form an Enterprisedecomposition hierarchy. Two organizations may besibling Enterprises under the same parent. In this case,they do not operate independently, but cooperate toachieve their goals. This cooperation is modeledthrough relationships in the Process.

    A common way of representing inter-departmentalcoordination is through a cross-functional process map[Rummler and Brache, 1995] in which the rows are thevarious individuals, departments, or organizations, andthe process representation runs from left to right withexplicit representation of coordination relationshipsamong activities across swim lanes. This is an impor-tant representation because most process improvementsare the result of improvements in inter-departmentalcollaboration. A key task for an executive/manager isthe management of the white space between thedepartments under his/her purview. Therefore, it is es-sential to model and analyze the interfaces between andamong departments. This map also shows the internalcustomers of an organization, which is especially im-portant for those organizations that are responsible forenabling processes that do not contribute directly tothe business goals of the parent Enterprise.

    Each Enterprise owns one or more Resources and ismanaged by exactly one Person (a special case of Re-source). This one-manager link is useful for organiza-tion charts showing the reporting structure within anorganization and for supporting implicit approvalprocesses.

    An Enterprise has one or more business Objectivesto achieve through its operations. Associated with eachbusiness Objective is a metric for evaluating achieve-ment or progress. An organization achieves its business

    Figure 2. IDEON ontologyenterprise organizational view.


  • Objectives by providing value to its customer Enter-prises (e.g., an external organization in the Environ-ment, or an internal sub-organization in the sameenterprise). The value can be in the form of a productsold or services performed.

    6.3. Process View

    The process view (Fig. 3) represents the (re)planning-executioncontrol cycle. A Process is a sequence ofactions that is taken to achieve a particular Objective.There is one organization (Enterprise) that is responsi-ble for each Process. A Process can be triggered by aparticular Event. An intelligent process may be able tomodify itself upon the receipt of certain event notifica-tions. The execution of a process may be constrained byone or more Conditions. For example, a die-castingprocess cannot start until the temperature indicated bygauge-1 is higher than 200 degrees.

    A Condition is represented by a logical expressionthat is defined in terms of entities in the system. AnEvent is defined as a change in the state(s) of entities inthe system. A Composite Event is defined as a logicalcombination of other events.

    A Process may be related to another Process throughcausal/temporal dependency relationships. For exam-ple, the shipping process cannot be started before themanufacture process has been completed. A Processcan also be related to another Process through thespecialization relationship. For example, the ISTI soft-ware development process is a specialization of the ge-neric software development process. This is importantfor indexing processes and for searching a process

    knowledge base for a particular process. A Process canbe further classified into three types: planning process,plan, and activity.

    The PlanningProcess is responsible for controllingthe entire plan execution and replanning cycle. To thisend, it is important for an enterprise to choose the rightstrategy with a set of processes (plans) for achieving theGoal. This does not happen automatically. An enterprisemust implement an agile planning process that knowshow to react to any type of event and can control theenterprise such that it stays on course.

    The Plan created by an enterprise can either be asequence of executable activities (operations), or ahigh-level plan consisting of several lower level plans(i.e., sub-plans) that are assigned to sub-organizationsof that enterprise. In the latter case, the assigned sub-organization can perform further planning to decom-pose the sub-plan into executable activities.

    An executable Activity is a unit of work that cannotbe further decomposed in the model. During execution,an activity is performed by one or more human re-sources with material resources (e.g., aircraft) used astools, inputs, or references. As a result of the executionof an activity, resources can be created, deleted, orfurther modified. The execution of an activity could alsoresult in a change in the state of the external environ-ment.

    6.4. Resource/Product View

    The resource view (Fig. 4) elaborates on the varioustypes of resources that might be needed to execute aprocess. A Resource can also be the product of a proc-

    Figure 3. IDEON ontologyprocess view.


  • ess. Resources can be classified into Human Resourcesand Material Resources. A HumanResource can beclassified into a Role or a Person. A Role containsinformation about a particular position, e.g., the quali-fication, responsibility, and authorization. Role will beused in most process definitions, but one or more Per-sons have to be assigned to each role before the processcan be executed. A Role can be assigned to one or morePersons and a Person can be assigned one or moreRoles. A MaterialResource can be further classified intoeither an InformationProduct or a PhysicalMaterial.This is an important distinction because an Informa-tionProduct can be directly controlled by a processmanagement system while a physical material cannot.

    An enterprises products are a subset of all the out-puts from the enterprises processes. A product can bea physical product that can be sold to the customers, adocument, a service to the customers, an executableprocess (or skeletal plan), or a new information system.A Resource object is a resource already owned by anenterprise (to execute processes), or created by a proc-ess in that enterprise. A non-human resource (i.e., ma-terial resource) created by a process can be a product ofthat enterprise. Similarly, a trained human (i.e., a humanresource) is the product of a training process. A product(material resource) may consist of product components.In such case, the product components are identified in

    the product breakdown structure (or, Bill Of Materialin a manufacturing environment).


    IDEON has been used to support multiple enterpriseapplications. Two such successful applications include:Crisis Action Planning and Execution; and IntegratedProduct-Process Development (IPPD)-enabled systemsengineering. Each application is discussed next.

    7.1. A Process-Centric Crisis ActionPlanning and Execution System

    Crisis Action Planning and Execution is a complexprocess that spans situation awareness, execution plan-ning, and execution [USPACOM, 1993]. Crisis ActionPlanning and Execution is a special class of C2 proc-esses that encompasses both warfighting operations aswell as operations other than war. The typical charac-teristics of a crisis action planning and execution opera-tion include:

    Multiple stakeholders with different win-con-ditions that can be in conflict

    Decisions that must be made in the presence ofuncertainty and ambiguity

    Figure 4. IDEON ontologyresource/product view.


  • ObserveOrientDecideAct (OODA) cycletime is a key determinant of success

    A sparse database of past incidents to draw upon

    Crisis management teams face several challenges, notthe least of which is the need to shrink the cycle timefrom the recognition of a crisis event to the accomplish-ment of the mission. In large part, this means being ableto compress the execution and replanning cycle. Toachieve this overarching objective, crisis managementteams need to (a) have the necessary information at theirfingertips at the right time; (b) maintain a high degreeof situation awareness and concentrate on high-leveltasks (i.e., to be offloaded from low-level/routinetasks); (c) be able to try out different scenarios andquick change their overall process or plan in responseto certain key events; (d) be able to visualize the exe-cuting plan from different perspectives and drill-down to more detailed levels if necessary; (e) be ableto coordinate and collaborate with other stakeholdersrapidly and easily whenever the need arises; and (f)seamlessly transition from collaborative (i.e., human-in-the-loop) replanning to automated execution, andvice versa.

    For this application, IDEON provided the underly-ing framework consisting of key business objects,their relationships and attributes [Madni and Gayton,1999]. This conceptual framework was used to: (a)create an online catalog of component processes in-

    volved in creating a crises response package; (b) com-pose a crisis response to a specific crisis based on thesecomponent processes and their specific tailoring to thecrisis at hand; and (c) managing the crisis over the Webusing the composed model as a reference or guideduring the conduct of a crisis operation. During execu-tion, the system is capable of interactively/automat-ically adapting the flow, work allocation, and personnelassignments in response to contingency events.

    The system concept for an IDEON-based distributedcrisis action planning and execution system is shown inFigure 5. Central to this system concept are the capa-bilities for (a) process design and (b) intelligent processmanagement. These capabilities are based on our coreontology for integrated product-process development[Madni, Madni, and McCoy, 1998]. The process designcapability allows process engineers/human planners to:(1) design/author processes/plans; (2) verify proc-ess/plan correctness with respect to completeness andconsistency and store verified processes/plans in a Cri-sis Action Planning and Execution (CAPE) Assets Li-brary; (3) analyze processes/plans in terms of theirresource requirements, cycle times and cost; (4) stream-line/simplify processes/plans to eliminate redundanciesand extraneous handoffs; and (5) re-engineer proc-esses/plans to exploit promising new C2-related infor-mation technologies.

    The intelligent process manager enables and over-sees plan execution, invokes the various applications

    CAPE: Crisis ActionPlanning andExecutionIPM Component

    replanningProcessModeler orPlanner


    3 -Party Applications(e.g. geospatial force

    planning, force management)




    CAPE AssetsLibrary



    Execution Audit Trailand Potential Plan



    incomingexternal data

    Client Workstation(Collaboration Option)


    Intelligent ProcessManager

    plan adjustments/repair replanning


    Figure 5. IDEON-based crisis action planning and execution system.


  • that support the executing plan, and accesses data re-quired for plan execution. The IPM is not only proc-ess-aware but also situation-aware in that it canrecognize and respond to key external or internalevents. This response can range from automatic planexecution adjustment, to plan repair (e.g., replacing aninvalid component with a valid one from the proc-ess/plan asset library), to execution support during col-laborative replanning after handoff to a virtualcollaboration environment.

    IDEON Extensions for Crisis Action Planning andExecution. IDEON customization for this applicationconsisted of: introducing the concept of a plan, whichis defined as (a) the output or product of a planningprocess and (b) an executable process instance. Thespecific interpretation is based on usage. In other words,usage context determines whether the plan is viewed asan output or product, or whether it is viewed as anexecutable process instance. The same type of distinc-tion is made when defining the status of a plan. Whena plan is viewed as a product, its status takes on valuessuch as: created, modified, and finalized. When a planis viewed as a process instance, its status takes on valuessuch as started, ongoing, suspended, aborted, and com-

    pleted. In addition, specific events were defined thatserved as criteria for adaptation of the crisis responseduring actual operations. This capability provides theagility in managing crisis operations.

    7.2. Integrated Product-ProcessDevelopment (IPPD)

    The DoDs Integrated Product-Process Development(IPPD) mandate [DoD, 1996] requires system develop-ers to concurrently address product and process issuesfrom a full life-cycle perspective, and to start this activ-ity from the very beginning of the product life-cycle.Integrated Product-Process Development emphasizesthe concurrent development of a product along with theprocesses by which the product is created and sup-ported. A central concept in IPPD is that of IntegratedProduct Teams, which are responsible for carrying outthe IPPD process. A major aspect of the IPPD lifecycleis the modeling, analysis, improvement/redesign, exe-cution, and management of the IPPD process and itsintegration with product design data/tools.

    IDEON was extended to support IPPD-enabled sys-tems engineering. The extended IDEON is referred toas IDEON/IPPD [Madni, Madni, and Lin, 1998].

    Figure 6. IPPD process management system concept.


  • IDEON/IPPD provides the conceptual foundation formodeling, analyzing, and redesigning or improvingcomplex systems development processes while takingsystem constraints into account. A system is consideredto be complex [Sage, 1998] when we cannot under-stand it through simple cause-and-effect relationshipsor other standard methods of systems analysis. In acomplex system, we cannot reduce the interplay ofindividual elements to the study of individual elementsconsidered in isolation. Often, several different modelsof the complete system, each at a different level ofabstraction, are needed.

    For this application, IDEON provided the underly-ing conceptual framework for modeling/designing andpersistently storing the IPPD process for subsequentoperation over the Web [Madni, Madni, and McCoy,1998]. Figure 6 presents the overall system concept forthe resultant system. IDEON extensions for this appli-cation included the addition of: (a) new constraintsmodeled as pre- and post-conditions that define specificgates in the IPPD process; (b) the association of stateswith each component of the complex system or highlyengineered product; (c) the definition of interfaces be-tween components; (d) the definition of productmetadata with linkage to existing product design toolsand data; and (e) the incorporation of concepts such asproduct specification with a link to the design thatsatisfies it.


    Competitive advantage in todays environment de-pends, to a large extent, on whether or not an enterprisecan capitalize on IT developments and trends to exploitfast moving business opportunities. Change, onceviewed as a short period of relative instability, is now acontinuous process. At the same time, the concept of amonolithic enterprise that totally owns all products,services, and channels to serve a customer are rapidlybeing replaced by strategic partnerships, virtual enter-prises, and integrated value chains. The need to operatein a dynamic business and technical environment isdriving the need for technology infrastructures andapplication architectures that are increasingly moreflexible, integrable, and maintainable. It is in responseto these needs that IDEON was created. Unlike otherenterprise ontologies, IDEON enables and/or supportsthe creation, integration, and management of collabo-rative, distributed enterprises. Specifically, it supportsintegrated planning and execution of enterprise proc-esses which are key requirements in command andcontrol, supply chain management, and crisis actionplanning and execution systems. This paper has pre-

    sented the underlying principles and key componentsof IDEON as well as two specific enterprise applica-tions that are based on IDEON. As discussed in thispaper, these applications required minimal extensionsto IDEON to provide the requisite functionality. Anearlier version of IDEON has been implemented in theProcessEdge Enterprise Suite from Intelligent Sys-tems Technology, Inc.


    Department of Defense (DoD), Guide to integrated productand process development (version 1.0), Office of the Un-der Secretary of Defense (Acquisition and Technology),Washington, DC, February 5, 1996.

    M.S. Fox, J.F. Chionglo, and F.G. Fadel, TOVE manual,University of Toronto, Toronto, 1992.

    M.R. Genesereth and R.E. Fikes, Knowledge interchange for-mat, version 3.0, reference manual, Knowledge SystemsLaboratory, Stanford University, Palo Alto, CA, 1992.

    T.R. Gruber, Toward principles for the design of ontologiesused for knowledge sharing, KSL-93-04, Knowledge Sys-tems Laboratory, Stanford University, Palo Alto, CA,1993.

    M. Gruninger and M.S. Fox, Methodology for the design andevaluation of ontologies, Workshop on Basic OntologicalIssues in Knowledge Sharing, Montreal, Quebec, Canada,August 1920, 1995.

    K. Kosanke, CIMOSAoverview and status, Comput Ind27(2) (October 1995).

    D.B. Lenat, Cyc: A large-scale investment in knowledgeinfrastructure, Commun ACM 38(11) (November 1995)(see also other articles in this special issue).

    A.M. Madni and J.P. Gayton, A process-centric crisis actionplanning and execution system, Proc 13th Int Conf SystEng, Las Vegas, Nevada, August 1012, 1999, pp. SE205SE210.

    A.M. Madni and W. Lin, ISTI distributed enterprise ontology(IDEON ): An overview, ISTI White Paper ISTI-WP-5/97-1, Intelligent Systems Technology, Santa Monica,CA, 19971998.

    A.M. Madni, C.C. Madni, and W. Lin, IDEON /IPPD: Anontology for systems engineering process design and man-agement (invited paper), Proc 1998 IEEE Int Conf Syst,Man, Cybernet, San Diego, CA, October 1114, 1998.

    A.M. Madni, C.C. Madni, and W.L. McCoy, Process supportfor IPPD-enabled systems engineering (invited paper),Proc 1998 IEEE Int Conf Syst, Man, Cybernet, San Diego,CA, October 1114, 1998, pp. 2585-2590.

    Meta Data Coalition, Open Information Model, Version 1.1(Proposal) , November 1999, [Open Infor-mation Model (last seen: April 17, 2000, last update:unknown)].

    G.A. Rummler and A.P. Brache, Improving performance:How to manage the white space on the organization chart,2nd ed., Jossey-Bass, 1995.


  • A. Sage, Toward systems ecology, IEEE Comput (February1998), 107109.

    C. Schlenoff, M. Gruninger, F. Tissot, J. Valois, J. Lubell, andJ. Lee, The Process Specification Language (PSL): Over-view and version 1.0 specification, NISTIR 6459, Na-tional Insti tute of Standards and Technology,Gaithersburg, MD, 2000.

    M. Uschold, M. King, S. Moralee, and Y. Zorgios, The enter-prise ontology. Knowledge Eng Rev 13 (Special Issue on

    Putting Ontologies to Use) (1998) (also available fromAIAI as AIAI-TR-195).

    USPACOM, Crisis Action Planning and Execution, Prelimi-nary Functional Economic Analysis (Draft), USPACOM,Nov 30, 1993.

    P.E. van der Vet and N.J.I. Mars, Structured system conceptsfor storing, retrieving, and manipulating chemical informa-tion. J Chem Inf Comput Sci 33 (1993) 564568.

    H.B. Woolf (Editor), Websters new collegiate dictionary, G.& C. Merriam, Springfield, MA, 1981.

    Azad M. Madni is the CEO of Intelligent Systems Technology, Inc. He has previously served in a varietyof leadership roles in high technology companies. He also provides strategic technology consultingservices to corporate executives. He has written over 150 articles, reports, and book chapters in enterpriseontologies, intelligent process management, enterprise modeling and simulation, integrated planning andexecution, adaptive decision aiding, collaborative systems engineering, and adaptive instruction indistance learning. Dr. Madnis research has been sponsored by several R&D agencies of the U.S.Government including the Defense Advanced Research Projects Agency, the Air Force Office of ScientificResearch, the Air Force Research Laboratory, the Naval Research Laboratory, the Office of NavalResearch, the Army Research Institute, the Department of Commerce, the Department of Energy, and theNational Aeronautics and Space Administration. He has successfully commercialized his research inenterprise process design, collaborative process management, humansystem integration, and concurrentengineering. He has received numerous commendations for technology innovation, transfer, and commer-cialization from various agencies of the U.S. Government. He has received national acclaim for leadingISTI to several prestigious awards and national rankings, including the 1998, 1999, and 2000 Deloitte &Touche Los Angeles Fast 50, the 1998 and 1999 Technology Fast 500, the SBAs National Tibbetts Awardfor California, the selection to Computerworlds 100 Emerging Companies to Watch in 2000, and the BlueChip Enterprise Award from the U.S. Chamber of Commerce and Mass Mutual. A past Visiting IndustrialFellow at Caltechs Jet Propulsion Laboratory Center for Space Microelectronics, he is listed in theMarquis Whos Who in Science and Engineering and Whos Who in Industry and Finance. Dr. Madnireceived his B.S., M.S., and Ph.D. in Engineering from the University of California at Los Angeles. Healso has an Executive MBA from the AEA/Stanford Executive Institute.

    Dr. Weiwen Lin is a Senior Member of the Technical Staff and Technical Director of Intelligent SystemsTechnology, Inc. At ISTI, he provides technical leadership to project teams engaged in the developmentand implementation of state-of-the-art distributed objects for collaborative planning and web-baseddistance learning. He serves as a co-Principal Investigator on DoD and NIST research projects ondistributed process management and web-based adaptive instruction. Previously, he was a member of theresearch department at Anderson Consulting where he designed and implemented the security system fora medical information system. He received his M.S. in Computer Science and Ph.D. in MechanicalEngineering from Stanford University. His research interests include knowledge representation, knowl-edge management, enterprise modeling, distributed object architectures, and web-based security.

    Carla C. Madni is currently the Vice President of Operations of Intelligent Systems Technology, Inc., aposition that she has held for the last six years. Previously, she was a Senior Program Manager ofPerceptronics where she oversaw and managed multiple R&D programs. Her research interests areknowledge acquisition, distributed problem solving, enterprise modeling, process management, andadaptive instruction. She has been a coinvestigator and program manager on DARPA, Air Force, Navy,and Army R&D programs. She has done extensive consulting on humansystem engineering projects formajor aerospace companies such as Lockheed Martin, Northrop Grumman, and Hughes. She received herB.S. in Biomedical Engineering from Tulane University and an M.S. in Engineering Systems withspecialty in Distributed Problem Solving from UCLA. She is a member of the IEEE, the Human FactorsSociety, and the National Association of Female Executives.