Expert systems – do what I say, not what I should have said

Esoteria

We’ve studiously avoided talking about requirements for expert systems because it is such a small niche of software development. Please let us know in the comments on this post if this is an area you would like to read more about. This post is both a discussion of the main barrier to success for these systems and an introduction to future posts if you ask for them in the comments on this post.

Background

Expert systems can solve some of the hardest problems. Yet AI software has not dominated the software landscape, neither Heinlein’s nor Vinge’s fictions have become real. Why has AI software failed? After over 10,000 hours of gathering, validating and implementing requirements for expert systems, we’re convinced that it’s because programmers are being asked to solve the wrong problems.

The problem isn’t that the hardest problems are too hard to solve, it’s that they often don’t need to be solved at all.

Expert systems are often referred to as knowledge engineering systems. An expert system takes a database containing data, and adds engineering rules to it. This database is then usually known as a knowledge base. An engine can then process inputs into “the system”, and generate outputs in accordance with the data and rules embodied in the knowledgebase.

Catalyst for this post
We recently were linked to from Nilsnet (thanks!), and the first article we read was titled ‘Expert System = program that almost solves a toy version of a non-problem‘ by Nils Davis. In that article, he also links to an article that presents a criticism of AI. This just started the gears turning…

Business applications of expert systems
There are a few ‘common’ problems that are addressed with expert systems:

• Resource planning and allocation: Minimizing the amount of work-in-process inventory that has to be carried to achieve a given production schedule, determining the lowest-cost manufacturing facility to source an order, airplane route scheduling.
• Equipment configuration: Custom-configuration of high end equipment (telecommunications hardware, super-computers and clusters) with validation that the equipment will be operational as ordered.
• Travelling salesman: Minimizing the distance or time spent travelling to multiple locations to save costs in scheduling of deliveries.
• Resource optimization: Resolving otherwise computationally prohibitive constraints to achieve optimal selections of services, software, or hardware.
• Automation of tedious engineering work: Calculating and validating layout and placement information in association with engineering rules (aircraft interiors, card placement in modular systems, traffic routing in a pbx, etc)

Migration projects are the norm
We’ve talked in the past about the migration continuum, here’s a diagram from that post depicting the range of projects

Every expert system project we’ve seen has been a migration project from an existing process. Fewer than 10% have involved major process changes. These projects almost always get relegated to being plug-ins into existing business processes. The client companies simply automate a step in their existing process. In one major engagement, the client was coincidentally re-engineering their entire project, but the expert systems portion was no more than a box in a flowchart from an executive perspective. A multi-million dollar box, true, but still a second-class portion of the project.

Mis-application of technology
If engineering is the application of science to practical problems, then knowledge engineering is the mis-application of science to impractical problems.

Using expert systems to solve problems requires programmers that are “wired differently.” There are two factors that at least correlate with this.

1. The experts in these technologies tend to be unappreciative of the other elements of successful software.
2. The non-experts in most organizations do not understand the technology – neither its capabilities nor its limitations.

Myopic viewpoint

To quote the Gary Martins reference (from Nils’ post):

While all other areas of technology have enjoyed heroic advanages since [1955], AI advocates continue to pick over the same stale chestnuts that seemed so fascinating way back then.

I chuckled when I read this. I remember a project that was undertaken at my previous employer to rewrite/migrate an existing expert system engine to a new platform. The first thing the developer did was create a set of these chesnuts (9-queens, bin-packing, etc.) as his criteria for validating his work. Only after getting feedback did he incorporate real-world problems (pbx trafficing, frame-relay network design, card-slotting). This is exactly the lack of appreciation that prevents the technologists who understand the technology from thinking about valuable applications.

We’ve talked, in Intimate Domains about the importance of operating and communicating in the intersection of these domains, as the following Venn diagram shows.

The expert system experts tend to conspicuously avoid any overlap with the stakeholders/users/marketing group. My favorite quote from an expert system developer about users:

I’d rather pick up garbage than design user interfaces.

Hmmm.

Lack of understanding

Even technically savvy business people don’t have an appreciation of the applicability of expert systems to their problems. Unfortunately, there aren’t many people who can live in both worlds (switch hitters) and provide that synthesis of ideas. Many a glazed eye has ignored a powerpoint presentation attempting to explain the technology.

Lack of collaboration

Ultimately, both of these problems result in a lack of collaboration. A typical conversation might go like this:

Business: We want the software to configure the optimal racked storage system based on our customer’s needs.
Developer: Define optimal. Lowest cost? Highest performance? Highest profit (to our knowledge, no one has implemented a profit-maximizing configurator)?
B: Lowest cost. Can you make it propose upselling suggestions?
D: Of course we could, that’s trivial. But it’s not a good application of this technology. You should focus on the configuration.
B: OK, you’re the expert. How much will this cost? How fast will it run?
D: Optimality is hard. We did a prototype, and we expect it will take a minute to process for a fully maxed out system. Also, it will cost you (really large amount).
B: Well, we need it – go ahead. [Makes note to himself: Replace these guys asap – too expensive]

Here are a couple improvements to the conversation. We start by putting a requirements analyst into the loop.

Business: We want the software to configure the optimal racked storage system based on our customer’s needs.
Analyst: Do you want to optimize on cost to your customer, profits to your company, or some other metric? How important is optimality?
B: Lowest cost. What do you mean important? It’s critical – that’s how we compete!
A: Well, there’s a theoretical lowest cost for any solution. An engineer can figure it out in a day, our software can do it in about a minute. And it will cost you (really large amount). But if we only had to get within 1% of the optimal solution (say $1,000 for a $100,000 storage system), we could do it for half the cost and it would take about a second for our software to find the answer. Besides, our analysis shows that your average system cost your customers 10% more than the “optimal” price. You would be getting 90% of the benefit of the system at half the cost.
B: Our sales reps have the authority to adjust prices up and down 3%, and sales managers can cut them by 5%. We can live with 1%.
…

Maybe if these conversations had taken place, the companies that failed to capitalize on expert systems would still be around. The problem is that the technologists, in their eagerness to please, do whatever is asked of them (if they can). They never learned to question the value of what they were being asked to do. In our example, the customer didn’t need to get the optimal price – any improvement would make them more competitive. And the business person knew it. The technologist didn’t know to ask.

There are many examples like this in the engineering domain as well. A subject matter expert may say “It must be X,Y,Z” and the developer will say “not a problem.” X,Y,Z might be a choice that saves a penny over X,Z,Y. And implementing “X first” might be a lot easier. Furthermore, the SME should have said ” is important.”

Someone who understands the particular expert system, and who understands business and engineering rules needs to act as an intermediary to gather the requirements. This need is no different than with any software project. The problem is there are so few people who can fill it that the industry is languishing (again) before the problem can truly be addressed.

Conclusion

There are a lot of amazing things that can be accomplished with expert systems. The challenge is in knowing when those solutions are unneccesary. Again, please add a comment if you would like to read more (or not) about expert systems at Tyner Blain. Thanks in advance!