Application 2 – Annotated Bibliography

tchyar

Thinkbigforreuse.CommunicationsoftheACM.pdf

Home >Information Systems homework help >Application 2 – Annotated Bibliography

contributed articles

142 c o m m u n i c at i o n s o f t h e a c m | J a n u a r y 2 0 1 0 | v o l . 5 3 | n o . 1

d o i : 1 0 . 1 1 4 5 / 1 6 2 9 1 7 5 . 1 6 2 9 2 0 9

by Paul d. Witman and terry ryan

M a n y o r g a n i z at i o n s a r e s u c c e s s f u l w i t h s o f t wa r e

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 BigFi- nancial was trying to gain commonal- ity in business processes and operating models, reuse of large-grained compo- nents 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. Ap- proximately 500 people are employed by BTC, reporting ultimately through a single line manager responsible to the Global Retail Business unit head of Big- Financial. BTC is organized to deliver both products and infrastructure com- ponents to BigFinancial, and its prod- uct line has through the years included consumer Internet banking services, teller systems, ATM software, and net- work 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 ap- plication systems, the Worldwide Single Signon (WSSO) subsystem, and the Big- Financial Message Switch (BMS).

background – software reuse and bigfinancial Various definitions appear in the lit- erature for software reuse. Karlsson de- fines 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 Big- Financial, as BigFinancial has demon-

think big for reuse

J a n u a r y 2 0 1 0 | v o l . 5 3 | n o . 1 | c o m m u n i c at i o n s o f t h e a c m 143

contributed articles

portal services, and alerts capabilities, and thus the JBT infrastructure is al- ready reused for multiple applications. To some extent, these multiple appli- cations 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 sever- al 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 variabili- ty, BTC found that it was able to accom- modate these requirements by design- ing 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 behav- ior, while maintaining a consistent set of underlying application code.

In the late 1990s, BTC was respon- sible for creation of system infrastruc- ture components, built on top of in- dustry-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 man- agement, high-reliability logging pro- cesses, 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 sup- port consumer Internet banking as

strated 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 fur- ther expanded upon by Clements and Northrop2 and by Krueger6 suggest that software components can be treated similarly to the notions used in manu- facturing – reusable parts that contrib- ute to consistency across a product line as well as to improved efficiencies in manufacturing. Benefits of such reuse include the high levels of commonal- ity 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 func- tionality and user interfaces across systems within a business, and across business units.

BigFinancial has had several in- stances of successful, large-grained re- use projects. We identified projects that have been successfully reused across a wide range of business environments or business domains, resulting in sig- nificant benefit to BigFinancial. These included the JBT platform and its re- lated application packages, as well as the Worldwide SSO product. These projects demonstrated broad success, and the authors evaluated these for evi- dence 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 re- used 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 ap- propriately 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 compo- nents. JBT supports three application sets today, including online banking,

well as automated teller machines. The Internet banking services will be iden- tified here as the Legacy Internet Bank- ing product (LIB).

BigFinancial’s initial forays into Internet transaction services were ac- complished 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 re- sponsible 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, with- out 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 re-mapped its content for the browser environment.

In 2002, BigFinancial and BTC rec- ognized 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 hard- ware and operating environments. BTC planned its activities such that the costs of the new development could fit within the existing annual mainte- nance and new development costs al- ready being paid by its clients.

BTC and business executives cited trust in BTC’s organization as a key to allowing BTC the opportunity to devel- op the JBT product. In addition, BTC’s prior success with reusing software components at fine and medium gran-

table 1. selected reuse results

Project reused in business units

System Infrastructure Consumer Internet banking; automated Teller Machines

all users of BTC’s legacy Internet banking components – >35 businesses worldwide

System Infrastructure Internet banking – Small Business approximately 4 business units worldwide

Internet banking Europe > 15 business units

Internet banking asia > 10 business units

Internet banking latin america > 6 business units

Internet banking north america > 4 business units

contributed articles

144 c o m m u n i c at i o n s o f t h e a c m | J a n u a r y 2 0 1 0 | v o l . 5 3 | n o . 1

ularities 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 con- ducted detailed interviews with several BTC managers and architects, and re- viewed several hundred documents. Current deployment statistics for JBT are shown in Table 2.

The JBT infrastructure and appli- cations were designed and built by BTC and its regional partners, with in- put from its clients around the world. BTC’s experience had shown that con- sumer banking applications were not fundamentally different from one an- other across the business units, and BTC proposed and received funding for creation of a consolidated applica- tion set for Internet banking. A market evaluation determined that there were no suitable, globally reusable, com- plete applications on the market, nor

any other organization with the track record of success required for confi- dence in the delivery. Final funding approval came from BigFinancial tech- nology 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 appli- cation packages, and the applications themselves. The applications delivered with the initial release of JBT included a consumer Internet banking applica- tion set, an account activity and bal- ance alerting function, and a portal content toolset.

Each of these components was de- signed to be reused intact in each busi- ness 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 appli- cations was to include capabilities that were designed to be common to and shared by as many business units as possible, while allowing for all neces- sary business-specific variability.

Such variability was planned for in the requirements process, building on the LIB infrastructure and applica- tions, as well as the legacy portal and alerts services that were already in pro- duction. Examples of the region- and business-specific variability include language variations, compliance with local regulatory requirements, and functionality based on local and re- gional competitive requirements.

JBT’s initial high-level requirements

documents included requirements across a range of categories. These categories included technology, opera- tions, deployment, development, and tools. These requirements were in- tended to form the foundation for ini- tial discussion and agreement with the stakeholders, and to support division of the upcoming tasks to define the archi- tecture. 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 docu- ments included language, business rules, host messaging, logging, portal services, and system management.

One of BigFinancial’s regional tech- nology leaders reported that JBT has been much easier to integrate than the legacy product, given its larger applica- tion base and ability to readily add ap- plications to it. Notably, he indicated that JBT’s design had taken into ac- count 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, BigFi- nancial indicates that the cost savings for first-time business unit implemen- tations of products already deployed to other business units averaged between 20 and 40%, relative to the cost of new de- velopment. Further, the cost savings for subsequent deployments of updated re- leases to a group of business units result- ed 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 applica- tion set. There remain, in some cases, functions required only by a specific business or region. The JBT architec- ture 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

figure 1. Java banking toolkit architecture overview

table 2. Jbt reuse results

region business units

Europe > 18 business units

Asia > 14 business units

Latin America > 9 business units

North America > 5 business units

J a n u a r y 2 0 1 0 | v o l . 5 3 | n o . 1 | c o m m u n i c at i o n s o f t h e a c m 145

contributed articles

ments to global product capabilities, along with the cost of training, devel- opment and testing of business rules, and ramp-up of operational processes. In contrast, ongoing maintenance sav- ings are generally larger, due to the commonality across the code base for numerous business units. This com- monality enables bug fixes, security patches, and other maintenance activi- ties 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, in- cluding organizational structure, tech- nological foundations, and economic factors. In addition, several new ele- ments have been identified. These in- clude 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 re- use. In addition, due to its position as a global technology provide to BigFinan- cial, BTC was able to leverage its knowl- edge of requirements across business units, and explicitly design products to be readily reusable, as well as to drive commonality of requirements to sup- port 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

elements. In addition, transactional messaging is isolated from the applica- tion via a message abstraction layer, so that unique messaging models can be used in each region, if necessary.

JBT includes both the infrastruc- ture and applications components for a range of banking functionality. The infrastructure and applications com- ponents are defined as independently changeable releases, but are currently packaged as a group to simplify the de- ployment 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 enhance- ment requests and prioritize new busi- ness deployments.

results The authors examined a total of six dif- ferent cases of software reuse. Three of these were subcases of the Java Banking

Toolkit (JBT) – Internet banking, portal services, and alerts, along with the re- use of the JBT platform itself. The oth- ers 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 repre- sented as a two dimensional graph, as shown in Figure 2.

BigFinancial measures its reuse success in a very pragmatic, straight- forward fashion. Rather than measur- ing reused modules, lines of code, or function points, BigFinancial instead simply measures total deployments of compatible code sets. Due to on- going 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 busi- ness 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 de- ployments due to the significant effort required to map business unit require-

figure 2. reuse expectations and outcomes

contributed articles

146 c o m m u n i c at i o n s o f t h e a c m | J a n u a r y 2 0 1 0 | v o l . 5 3 | n o . 1

in actual reuse environments. Some of these technologies and patterns are platform-independent interfaces, busi- ness 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 de- signing systems, and have been exam- ined more closely for their contribution to the success of the reuse activities. In this examination, they have been found to contribute highly to the technologi- cal 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 motiva- tions. (Application service providers are now often referred to as providers of Software as a Service.) As commer- cial providers, they are more likely to be market-driven, often with sales of Pro- fessional 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 opportu- nity to examine, in-depth, the various forms of reuse practiced on three proj- ects, and three subprojects, inside Big- Financial. Some of those forms include design reuse, code reuse, pattern reuse, and test case reuse. The authors have found based on documents and re- ports from participants that the active practice of systematic, finer-grained re- use contributed to successful reuse of systems at larger levels of granularity.

This study has provided a view of management structures and leader- ship styles, and an opportunity to ex- amine how those contribute to, or work against, successful reuse. Much has been captured about IT governance in general, and about organizational con- structs to support reuse in various situ- ations at BigFinancial/BTC. Leadership of both BTC and BigFinancial was cited as contributing to the success of the re- use 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 organi- zation to its client’s technology groups, and its members often have long-stand- ing relationships with their peers. Ring and Van de Ven examine the broader notions of cooperative inter-organiza- tional 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 organiza- tional level is itself mitigated by the po- tential overriding forces of the legal or organizational systems.10 This element does seem to be applicable to BTC’s en- vironment, in that trust is reported to have been foundational to the assign- ment of the creation of JBT to BTC.

Griss notes that culture is one ele- ment 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 com- mented 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 vig- orously opposed to a definition of reuse

figure 3. reuse cost savings ranges

J a n u a r y 2 0 1 0 | v o l . 5 3 | n o . 1 | c o m m u n i c at i o n s o f t h e a c m 147

contributed articles

Paul D. Witman, ([email protected] ) is an Assistant Professor of Information Technology at California Lutheran University.

Terry Ryan ([email protected]) is an Associate Professor and Dean of the School of Information Systems at Claremont Graduate University.

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 demonstrat- ed 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 appropri- ate 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 unsuc- cessful in that environment.

While BTC’s JBT product does, to some extent, work as part of a software product line (supporting its three ma- jor 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 BigFinan- cial Message Switch. Gallivan3 defined a model for technology innovation as- similation and adoption, which includ- ed the notion that even in the face of management directive, some employ- ees and organizations might not adopt and assimilate a particular technology or innovation. This concept might part- ly explain the results with BMS, that it was possible for some business units and technology groups to resist its in- troduction on a variety of grounds, in- cluding business case, even with a de- cision 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 organiza- tional location, along with the organi- zation’s more limited experience with

globally reusable products, may have contributed to the difficulty in accom- plishing broader reuse of that product.

conclusion While BTC’s results and BigFinancial’s specific business needs may be some- what unusual, it is likely that the busi- ness and technology practices support- ing 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 suc- cessful project will be a solid technolo- gy 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 busi- ness partners. Establishing that trust will be vital to even having the oppor- tunity to propose a large-grained reus- able project.

References 1. Card, D. and Comer, E. Why do so many reuse

programs fail? IEEE Software 11, 5, 114-115. 2. Clements, P. and Northrop, L.m. Software Product

Lines: Practices and Patterns Addison-Wesley Professional, 2002.

3. Gallivan, m.J. Organizational adoption and assimilation of complex technological innovations: Development and application of a new framework. The DATA BASE for Advances in Information Systems 32, 3, 51-85.

4. Griss, m.L. Software reuse: From library to factory. IBM Systems Journal 32, 4, 548-566.

5. Karlsson, E.-A. Software Reuse: A Holistic Approach. John Wiley & Sons, West Sussex, England, 1995.

6. Krueger, C.W. New methods in software product line practice. Comm. ACM 49, 12, (Dec. 2006), 37-40.

7. malan, R. and Wentzel, K. Economics of Software Reuse Revisited. Hewlett-Packard Software Technology Laboratory, Irvine, CA, 1993, 19.

8. morisio, m., Ezran, m. and Tully, C. Success and failure factors in software reuse. IEEE Transactions on Software Engineering 28, 4, 340-357.

9. Ramachandran, m. and Fleischer, W., Design for large scale software reuse: An industrial case study. In Proceedings for International Conference on Software Reuse, (Orlando, FL, 1996), 104-111.

10. Ring, P.S. and Van de Ven, A.H. Developmental processes of cooperative interorganizational relationships. Academy of Management Review 19, 1, 90-118.

11. Sabherwal, R. The Role of Trust in Outsourced IS Development Projects. Comm. of the ACM 42, 2, (Feb. 1999), 80-86.

12. Szyperski, C., Gruntz, D. and murer, S. Component software: beyond object-oriented programming ACm Press, New York, 2002.

13. Witman, P. and Ryan, T., Innovation in large-grained software reuse: A case from banking. In Proceedings for Hawaii International Conference on System Sciences, (Waikoloa, HI, 2007), IEEE Computer Society.

content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's

express written permission. However, users may print, download, or email articles for individual use.