Redesigning Software Procurement through Intelligent Agents

Mark Nissen, Naval Postgraduate School, 555 Dyer Rd. Code SM/Ni, Monterey, CA 93943; e-mail:

MNissen@nps.navy.mil.

Anshu Mehra, Gensym Corporation, 125 Cambridge Park Dr., Cambridge, MA 02140; e-mail:AMehra@gensym.com.

Abstract

Software procurement represents a process of vitalimportance to most enterprises in the public and privatesectors, but particularly in the U.S. government, the softwareprocurement process is highly pathological. Intelligent agenttechnology offers the potential to remedy this processpathology and an agent-based redesign transformation isrecommended to dramatically improve the performance of thesoftware procurement process. This paper outlines a numberof contemporary agent applications and presents the results ofa measurement-driven redesign analysis of the governmentsoftware procurement process. We discuss intelligentsoftware procurement agents that are developed to automateand support this process using a novel tool called the AgentDevelopment Environment (ADE). The paper highlights thebehavior and utility of intelligent software procurementagents and presents some preliminary results associated withtheir application to an operational government organization.We show how this agent-based process redesign offersexcellent potential for improvement in both cost and cycletime for the process and offer an agenda for continuedresearch along these lines.

Redesigning Software Procurement

With the passage of each product lifecycle, software becomesincreasingly important to efficiency and effectiveness in thepublic and private sectors alike. Many major corporations relyon the power of information technology (IT) to competeeffectively in this fast-paced, hypercompetitive, global businessenvironment of today, and the military has 10ng invested insoftware-intensive weapon and communication systems. Withan expanding mission but declining budget, the U.S.government is fast becoming software-dependent as well, as itrepresents the largest single buyer in the world with anestimated $40B worth of annual software procurement (STSC1996).

However, U.S. govemment procurement lead timesare notoriously long and the time required for softwarepurchases often exceeds the product lifecycles themselves. Itwidely employs linear, bureaucratic, paper-based, regulation-laden procurement processes, even when buying the samecommercial off-the-shelf (COTS) sottware used consumers, for example. Although the govemment has madeconsiderable progress in terms of procurement over the lastfew years (e.g., acquisition streamlining, using EDI, eleclronicbulletin boards, emphasizing COTS software, establishing apreference for commercial specifications and standards), itsprocurement process will always be disadvantaged withrespect to those found in the corporate sector. The immensesize of the government organimtion, requirements for publicIrust and accountability, socioeconomic legislation and otherattributes all contribute to this result. In fact, the governmentmust develop superior processes just to achieve parity with theprivate sector in terms of process efficiency and effectiveness.

In this paper, we employ measurement-driveninference to diagnose a number of pathologies associated withthe govemment procurement process and use the results toredesign software procurement through an intelligent agentapplication. This agent technology serves to enforce processintegration between buyer and seller, takes advantage of globalconnectivity, satisfies regulatory requirements with evengreater consistency than is possible today, and automates mostof the software procurement process with attendant savings interms of cost and cycle time. When implemented to augmentthe govemmenfs suite of legacy, current and emerging ITtools, this agent application can effect the kinds of quanUmaperformance improvements sought through process redesign(Davenport 1993). We provide a brief overview of someexemplary intelligent agent applications in the followingsection and then outline the key steps and results associatedwith redesign of the software procurement process. Thearchitecture for our intelligent agent application is discussedsubsequently, followed by the case of its initial application in

From: AAAI Technical Report WS-98-13. Compilation copyright © 1998, AAAI (www.aaai.org). All rights reserved.

the govemment acquisition domain. We close the paper withan agenda for continued research along these lines.

Intelligent Agent Applications

Work in the area of software agents has been ongoing for sometime and it addresses a broad array of applications. Indeed, oneneed not research too far back in the literature to identify aplethora of agent exarnpleg zo many that any attempt toreview them, even briefly, would constitute a journal-lengthpaper in and of itsel£ In this section we provide a high-leveloverview of extant agent applications, with particular emphasison a framework to relate them with this present work.

It is informative to group extant agent applicationsinto four classes: 1) information filtering agents, 2) informationreWieval agents, 3) advisory agents, and 4) performative agents.Briefly, most information filtering agents are focused on taskssuch as filtering user-input preferences for e-mail (e.g., Maes1994, Malone et al. 1987), network news groups (Sycara andZeng 1996), frequently asked questions (Whitehead 1994)

arb. iwary text (verity 1997). Information relrieval agentsaddress problems associated with collecting informationpertaining to commodities such as compact disks (Krulwichn.d.) and computer equipment (uVision 1997), in addition services such as advertising (PriceWatch 1997) and insurance(Insurance 1997). We also include the ubiquitous Webindexing robots in this class (see Etzioni and Weld 1995) alongwith Web-based agents for report writing (Amulet 1997),publishing (InterAp 1995) and assisted browsing (Burke al.1997). Agents for technical information delivery (Bradshaw al. 1997) and information gathering (Knobloch and Ambite1997) are not Web-based per se, but they perform a similarfunction.

A third class of agents is oriented toward providingintelligent advice. Examples include recommendations forCDs (Maes 1997), an electronic concierge (Etzioni and Weld1995), an agent ’qaost" for college campus visits (Zeng andSycara 1995) and planning support for manufacturing systems(Maturana and Norrie 1997). Agents for strategic planningsupport (Pinson et al. 1997), software project coordination(Johar 1997) and computer interface assistance (Ball et al.1997) are also grouped in this class, along with support formilitary reconnaissance (Bui et al. n.d.) and financial portfoliomanagement (Sycam et al. 1996). Performative agents in thefourth class are generally oriented toward functions such asbusiness transactions and work performance. Examplesinclude a marketplace for agent-to-agent transactions (Chavezand Maes n.d.) and an agent system for negotiation (Bui n.d.),

in addition to the performance of knowledge work such asautomated scheduling (Sen 1997, Walsh et al. 1997),cooperative learning (Boy 1997) and automated digitalservices (Mullen and Wellman 1996).

The intelligent software procurement agentsdeveloped through this present research are probably bestcategorized in the fourth group above (i.e., performativeagents), but they have been designed to also exhibit behaviorssuch as information filtering and reWieval, and their use can beaccomplished through simulation (i.e., in an advisory role) aswell as enactment (i.e., the performative role). Thus, intelligentsoftware procurement agents have similarities with examplesfrom each of the four classes above. To further descnl~e anddifferentiate intelligent supply chain agents, we have integratedthe agent-taxonomy work of Franklin and Graesser (1996)with a three-dimensional structure from Gilbert et al. (1995) develop the analytical framework presented in Figure 1.

CollaborationParallel processing

ISCA

E

programmingMobility

Expert systems

Intelligence

Figure 1 Agent Framework

In this framework we use the same intelligence andmobility dimensions noted in the three-dimensional slruaxa~above, but with the substitution of the new dimensioncollaboration in lieu of autonomy/agency. This follows thepresumption of agent autonomy slressed by Franklin andGraesser. For purpose of discussion, we have annotated liftsthree-dimensional space with one, relatively "pure" exemplarfrom each dimension. For example, many expert systemapplications are quite extensive in terms of formalized, expert-level intelligence, but they traditionally are not designed tooperate on foreign hosts nor do they generally collaborate withother expert systems to jointly solve problems. Similarly,/emote programming of the sort enabled by Java andTelescript equip programs to execute on foreign machines, butthese procedural applications are not generally endowed withthe capability for intelligent inference nor are they usuallythought of in terms of collaborative processing. Likewise,

parallel processing has an explicit focus on collaborativeproblem solving between multiple, parallel processors, but thisproblem solving is usually focused more on proceduralprocessing than intelligent reasoning and execution on foreignhosts is rarely envisioned. Clearly exceptions exist for eachclass (e.g., distn’outed AI, intelligent Java agents, etc.), but thesethree exemplars should convey the basic concepts associatedwith each dimension.

Notice the annotation for intelligent softwareprocurement agents (labeled "ISCA" in the figure). Althoughthis class of systems is not as exlreme as any of the threeexemplars from above along any particular dimension, itoccupies a position roughly in the middle of this three-dimensional agent space; all three of the exemplars from aboveare situated along only a single axis. This adds to the challengeof our agent development work, but it serves to enable a newset of capabilities that prove to be quite effective and useful foroperational processes such as software supply chainmanagement. With this in mind, we tum now to the sottwareprocurement process redesign.

Software Procurement Process Redesign

The government procurement process is costly and time-consuming, particularly with respect to IT. There are manyinstances of procurements taking so long that purchasedsoftware becomes obsolete before it is received by thegovernment user and put into place in the organization, forexample. Because the set of processes associated with softwareprocurement appear to be so pathological for the govemment,we focus our initial redesign activities on this area, and weinclude the corresponding order-fulfillment processesassociated with commercial software vendors to analyze a two-segment supply chain process in this section. We first inlroducethe integrated supply chain process and then step through themeasurement-driven inference associated with its redesign.

Integrated Supply Chain Process

As noted above, two primary processes are involved with thissupply chain----government software purchasing andcommercial software order fulfillment--and we present anddiscuss two process instances in terms of a single, integratedwhole; that is, both purchasing and order fulfillment aremodeled as a single process that spans organizationalboundaries. Specifically, the government software purchasingprocess examined through this investigation pertains to workdone by the Supply Department at the Naval Postgraduate

School (NPS). Although a leading, accredited university likemost schools that offer graduate management, engineering andlike degrees, NPS is also a government institution. Thea~fore itis subject to all the same procurement laws and regulations tiaragovem the purchasing activities of any military unit or federalagency.

The commercial software order fulfillment processexamined through this investigation pertains to work done bythe Product and Licensing Department at GensymCorporation. Gensym is a leader in software for developingintelligent real-time applications and maintains an activeresearch and development activity that drives frequent productinlroductions, updates and releases. Therefore it represents thekind of rapid product evolution that has been problematic forgovernment procurement. The high-level process delineated inFigure 2 depicts the integration of the User, NPS SupplyDepartment and software Conlractor.

UserID rq~ts

Source selection

Use goods

Supply Dept

Vedfyform¥Reseercll $oui’oesY

Issue RFC

Analyze qootas’~

~b’Issua ol~lb~

Receive good~

Make peymen~

Contractor

,s Prep quote=

FulflllCrderSend Invoice

¯ ]~ Deposit fund8

Figure 2 Integrated Supply Chain Process

The process begins with a user in the organizationidentifying a need and determining his or her preliminarysoftware requirements. A market survey follows with themarket information (e.g., products, capabilities, companies,prices, etc.) used to complete a (paper-based) procurementrequest form. This form is submitted to the Supply Departmentfor processing, in which a Buyer verifies the form (e.g., interms of completeness, required documentation sueh as sole-source justification, adequate budget, etc.) and then researchessome potential sources for procurement (e.g., existingconlracts, approved-vendor lists, small/disadvantaged-businessfists, etc.) in addition to the sources identified through themarket survey. An RFQ is generally issued and quotations areanalyzed by the Buyer, who then Summarizes the informationfor review and source selection by the user. A purchase order isthen issued and the transaction is completed as the software isdelivered to the user and payment is made.

Not shown in the figure is the underlyingknowledge, expertise and information that is required forpeople to perform the software purchasing and orderfulfillment processes depicted above. For example, the usermust know how to conduct a market survey and have access toalternative sources of software supply, as well as anunderstanding of the basic procedures for govemmentprocurement and information pertaining to the specific

purchase request form used. Similarly, the Buyer mu.st possessthorough knowledge of the Federal Acquisition Regulationand know how to review the purchase request (e.g., whatconstitutes completeness, when to request additionalinformation, etc.) and have current information pertaining toalternative sources of supply. The Buyer must also have accessto one or more suppliers’ systems to be able to post the RFQand requires knowledge of the procedures required forquotation analysis and source selection. Access to andunderstanding of the receiving and payment systems andprocedures is also necessary to complete the transaction, and ofcourse vendor personnel must understand the policies,procedures and systems associated with software product andlicensing. These kinds of knowledge, expertise andinformation suggest that an intelligent system may offer goodpotential to support this integrated process.

Process Redesign

To redesign this integrated process, we employ themeasurement-driven method described in Nissen (1996,1997a, 1997b), which obtains measurements from a graph-based process representation to diagnose pathologies andrecommend redesign transformations. The knowledge-basedmethod and technology have been successfully employed toredesign a number of govemment procurement processes (e.g.,see Nissen 1997c), and we highlight each of the key stepsbelow.

Step 1. Model baseline process. In terms of process redesign,the baseline (i.e., "as is" process that exists before redesign)process is the one diagrarmned in Figure 2 above.Measurement-driven inference requires a representation thatsupports automated measurement, so we convert the informalmodel from above into an a~ibuted directed graph (A-digraph) as shown in Figure 3. With this model, each processactivity is represented as a node linked to predecessors andsuccessors by directed edges in the graph. To avoid clutter,only the first seven activities are shown in the figure for thisbaseline process. For reference, we also list a representative setof atlributes associated with the "Research Sources" step.These include, for example, role and cardinality of the agentresponsible for performing the activity, along with the

corresponding department and organization, inputs to andoutputs from the activity, and classes of tools andcommunications used to support the process and its products.As an A-digraph representation, this model suppo~ automaticprocess measurement using our graph-based measurementscheme.

ID Mkt PR Verify Rsch Issue Prep

- Level (1)- Type (A)- Agent (SupO)- Cardinality (1)- Dept (Supply)- Org (NPS)- Inputs (verified_PR form)- Outputs (vendor_list)- Tools (DBMS)- Communication (paper)

Figure 3 Baseline A-Digraph Representation

Step 2. Measure baseline process. Measurements are obtainedby counting certain nodes, edges and atlributes that possessheuristic value in terms of process diagnosis. Some of therelevant measures and baseline process values are presented inTable 1 for discussion. Details associated with the measuresand measurement process are provided in the references above.From the table, we see that the process is comprised of twelveactivities (i.e., size = 12) and, as a sequential process flow, it twelve steps in length. The parallelism measurement (1.00 is theoretical minimum for this measure) is calculated as the ratioof size divided by length and quantifies the sequential nature ofthis baseline process instance. The other measures areexpressed in terms of normalized attribute counts. Forexample, the handoff fraction (0.67) indicates that roughly twothirds of. the process activities are associated with time-consuming handoffs from one organizational role to another.Such handoffs are often associated with work sitting in in-boxes and out-boxes, awaiting agent assignment, managerialapproval, couriers, mail service and like activities that am wellknown contributors to cycle time. The three IT fractions amused to quantify the extent to which the process involves IT-based support, communication and automation, respectively.Zero represents a theoretical minimum for these measures.

Step 3. Diagnose process pathologies. The measurementspresented in Table 1 offer heuristic value in terms of processdiagnosis, and the diagnostic implications of these measuresam also shown in the table as they pertain to processpathologies. For example, we noted above that process friction

has a well known impact on process cycle time, as dosequential process flows and paper-based communications.Likewise, manual, labor-intensive processes are also wellknown to suffer from relatively high cost. These diagnosedpathologies are used in tum to match redesign transformations.

Table 1 Baseline Process Measurements

Measure Value Diagnosis

Process size 12

Process length 12

Parallelism 1.00" Sequential process

Handoffs fraction 0.67 Process friction

IT-Support fraction 0.25 Manual process

1T-Communication fr. 0.00" Paper-basedprocess

IT-Automation ft. 0.00" Labor-intensiveprocess

and deploy agents. ADE is built on G2,. an object-orientedgraphical environment that offers a robust platform for thedevelopment of intell/gent real time systems. ADE supportsthe development of multi-agent applications capable ofrunning on a single machine or on a dislributed network. Themain ADE components are Agent, Message, ActiviOp, Host andEnvironment. In this section we briefly outline each in turn,followed by a discussion of agent simulation. We begin with ahigh-level architectural schema that inter-relates each of theseADE components. This is diagrammed in Figure 4.

i!!i

Software Proceu 2

Figure 4 ADE Architectural Schema

Step 4. Match redesign Wansformations. Several redesignIransformations are matched with the pathologies diagnosed inthe preceding step. For example, the sequential process flowmatches with a de-linearize Wansformation (i.e., performingsome process steps in parallel as opposed to serially), but check of inputs and outputs for each step precludes theactivities of this process from being performed with greaterconcurrency; that is, the output from each step is required as aninput to the next, so de-linearization is infeasible. Altematively,the combination of process friction with a manual, paper-basedprocess flow matches with a workflow-system Wansformationto support the process activities. Further, the labor-intensiveprocess (i.e., absence of automation) matches with thediagnoses above to suggest that an intelligent agenttransformation may augnaent the workflow system to furtherenhance process performance. Clearly many other redesignrecommendations can be made from these measurements anddiagnoses, but these are directly applicable to the presentdiscussion (i.e., intelligent agent transformation of sottwareprocurement). We now discuss the architecture associated withour intelligent procurement agent Wansformation.

Agent Development Environment and

Architecture

Agent Development Environment (ADE) is the integrateddevelopment environment to design, develop, debug, simulate

O-~’Agent. In ADE, agents communicate through

messages or events (a subclass of message). ADE provides basic direct addressing message service, with some optionalfunctionality (e.g., guaranteed delivery, message broadcast,subject-based addressing). ADE uses delegation based eventhandling similar to the JavaBeans model in which agents usemessages to generate and listen for events. Each agent has anetwork-wide unique name. This enables communicationamong agents dis~buted across a network to be independentfrom an agenf s location. Agents refer to each other by theirname and the name of an agent cannot be changed during itsentire "life."ADE provides a "Yellow Pages" lookupcapability; that is, specific properties can be defined for agents,enabling other agents to send messages qualified by theirproperties. Each agent can query the yellow pages to find thenames of agents matching a specific Boolean set of properties.Agents can be dynamically created, deleted, cloned and movedacross the network. ADE provides a base agent class calledAdeAgent. AdeAgent can be specialized and augmented byapplication-specific agent types. Example agents includeResourceMonitoringAgent, ManufacturingCellAgent andJobBrokerAgent.

Agents in ADE are autonomous, multi-threadedobjects with their own state. Each thread of control of an agentis represented by an activity instance. An agent canconcurrently perform multiple activities. For example, aMachineToolAgent can be concurrently performing two

5

activities: monitoring a machine job and negotiating future jobswith other agents. Messages and other events are sent, andlistened for, within the context of a specific activity of anagent. Agent activities are defined either using the Grafcetgraphical language (discussed below) or directly with methodsfor activity subclasses.

Message. ADE provides a base level message class

of type AdeMessage. Agents communicate with each other bysending objects of type AdeMessage or its subclass. Amessage contains the destination agent name. Messages arehandled by agent activities. A message can be sent to a specificactivity of an agent. In ADE, no acknowledgment is requiredfor messages. Exchange of messages between agents may besynchronous or asynchronous. A synchronous message blocksthe activity of the agent until the reply is received from theagent to which the message was sent. Alternatively, an agentmay continue to perform its activity without blocking. It isassumed that messages take a finite amount of time to bedelivered. Thus, it is possible for messages to get delayed orlost, and for messages sent in opposite directions by differentagents to cross one another O.e., both be in transit at the sametime). ADE supports two major subclasses of AdeMessage: (i)AdeSolication is a message for which the sending agentexpects a reply; and, (ii) AdeAssertion is a message for whichthe sending agent expects no reply. Messages are used for thecommtmication between agents and between the differentactivities of the same agent. Communication between agentsand external devices or processes is also accomplished throughmessages. A subclass of AdeMessage called AdeEvent isprovided in ADE for discrete event simulation.

I Activity. An activity defines a specific behavior of anagent. AdeActiviO~ class provided in ADE facilitates the

development of a multi-thread capability without dealing withthreads, stacks and priorities. An agent may be concurrentlyperforming multiple activities of the same type or of differenttypes. Within an activity, multiple threads may be active at thesame trine. Messages sent to an agent may either initiate a newactivity or may continue a dialog with an ongoing activity. Inthe first case, the agent starts a new thread of activity. Duringexecution of an activity the agent can send and receivesynchronous and asynchronous messages. Once an activity isstarted, the message can be sent directly to it. An activitymaintains a queue of received messages. Within an agent, theAgentHandler defines the destination activity for each messagereceived. This handler is called when a message does not

identify its destination activity, which usually occurs when anagent is initiating communication with other agents.

Activities are defined either as methods or usingGrafcets. AdeGrafcet is a graphical language that shows bothparallel and sequential control structures in easy-to-understandpictorial form. AdeGrafcet is an extension of Grafcet, orSequential Function Charts (SFC), a grapl;fical language thathas been accepted as an induslrial standard (IEC 848 and IEC1131-3) for local, PLC-level sequential logic control (Davidand Alia 1992). A Grafcet Chart contains Nodes and the Linksamong them define the flow of control of the activity of anagent. The main types of nodes are Steps, Trams#ions,MacroSteps, IterativeSteps and ProcessSteps. The m~fin typesof links are Branches and Joins.

A Step represents a state, phase or mode. Associatedwith a step are actions.that are performed when a step isactivated. In standard Grafcet the actions that can be done in astep are of a Boolean nature, whereas AdeGrafcet actions insteps are more general; they can be compared with statementsof a conventional programming language. Message statementsto other agents may be embedded in the action of a step, andactions are intemally represented as procedures. The Iransitionsact as gates on the flow of control through the Grafcet Chart.Each transition is associated with a condition that determineswhether or not control can pass through the transition. In ADEGrafcet transition conditions are expressed as Booleanexpressions written as procedures. Conlrol can pass through atransition when its Boolean conlrol expression evalo_at~ toTRUE. Wait statements for specific messages from otheragents may be embedded in condition procedures.

AdeGrafcet also provides MacroStep as a way toembed one Grafcet chart in another. IterativeStep enables thedefinition of embedded Grafcet Charts whose process isrepeated a number of times. ProcessStep is a MacroStepexecuted in more than one Grafcet Chart They are equivalentto subroutines in standard programming languages. A Linkconnects steps to Iransitions. Grafcet allows a single step to befollowed by more than one transition, and a single Iransition tobe followed by more than one step. Thus, Grafcet allowsconlrol to fan-in and fan-out, and Grafcet provides for a choicebetween synchronous and asynchronous operations through avariety of fan-in and fan-out links. There are five types of links:Asynchronous Branch, SynchrononsBranch, First-TreeBranch, Asynchronous Join and Synchronous Join,

__ Host. In ADE, every agent registers itself to

AdeHost. There is one AdeHost for every software process on

which a multi-agent application is running. An AdeHost isresponsible for delivering messages, as well as dynamicallyinitializing, moving, cloning and destroying agents. When anagent is created, it is assigned to a specific host. The host theninstalls the agent, registers the agent properties and, ifrequested, connects the agent to databases, on-line controlsystems, etc. The "Locator Service" of a host enables eachagent to locate all the other agents in the application. When anagent moves (e.g., from one machine to another), AdeHostforwards all the future messages to the new address.

Environment. ADE supports agent clusters by

providing a special agent called AdeEnvironment. As depictedin the figure above, agents belonging to an environment mayreside on different hosts. AdeEnvironment enableshierarchical grouping and encapsulation of agents and provideslocal "Yellow Pages" services. Although agents can move todifferent hosts across a network, an agent may belong to onlyone environment. Agents within an environment may bedisallowed to communicate with outside agents, and an

environment can be a cluster of other environments.

Agent Simulation. Because agent-based systems can exhibitcomplex emergent dynamics, simulation is an essentialcomponent of a multi-agent development environment. ADEsupports simulation during development through aSimulcaionAgent that emulates the behavior of extemal devicesor processes. In this way, the interaction of agents with theextemal physical environment can be simulated during thedevelopment phase. When the multi-agent application isdeployed, the interface with the Simulation-agents is replacedby the actual interface with the physical devices.

Summary. In summary, ADE provides: (i) a predefined classhierarchy of agents and agent components; (ii) an agentcommunications "middleware"; (’hi) a graphical programminglanguage to design and develop agents’ behavior based on theGrafcet standard; (iv) a distributed simulation environment test multi-agent applications built with ADE; (v) a completedebugging and tracing environment; and, (vi) a deploymentcenter to deploy agents in the G2 environment or as"JavaBeans" in Java Virtual Machines.

Redesign Agents and Results

In this section we present the preliminary results from our useof ADE and application of intelligent software procurementagents to redesign the govemment software procurementprocess. We briefly describe the structure and behavior of the

intelligent software procurement agents developed to performin this environment and discuss the performance implicationsof this agent-based process wansformation.

IIINI I II IIIINIHill

~Identify need L

,oftwKe mqulrwnen~

ttnd me~ to "thLfl(et4~lnt"to oonduot rmvket murv~ry

tlmloutweJt for"uler goodl"/mel:~le from "supply dlpt"

inform the uaer- Infon~ t~ ualr-oodt received"

Figure 5 Grafcet for User Behavior

Agent Structure and Behavior

In order to describe the structure and behavior of the intelligentsoftware procurement agents developed to perform in flatsenvironment, we draw from the ADE discussion in previoussections and begin with the Grafcets developed to support theNPS-Gensym software supply chain. The first Grafcet,presented in Figure 5, depicts the user behavior and mapshomomorphically to the integrated process flow from Figures2 and 3. For example, the Gmfcet flow begins with the user

identifying his or her need and determining the preliminarysoftware requirements. The next step involves the marketsurvey. Notice the "market agenf’ that is identified as therecipient of a task message here. The supp& chain agent doesnot care whether this task is accomplished by a human ormachine agent, so long as the market survey is completed.Upon receipt of acceptable market survey results, the agentuses its knowledge of NPS purchasing procedures to create thepurchase request form which is sent to the Supply Deparlmentfor processing.

The corresponding Grafcet for the SupplyDeparlment is presented in Figure 6, where the supply agent is"listening" for a purchase request. Recall that the agents aremulti-threaded, so they can be performing a host of otheractivities while waiting for such requests. As depicted in Figure2 above, the supply agent verifies the purchase request, whichis either retumed for additional information or processedthrough the subsequent steps (e.g., researching sources, issuingRFQ, etc.) depicted in the figure.

............. FFFF’FF r~lrl~ irqrrlrrr FF

[] []

~verify POR formnot OK

Bouro~8/

lend ’FIFQ" messagm to ~11tmotom" of the produot

w~Jt for"quoted’n o "quoIQQn

analyze quote tirneout

no "quote" OK

Figure 6 Grafcet for Supply Department Behavior

The software contractor behavior is specifiedthrough the Grafcet presented in Figure 7. As above, theconWactor agent is multi-threaded, so it can do more than justwait for an incoming order from the NPS Supply Department.Upon receipt of such an order, however, it prepares a quotationand sends it to the requesting agent (i.e., supply). If an order received, the agent’s tasks branch to fulfill the order (i.e., sendthe software "goods") and invoice the customer.

The agents’ activity behaviors are implemented viathe Grafcet Charts shown in Figures 5-7. Specific behavior foreach step and node of the Grafcet chart is described through amethod. The distributed nature of the ADE enables agents tointer-operate on different hosts (i.e., agents can besimultaneously at the customer’s and supplier’s sites). Thedistributed agents can communicate with each other viaAdeHost. The supply chain application described in this paperinvolves multiple instances of only a single agent type for theuser, supply deparlment and software contractor. Amarketspace of multiple agent types can be created by

subclassing AdeAgent and describing the agents’ behaviorusing Grafcets.

fulfill order, tend "goodd’ tend "1In voloe"

w~Jt for"l:ayment~

depotlt fundl

Figure 7 Grafeet for Software Contractor Behavior

Preliminary Redesign Results

We note the preliminary nature of these redesign results, for thework to date has taken us only through a proof-of-conceptdemonstration of the integrated supply chain agents. Althoughwe have obtained measurements from this agent-based, post-redesign process configuration, we have yet to simulate theprocess performance or measure the implemented redesignthrough pilot or like testing. Nonetheless, even thesepreliminary results are very encouraging and suggest continuedwork along these lines. The post-redesign measurements arepresented in Table 2, along with the corresponding baselineprocess measurements from above for reference.

From the table one can observe the agent-basedredesign transformation has no effect on process size, length orparallelism, nor did we predict that it would. Thus, we see noperformance implications with respect to these measures. Incontrast, the redesign has a Iremendous effect on the remainingfour measures--handoffs, IT-Support, IT-Communication andIT-Automation fractions---which are associated with reducedcost and cycle time as shown in the table. Although we haveyet to simulate or pilot this agent-based redesign, results suchas these (e.g., eliminating process handoffs and dramaticallyincreasing the density of IT employed in the process) offerexcellent potential to generate the kinds of performance effectsnoted in the table. With this, we feel confident that the

intelligent agents developed through this research can beemployed to dramatically improve performance, not only ofthis software procurement process, but many sottware andoflaer procurement processes in like organizations across awide range of indusWies and sectors. This leads to our agendafor continued research along these lines.

Table 2 Redesign Process Measurements

Measul~ Baseline Redesign Performance

Implication

Process size 12 12

Process length 12 12

PamUelism 1.00’ 1.00"

Handoffs fraction 0.67 0.00’

IT-Supportfiaction 0.25 0.92

IT-Comm. ft. 0.00" 0.83

IT-Automation ~. 0.00’ 0.67

- cycle time

- cost

- cycle time

- cost

Continued Research

In this paper, we redesigned a software procurementprocess and described the Agent DevelopmentEnvironment for developing distributed multi-agentapplications. We then presented a supply chainmanagement application developed for the governmentsoftware procurement process. The application isextremely important because the U.S. government

¯procurement lead times are notoriously long and thetime required for software purchases often exceeds theproduct lifecycles themselves. Although tho proof-of-concept implementation is far from an "industrialstrength" application, it satisfies our feasibility goalsand suggests the agent-based approach and ADEtechnology have potential to scale well across multipleusers, customers and vendors. And our measurementssuggest excellent potential for dramatic performancegains through reduced processcost and cycle time. Thissatisfies our primary objective for this early researchstage.

We are now constructing a simulation modelfor the integrated supply chain process that is used atthe Naval Postgraduate School and Gensym Corp. Weplan to use simulation to analyze and compareprocurement costs and lead times for the paper-based"as is" process and the agent-based "redesigned"

process. The simulation results will also be used toadapt and tailor the supply chain agents. Also, sincesoftware as a product is comprised of digitalinformation, the exchange of software-productinformation and the goods themselves can beperformed electronically. Future work in this area canutilize EDI and the Web to exchange products andproduct information via intelligent autonomous agents,thus further reducing procurement lead times. Theagent-based commercial transactions between buyersand sellers can supplant the traditional EDI forbusiness-to-business commerce and can potentiallyincrease speed and responsiveness in today’shypercompetitive business environment.

References

Amulet. Amulet online description. Interact address:http://www.amulet.com (1997).

Ball, G., Ling, D., Kurlander, D., Miller, J., Pugh, D., Skelly,T., Stankosky, A., Thiel, D., Van Dantzich, M. and Wax T."Lifelike Computer Characters: The Persona Project atMicrosoft," in J. Bradshaw (Ed.). Software Agents. AAAIPress: Menlo Park, CA (1997).

Boy, G.A. "Software Agents for Cooperative I.eaming," in J.Bradshaw (Ed.). Software Agents. AAAI Press: Menlo Park,

CA (1997).

Bradshaw, J.M., DutfMd. S. Benoit, P. and Woolley, J.D."KAoS: Toward an Industrial-Strength Open AgentArchitecture," in J. Bradshaw (Ed.), Software Agents. AAAIPress: Menlo Park, CA (1997).

Bui, T. "Intelligent Negotiation Agents for Supporting Intemet-based Competitive Procurement," working paper (n.d.).

Bui, T., Jones, C., Sridar, S. and Ludlow, N. "Decision Supportfor Reconnaissance Using Intelligent Software Agents," NavalPostgraduate School research proposal (n.d3.

Burke, R.D., Hammond, K.J. and Young, B.C. "The FindMeApproach to Assisted Browsing," IEEE Expert (July/August1997), pp. 32-40.

Chavez, A. and Maes, P. "Kasbah: An Agent Marketplace forBuying and Selling Goods," working paper (n.d.).

David, R. and Alia, H. Petri Nets and Grafcet: Tools forModeling Discrete Events Systems. Prentice-Hall International:UK (1992).

David, R. "Grafcet: A Powerful Toll for Specification of LogicControllers," IEEE Transactions on Control SystemsTechnology 3:3 (September 1995), pp. 253-268.

Etzioni, O. and Weld, D.S. "Intelligent Agents on the Intemet:Fact, Fiction, and Forecast," IEEE Expert (August 1995), pp.44-49.

Frankfin, S. and Graesser, A. "Is It an Agent or Just aProgram? A Taxonomy for Autonomous Agents," inProceedings of the Third International Workshop on AgentTheories, Architectures, and Languages Springer-Verlag: NewYork, NY (1996).

Gilbert, D., Aparicio, M., Atkinson, B, Brady, S., Ciccarino, J.,Grosof, B., O’Connor, P., Osisek, D., Pritko, S., Spagna, R.,and Wilson, L. "IBM Intelligent Agent Strategy," workingpaper, IBM Corporation (1995).

Insurance. Insurance online description. Intemet address:htlp://www.dmatters.co.uk (1997).

InterAp. "InterAp Assigns Intelligent Agents to the Web,"PCWeek (12 June 1995).

Johar, H.V. "SoftCord: an Intelligent Agent for Coordinationin Software Development Projects," Decision Support Systems20 (1997), pp. 65-81.

Knobloch, C.A. and Ambite, J.L. "Agents for InformationGathering," in J. Bradshaw (Ed.), Software Agents. AAAIPress: Menlo Park, CA (1997).

Krulwich, D. An Agent of Change. Andersen ConsultingCenter for Strategic Technology Research (n.d.).

Maes, P. "Agents that Reduce Work and InformationOverload," Communications of the ACM 37:7 (July 1994), pp.30-40.

Maes, P. "Pattie Maes on Software Agents: Humanizing theGlobal Computer," Internet Computing (July-August 1997).

Malone, T.W., Grant, K.R., Turbak, F.A., Brobst, S.A andCohen, M.D. "Intelligent Information-Sharing Systems,"Communications of the ACM 30:5 (1987), pp. 390-402.

Maturana, F.P. and Norrie, D.H. "Distributed Decision-makingUsing the Contract Net Within a Mediator Architecture,"Decision Support Systems 20 (1997), pp. 53-64.

Mullen, T. and Wellman, M.P. "Market-based negotiation fordigital library services," Second USENIX Workshop onElectronic Commerce (November 1996).

Nissen, M.E. "Measurement-Driven Inference forReengineering Support"; appeared in the Workshop of AI inBusiness Working Notes from the AAAI 96 Conference(1996).

Nissen, M.E. "Toward Intelligent Web-based RedesignSupport," AAAI Technical Report WS-97-02 (1997a).

Nissen, M.E. "Reengineering Support through Measurement-Driven Inference," Intelligent Systems in AccountingFinance and Management Vol 6 (1997b).

Nissen, M.E. "Reengineering the RFP Process lhroughKnowledge-Based Systems," Acquisition Review Quarter&(Winter 1997); also published in the Acquisition ReviewQuarterly World Wide Web electronic library:http://www.dsmc.dsm.mil/pubs/arq/97arq/nissen.pdf (1997c).

Pinson, S., Louca, J.A. and Moraltis, P. "A DistributedDecision Support System for Slrategic Planning," DecisionSupport Systems 20 (1997), pp. 35-51.

Porter, M. and MiUar. V. 1985.

PriceWatch. PriceWatch online description. Interact address:http:/Avww.pricewatch.com (1997).

Sen, S. "Developing an Automated Distributed MeetingScheduler," IEEE Expert (July/August 1997), pp. 41-45.

Sokol, P. From ED1 to Electronic Commerce: A Bus~_ssInitiative McGraw-Hill: New York, NY (1996).

STSC. Guidelines for Successful Acquisition and Managementof Software Intensive Systems Sofl:ware Technology SupportCenter: Hill AFB, UT (1996).

Sycara, K., Pannu, A., Williamson, M. and Zeng, D."DisWibuted Intelligent Agents," IEEE Expert (December1996), pp. 36-46.

Sycara, K. and Zeng, D. "Coordination of Multiple IntelligentSoftware Agents," to appear in International Journal ofCooperative Information Systems (1996).

Verity. Verity online description. Intemet address:http://www.verity.com (1997).

Walsh, W.E., Wellman, M.P., Wurman, P.R. and MacKie-Mason, J.K. "Some Economics of Market-based Disln"outedScheduling, Submitted for publication (1997).

Whitehead, SID. "Auto-faq: An Experiment in CyberspaceLeveraging,: Proceedings of the Second International WWWConference 1 (1994), pp. 25-38.

Zeng, D. and Sycara, K. "Cooperative IntelligentSoftware Agents," Carnegie Mellon Universitytechnical report no. CMU-RI-TR-95-14 (March 1995).

10