Many organizations are successful with software reuse at fine to medium granularities ranging from objects, subroutines, and components through software product lines. However, relatively little has been published on very large-grained reuse. One example of this type of large-grained reuse might be that of an entire Internet banking system (applications and infrastructure) reused in business units all over the world. In contrast, “large scale” software reuse in current research generally refers to systems that reuse a large number of smaller components, or that perhaps reuse subsystems.9 In this article, we explore a case of an organization with an internal development group that has been very successful with large-grained software reuse.
BigFinancial, and the BigFinancial Technology Center (BTC) in particular, have created a number of software systems that have been reused in multiple businesses and in multiple countries. BigFinancial and BTC thus provided a rich source of data for case studies to look at the characteristics of those projects and why they have been successful, as well as to look at projects that have been less successful and to understand what has caused those results and what might be done differently to prevent issues in the future. The research is focused on technology, process, and organizational elements of the development process, rather than on specific product features and functions.
Supporting reuse at a large-grained level may help to alleviate some of the issues that occur in more traditional reuse programs, which tend to be finer-grained. In particular, because BigFinancial was trying to gain commonality in business processes and operating models, reuse of large-grained components was more closely aligned with its business goals. This same effect may well not have happened with finer-grained reuse, due to the continued ability of business units to more readily pick and choose components for reuse.
BTC is a technology development unit of BigFinancial, with operations in both the eastern and western US. Approximately 500 people are employed by BTC, reporting ultimately through a single line manager responsible to the Global Retail Business unit head of BigFinancial. BTC is organized to deliver both products and infrastructure components to BigFinancial, and its product line has through the years included consumer Internet banking services, teller systems, ATM software, and network management tools. BigFinancial has its U.S. operations headquartered in the eastern U.S., and employs more than 8,000 technologists worldwide.
In cooperation with BTC, we selected three cases for further study from a pool of about 25. These cases were the Java Banking Toolkit (JBT) and its related application systems, the Worldwide Single Signon (WSSO) subsystem, and the BigFinancial Message Switch (BMS).
Background Software Reuse and BigFinancial
Various definitions appear in the literature for software reuse. Karlsson defines software reuse as “the process of creating software systems from existing software assets, rather than building software systems from scratch.” One taxonomy of the approaches to software reuse includes notions of the scope of reuse, the target of the reuse, and the granularity of the reuse.5 The notion of granularity is a key differentiator of the type of software reuse practiced at BigFinancial, as BigFinancial has demonstrated success in large-grained reuse programs building a system once and reusing it in multiple businesses.
Product Line Technology models, such as that proposed by Griss4 and further expanded upon by Clements and Northrop2 and by Krueger6 suggest that software components can be treated similarly to the notions used in manufacturing reusable parts that contribute to consistency across a product line as well as to improved efficiencies in manufacturing. Benefits of such reuse include the high levels of commonality of such features as user interfaces,7 which increases switching costs and customer loyalty in some domains. This could logically extend to banking systems in the form of common functionality and user interfaces across systems within a business, and across business units.
BigFinancial has had several instances of successful, large-grained reuse projects. We identified projects that have been successfully reused across a wide range of business environments or business domains, resulting in significant benefit to BigFinancial. These included the JBT platform and its related application packages, as well as the Worldwide SSO product. These projects demonstrated broad success, and the authors evaluated these for evidence to identify what contributed to, and what may have worked against, the success of each project.
The authors also identified another project that has been successfully reused across a relatively narrow range of business environments. This project, the BigFinancial Message Switch (BMS) was designed for a region-wide level of reuse, and had succeeded at that level. As such, it appears to have invested appropriately in features and capabilities needed for its client base, and did not appear to have over-invested.
Online banking and related services
We focused on BTC’s multi-use Java Banking Toolkit (JBT) as a model of a successful project. The Toolkit is in wide use across multiple business units, and represents reuse both at the largest-grained levels as well as reuse of large-scale infrastructure components. JBT supports three application sets today, including online banking, portal services, and alerts capabilities, and thus the JBT infrastructure is already reused for multiple applications. To some extent, these multiple applications could be studied as subcases, though they have thus far tended to be deployed as a group. In addition, the online banking, portal services, and alerts functions are themselves reused at the application level across multiple business units globally.
Initial findings indicated that several current and recent projects showed significant reuse across independent business units that could have made alternative technology development decisions. The results are summarized in Table 1.
While significant effort is required to support multiple languages and business-specific functional variability, BTC found that it was able to accommodate these requirements by designing its products to be rule-based, and by designing its user interface to separate content from language. In this manner, business rules drove the behavior of the Internet banking applications, and language- and format-definition tools drove the details of application behavior, while maintaining a consistent set of underlying application code.
In the late 1990s, BTC was responsible for creation of system infrastructure components, built on top of industry-standard commercial operating systems and components, to support the banking functionality required by its customers within BigFinancial. The functions of these infrastructure components included systems management, high-reliability logging processes, high-availability mechanisms, and other features not readily available in commercial products at the time that the components were created. The same infrastructure was used to support consumer Internet banking as well as automated teller machines. The Internet banking services will be identified here as the Legacy Internet Banking product (LIB).
BigFinancial’s initial forays into Internet transaction services were accomplished via another instance of reuse. Taking its pre-Internet banking components, BTC was able to “scrape” the content from the pages displayed in that product, and wrap HTML code around them for display on a Web browser. Other components were responsible for modifying the input and menuing functions for the Internet.
The purpose for this approach to Internet delivery was to more rapidly deliver a product to the Internet, without modification of the legacy business logic, thereby reducing risk as well. In what amounted to an early separation of business and presentation logic, the pre-Internet business logic remained in place, and the presentation layer remapped its content for the browser environment.
In 2002, BigFinancial and BTC recognized two key issues that needed to be addressed. The platform for their legacy Internet Banking application was nearing end of life (having been first deployed in 1996), and there were too many disparate platforms for its consumer Internet offerings. BTC’s Internet banking, alerts, and portal functions each required separate hardware and operating environments. BTC planned its activities such that the costs of the new development could fit within the existing annual maintenance and new development costs already being paid by its clients.
BTC and business executives cited trust in BTC’s organization as a key to allowing BTC the opportunity to develop the JBT product. In addition, BTC’s prior success with reusing software components at fine and medium granularities led to a culture that promoted reuse as a best practice.
Starting in late 2002, BTC developed an integrated platform and application set for a range of consumer Internet functions. The infrastructure package, named the Java Banking Toolkit (JBT), was based on Java 2 Enterprise Edition (J2EE) standards and was intended to allow BigFinancial to centralize its server infrastructure for consumer Internet functions. The authors conducted detailed interviews with several BTC managers and architects, and reviewed several hundred documents. Current deployment statistics for JBT are shown in Table 2.
The JBT infrastructure and applications were designed and built by BTC and its regional partners, with input from its clients around the world. BTC’s experience had shown that consumer banking applications were not fundamentally different from one another across the business units, and BTC proposed and received funding for creation of a consolidated application set for Internet banking. A market evaluation determined that there were no suitable, globally reusable, complete applications on the market, nor any other organization with the track record of success required for confidence in the delivery. Final funding approval came from BigFinancial technology and business executives.
The requirements for JBT called for several major functional elements. The requirements were broken out among the infrastructural elements supporting the various planned application packages, and the applications themselves. The applications delivered with the initial release of JBT included a consumer Internet banking application set, an account activity and balance alerting function, and a portal content toolset.
Each of these components was designed to be reused intact in each business unit around the world, requiring only changes to business rules and language phrases that may be unique to a business. One of the fundamental requirements for each of the JBT applications was to include capabilities that were designed to be common to and shared by as many business units as possible, while allowing for all necessary business-specific variability.
Such variability was planned for in the requirements process, building on the LIB infrastructure and applications, as well as the legacy portal and alerts services that were already in production. Examples of the region- and business-specific variability include language variations, compliance with local regulatory requirements, and functionality based on local and regional competitive requirements.
JBT’s initial high-level requirements documents included requirements across a range of categories. These categories included technology, operations, deployment, development, and tools. These requirements were intended to form the foundation for initial discussion and agreement with the stakeholders, and to support division of the upcoming tasks to define the architecture. Nine additional, more detailed, requirements documents were created to flesh out the details referenced in the top-level requirements. Additional topics addressed by the detailed documents included language, business rules, host messaging, logging, portal services, and system management.
One of BigFinancial’s regional technology leaders reported that JBT has been much easier to integrate than the legacy product, given its larger application base and ability to readily add applications to it. Notably, he indicated that JBT’s design had taken into account the lessons learned from prior products, including improvements in performance, stability, and total cost of ownership. This resulted in a “win/win/win for businesses, technology groups, and customers.”
From an economic viewpoint, BigFinancial indicates that the cost savings for first-time business unit implementations of products already deployed to other business units averaged between 20 and 40%, relative to the cost of new development. Further, the cost savings for subsequent deployments of updated releases to a group of business units resulted in cost savings of 50% 75% relative to the cost of maintaining the software for each business unit independently.
All core banking functionality is supported by a single global application set. There remain, in some cases, functions required only by a specific business or region. The JBT architecture allows for those region-specific applications to be developed by the regional technology unit as required. An overview of the JBT architecture is shown in Figure 1.
BTC implemented JBT on principles of a layered architecture,12 focusing on interoperability and modularity. For example, the application components interact only with the application body section of the page; all other elements of navigation and branding are handled by the common and portal services elements. In addition, transactional messaging is isolated from the application via a message abstraction layer, so that unique messaging models can be used in each region, if necessary.
JBT includes both the infrastructure and applications components for a range of banking functionality. The infrastructure and applications components are defined as independently changeable releases, but are currently packaged as a group to simplify the deployment process.
Funding and governance of the projects are coordinated through BTC, with significant participation from the business units. Business units have the opportunity to choose other vendors for their technology needs, though the corporate technology strategy limited that option as the JBT project gained wider rollout status. Business units participate in a semi-annual in-person planning exercise to evaluate enhancement requests and prioritize new business deployments.
Results
The authors examined a total of six different cases of software reuse. Three of these were subcases of the Java Banking Toolkit (JBT) Internet banking, portal services, and alerts, along with the reuse of the JBT platform itself. The others were the Worldwide SSO product, and the BigFinancial Message Switch. There were a variety of reuse success levels, and a variety of levels of evidence of anticipated supports and barriers to reuse. The range of outcomes is represented as a two dimensional graph, as shown in Figure 2.
BigFinancial measures its reuse success in a very pragmatic, straightforward fashion. Rather than measuring reused modules, lines of code, or function points, BigFinancial instead simply measures total deployments of compatible code sets. Due to ongoing enhancements, the code base continues to evolve over time, but in a backwards-compatible fashion, so that older versions can be and are readily upgraded to the latest version as business needs dictate.
BTC did not explicitly capture hard economic measures of cost savings. However, their estimates of the range of cost savings are shown in Figure 3. Cost savings are smaller for new deployments due to the significant effort required to map business unit requirements to global product capabilities, along with the cost of training, development and testing of business rules, and ramp-up of operational processes. In contrast, ongoing maintenance savings are generally larger, due to the commonality across the code base for numerous business units. This commonality enables bug fixes, security patches, and other maintenance activities to be performed on one code base, rather than one for each business unit.
BigFinancial has demonstrated that it is possible for a large organization, building software for its own internal use, to move beyond the more common models of software reuse. In so doing, BigFinancial has achieved significant economies of scale across its many business units, and has shortened the time to market for new deployments of its products.
Numerous factors were critical to the success of the reuse projects. These included elements expected from the more traditional reuse literature, including organizational structure, technological foundations, and economic factors. In addition, several new elements have been identified. These include the notions of trust and culture, the concepts of a track record of large-and fine-grained reuse success, and the virtuous (and potentially vicious) cycle of corporate mandates. Conversely, organizational barriers prove to be the greatest inhibitor to successful reuse.13
BTC took specific steps, over a period of many years, to create and strengthen its culture of reuse. Across numerous product lines, reuse of components and infrastructure packages was strongly encouraged. Reuse of large-grained elements was the next logical step, working with a group of business units within a single regional organization. This supported the necessary business alignment to enable large-grained reuse. In addition, due to its position as a global technology provide to BigFinancial, BTC was able to leverage its knowledge of requirements across business units, and explicitly design products to be readily reusable, as well as to drive commonality of requirements to support that reuse as well.
On the technical factors related to reuse, BTC’s results have provided empirical evidence regarding the use of various technologies and patterns in actual reuse environments. Some of these technologies and patterns are platform-independent interfaces, business rule structures, rigorous isolation of concerns across software layers, and versioning of interfaces to allow phased migration of components to updated interfaces. These techniques, among others, are commonly recognized as good architectural approaches for designing systems, and have been examined more closely for their contribution to the success of the reuse activities. In this examination, they have been found to contribute highly to the technological elements required for success of large-grained reuse projects.
Product vendors, and particularly application service providers, routinely conduct this type of development and reuse, though with different motivations. (Application service providers are now often referred to as providers of Software as a Service.) As commercial providers, they are more likely to be market-driven, often with sales of Professional Services for customization. In contrast, the motivations in evidence at BigFinancial seemed more aimed at achieving the best combinations of functionality, time to market, and cost.
The research provided an opportunity to examine, in-depth, the various forms of reuse practiced on three projects, and three subprojects, inside BigFinancial. Some of those forms include design reuse, code reuse, pattern reuse, and test case reuse. The authors have found based on documents and reports from participants that the active practice of systematic, finer-grained reuse contributed to successful reuse of systems at larger levels of granularity.
This study has provided a view of management structures and leadership styles, and an opportunity to examine how those contribute to, or work against, successful reuse. Much has been captured about IT governance in general, and about organizational constructs to support reuse in various situations at BigFinancial/BTC. Leadership of both BTC and BigFinancial was cited as contributing to the success of the reuse efforts, and indeed also was cited as a prerequisite for even launching a project that intends to accomplish such large-grained reuse.
Sabherwal11 notes the criticality of trust in outsourced IS relationships, where the participants in projects may not know one another before a project, and may only work together on the one project. As such, the establishment and maintenance of trust is critical in that environment. This is not entirely applicable to BTC, as it is a peer organization to its client’s technology groups, and its members often have long-standing relationships with their peers. Ring and Van de Ven examine the broader notions of cooperative inter-organizational relationships (IOR’s), and note that trust is a fundamental part of an IOR. Trust is used to serve to mitigate the risks inherent in a relationship, and at both a personal and organizational level is itself mitigated by the potential overriding forces of the legal or organizational systems.10 This element does seem to be applicable to BTC’s environment, in that trust is reported to have been foundational to the assignment of the creation of JBT to BTC.
Griss notes that culture is one element of the organizational structure that can impede reuse. A culture that fears loss of creativity, lacks trust, or doesn’t know how to effectively reuse software will not be as successful as an organization that doesn’t have these impediments.4 The converse is likely then also reasonable that a culture that focuses on and implicitly welcomes reuse will likely be more successful. BTC’s long history of reuse, its lack of explicit incentives and metrics around more traditional reuse, and its position as a global provider of technology to its business partners make it likely that its culture, is, indeed a strong supporter of its reuse success.
Several other researchers have commented on the impact of organizational culture on reuse. Morisio et al8 refer in passing to cultural factors, primarily as potential inhibitors to reuse. Card and Comer1 examine four cultural aspects that can contribute to reuse adoption: training, incentives, measurement, and management. In addition, Card and Comer’s work focuses generally on cultural barriers, and how to overcome them. In BTC’s case, however, there is a solid cultural bias for reuse, and one that, for example, no longer requires incentives to promote reuse.
One key participant in the study had a strong opinion to offer in relation to fine- vs. coarse-grained reuse. The lead architect for JBT was explicitly and vigorously opposed to a definition of reuse that slanted toward fine-grained reuse of objects and components at a fine-grained level. This person’s opinion was that while reuse at this granularity was possible (indeed, BTC demonstrated success at this level), fine-grained reuse was very difficult to achieve in a distributed development project. The lead architect further believed that the leverage it provides was not nearly as great as the leverage from a large-grained reuse program. The integrators of such larger-grained components can then have more confidence that the component has been used in a similar environment, tested under appropriate loads, and so on relieving the risk that a fine-grained component built for one domain may get misused in a new domain or at a new scale, and be unsuccessful in that environment.
While BTC’s JBT product does, to some extent, work as part of a software product line (supporting its three major applications), JBT’s real reuse does not come in the form of developing more instances from a common set of core assets. Rather, it appears that JBT is itself reused, intact, to support the needs of each of the various businesses in a highly configurable fashion.
Organizational barriers appeared, at least in part, to contribute to the lack of broad deployment of the BigFinancial Message Switch. Gallivan3 defined a model for technology innovation assimilation and adoption, which included the notion that even in the face of management directive, some employees and organizations might not adopt and assimilate a particular technology or innovation. This concept might partly explain the results with BMS, that it was possible for some business units and technology groups to resist its introduction on a variety of grounds, including business case, even with a decision by a global steering committee to proceed with deployment.
We noted previously the negative impact of inter-organizational barriers on reuse adoption, particularly in the BMS case. This was particularly evident in that the organization that created BMS, and was in large part responsible for “selling” it to other business units, was positioned at a regional rather than global technology level. This organizational location, along with the organization’s more limited experience with globally reusable products, may have contributed to the difficulty in accomplishing broader reuse of that product.
Conclusion
While BTC’s results and BigFinancial’s specific business needs may be somewhat unusual, it is likely that the business and technology practices supporting reuse may be generalizable to other banks and other technology users. Good system architecture, supporting reuse, and an established business case that identify the business value of the reuse were fundamental to establishing the global reuse accomplished by BTC, and should be readily scalable to smaller and less global environments.
Key factors contributing to a successful project will be a solid technology foundation, experience building and maintaining reusable software, and a financial and organizational structure that supports and promotes reuse. In addition, the organization will need to actively build a culture of large-grained reuse, and establish trust with its business partners. Establishing that trust will be vital to even having the opportunity to propose a large-grained reusable project.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment