The Case for Expressive Systems
On the derivatives trading floor at J.P. Morgan in New York, there is a new information system called Kapital. The trading environment supported by this system is a demanding one: the traders who use it are at the cutting edge of creativity in the financial markets. In addition to trading a wide variety of instruments, they are continually inventing new instruments by combining parts in new ways, “bundling,” or fashioning an entirely new set of custom terms and conditions. Conventional applications development approaches do not easily support the degree of systems flexibility required by such an environment.
Kapital employs some of the most sophisticated technology currently fashionable in the world of information systems today: it is based on a distributed client/server architecture, borrows techniques from the world of artificial intelligence, and is one of the purest implementations of the concept of object-oriented software in the business community. Using Kapital, traders can choose the user interface that suits them, from simple business forms to graphical representations. They can perform powerful financial analytics using complex mathematical models. Kapital accommodates real-time data feeds giving current market information and performs sophisticated portfolio analysis against a variety of market assumptions.
However, what really distinguishes Kapital from other information systems is not the technology, but the fact that it does not attempt to fulfill a specified set of user requirements — at least in the conventional sense. Rather, Kapital attempts to model the very “language” of J.P. Morgan’s trading business — not only the vocabulary, but also the grammar and, arguably, the style. Kapital implements that language in software, so that the traders can directly express their ideas for new “exotic” tradable instruments. One objective for the system was that, as fast as traders could conceive a valid opportunity for a new kind of financial instrument, he or she should be able to directly interact with the system to create that instrument, simulate its performance in terms of risk and profitability, and if satisfied, price and trade it immediately. To do this required that the software present atomic-level financial components and business rules to the traders, along with the capability to manipulate and extend them in new ways.
Kapital is not a programming language in the conventional sense; it bears no resemblance to the so-called “fourth generation” programming languages on the market today, nor even the graphical programming tools now gaining popularity.
References
1. E. Dyson, ed., “An Explicit Look at Explicitness,” Release 1.0, October 1993, pp.1–19.
2. B. Nardi, A Small Matter of Programming (Cambridge, Massachusetts: MIT Press, 1993).
3. M. Treacy and F. Wiersema, “Customer Intimacy and Other Value Disciplines,” Harvard Business Review, January–February 1993, pp. 84–93.
4. T. Malone, J. Yates, and R. Benjamin, “Electronic Markets and Electronic Hierarchies,” Communications of the ACM 30 (1987): 484–497.
5. H. Mintzberg, Mintzberg on Management (New York: Free Press, 1989), p. 243.
6. S. Haeckel and R. Nolan, “Managing by Wire,” Harvard Business Review, September–October 1993, pp.122–132.
7. J. Rockart and D. De Long, Executive Support Systems (Homewood, Illinois: Dow Jones-Irwin, 1988).
8. J. Martin, Rapid Application Development (New York: Macmillan, 1991).
9. R. Pawson et al., Building the New Information Infrastructure (London: CSC Foundation, 1993).
10. R. Morison, The New I/S Agenda (Cambridge, Massachusetts: CSC Research and Advisory Services, 1994).
11. J. Tibbets, “Object Orientation and Transaction Processing: Where Do They Meet?” (Phoenix, Arizona: OOPSLA 91, Sixth Annual Conference, addendum to the proceedings, 6–11 October 1991), pp. 3–15.
12. B. Nardi and J. Miller, “Twinkling Lights and Nested Loops: Distributed Problem Solving and Spreadsheet Development,” International Journal of Man-Machine Studies 34 (1991): 161–184.