- Business Intelligence (1)
- Methodology (3)
- Operations Research (4)
- Risk (2)
- Vision (1)
Business Intelligence and Operations Research
Mike Trick writes about mutually assured incomprehension between the Business Intelligence (BI) and Operations Research (OR) communities. The two provide similar sounding approaches to intelligent decision-making, but appear to exist in parallel universes in terms of practice and research. He ends by expressing the hope that:
…OR people should see the BI community as a great source of problems and inspiration (and should make an effort to learn their language). But BI will inevitably use non-OR methods for some of their issues, so is rightly not “the same as” OR. But we as a field should know more about what they are doing if we are going to be part of this business direction.
Can BI and OR cooperate for mutual benefit? I look at the issue from the perspective of two technology experiences.
A traveling salesman story
The baffling non-communication between BI and OR immediately reminds me of Traveling Salesman Problem (TSP) research back in the late 80s. The OR (Groestchel, Cook, and others using polyhedral combinatorics), Computer Science (Bell Labs folks using Lin-Kernighan type heuristics) and Artificial Intelligence (using ANN, Simulated Annealing and related “bio-physical” approaches) communities were all working on the same problem, with little cross-pollination. I was fortunate to attend a conference at Rice University that invited leading lights from camp to develop a holistic vision of TSP research.
As a graduate student, I recall sharp surprise by how the limitations and strengths of each school drove its research. The AI folks armed with elegant learning-oriented methods, focused on small – say a few dozen cities – instances, often drawn directly from the real world. Their algorithms would solve series of iteratively changing instances, reliably and fast. Though there was little emphasis on mathematical optimality, their results were accessible to non-expert readers.
The CS folks were at the other end of the size spectrum. They were interested in instances drawn from telecom networks, with millions of cities, which needed to be solved in seconds. Their algorithms were essentially heuristics, so their results focused on empirical performance measures – solve time and distance from optimality. The application areas often involved real-time setting, so narrowing the range of outcome variability was the key research driver.
The OR approach – based largely on cutting plane methods for integer programming – implicitly assumed that provable optimality was the goal. The focus was on solving larger and larger problems to optimality ever faster. At that time, if I recall correctly, the largest solved involved a few thousand cities. However, the methods were extremely non-robust. There were many small “deviant” instances, for which known cutting planes were insufficient. Even worse, within any instance class and size, there could be 10x (or more) variability in solution times.
I recall that by the end of the conference, each research school far better appreciated the others’ methods. For example, in my own research (on a different but related problem) I discovered that a hybrid technique combining a randomized Lin-Kernighan type “kick” heuristic with a cutting plane method worked best. In the broader research community however, the TSP dialog did not lead to a common “business direction”. Perhaps this was due to the mechanics of the research enterprise, which can be quite territorial.
However, it is possible for commonality of goals to induce a commonality of trajectory. This is evident from the CPLEX experience at Ilog.
CPLEX et Ilog
In the late 90s, Ilog was an emerging vendor of optimization tools to the business community. Faced with the challenge of expanding beyond its European base, it found that its bread-and-butter CS-based optimization technology – Constraint Programming – was little known and unappreciated in the US. There, OR techniques such as linear and integer programming were pervasive. A small company called CPLEX Optimization was the leading US vendor. Though the initial idea was for Ilog to license and embed CPLEX technology, Ilog ended up acquiring the company.
The CPLEX acquisition created a host of integration issues for Ilog. Most of them are irrelevant to our story, but a key problem was the mix of mutual incomprehension and suspicion between the two technical groups. The Ilog folks, hailing from a CS background and flush with a string of European successes based on Constraint Programming (CP), viewed OR methods as non-robust and old school. (Constraint Programming gained prominence in the 1980s in the AI community. The simplex method in OR dates all the way back to 1948!) CPLEX folks had a hard time moving beyond the fact that CP offered neither provable optimality nor guaranteed solve times.
As CPLEX rose to become Ilog’s most successful product over the years, an interesting convergence occurred. CPLEX increasingly incorporated CP-like heuristics into its core engine. And CP product development increasingly became driven by CPLEX’s strengths: fast performance and large-scale numerical robustness. Ilog also developed products incorporating CPLEX and CP, creating offerings still without competition in the marketplace. Today, tensions between the two product lines continue to generate tectonic rumbles. But ten years down the road, ILOG has surmounted the original mutual incomprehension between the two teams and grown to the premier player in its space.
BI and OR: Quo Vadis?
In TSP research, though all parties shared goals, convergence did not occur in any meaningful sense. Within Ilog, CP and CPLEX were able to cross-pollinate and cooperate to mutual benefit. What are we to make of these two cases?
One difference, perhaps the key difference, is that the cooperative motivations for TSP researchers were weak. Research is a Darwinian enterprise; schools of knowledge play in a zero-sum sandbox. At Ilog, it was clear that CPLEX needed to succeed for Ilog to grow. Shared purpose – helped along by managerial directives – drove the cooperation of two technologies.
On the face of it, the BI/OR situation is more akin to the TSP case: there is (in Al Gore’s evocative phrase) no controlling authority forcing cooperation. However, from the OR perspective, the situation is far more fraught. The OR profession is in a period of existential self-reflection. What is the proper domain of OR? Is OR mainly a research area or is it a profession (or both)? If it’s a profession, should it include the usual attributes such as licensure, professional closure, and a professional code of conduct?
In contrast, BI has captured much of the “intelligent decision-making” mind-share in the business world in a very short period of time. And all that, on the basis of market-ready IT-aware technologies, with a less established research base. The strengths and weaknesses of the two communities are starkly complementary. And as the need for smart IT expands, the multiplicative impact of cooperation (in whatever form) has inescapable logic.