The derivatives business is highly complex, involving rapidly changing products and a great variety of trading term structures, marketing approaches, and risk management strategies. Information systems that support the derivatives business must therefore be extensible, adaptable, and responsive to rapid changes. The domain complexity of derivatives, however, poses a fundamental problem in building such systems. Technology specialists lack the domain expertise to react rapidly to changes, while business users lack the technology skills to maintain the systems. Such a gap between technology specialists and business users—referred to as the Business-Technology gap (B-T gap)—results in excessive reliance of both groups on each other to institute changes rapidly. Realizing the need for flexibility and agility, the derivatives business at Bankers Trust Australia Limited (BTAL) embarked on the Arcadia project in 1994. The goal of the Arcadia project was to build a component-based end-user computing architecture to bridge the B-T gap.
Pre-defined components allow business users to be self-reliant and to assemble their own applications on demand. We define components as abstract, self-contained packages of functionality performing a specific business function within a technology framework [2]. These business components are reusable with well-defined interfaces. However, creating and using business components are nontrivial tasks; there are many technical and organizational issues that impede successful deployment (see [8] for an excellent overview). While much of the literature emphasizes the technical issues, critical organizational issues such as the B-T gap itself and efforts to minimize this gap have received little attention. Although the concept of a B-T gap is not new [4, 5, 10], this case study highlights the impact of component technology on the B-T gap and reinforces the importance of shared knowledge and cultural issues in bridging the gap. There is, in fact, a two-way effect—the B-T gap affects business components and vice versa. This article takes a holistic view to discuss the successful implementation of a business component architecture at BTAL.
We begin with some brief background information on the derivatives business. The derivatives business fundamentally sells risk services, transferring risk from an external party to the bank, which then manages the financial risk. It deals with derivative instruments that involve buying or selling contracts of financial assets where the value of the contracts is derived from the price of the underlying asset (for example, options contracts, forward contracts, future contracts and swap agreements). The derivatives business ranks among the most complex and risky financial services. Speed, flexibility, and agility are important attributes because millions of dollars can be gained or lost within seconds.
The Business-Technology Gap
The B-T gap is exemplified as the clash of subcultures arising from the fundamentally different assumptions regarding information technology (IT) held by the business and technology groups [9]. Business users often assume that IT solutions are inadequate at capturing the dynamic, holistic, and imprecise nature of information, are often difficult to learn and can be perceived as threatening to management control and the organizational structure. In contrast, the typical techno-centric assumptions blame any shortcomings in the delivery of IT on inadequacies of the business group in using the technology. The extent of the B-T gap has serious implications for the risks and benefits of component-based architecture since the gap hinders the development, deployment, and adoption of components. Further compounding the effect is the type of business processes within an organization.
Table 1 summarizes the risks and benefits associated with the type of complex process (static or dynamic) and the extent of the B-T gap (small and large). Our analysis does not consider simple business processes since the efforts required to deploy a component-based architecture cannot be justified. Similarly, complex processes that are static do not exploit the advantages of component technology reuse and subsequently do not provide sufficient returns on investment (Cells 1 and 3). Conversely, components have significant benefits when business processes change rapidly (are dynamic), yet, the risks are high when the B-T gap is large (Cell 4). A large gap impedes the creation of components that encapsulate organizational knowledge since it results in poor communication between IT specialists and business users. Consequently, the ideal situation for component-based architecture is when the extent of the B-T gap is low and business processes are complex and dynamic as shown in Table 1 (Cell 2).
BTAL’s business processes were complex and rapidly changing so the component-based architecture could potentially provide significant benefits. However, because the associated risks depended largely on the level of the B-T gap, BTAL needed to reduce the gap to lower the risks and to maximize the benefits (that is, by moving from Cell 4 to Cell 2). When the Arcadia project was conceived, both the business users and technology specialists attempted to bridge this gap by creating a new subculture based on shared mental models. Such an approach, supported by collaboration and a socialization process, created overlapping knowledge and necessary information redundancy to enhance mutual understanding [5, 7, 9]. BTAL initiated educational and training programs where business users improved their technology skills and technology specialists learned the derivatives business. BTAL also actively instituted appropriate reward systems for both users and IT specialists. In addition, the component-based architecture itself provided some impetus to further lowering the B-T gap. Components hide technical details from users while promoting a common language for communication.
A series of actions taken in phases before, during, and after the development of Arcadia supported the efforts to further minimize the B-T gap (Lesson #1). The critical issues before the development phase were the management of expectations, identification of business users’ technology skills, and choosing the appropriate technology for implementation. During the development phase, issues involved the selection of a project team, sharing of business knowledge, training, and gradual buy-in of business users into the new architecture. The post-development phase included the understanding of component usage, analyzing performance gains and planning for gradual diffusion into the organization. These actions—both technical and organizational—made component-based architecture ideally suited to BTAL’s complex and dynamic business processes.
Pre-Development Phase
The pre-Arcadia infrastructure—stovepipe legacy systems, macros within spreadsheets and complex pricing libraries written in the C programming language—required dependence on the IT staff for coding queries and maintenance, limiting traders’ flexibility and agility. Although the traders appreciated the need for a new IT architecture that would allow them to become more self-reliant, they could not afford to sit for long hours explaining trading strategies to technology experts and were reluctant to learn an entirely new system since business risks were very high. Overall, the pragmatic choice for an application front end was to continue using the familiar spreadsheet to avoid disruption and the need for training (Lesson #2).
Solution choices. BTAL examined several alternatives for the new infrastructure. Criteria used for evaluation of these choices included cost, risk, customization, possible disruption of day-to-day activities, vendor reliance, and the effect on the B-T gap. Figure 1 describes the decision process that led to in-house business component development. Vendor solutions, estimated as much more expensive than in-house development, gave BTAL less control for satisfying internal decision-making strategies and responding quickly to business changes. Even more significant, the vendor solutions, in a similar way to ERP systems, were risky and possibly highly disruptive since they necessitated a large-scale implementation that compelled most users to change their usage behavior at the same time. This risk was associated with forcing users to adapt to the technology instead of adapting the technology to the users. Although frameworks such as the Infinity Financial Technology’s Fin++ had merit, they were generic and therefore required significant customization that would lead to even more dependence on the vendor. Overall, BTAL perceived a vendor solution would not necessarily promote a closer B-T working relationship, nor bridge the B-T gap.
The technical framework for in-house development was analyzed from three different perspectives. A fourth alternative, Java RMI, was not considered mature enough technology at the time the Arcadia project was initiated. The Smalltalk option had inherent appeal for its ability to create high-quality and extensible systems, supporting an iterative and dynamic development methodology (being a late binding language), allowing incremental and instantaneous compilation, and serving as a 4GL scripting language [3]. Although BTAL had significant Smalltalk experience, Smalltalk was too closed an environment and it would require traders to adapt to a whole new way of interacting with systems. Similarly, BTAL also rejected the traditional object-oriented option since it required extensive changes to the infrastructure, and the business users would have to undergo significant relearning and training.
The component-based option provided many advantages. It allowed the IT group to leverage the users’ competency, skills, and familiarity with Excel spreadsheets while developing a robust system behind it. The traders’ experience in using pricing libraries within spreadsheets facilitated their understanding of functionalities as components (Lesson #3). Also, the maturing Distributed Common Object Module (DCOM) standards—a strategic Microsoft architecture—provided a pragmatic solution for integration of end-user applications and domain components on the desktop (Lesson #4). With the base platform Windows NT, BTAL was keen on minimizing the number of vendors involved in technical support. In the context of the time, DCOM was considered a leading-edge approach when the project started and, therefore there existed some technical risk inherent in being an early user. However, since DCOM was evolving very quickly on a narrow front, the risk was relatively low compared to the alternative—CORBA—a technology that was moving slowly, albeit on a very broad front of services and facilities.
Development Phase
Since there was some apprehension of the relatively new and untested component-based software development within BTAL, the Arcadia project itself was kept low-key. It was decided early in the project that users should not be mandated to use the infrastructure since the new architecture required a significant cultural change in how they used the technology. Instead, adoption would be facilitated by demonstrating the ease-of-use of components. BTAL’s strategy was to induce senior business management and users to evangelize the technology leading to a natural word-of-mouth diffusion within the organization (Lesson #5). This would avoid intimidating users with component language such as “object orientation, inheritance, delegation, aggregation, specialization, and metaobjects.”
Given the complexity of the task, the decision to keep the group small in the development stage seemed appropriate. At first, this appears to contradict most research studies, which stress the importance of involving users early during the requirements analysis stage. One could rationalize this low-key and small group strategy by understanding the fundamental differences between the current project and traditional system development. This approach was more an apprentice model that involved an exploratory approach. A smaller group also promoted closer relationships among team participants, and enhanced direct communication and coordination. The project group—somewhat unusual—included three developers, two key business drivers, and five business users (super users), who provided feedback from testing and validating the components. The key business drivers, (one was an expert in mathematical modeling and another a business manager), were detail-oriented and knew the complex derivatives business well. While a great deal of component literature discusses a high-level abstraction, what was really needed was an understanding of the complex details that could then be abstracted to higher levels through rapid iteration (Lesson #6). This project also deviated from the traditional norms of rapid prototyping; this prototype phase was designed to be a lengthy process. In hindsight, this seems to be a reasonable strategy since the process steps—identifying, defining and refining interface specification, configuration, and verification—were highly iterative (Lesson #6).
The project team also kept a historical audit trail of the business and technology decision making process in Lotus Notes. This discussion forum facilitated coordination and asynchronous communication, and the management of a multitude of diverse interactions among the members. Another issue critical for the development was the incentive scheme to retain the core technical group. A culture with bonus incentives based on performance and underlying profit of the business group was key to this project. Performance was evaluated based on the value to the business, quality, long-term as well as short-term delivery, teamwork, and knowledge sharing. Incentives were also tied to the level of reuse resulting from the project.
Component building process. The first step in developing the components was to construct a framework consisting of six layers: presentation layer, business process, business components, foundation components, persistent data, and (distributed) computing infrastructure. The highest layer (presentation layer) is the most dynamic in nature while the computing infrastructure is the most stable. An example of a layered architecture for derivatives business is illustrated in Figure 2. Of interest in this case study are the business process, business components, and the foundation components layers. The foundation components are a set of reusable modules that perform specific tasks, such as modules to execute mathematical models, and rule specification. These components are relatively stable. Business components are a collection of foundation components and higher-level abstractions that perform certain tasks of a business process. For example, the instrument components comprise high-level abstractions of financial instruments and mappings to underlying math models for pricing. A business component may be used in one or more business processes. The business process uses a collection of business components, designed such that they can exist on their own requiring minimal communication with other business components. It is important to stress that designing a generic component is one of the most difficult tasks in this type of software development.
Although the framework development seems quite straightforward there were many challenges during the design stage. The first problem was to identify component candidates and to arrive at the boundaries and scope of these components (see Figure 3). This process of identifying, specifying, and implementing components was a highly iterative process. The lack of component development experience and the lack of sophisticated tools to support these activities further complicated the development process. The actual phases involved, represented in Figure 3, show an iterative process [2]. Therefore, the prototype development itself was time consuming and a long process (Lesson #6). Nevertheless, the investment in time was worthwhile, since the prototype components needed minimal modification to reach production-scale standards. The time needed was further extended because of the need to build some underlying component infrastructure in C++, which unlike Smalltalk, meant programmers had to deal with infrastructure details such as garbage collection.
There were many other technical challenges present in any modern component infrastructure that hindered development and deployment: efficiency of operation, portability of kernel software, component deployment process space, and management of remote objects and persistent objects. The components had to execute fast, which required infrastructure overhead to be kept at a minimum. All infrastructure items were developed as a layer around the kernel. Thus the kernel was independent of the infrastructure. This approach preserved the portability of the core software but allowed the infrastructure to be fully exploited. However, this approach meant that a component-to-object mapping layer had to be developed. The mapping of objects to relations also became an issue for user interface and persistent data management. Finally, the component deployment model that was used packaged components into a separate process space rather than operating within the various client programs’ process space.
Post-Development Phase
Following the development of Arcadia, BTAL took further steps to minimize the B-T gap by analyzing component usage and benefits. Within BTAL, many users became aware of the benefits of component-based architecture from viewing discussion threads in Lotus Notes that documented the rationale for decisions made. Interestingly, traders—who were reluctant to produce paper specifications—documented partial specifications for new components as required. This was a remarkable change in a culture from one of informality to some degree of formality facilitated by easy-to-use technology and a desire to share knowledge.
The components encapsulated shared knowledge created from collaboration and socialization between users and technologists [5, 7] at many points in the iterative cycle. For example, collaborative decisions were made on the identification of candidate components, selection of components, and the usage dependencies between components. Over time, BTAL created a collection of components that captured the relatively static aspects of its derivatives business knowledge. A portfolio business component, for example, abstracted a collection of financial instruments widely used throughout BTAL. As users increasingly accessed the business components from the repository, the encapsulated organizational knowledge was reinforced and reused, reducing the need to “reinvent the wheel” [6]. Moreover, the encapsulated knowledge within the static components lowered learning barriers to facilitate diffusion [1] throughout BTAL and to other international divisions. Figure 4 shows the organizational learning cycle using the component-based architecture.
With the deployment of components, the way in which business users (traders) interact with IT and technology specialists changed significantly. As traders realized the power of Arcadia, they found spreadsheets a hindrance. In fact, spreadsheets have been replaced for most core processes. However, the changes occurred imperceptibly with minimal re-learning and training. IT specialists and business users have increased their productivity as their roles changed. The business users assemble and script their own applications along with IT specialists, and now have better control of their business processes. At the same time, IT specialists focus on optimizing the performance of applications scripted by business users (Lesson #7).
Measuring success. The success of Arcadia can be measured in terms of the level of diffusion within BTAL and the interest generated in other global operations of Bankers Trust. Arcadia has now expanded to the equities and foreign exchange businesses, and is now being tested by the BT global metals and mining business in London. The number of traders and back office staff using this infrastructure has grown to more than 80 and is expanding rapidly. The actual benefits of this project are difficult to establish since they are realized over the long-term. However, the cost of developing components in C++ is relatively small compared to the cost of alternative systems. Initially, BTAL hoped there would be reuse of components, but did not plan or focus on reuse outside the derivatives business. Reuse was not a show stopper or factor that would prevent the project from proceeding (Lesson #8). Nevertheless, the level of reuse has been a surprising business benefit that is currently being experienced in many parts of Bankers Trust. Assuming 30% of the cost of the components is just the initial development and the rest for maintaining, enhancing, and managing components over the project’s lifetime, then the leverage from the reuse is actually quite high. Arcadia is either being reused or targeted for reuse in at least nine different types of applications. So from just an overall cost/benefit perspective, an estimate of the present value of the opportunity cost saved is well over $40 million (in Australian dollars). With the expected reuse of not just the components, but the architecture itself in other parts of the business, the much-touted benefits of components seem to have been realized—albeit at an unexpected level.
Conclusion
One of the important objectives of component-based systems is to provide business users the ability to assemble their own applications. In that respect, the Arcadia project has been highly successful. The component-based architecture appeared ideally suited to BTAL’s complex and dynamic business processes. Yet, certain key decisions from an organizational perspective were critical to the success of this project. These included a sincere effort to reduce the B-T gap, development of a shared knowledge base, voluntary acceptance rather than mandatory usage, and leveraging business users’ existing skills. The Arcadia project has been a continuous learning experience for BTAL. The development process has been highly iterative and sometimes unconventional, since traditional system design methodologies appeared unsuitable. The problems were compounded by a lack of good tools and experience in developing components. Therefore, the entrepreneurial approach (an apprentice model) with a high-degree of persistence that BTAL adopted seemed appropriate. The project itself was kept low-key throughout the development process to manage expectations. Furthermore, BTAL relied on gradual diffusion through word-of-mouth from senior management and users. Now, components are used for all core computations, while spreadsheets are used primarily for interaction and experimentation. BTAL showed that effective collaboration bridges the B-T gap and results in a successful implementation of component-based applications with a significant business value for the organization.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment