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. Its basic constructs are not simply high-level representations of the computer’s resources (although these are provided where useful), but the natural constructs and components of the trader’s world: cash flows, interest rate scenarios, risk profiles, and so forth.

While giving users direct manipulation of the system’s capabilities, Kapital does not eliminate the need for professional programming. A high-caliber team needs to maintain and continuously enhance the business language and its supporting technologies. Furthermore, traders may call on professional programmers to assist them in implementing a more difficult idea, refining a prototype they have developed, or writing a new component from scratch. However, the response time for such requests is measured in minutes and hours, not weeks and months. In part, this is because Kapital provides high-level business capabilities and low-level technical components in one integrated environment. The developers do not have to translate a requirement from a business domain, as with conventional programming, into a different technical medium.

Kapital is an example of a new kind of information system that is beginning to emerge in business, which we have dubbed “expressive systems.” Conventional systems support only the standard business operating procedures for which they were designed.1 Expressive systems are designed to support exceptions from standard operating procedures, empowered actions, new product ideas, services tailored to individual customer’s needs, ad hoc or even temporary changes in organizational structure —none of which, by definition, can be specified up front. These changes can be implemented in a time frame appropriate to the business need — in some cases, in seconds or minutes, by the users themselves; in more complex cases, in hours or days, with the help of professional programmers; but never in terms of weeks or months.

Expressive systems not only make it easy to implement these changes, they encourage business managers or empowered workers to explore more possibilities for change and thus improve business performance. Using an expressive system within any of these contexts feels as natural as using an electronic spreadsheet program to develop a financial model and then explore “what-if” scenarios.2 But expressive systems are not mere simulation tools. They permit the user to execute the action through the same system, whether that result is a new financial instrument to trade, a new way of routing documents through an administrative function, or a reallocation of work orders between manufacturing plants.

In this paper, we show, with reference to both examples and new theory, that expressive systems will in time become the dominant paradigm for business computing. Implementing expressive systems, however, will require organizations to address new technologies and redevelop many of their existing systems. Furthermore, the implementation and support of expressive systems will require a substantial modification to the roles and structure of the information systems department.

Roles for Expressive Systems

We have identified three specific roles that expressive systems will play in business:

• Reducing the time to market for introducing new products.
• Facilitating the tailoring of products and services to individual customer’s needs.
• Making operational processes more responsive to unforeseen events.

(Interestingly, these three roles correspond to Treacy and Wiersema’s three dimensions of market leadership: product leadership, customer intimacy, and operational excellence.3 This suggests that expressive systems have a role in all organizations that seek to lead their markets.)

Reducing Time to Market

In many industries, from automobiles to pharmaceuticals, reducing the time to bring new concepts to market is critical. Computer-aided design systems, arguably an early form of the expressive system concept, have encouraged users to explore more design alternatives and better understand the consequences of their actions. The new Boeing 777 aircraft was completely designed on computers using a package called Catia. For the first time in modern aircraft design, it was not necessary to build an evolving full-scale prototype to find out if the pipework and other systems could be routed through the narrow confines of the airframe. The computer simulation provided that intelligence — the first 777 was built to fly.

The advance of new prototyping technologies, such as stereo lithography, which can create a plastic three-dimensional form from a computer model in seconds, and robotic assembly means that the users of such systems can express their ideas directly into physical form. However, the greater the information content of products and services, the stronger the potential for expressive systems to reduce the product development time.

In a limited range of cases, expressive systems can potentially eliminate the product development process altogether. Arguably this is the case with J.P. Morgan’s Kapital system. The ability to create new financial instruments “on the fly” changes the trading paradigm from looking for opportunities to trade each of a set of preexisting instruments to creating the instrument needed to take advantage of each opportunity that arises.

While the financial trading environment is undoubtedly a rarefied one, it is worth noting that there is a clear pattern of innovations transferring from this environment to “ordinary” business.4 Telecommunications companies and energy utilities, for example, are starting to deploy systems of similar sophistication in order to introduce new forms of billing and new value-added services, in response to rapidly changing market conditions.

Tailoring Products and Services to Customer’s Needs

Many organizations recognize that to retain their most valued customers, they must increasingly respond to an individual customer’s needs. The difficulty lies in being able to do this with something approaching the economy of standardized services; information systems are clearly the key to this objective. Banks and other financial services have for years been developing “parameter-driven” information systems that would allow them to vary the parameters of a financial product (the interest rate, term, and any discounts) without the need to write new program code. In reality, however, the degree of customization this approach offers is still small, and the professional systems effort needed makes it uneconomical for application to individual customers. One organization that is seeking to break this limitation is Britain’s National Westminster Bank (Nat West).

As part of a series of initiatives to define the future of retail banking, the IT strategy department at Nat West developed sophisticated PC-based software that would permit not only the parameters, but the very operating structure, of a bank account to be tailored. Suppose, for example, that a high net-worth customer preferred to have her checkbooks sent, not to her home, but to the nearest branch of the bank — with an advisory letter sent to her home. This apparently simple requirement would be beyond the scope of most parameter-driven systems and would require expensive manual intervention. Nat West’s prototype system permits this scenario simply to be drawn out graphically on the screen, creating the necessary supporting systems automatically.

Several things about Nat West’s prototype system stand out:

• The software was designed to be used by an IT-literate bank manager or, more probably, by a systems professional sitting next to the bank manager. But, either way, the new type of account is created in real time, typically in response to a customer request.
• The system is graphical, with icons representing all the business constructs that a bank manager would expect to deal with — customer, interest rate calculator, statement, checkbook, and so forth.
• The system does not present the user with a series of predefined options. Rather, it feels like a well-designed child’s construction kit, with which the user can quickly explore and implement almost any idea.
• The user can see the profitability, or otherwise, of the financial product. (This can even be done on a separate screen, allowing the basic product to be designed in front of the customer.)
• Built-in constraints prevent the user from building illegal or nonsensical financial products.

It may be several years before this scenario pervades the bank’s branch network, but Nat West is committed to implementing its system and probably has at least a couple of years’ lead on its competitors. The difficult part is not designing the graphical front end, but redesigning the deep structure of the core information systems to allow them to be manipulated this way.

Expressive systems therefore perform two important functions in product or service customization. The first is to permit the customization to take place in “real time” at the point of customer contact, rather than later in a back office. The second is to permit the user to explore and understand the consequences (here, in terms of profitability) of the proposed approach or action. Without this capability, there can be no substance to the concept of empowered actions. This theme carries over into the third function.

Responding to Unforeseen Events

In the context of improving operational performance, expressive systems take on two roles: the first is to optimize the refinement of resource use; the second is to facilitate the handling of unexpected events and potentially chaotic disruption.

Manufacturing, logistics, and other key operational functions have been subject to intensive study and refinement for many years. Both quality and efficiency have been driven up, waste reduced, and nonproductive costs, such as stock, virtually eliminated. The scope for further refinement is narrowing rapidly. But the refinement has brought a new problem: greater potential for chaotic disruption (we use chaotic in the mathematical sense).

American Airlines, whose operating procedures and information systems are second to none, has recognized this. Its systems operational control is the business unit charged with executing the flight schedule and marshaling the many different resources on which it depends. Any flight may draw its plane, flight crew, and cabin crew from three different incoming flights, while baggage handling, gate space, catering, cleaning, and other ground-based resources must also be coordinated. With this level of dependency, unforeseen events, from unscheduled maintenance to adverse weather (not to mention presidential haircuts!), have the potential for chaos. Currently, the antidote means preserving the structure of the dependencies at all cost — even if this means delaying whole complexes of flights. No one really knows the true cost of these off-schedule operations because of the difficulty of separating the complex costs from routine operations and estimating the impact on customer loyalty, but they are believed to be enormous.

Reducing this cost cannot, by definition, be achieved in the same manner as previous operational refinement. As part of a long-term program to apply the power of IT to this thorny problem, American Airlines has developed new systems specifically to support its flight dispatchers, the individuals who manage a flight from the ground, including all resources and any route changes. Previously, flight dispatchers had to access information systems through the same kind of transaction-oriented interface as the reservation systems. The new system not only provides more direct manipulation of the system, but also helps the dispatchers to explore the consequences of each unscheduled event and each possible response. One feature of the user interface, for example, is a time line that graphically portrays the prior events on which a particular flight depends, future flights that in some way depend on it, and their current status. Dispatchers can instantly see the consequence of shifting the proposed take-off time, in terms of disruption to the schedule, to staff and internal resources, and, of course, to passengers. No airline currently has an effective model of the financial costs of such disruption, or of the impact on future revenue from customer dissatisfaction, but the American Airlines system is a significant step in that direction. One way of looking at this type of expressive system is that it takes the conventional concepts of operations research (including, for example, PERT networks) and makes them an integral part of real-time operational systems.

A second example is Black & Decker (B&D), whose complex manufacturing operations have been based for twenty years on MRP II, the standard for manufacturing resources planning. An increasing proportion of B&D’s sales is coming from large and streamlined retail operations, such as Home Depot, that may place orders on the basis of “deliver within seven days or the order is canceled, and we devote the shelfspace to competitive products.” With some retail stores four days away by road, this gives B&D just three days to respond. But the MRP II systems require so much setting up and processing time on mainframe computers that they can be run only every seven days.

Moreover, the MRP II algorithm works in one direction only: it converts a master build schedule into a materials requirements plan and thence into a capacity plan. If there is an unexpected change to the availability of manufacturing capacity, or to the availability of materials, the MRP II system cannot identify the consequences or advise alternative actions.

Against this backdrop, B&D formed a new team for advanced manufacturing technology with the goal of designing the manufacturing control system of the future. That system, built with the help of a small but innovative software vendor called Intellection, is now in operation in several of its plants. B&D believes that it now has an operational flexibility that not even the Japanese can match. It allows the company to consider the consequences of any event and dynamically explore alternative ways to meet the same requirements. In the not-too-distant future, the system will be accessible from every machine cell in the plant, enabling individual machine operators to identify and understand the consequence of, say, shutting down the machine for an hour’s preventative maintenance and finding alternative ways to get the parts made in the meantime.

Thus a key role for expressive systems in high-performance operations is to reduce the potentially chaotic effect of disruptive events. Henry Mintzberg wrote, “When the planners run around like Chicken Little crying, ‘The environment is turbulent! The environment is turbulent!,’ what they really mean is that something has happened which was not anticipated by their inflexible systems.”5

Expressive Systems Contrasted with Other Systems

There are other kinds of information systems, such as decision support systems, and other new approaches to systems development, such as rapid application development, that are seeking to address some of these same business goals.6 However, there are also some clear distinctions, and it is these distinctions, we believe, that make the expressive systems approach more effective in meeting those goals.

Decision support systems, or executive information systems, have made it possible for users to express their information requirements directly, and their ease of use has encouraged managers both to analyze past performance in greater depth and to simulate better the possible consequences of proposed actions.7 However, the functionality of executive information systems is typically limited to obtaining and analyzing information – they are not a medium through which actions can be executed, in contrast to each of the examples discussed above.

Furthermore, creating a decision support system is usually a matter of grafting new software on to the front end of existing transactional systems. The front end, whether an off-the-shelf package or specifically designed for its purpose, shields the user from the technical details of accessing the underlying systems, provides powerful data manipulation tools, and typically wraps the whole in a nice graphical interface. Newer generations of such packages permit the user to change data stored in the underlying systems, for example, to change a customer’s address, and perhaps to invoke standard procedures, such as “issue a statement” without leaving the graphical environment. But the only actions or functions available to the user are the fixed set of transactions that the underlying system was designed to support.

If expressive systems are to support actions not previously specified, the user needs access not only to predefined transactions, but to the building blocks from which new kinds of transactions can be constructed. Most of today’s core transactional and other “mission critical” information systems were not written with this objective in mind and do not support access at this component level. Some very modern, large systems include application programming interfaces (APIs), which provide better access to the underlying functionality, but these are intended for professional programmers who will be constructing substantial new software applications. Creating the component level access required to implement the expressive systems concept typically requires a complete rewrite of existing core systems.

Within the IS community, the biggest competitor to the concept of expressive systems is probably rapid application development (RAD)8 — the new techniques for dramatically reducing the lead time to develop new systems. Some instances of RAD deploy similar technology to that in expressive systems (including client/server and object orientation). Some use conventional systems technology and programming languages but deploy different management techniques such as intensive workshops involving users and developers (sometimes called joint application development, or JAD), and time-boxed deliverables.

The significant difference between the RAD approach and the expressive systems approach lies not in the technology or the actors, but in the intent of the process. JAD and RAD are fundamentally techniques for getting better agreement and ownership of the required specification, either through intensive user/developer workshops at the start of the process, or through an iterative process of delivering crude prototypes of systems and refining the specification based on user feedback from those prototypes, toward a stable end point.

In the expressive systems approach, the iteration is primarily away from a stable start point. The basic components and capabilities of the system provide the start point, but as individual business units or individual users use them, they will move away from the start point as their needs change.

Implementing Expressive Systems

Expressive systems therefore change the concept of an application. Today, the term “application” refers to a collection of programming code and data that together meet a neatly circumscribed and well-defined set of business requirements, such as an order-processing system or a credit management system. Applications account for the greater part of the budget, manpower, and management attention of most IS departments. The applications are supported by a common technical infrastructure, whose costs and management are shared, but these are smaller by proportion. Implementation of an expressive system requires an inversion of this balance, with a much thinner applications layer and a much thicker (or richer) shared infrastructure, which comprises not only technical components but also business constructs.9

If they are thin enough, applications can be thought of as a wiring layer. We find that this notion has particular appeal to systems professionals old enough to remember analog computers, in which applications were constructed by wiring together standard components on a plug-and-socket panel. Moreover, some of the PC- and workstation-based software tools most appropriate to building expressive systems (for example, Digitalk Parts, NeXTStep, and IBM’s VisualAge) permit software components to be visually wired together on screen.

We could go farther and say that the word “application” changes its sense from a noun to a verb (strictly, the gerund of a verb).10 Application now refers to the process through which the infrastructure is applied to the needs of a business situation or an individual user, rather than to a piece of software in its own right.

So what does the thicker infrastructure actually contain? The sine qua non for expressive systems is an “uncommitted” software model of the business (or the particular domain of the business that the system is to serve). In microelectronics, an uncommitted array is a silicon chip that is made as a standard component but, in the final stage of manufacture, is committed to a specific customer application, such as the video circuitry for a games machine or the ignition control system of a car. Similarly, an uncommitted software model represents a business in generalized form but can be committed (or recommitted) to a particular product set, market channel structure, or business organization.

For some years, there has been limited implementation of this concept in the form of tailorable software packages, which are now gaining in popularity. Here, the user organization has the ability to choose between a number of options (possibly a very large number), predetermined by the vendors of the package. In a truly uncommitted software model, however, the designers have not attempted to foresee all the possible configurations. It is like the difference between a model car that can be customized with decals and accessories, and a Lego set.

Designers of children’s construction sets face a constant trade-off. Versatility requires more different kinds of components and lower-level components (individual wheels and bricks). Ease of construction demands fewer components, and this typically translates to ready-made subassemblies, like a vehicle cab or house roof. Designers can partially overcome this by creating powerful high-level components that take on several different roles. This principle is called “abstraction,” and it is the key to building powerful uncommitted software models of the business. The following example illustrates why:

Three years ago, the Bradford & Bingley Building Society (roughly equivalent to a savings bank) replaced most of its systems portfolio with a new system, developed from scratch and based on an uncommitted business model. The old system was proving increasingly costly to maintain and needed replacement anyway. The principal objective, and the reason for the choice of approach, was a system that no longer constrained innovation. The chief executive himself stated that he did not want to be told that he could not implement an organizational or product change because the system would take two years to modify — a clear, if negatively stated, call for an expressive system.

Within Bradford & Bingley’s system is a generic products engine, which is built around such a generalized concept of a savings product that it is capable of also serving as a loan or insurance product. Each product is attached, not to a customer, but to a more abstract software construct known as “associate” — defined as a party with which the firm has a relationship. More specific versions of associate include the conventional notion of customer, but also agents and branches (retail outlets). By making all other parts of the software interface with the abstract or common version of these specific entities, a decision to change an agent-based product to a branch-based product has no external impact. Equally, if the firm decided to launch a specialized savings product for its own employees, which might entail special terms or security arrangements, it merely requires a new specialized subclass of associate called “employee,” but no change to the product engine. Bradford & Bingley’s system also has generic software engines for document creation, for the management of workflow in an administrative process, and for managing selected groups of associates for marketing.

Abstraction is not a new concept in information systems; indeed, it is a basic principle of data modeling, but there have been few attempts to apply this to the functionality (i.e., the code) of systems. Historically, the view has been that code needs to be written to meet the specific needs of an individual application. To the extent that there has been any reuse of existing code, it has been at a very technical level: reusable subroutines for implementing a complex mathematical function or for managing computer resources. Little attention has been given to identifying generic or abstract business functions and implementing these as reusable components.

The advent of object orientation is changing this by replacing the artificial separation of code and data with the more natural concept of self-contained objects. A software object completely models a component of the business domain: it contains the data that represents that component and all the functionality that may change or interact with that data.

Object orientation has a natural fit with expressive systems in several ways: it underpins most sophisticated graphical user interfaces and facilitates the construction of reusable components. However, the greatest significance of object orientation, and the one least understood by most IS professionals, is its ability to support business abstraction. Two principles of object orientation apply here. The first is called inheritance, which facilitates the creation and management of specialized subclasses of objects, as in the relationship between associate and customer. The second is called “polymorphism,” in which different objects execute different code in response to the same message. A spreadsheet and a word-processed document can both respond to the message “print,” but the way they perform that function will be different. Polymorphism simply reflects the reality that, in business, there are fewer things we want to do than ways we want to do them. Expressive systems should provide the support for the generic things we want to do, and the user’s application of that capability implements the particular way it is to be done.

The New IS Department

What kind of IS department will be needed to implement and/or support information systems that are based primarily on the expressive systems model? No single organization that we have encountered has yet completed this transition, but those who have partially moved toward expressive systems have had enough experience that we can piece together a plausible model for the future IS department. Organizations that identify with the potential benefits of expressive systems must recognize that implementing the concept is as much about changing the structure and behavior of the IS department as it is about changing the technology.

The first distinction between this future model and the IS department of today is in the realm of values, attitudes, and beliefs. Take the widespread belief that “If only we could get the users to specify exactly what it is they require, then our problems would be solved.” The concept of expressive systems, unlike iterative development, is not based on the notion that users have difficulty expressing their exact requirements; it is based on the realization that increasingly users cannot state their requirements completely because they themselves cannot know all the business conditions and events they will be facing.

A second distinction concerns the role of systems themselves. In the future model, the role of systems is primarily to facilitate change. This means that the IS department must anticipate business change. It does not mean that IS must predict business change; rather it means that it must build systems that are resilient to future change through the use of abstraction, componentization, and rewirable infrastructure.

Thirdly, IS professionals must change their current beliefs about the difference between developers and users. The distinction has been historically valid because the user and developer dealt with different views of the same system. The developer’s view comprised lines of programming code, data structures, and operating system calls, which together form a high-level representation of the computer’s resources. The user’s view comprised menus of commands, forms to be filled, queries and reports, which together form a representation of the specific business operations being supported. It is the translation between these two representations that makes conventional systems development such a time-consuming, arduous process. Expressive systems resolve the problem by having the developer and the user share the same representation — a representation of the natural components and structure of the problem domain rather than a specific solution to it.11

Consider, for example, a spreadsheet. Its success lies in the fact that its constructs (tables, cells, and formulas) are a very natural representation of the structure of financial modeling problems and are suited to both very simple and very complex applications. If you have used a spreadsheet, you have almost certainly developed an application; moreover, between developing the spreadsheet and using the resulting application, there is no switch in the representation used. There is a clear distinction between the authors of the spreadsheet package (Microsoft or Lotus, say) and the user/developers, but this is not the same relationship as between conventional systems developers and users.

It is a curious fact that while many IS departments acknowledge the very sophisticated spreadsheet applications within their businesses, few provide any real support for spreadsheet development. Indeed, there is often an underlying cynicism with regard to end-user development in general. Professional developers are fond of quoting surveys demonstrating that 70 percent of all spreadsheets contain some kind of error but are less keen to help reduce those errors.

In the expressive systems era, professional developers still have roles to play, but those roles will change. Some will be deployed in the creation, management, and continuous enhancement of the infrastructure. This, we believe, will divide into three processes: “Business model maintenance” will be concerned exclusively with the uncommitted software model. Its developers will be high-caliber abstract thinkers, and a key issue will be the communication of the knowledge of this model to those applying it. The second process is concerned with the technologies that support the business model. One of the keys will be ensuring that significant new technologies are introduced to the system in the form of generic infrastructure services, rather than as specific applications. The final process we might call technology services, which most closely resembles the IS operations function today, except that it will be concerned with monitoring and improving performance at the level of individual software components rather than just of whole systems.

The professional developers’ other role will be to act as mentors within the application process.12 For example, in the sales and marketing department of Clorox Company, developers have completely adopted this role. In 1985, Clorox installed one of the earliest, truly expressive data retrieval and manipulation packages, Metaphor (which was also an early example of an object-oriented system). In Metaphor, users write modules or capsules and then visually wire the capsules together to generate the reports or screens they require. Almost 150 people in the sales and marketing department use Metaphor intensively, and they are supported by between one and three systems professionals, as needs vary. As part of their mentoring role, the professionals look for commonality in capsules written by different users. The professionals rewrite those versions into a standard, robust, more flexible capsule and offer it around to all the users (who themselves often share capsules with each other via e-mail). The notion of improving user-developed systems would be anathema to many systems professionals. But Clorox has found that the net ratio of functionality created to professional systems input exceeds every other application of information systems in the company — which more or less sums up the case for expressive systems.