The “Story” Behind BOL
The hypothesis of this tutorial is that there are efficiencies yet to be gained in today’s fast evolving e-businesses and e-collaborations (aka not businesses). In order to maximize productivity of the expensive human work force in such an organization, it is necessary to minimize the amount of time that these expensive resources spend in accomplishing low-value, repetitive, straightforward tasks. Freeing up this time adds to the amount of time that humans can be engaged in solving the more difficult problems. Computerized “agents”, acting in the name of the human, take the mundane task burden off the human director, automating processing of these tasks and alerting the human only when his expertise is required.
Several on-line book and media sales web sites exist, aiming to implement a rapid response to buyer requests for merchandise. BooksOnLine implements similar client interfaces, while also embedding agent technology. For this exercise we assume that a company named BooksOffLine exists as a traditional brick and mortar or mail order bookseller. The Chief Technology Officer (CTO) has sold the CEO on the idea of “Amazoning” their business, changing the name to BooksONLine. But they want to go one level better than Amazon, and try and integrate all their business partners in the automation exercise, making their whole enterprise as seamless, and therefore as efficient, as possible.
The CTO has laid out the general idea behind the design as
shown in Figure 1. BooksOnLine
itself needs to have people and/or computers that take and track orders, and
also that maintain inventory and report stock from the warehouse. The CTOs plan calls
for separate computers to aid, advise, or be directed
by the humans to control the ordering and the warehousing functions. This is logical since the current order
center is in
The CTO realizes that a large portion of his operation is devoted to labor associated with transactions with external organizations. These are entities outside of his company boundaries that have their own corporate infrastructure, process issues, and profit and loss realities. The CTO has identified the largest of the “labor-suckers” as the tasks involving payment verification and billing, shipping, and reordering books or other media from publishers. In Figure 1, this functionality is identified as the Payment, Shipper, and Publisher circles. These circles represent a capability that will reside at each of the external organizations to provide automated interface to the internal BooksOnLine organization. The CTO has worked hard to convince his external business partners in these functional areas to allow components of the system to be integrated with their own contemporary or legacy systems. This will allow many BOL queries to the Payment, Shipper, and Publisher to be made automatically, without anyone from BOL every calling anyone at one of the other companies. Each of these components must talk to the other seamlessly to avoid the human labor element where possible. Therefore, the CTO has had his staff search for the latest in collaborating agent technology resources, and they have evaluated and chosen the COUGAAR infrastructure to use for the implementation of this revolutionary system. This will allow for a common language of tasking to be spoken between internal and external organizations.
After a week of evaluating the COUGAAR documentation and
working through the basic tutorials, the BOL design team recognizes that their
enterprise relationship circles from Figure 1 correspond naturally to the
COUGAAR cluster construct, and that each circle in the figure will be developed
as a cluster within a COUGAAR society of cooperating and collaborating cluster
agents. Each of these organizations will
have several different sub-functions, to be implemented by developing COUGAAR PlugIn components.
For a good discussion of Clusters and Plugins,
see the COUGAAR Architecture Document, dated
Figure 1. BooksOnLine Clusters, Internal Company and External Partners
Within the eventual society, there will be multiple
instances of many of the clusters. There
will be one Warehouse, Publisher, and Shipper cluster for each different
physical/corporate entity of that type involved (Warehouse 1 in
The CTO hopes that by implementing this system of collaborating clusters, he can reduce the labor required to process, fill, and bill orders by 25%, or more.