In Section 1.2 I claimed that nearly all multi-agent systems have an organization, because any agent system will have a pattern of interactions and an assignment of responsibilities, and these characteristics by themselves constitute an organizational design. Viewed in this light, there has been an enormous amount of research into the process of dynamic organizational search and design, because many of these sys- tems decide such organizational characteristics dynamically. For example, the simple process of contracting out or assigning a task creates a manager-worker interaction
[178]. The related work presented below is differentiated from the majority of these projects in that the search process in each is grounded in an explicit representation of the organizational space. Where the others are superficially related because they implicitly result in organizational decisions, those below are more directly related because they address the problem of automated organizational design in a direct and (mostly) general fashion.
Before focusing on particular design methodologies, it is worth mentioning the relationship that organizational evaluation has with design. A key characteristic of any domain-independent design process is the ability to predictively evaluate how well competing designs will behave under expected conditions. This can be accom- plished in various ways, including the use of heuristic analysis, predictive models and simulation. Like the technique-specific models described at the beginning of Section 6.1, ODML uses predictive mathematical models for its evaluation. The benefit this approach has over a simulation-based evaluation is speed. A mathematical model’s evaluation type is typically measured in seconds – it requires only as much time as needed to evaluate the equations. Conversely, a true simulation can require minutes, hours or even days to determine characteristics for a single design consisting of a large number of entities. Heuristic approaches are less easily categorized, as any sort of approach (case based, analytic, simulation, or other) might possibly be embedded in the process. In practice the drawback to using heuristics is their typical lack of generality – a new battery of tests may needed to be devised as the organizational alternatives change. i
As with organization representations, each of these techniques has its place. The utility of each depends on the user’s relative need for detail, optimality, speed or gen- erality, among other things. The analytic approach was selected for ODML because a design process that may potentially consider all of the (potentially vast number of) organizational design alternatives can greatly benefit from its speed and accuracy.
Although not demonstrated in this work, it is also quite possible to use a hybrid scheme that exploited the strengths and avoided the weaknesses of each. In this case, one might use the analytic approach to form a rough view of the organizational space, and use detailed simulation to empirically compare a small subset of representative instances.
The SADDE design methodology [171] discussed previously can be thought of as an approximation of this technique. Each agent in SADDE expects a set of pa- rameters, each of which controls some aspect of the agent’s behavior. The search process thus attempts to find an appropriate set of values to assign to organizational parameters for all participants. In this particular work, agents act as consumers and producers in an electricity market. A typical parameter dictates how a producer should generate its electricity, while another specifies the strategy consumers should use when placing bids. This strategy allows local agent characteristics to be modi- fied, and consequently affect how they interact with other agents, but changes to the higher-level organizational structure are not considered without human intervention.
Iterative evolutionary computing is used to explore the space of parameters. Each agents’ parameter set comprises a single gene, and the complete set of genes makes up a chromosome. During the search, a particular chromosome is used to instantiate a multi-agent system, which is then evaluated with a fitness function to determine the utility of the organization. Biologically-inspired notions of mutation and genetic crossover among chromosomes, weighted by the results of the fitness evaluation, are used to create new organization candidates. These candidates are then ranked and evolved in an iterative manner by comparing them against the equation based model (EBM), and the most fit organization is chosen.
SADDE is only an approximation of the hybrid scheme because of its loose connec- tion between the EBM and the agent organization. As mentioned earlier, the EBM is a descriptive target, not a predictive model, and the genetic manipulations are
used to coerce the agents into a design that conforms to those equations. In ODML, it is the modeling process itself that ensures the consistency between the form and function of the design, which is what allows the utility expression to directly guide the search process.
Like ODML, So and Durfee [180, 179] search for structures that are a best match between organization and environment using closed-form expressions to model the various relevant performance metrics. The search process makes use of an organi- zational model, a task environment model, and a performance model. The orga- nizational model defines elements such as the available agents, and the way tasks and work flows are assigned among them. The particular organizations considered are limited to various forms of hierarchies, corresponding to a functionally decom- posable task. The task environment model describes the task itself, along with any environmental characteristics that might affect the organization’s performance. This detailed view coincides with my own, that all relevant features of the domain must be considered when forming the organization. The performance model consists of a number of metrics by which the organization may be judged, such as response time, throughput, reliability, etc. The particular metrics which are listed are all global in character – per-agent analysis is not discussed. The search strategy employed in this work is broken down into four phases: monitor, design, evaluate and implement. Like ODML, evaluation is accomplished by using closed-form formulas to predict various performance metrics. Unlike ODML, these concepts were not formalized into a gen- eral organizational representation language suitable for defining a search space, and only hierarchical systems are considered.
Although the primary function of the STEAM framework outlined above is to enforce teamwork semantics at runtime, it also incorporates some adaptation facil- ities through the specification of monitoring points and re-planning [185]. A set of logical rules, called role-monitoring constraints, may be defined to monitor team per-
formance. At runtime, the validity of these statements may be ascertained through plan recognition or explicit communication among participants. If a constraint is found to be violated, and that failed constraint implies that a team goal is no longer achievable, a repair mechanism may be invoked to handle the failure. Like the adap- tation process described in Section 4.5, this repair process can be viewed as a form of organizational design. The repair mechanism itself is just another team opera- tor, which allows the existing organizational machinery to perform the repair task correctly. Repair techniques are generally limited to role reallocation. A suitable, non-conflicting participant is found to satisfy the failed role, and the substitution is then announced to the other team members. Although this approach lacks the quantitative grounding available in ODML and is limited to role-based repairs, the runtime capabilities inherent in STEAM provide a level of automation absent in an ODML-based implementation. Thus, while the level of design and adaptation is more limited, the process itself is more straightforward to enact. This is a key difference be- tween STEAM, which has robust runtime semantics and behaviors and a less detailed representation, and ODML, which reverses this tradeoff.
Nair et al. offer a organizational adaptation technique based on a formal model called a RMTDP (Role-based Multiagent Team Decision Problem) [138], based on a distributed POMDP framework. The goal of an RMTDP is to provide a way to create and adapt role-agent matchings. Like ODML, the space of possible assignments is combinatoric, so heuristic search techniques must be used if assignments are needed in a timely manner. Also like ODML, the RMTDP model is used for both creation (team formation) and adaptation (team reformation). The model itself consists of a set of states, actions, transition probabilities, observations, observation probabilities, a reward function and a set of roles. Actions and rewards are divided into role-taking and role-executing types, where the former reflects an agent taking on a role and the latter the actions agents can perform in that role. The action timeline is also divided,
so that each role-taking epoch is followed by a role-executing one. It is pointed out that although this limits the representation, it also facilitates the cost-assignment problem.
Initial role allocation is accomplished by associating an RMTDP policy for each possible assignment of agents to roles. This is in contrast to ODML, where a single template represents the entire organizational space. In order to avoid searching the entire space of assignments, a branch-and-bound pruning approach is used. The maximum value of each child in the search tree is estimated using the system’s plan hierarchy, and if it is not possible gain utility by pursuing a child, it is pruned from the tree. RMTDPs can also be used for adaptation, although like STEAM it is limited to role-based reallocation strategies. However, it was demonstrated that using an RMTDP-based policy along with STEAM’s normal interpreter-based repair results in behaviors that more reliably accounts for cost and the probability of failure. RMTDP and ODML also differ in their ability to relate organizational decisions to tangible performance characteristics. Like ODML, the policy derived from a RMTDP may be based on a range of characteristics. Unlike ODML, the quantitative rationale for or explanation of a particular decision is lost in the policy’s transition function. This can make an RMTDP policy difficult to use when runtime conditions do not match those the policy was derived under, while an ODML structure would directly propagate such changes through the existing model.
The MaSE framework [127, 46] uses capability functions to evaluate and rank different organizational decisions. For example, a role capability function is used to determine how well a particular role can satisfy a particular need. Similarly, and organizational assignment function computes the capability score for the organiza- tion as a whole. The design process works by finding a set of agents that have the capabilities needed by the roles that have been selected to meet the high-level goals.
Although details are not given describing how this search is performed, the process
seems conceptually similar to the role assignment problem discussed earlier, with a well specified way to evaluate role fitness. Although the design process used by MaSE is based upon quantitative data, it is driven by just the singular quality value that may not be sufficient to capture the complex tradeoffs different designs can have along different dimensions. ODML can explicitly represent and compare among an arbitrary set of quantitative features, and therefore can reason about tradeoffs that MaSE cannot.
H¨ubner’sMoise+model has also been used as the basis for controlled, top-down organizational adaptation [89]. Similar to the theoretical ODML-based process out- lined in Section 4.5, this process is separated into four phases: monitoring, design, selection and implementation. Monitoring determines if the current organization no longer satisfies the needs of the global purpose. In the design phase a set of candi- date, alternative organizations are created which address the deficiency. The selection phase chooses one of these alternatives, which is then implemented. This must be done according to a utility calculation where the benefits of the new organization are balanced against the costs of implementing it. The authors envision this process per- formed as a normal task within the system, and can therefore exploit organizational concepts in doing so. Their proposed strategy would employ roles such as a reorgani- zation manager, monitors, a designer and selector. General descriptions of how those tasks would be performed are not given, and thus are difficult to compare against ODML’s techniques. In a case study that is provided, several designers operating concurrently use a range of domain-specific techniques to explore the organizational space. A single selector then ranks and chooses the most appropriate structure. It seems quite possible that ODML or an ODML-like process could coexist within this set of designing agents.
The organizational work by Sims et al. also incorporates an automatic organiza- tional design feature [174, 173]. This more general technique was inspired by their
earlier design-specific work on bottom-up coalition formation [175]. As indicated in the previous section, the representation used by the design process is composed of a number of separate characteristics, including a goal tree, a set of role specifications, and a description of the available agents. The principal design process revolves around finding a set of role-goal and role-goal-agent bindings. It must first find a suitable set of roles that meet the requirements laid out in the goal tree and elsewhere, and then find a set of agents able to provide the capabilities specified by the roles. The search process uses a set of heuristic techniques to find and verify these bindings.
As part of that process, it may be decided that a role should be distributed among a set of agents, to satisfy computational needs, address spatial requirements or im- prove quality in some other way. This then creates the need for coordination among agents in the set, which is itself a separate organizational design process applied to a newly recognized “coordination goal”. Thus, the search is separated into two phases: the search for application-specific bindings (domain goals), and the search for coordination-domain bindings (coordination goals). Organizations are selected based on their ability to meet specified domain and role requirements. The current mod- eling framework lacks a direct means to quantitatively evaluate and rank otherwise valid organizations in a general way. It currently uses an external heuristic evaluation component to do so, which relies on model-specific rules and information to predict behaviors and guide the search.
A summary of these approaches is shown in Table 6.2. All of these provide suitable and reasonable mechanisms to enable organizational search. However, none of them address the range of organizational characteristics representable in ODML. Chapters 2, 4 and 5 demonstrated how one can use ODML to model concepts including agent interactions, role assignments, bounded resources, detailed performance predictions, and high-level organizational structures such as hierarchies, coalitions and teams at various levels of abstraction. This range encompasses and subsumes nearly all the
Framework
Characteristics Considered Search Technique Centralizedor Decentralized
ODML Organizational structure Generate and test Both SADDE Agent parameters Evolutionary computing Centralized
So Assignment and hierarchy Generate and test Centralized
STEAM Role assignment Rule matching Decentralized
RMTDP Role assignment Branch and bound Both
MaSE Role, capability assignment Role matching Centralized Moise+ Various Various Decentralized
Sims Organizational structure Heuristic search Centralized Table 6.2. A comparison of the characteristics and capabilities of several different organizational design and adaptation schemes.
characteristics considered by the approaches described in this section. Because of this, the scope of the design space using ODML can be richer in possibilities, and correspondingly harder to effectively search.