Developing Enterprise Systems with Intelligent Agent Technology by Faramarz Farhoodi and Peter Fingar farhoodi@trcinc.com . . . . . pfingar@acm.org © 1997, Farhoodi and Fingar Featured in Distributed Object Computing, "DOC" Magazine The Endorsed Publication of the Object Management Group Part 1: October 1997---Part 2: November 1997 For additional information, books and web links.

Going one step beyond distributed object technology, intelligent agents are poised to transform the way we model the enterprise and build information systems. In the first of this two-part article we explored the what and why of this advanced technology, and its business and technical benefits and implications. In part two we explore how to apply the paradigm to business, explore architectures and standards, and explain the relationship with object technology - in particular the Object Management Group's Object Management Architecture. An in-depth exploration of this topic could fill a few books. This article aims to describe the terrain and to provide a road map of the territory.

We concluded in the first part of this article that information systems based on intelligent agent technology are inevitable, even though the tasks of conceiving, designing and building them are not trivial. As we turn our attention to these tasks, we will benefit from keeping the fundamental question in mind, "How can we conceive, design, and build adaptive, enterprise-scale information systems?" Intelligent agent technology is an enabler of such systems, but is not an end unto itself. When combined with the maturing disciplines of object technology and business engineering, their synergy, embodied in agent-oriented business engineering (AOBE), can take us to a new level in the search for the prize of enterprise-level computing.

Our approach to building agent-based systems can be characterized in terms of three distinct, but related, topics:

1. A full-lifecycle solution development process that explicitly addresses domain modeling -- the effort spent in domain and problem understanding can be leveraged to guide and accelerate application development.
2. Ontology-based domain models -- fully understanding the domain is essential to understanding the problems in the domain. The richness of domain models determines reuse and flexibility.
3. Architecture -- applications must follow a consistent architecture approach so they can interoperate with each other.

After a brief introduction to the agent-oriented lifecycle, we focus our attention on the heart of the matter, domain modeling and architecture.

A full-lifecycle solution development process

The agent-oriented lifecycle model should be iterative and incremental. Over a decade of experience taught us that agent orientation will enrich contemporary OOA/D by providing an active modeling paradigm and better analysis models that enable reuse. As shown in Figure 1, our agent-oriented domain modeling and architectural frameworks can be integrated with best practice software engineering lifecycles, leveraging the contributions of artificial intelligence (AI) and object-oriented software engineering. We thus preserve considerable intellectual capital while taking the next step in development methods for truly intelligent and adaptive information systems. Radical new methods will not be accepted as corporations are not in this to advance computer science, they are in business.

Figure 1. Agent-oriented Lifecycle

Ontology-based domain models

Our approach to building agent-based solutions emphasizes the importance of domain modeling as a critical initial step in producing business applications. There are at least three distinct approaches to domain modeling: business process reengineering (BPR), object-oriented (OO), and artificial intelligence (AI), the underpinning of intelligent agent technology (IA). All three approaches are model-based and offer techniques for describing problem domains. As shown in Figure 2, the three approaches offer differing perspectives of the problem domain. The convergence of OO, BPR, and AI technology results in a significant breakthrough in building models of the enterprise that are capable of end-to-end integration of business analysis and software systems. Although the fusion of these disciplines is not yet complete to the point of standardization, pioneering companies have recognized the competitive advantage and launched major agent-oriented development initiatives.

Traditional BPR methods are expressive and easily (often, naively) understood for describing business process and organization. But traditional BPR produces separate models of data, processes and organization that soon become unmanageable. The models are difficult to integrate, validate or leverage for the development of software systems. Information is captured using informal techniques, and incomplete lifecycle models lack a clear implementation path .

Object-oriented methods are well suited to software engineering and have potential for reuse. They are, however, not inherently business oriented, not sufficiently expressive of most problem domains, and often foster premature commitments to design and implementation strategies. Consequently, they do not capture a sufficiently rich domain model for significant reuse. In practice, most OO methods are informal and not repeatable. Traceability is questionable and robust design heuristics are hard to find.

Business models must make a distinction between passive and active, goal-seeking objects (intelligent agents) if we are to close the gap between model and reality. Business object models need to contain behavioral declarations, role definitions, ontological awareness and constraint axioms.

Intelligent agent technology can be leveraged to enhance enterprise modeling as well as offering new techniques for developing intelligent applications and smart technical infrastructure services. An agent-oriented perspective allows us to develop rich and expressive models of the enterprise the foundation for adaptive, reusable business software. An agent-oriented approach such as the Knowledge Analysis and Documentation

System (KADS) supports richer representation of the problem domain and tend to be more rigorous and mature compared to BPR and OO. A method like KADS entails little commitment to design in early modeling phases and allows alternative implementation paths. On the down side, methods like KADS are not widely known outside the artificial intelligence community. They tend to be weaker on infrastructure issues and lack the diversity of commercial tools found in the object technology world. Traditional artificial intelligence is knowledge-base centric and can result in monolithic design.

What's new under the sun? Object-orientation and artificial intelligence have been around for decades. And, many informally describe "BPR" as new clothes on industrial systems engineering. It is the melding of these disciplines into a unified approach to enterprise modeling that represents the breakthrough. Blending the strengths and sifting out the weakness of each discipline, Agent-Oriented Business Engineering can take us one great step forward. AOBE is a full life-cycle proposition, not just a programming or implementation issue. The secret to AOBE's success is to apply agent technology up front as a domain modeling metaphor while using the maturity of OOSE to provide the infrastructure lacking in the artificial intelligence world. Figure 3 shows that agent-based domain modeling produces the business object model in terms of ontologies, and uses ideas and techniques from traditional business analysis (Process Modeling), OO (UML), and AI (Agents and Rules). While devoid of implementation details, the business object model is agent-based and is used to support user task analysis, requirements modeling, and the specification and design of the software object model. The flow of activities in the figure would be somewhat different if we were working in a green field. In the real world of business, green fields are rare, and the figure reflects the use of preexisting BPR and OO analysis models.

A domain model is commonly defined as a representation of entities, their attributes, their behaviors, and the processes that bind them together within a domain - nothing new to the experienced OO modeler. What is new and highly beneficial is to define the information in a domain model in terms of ontologies and then to use these to construct business object models. What is an ontology? Tom Gruber of Stanford University provides the short answer, "An ontology is an explicit specification of a conceptualization." He explains, "A body of formally represented knowledge is based on conceptualization: the objects, concepts, and other entities that are assumed to exist in some area of interest and the relationships that hold among them." An ontology defines the basic terms and relations comprising the vocabulary of a topic area, as well as the rules for combining terms and relations to define extensions to the vocabulary. All domain models embody an ontology-albeit mostly implicitly. Our agent-oriented approach to defining business objects emphasizes the use of explicit ontologies as implementation-neutral representations of knowledge that can then be mechanically translated into different target modeling tools.

An ontology can be expressed in a variety of waysfor example: informally (Natural Language, Graphical Notations), semi-formally (for example, Ontolingua), formally (first order logic languages such as Knowledge Interchange Format [KIF]). The de facto language for encoding ontologies is Stanford University's Ontolingua, a portable language for writing ontologies. Ontolingua is a LISP-like language that is based on KIF. Because KIF provides for the representation of knowledge about the representation of knowledge, storing business knowledge in KIF opens up many opportunities for delivering reuse and validation at the knowledge level.

Architecture is the Key to Agent-Oriented Development

Agent technology does not provide immunity to bad software engineering. Building enterprise-scale agent-oriented systems requires an architectural approach with a strong emphasis on software engineering processes and methods. Our approach to architecture for multi-agent systems is based on a consideration of fundamental design variables that can be instantiated in different ways to accommodate the creation of agents with reactive, deliberative or hybrid behaviors. Our approach to architecting distributed, multi-agent systems can be summarized as follows:

Given: A set of goals, objectives and tasks to be achieved or performed by a community of agents and a set of design variables,

Find: Appropriate instantiations for each design variable, based on available options, subject to applicable hard and soft constraints.

High-level design variables include:

• Internal architecture of agents - how each agent is constructed internally
• Control and Coordination approach - how intra and inter agent activities and processes are managed
• Cooperation style - whether and how agents work together to succeed in common goals
• Communication, interaction and knowledge sharing approach - how agents exchange and share information
• Granularity of agents - covering both process granularity and task granularity
• Depth of adoption of agency - starting from the user-interface, through application services and infrastructure services, to what extent should agents be used?
• Distribution model - the method of distributing application functionality among agents which run across multiple processors.

The following constraints are typical in enterprise systems: information bandwidths, limits of agent processing, resource availability, need for varied but guaranteed response times, reliability, security, distributability, scalability, portability.

By examining the characteristics and capabilities of intelligent agents, we can identify many of the architectural components that are needed to support an agent-oriented environment. For handy reference, Figure 4 repeats the illustration of the anatomy of an intelligent agent to center our discussion of architectural requirements.

An intelligent agent can:

• send and receive information to and from other agents using appropriate protocols (sensing and communication) - this requires communication services that support message queue management, asynchronous messaging and content-based routing of messages.
• generate multiple objectives, goals and plans for itself and other agents, process information received and perform reasoning (e.g. inferencing, synthesis and analysis) - these require services that support rich knowledge representation schemes (e.g. for Rules and Objects), alternative logics (e.g. fuzzy logic, temporal logic, bayesian logic), alternative inferencing strategies (forward, backward, opportunistic), planning (plan generation, plan execution, and plan repair), and concurrent operations.
• maintain explicit belief models of itself and other agents and can reason with incomplete, inconsistent and uncertain information. This requires support for belief revision (e.g. Truth Maintenance).
• have a set of capabilities (which can change dynamically) - i.e. the tasks it can perform - and can reason about its own and other agents capabilities and skills (e.g. planning, inferencing, communication and negotiation). This requires a task specification language, and mechanisms that support 'learning' (e.g. Explanation-based learning, Induction)
• assume roles and perform tasks and execute physical and non-physical actions - actions can result in events which in turn may trigger other actions and processes (in this context a process is analogous to a plan and consists of a pre-defined, temporally ordered, set of activities which are designed to achieve a given goal). This requires task selection and task execution mechanisms.
• engage in complex interactions with each other, such as negotiation and task delegation. This requires support for interaction protocols (e.g. Contracting, Conflict Resolution, Resource Allocation, Basic Communication). Knowledge Query Manipulation Language (KQML) is the de facto standard for designing inter-agent interaction protocols.
• dynamically join or leave groupings or organizations - organization may be functional or social. This requires support for specification of organizational structure, organizational procedures/rules, and roles/responsibilities.
• have its own internal architecture (e.g. Blackboard, Actor or Stimulus/Response). This requires different architectural specifications and alternative control algorithms.
• explain its reasoning in terms of 'how' and 'why'. This requires explanation mechanisms.

The kinds of agents in multi-agent systems strongly influence architecture. Four major types of agents are central to large-scale enterprise systems:

• System agents - these agents are responsible for providing infrastructure-level services to problem-solving and application agents (e.g. access to operating system services, access to data repositories, communications management and security monitoring).
• Functional Units (FUNs) - FUNs (Farhoodi 1991, 1993, 1994) are conceptual agents that represent an organization unit. They define a number of global characteristics for a grouping of cooperating agents, (e.g. common goals and objectives; organizational procedures and roles and responsibilities). Important benefits of organization include structuring communication and reducing uncertainty, increasing system coherence. Figure 5 illustrates the relationships between FUNs, agents, roles and tasks.

Figure 5. Relationships between a FUN, agents, roles and tasks.

• Application agents - these agents embody functionality or application logic within a domain (e.g. risk management). An application can be viewed as a FUN consisting of a cohesive set of agents which share information and cooperate to provide services to their clients.
• Interface agents - these mediate between application agents and external users of their services. Two sub-types of Interface Agents are: User Interface Agents and Wrapper Agents. Human users interact with the system via User Interface Agents which orchestrate other agents and FUNs to deliver user-level services. External computer systems are linked-in via wrapper agents which encapsulate their APIs behind standard protocols.

Agents are constructed from classes within three distinct hierarchies: Controller Class Hierarchy-contains prototype architectural behaviors (for example, Blackboard, Actor, Stimulus/Response); Agent Class Hierarchy-contains prototype agent behaviors, multiple inheritance being supported (for example, epistemic agent, mobile agent, social agent); and Task Class Hierarchy-contains default task definitions (for example, interaction management, problem-solving tasks). An agent represents a logical entity which physically comprises a cluster of components (each component type can be implemented as a separate Class of object). Such agents can be implemented in a variety of ways. For example an agent may be implemented using two frames (an Object-based AI data structure), a base frame and a Meta frame. The controller can be placed in the Meta-frame and the attributes and the assertional database can be placed or be referenced in the base-frame. Alternatively, an object-oriented approach may be used where each component is defined in its own class. The process that loads agents assembles their components and creates instances at run-time. An OODBMS may be used for persistent storage of agents.

Agents communicate with other agents through one or more communications channels which are linked to mailboxes or message queues. Figure 6 shows a logical view of a system architecture that allows agents to interoperate. The post offices in the figure provide delivery services for the mailboxes. This abstraction of communication services allows alternative standards and delivery technologies to be deployed, e.g. CORBA and DCOM. Each agent has a knowledge-base consisting of non-executable (attributes and own capabilities) and executable (how to perform tasks) knowledge. In addition, each agent has an internal assertional database for storing dynamic information, such as its beliefs about other agents. Local services support internal operations of agents (e.g. Message-Queue Management, Query Management and Belief Management). The architecture can be physically distributed across many threads, processes or processors, depending on requirements.

The figure highlights the way individual agents connect to communication services and the underlying technical infrastructure. The figure also shows how 'external' applications or legacy systems such as data repositories can be wrapped to appear as agents - agent wrappers are more sophisticated than object wrappers. They maintain rich semantic models of the application, database, or systems they represents. Abstraction layers insulate the agents from needing to know specific operating system or middleware APIs. The infrastructure should provide a common set of interfaces through which agents may plug into operating system services ala OMG's CORBA or Microsoft's DCOM.

The table below maps some examples of our agent components to CORBA Services and Common Facilities that can be leveraged to implement them.

Components	Potential Services and Facilities
Assertional database	Rule Management Facility, Information Management Facility
Communication Channels	Agent Facility, Events Service, Name Service, Trader
Controller	Rule Management Facility, Transaction Service
Persistent Knowledge	Persistence Service, Query Service
Tasks	Workflow Facility

The environmental needs of intelligent agent systems lead to requirements for a number of services that are yet to be defined by the Object Management Group's Object Management Architecture. Such services include:

• agent definition and management
• organizational and role models
• models for task distribution and task execution
• rule definition and management
• models of cooperation and coordination
• knowledge representation
• high semantic level interaction protocols or communication language for needs and results sharing, for negotiations, and requests for action.
• explicit control over inter-agent and intra-agent interaction both declarative and procedurally
• explicit models for agent networking and for defining mediators and facilitators of interactions.

Although building agent-based systems will be greatly enhanced by standards-based services, these systems can be built today if a solid systems architecture is defined. Components of the architecture can be superseded with standards-compliant components as they become available. Corporations in highly competitive industries cannot wait for full standardization as their competitors are not waiting.

Conclusion

Based on 12 years experience gained from large-scale agent-based projects, this article described an approach to developing complex agent-based software systems. A holistic, agent-oriented business engineering view of design was advocated, and an appropriate lifecycle model was introduced. The discussion of implementation strategies identified a number of technical issues. Currently, a mix and match software strategy has to be adopted, resulting in the need for well defined systems architecture to maintain coherence.

In the immediate future, the advent of Java and further development of CORBA services and facilities will pave the way for development of commercial strength standards. The Object Management Group has several initiatives underway and vendors have submitted related proposals such as IBM's Java Aglet API (J-AAPI) and the Mobile Agents facility.

Corporations will not take the step to agent-oriented business engineering because they can, they will do so because they must. As the Gang of Four state in their OMG Component Imperatives, "Now is the time to move CORBA and the OMA from the current domain, which delivers excellent results for expert programmers creating distributed systems, to the ubiquity of business applications, developed by unsophisticated programmers using visual development tools." While this vision of simplicity is appealing, the underlying enterprise framework is extremely complex and simply needs intelligent agent technology to manage and hide the complexity. With careful planning, sound software engineering and solid systems architecture, an intelligent greenhouse can be architected to grow the software of the future --- today.

# # #
4885/TPA/12/15/97