While the underlying concepts have been around for some time, actually putting them into practice requires enterprises to use new principles for developing applications. Agent technology is also likely to change the way software is tested, and could allow business users to use simulation techniques such as Service Virtualization to understand the implications of ideas before a line of code has been written.
I caught up with James Odell, author of Agent Technology – An Overview, and co-author of Business Process Management: The Next Wave who explains how agents will affect the future of software development and testing.
Service Virtualization: Why is implementing applications using agents or traditional programs important?
Odell: In a lot of cases we cannot implement applications most efficiently well using one big brain in the sky, which is what we used to think. But if we break them into smaller agents they can be more adaptive. Look at ants. They only have 3-4 different types of processes they can do, and they are adaptive because they depend on the environment. Agent-based modeling is a simulation of your process that uses the same principles. What would happen in the financial markets if we used agents like this?
Whenever I design systems, I look back at how nature would design this problem. For example, it would be difficult to do the new movie animations without agents. In these cases, they use agents to simulate the individuals wildebeests in a big stampede using a simple set of rules. When they go down a canyon they can avoid obstacles without crawling over them. There is a story that when they first made the orcs in the hobbit movie and they were all getting killed, they started to flee. So they had to adjust the rules so they wouldn’t. Making this kind of change is relatively simple to do with individual agents, but would be much harder to do if you were trying to centrally control each character.
What is an example of a business case where agent based modeling improved the way the application works?
GM used agents to develop a better system for painting trucks in their assembly line in Fort Wayne, Indiana. They realized the trucks did not come down the assembly line in the order of their color, and frequently many of the paint booths were not available with the correct color, or the painting booths were broken or being repaired.
They used an agent based scheduling program that had booth agents bid on paint jobs. The bidding amounts were based on the color they had available and how busy they were. A vacant booth agent with the color red, would bid high for red paint jobs, while a busy one would bid lower. A traditional scheduling application would have to re-compute the best assignment on the fly. This bottom-up agent based approach enabled other booths to pick up the slack on a moment’s notice.
At DHL, they are using the same principles to do agent based logistics, shipping, and billing. When gas prices jumped they could easily add surcharges to the agents to better optimize the full cost of delivering packages without having to rewrite the underlying logic.
Most of what people talk about with building intelligent applications involves adding bells and whistles. But the applications themselves are not always very adaptive. Instead, you might consider building a cloud application to be agent based.
What is your take on the current status of building cloud applications using these types of agent principles explicitly, and just leveraging these sorts of principles minus the weight of traditional BPM approaches?
Many people are implementing some of these principles using smaller units of programs that can make decisions, but not adopting the general approach that requires a new way of thinking. It’s sort of like the transition from functional programming to object oriented programming that occurred a few years ago. In the early days of programming, we were all writing code in Cobol and Fortran. Then when object oriented programming came along we had to learn not only a new syntax, but a different and more efficient way of tying objects together.
It is the same thing with agents. You have to think about how to embody this as a new way of designing applications in which each agents has its own set of rules that work and groups in which even those groups can be considered agents.
What are the integration challenges involved in building agent-based applications?
There is some parallel between APIs and agent communication languages (ACL) like FIPA ACL and KQML in that both facilitate communication between applications or agents. They are close, but a little different and most people don’t use ACLs today because they add overhead, but in the future as we write agent based applications that span global systems my agent language might not the same as yours. This leads to integration challenges between agent frameworks. We could have agent translators. Using a standard like FIPA ACL could provide a generic language to help solve this problem.
One problem that companies will run into lies in translating between the semantics of different information systems. For examples two hospitals that want to use agents to coordinate patient processes might have different ontologies used by their respective agents. Each hospital could use an agent to translate the relevant information in a way that could be understood by the agent at the other hospital.
If you start building these types of systems with an event processing system, you will have millions running around. You could test each agent to see that it is working, but what happens when they start interacting in unexpected ways.
This brings a whole new level of challenges to integration testing. If you really want to test your system, how else can you do it without putting it through its paces. Otherwise you don’t want to let it loose in your world to see what happens. For small systems this is fine, but with big systems, it could be like the bank that was supposed to be too big to fail.