Return to the Integrated Systems Project Home Page



Task Force


Study Group #5

Final Report

January 24, 1997


I. Executive Summary


III. The Case for Change

A. System Replacement Rationale
B. Need for Client/Server Architecture

IV. System Replacement

A. Timeline
B. Priority

V. Definition of Alternatives

VI. Decision Factors

A. Addressing These Issues
B. Explanation of Key Criteria and Ratings

VII. What Will the Future Look Like?

VIII. Data Summary




The mission of this study group is to determine the business viability and risks associated with a Best of Breed approach and a Single Vendor Partnership (Integrated) approach.

Data Summary

Based on all the information gathered from the study group reports, vendor visits, inquiries to peer institutions, and knowledge of our own institution, etc., it appears to Study Group 5 that a Single Vendor Partnership approach to our core administrative systems would be the best course of action for the institution. Both a Best of Breed and a Single Vendor Partnership approach would be viable solutions but the Single Vendor Partnership approach is better in several ways. In a post-implementation production environment, a Single Vendor Partnership approach would provide significantly less technical complexity, some cost savings and increased functionality for the users. It is more likely that a Single Vendor Partnership approach will better enable the institution to reach its goals in the areas of decentralization, process simplification and increased access to data.

Next Steps

The Steering Committee needs to appropriately weight all decision factors presented and reach a conclusion. There may be additional factors to examine and/or additional information to be gathered; Study Group 5 will be available to assist if needed. Once the Steering Committee makes its decision as to the direction the University will head, the following decisions will need to be taken by either the committee itself or some designated person/group:


"It is impossible to cross a chasm in a thousand small steps"
Old Chinese Proverb


The Integrated Systems Task Force (ISTF) has been charged with evaluating the technology that is available in the marketplace, the University's current situation, and with making a recommendation to the President and the Cabinet regarding a long term strategy that will minimize costs to the University and provide friendly management information tools to the users. The rapidly approaching millennium date change, an aging set of core administrative systems, an industry wide shift to client/server technology and the high cost of maintaining multiple core administrative systems on different platforms are four of the catalysts that are requiring the University to evaluate its administrative computing strategies. These catalysts are driving the University to make strategic decisions at a faster pace than in the past.

The mission of this study group is to determine the business viability and risks associated with a Best of Breed approach and a Single Vendor Partnership approach. Study Group #5 is comprised of the leaders of the first four study groups, a facilitator and a scribe.

Nancy Bertram - Study Group #1

Shirley Payne - Study Group #4

Jay Scott - Study Group #2

Shelley Payne - Facilitator

Barbara Deily - Study Group #3

Diane Mundell - Scribe

Significant Contributor - Belinda Stevens

In order to address the essence of the stated mission, the members of Study Group #5 conducted a thorough review of the first four study group reports, attended presentations given by four integrated systems vendors, reviewed hundreds of pages of vendor materials received in response to the RFI and participated in two site visits at James Madison University and Virginia Tech. Both of these universities are in the process of implementing integrated systems through single vendor partnership strategies. The combination of these four sources of information has given the members of the group a clear understanding of the systems that are currently available, the attributes of the available vendors and their ability to deliver a finished product, the idiosyncrasies of the University and how the University community will respond to an implementation of this magnitude. The work that has been done to date is by no means an exhaustive, all inclusive recommendation on how to proceed. The fast track timeline that the ISTF has embraced has placed limitations on the extent to which detailed research could take place.

The following report summarizes the challenges that confront the University at this time that make this a critical and time sensitive decision. In addition, it describes eight criteria that can be used in making the decision and the degree to which each technology strategy meets each criterion. It is hoped that consideration of the following information will provide the ISTF Steering Committee with sufficient information to make a recommendation to the President and the Cabinet regarding the appropriate strategy for the University.


System Replacement Rationale

Over the past one hundred and seventy years, the University of Virginia has evolved into a prominent institution, known around the world for its excellence in teaching, scholarship, and research. The 1995-96 President's Report provided much hard evidence that the University's reputation is well earned and that there have been significant recent efforts to strengthen this standing. With such encouraging indicators, it is easy to become complacent. The report reminds us, however, that, "There is much to be accomplished if we are to meet the challenges of the new century and safeguard the University for our posterity."1

Institutions today are dealing with an unprecedented number of external forces that could threaten the very existence of inattentive institutions. Some of these forces include:

These and other external forces are driving institutions to be concerned with their overall mission and strategy, tuition policy and financing, planning and budgeting for the long-term, productivity and cost control, prospective donations, and competition for students. Forward-thinking institutions are beginning to address these issues in dramatic new ways. For example, to attract a broader student population, institutions in thirteen states have recently joined forces to create the Western Governors University, a virtual institution that serves as a broker for course delivery from participating campuses. The actions of these progressive institutions will raise the bar for all others, making it even harder to remain solvent and competitive in the future.

As noted in the President's Report, the University of Virginia has also undertaken major new initiatives to deal with these issues. These actions notwithstanding, there are many other exciting opportunities for change. While the University's re-engineering efforts to date have been successful, we have only scratched the surface of what could be done in this area to improve service and efficiency. Likewise, great strides have been made to give students the ability to register, add/drop courses, request grade information, etc. in an automated fashion, but there will be the continuing challenge of keeping the student/machine experience a positive one as student expectations grow. The opportunities for further progress are many.

It is widely recognized that high quality administrative computing systems are primary enablers for making the kinds of changes the University may want and need in the future. These systems must be rich in functionality, easy to learn and use, highly flexible, and technically supportable. They must serve the needs of all constituents, especially given the University's decision to delegate an increasing share of the administrative workload to schools, departments, and other "program-delivery" units outside the central administration. Unfortunately, all mission-critical University systems do not fit this description. We suffer from the following:

These problems will become more and more apparent as the University identifies needed changes to meet the challenges posed by the external forces described. Although steps have been taken to enhance the functionality of and improve end-user access to these systems, these measures are simply finger-plugs in a leaking dike. The effort to maintain the current portfolio of aging systems will continue to grow, giving us fewer resources to invest in systems work supporting strategic business initiatives. Any new software we develop will be built on a crumbling foundation of core administrative systems. Over time these systems will become serious impediments to change at the University.

Need For Client/Server Architecture

A key information technology strategy at the University is to employ client/server technology wherever possible in replacing or developing new administrative applications. Unlike traditional computing, where all application activities occurred on the mainframe, client/server technology allows individual application tasks to be placed on the hardware/software platform best suited to handle the task.

In March of 1994, the Administrative Advisory Sub-committee of the Committee On Information Technology and Communications (now known as UCIT) endorsed an "application by application conversion" model for migrating to client/server technology. This model called for using client/server systems to replace existing systems on a case by case basis. It was the belief of the Sub-committee that, "Since these applications determine the boundaries of computing capabilities for user departments for the long-term, it is critical that each application project attempt to exploit the best technology available at the time."2  While this technology was supported, wholesale conversion was not endorsed then because the technology was still somewhat immature and had not been fully proven to support wide-scale mission-critical systems. Three years is a very long time in technology development terms. Client/server technology has matured considerably since early 1994 and has become the standard platform for administrative systems across all industries, because of the significant flexibility it affords in distributing application support responsibility, managing performance, employing user interface design capabilities not available on the mainframe, and other advantages. Today, finding application software vendors who do not market client/server-based systems as their flagship products would be extremely difficult. The idea of moving to client/server systems was supported in 1994, and we have even more reason to support this strategy now.

One of the ISTF study groups identified the benefits of enterprise-wide client/server systems as follows:

To fully achieve these benefits, there is much planning and preparation that needs to take place. The study group made a number of recommendations for initiating this activity that should be undertaken soon.   


System Replacement Timeline

It is impossible to say at this point how long it might take to replace all our core administrative systems. The experiences of other institutions committed to this course vary greatly. James Madison University, for example, implemented selected components of a purchased human resources system at the central administrative level in nine months, but a similar effort at Virginia Tech has taken three years to implement. The number of factors affecting implementation time are many. At James Madison, a "no frills" approach was taken to get the system up and running as quickly as possible. In Virginia Tech's case, the project was plagued for several years with lack of staff and insufficient funding. If and when the University begins its own replacement project, it will be important to plan well and set expectations appropriately. Experience shows that implementing enterprise-wide systems requires significant effort on the part of both information technology and end-user personnel, especially on the front-end when re-engineering and requirements definition takes place. Key ways to keep the overall lengths of projects to a minimum, however, have been discussed by the full ISTF and/or ISTF sub-groups and these are summarized below:


Order Of System Replacement

Although the order of replacement is important for the long term success of the University, it should not be the single determining factor in the selection of a vendor. If the University decides to enter into a partnership agreement with a single vendor, the selection of a vendor should be driven by the overall qualities the vendor can to bring to such a partnership. These qualities should include: 1) a commitment to higher education, 2) a desire on the part of the vendor to enter into a partnership with the University, 3) the vendor's track record in implementing systems, and 4) the level of trust we have in the vendor.

The selection should not be driven by the vendor's ability to meet system requirements in a single business area, but should meet core institutional strategic needs. During contract negotiations, however, it would be very important to have the order of systems replacement defined so that specific language could be written into the contract about the responsibilities each partner has for ensuring success of a concrete implementation plan. Should the University decide to continue its Best of Breed strategy, the order of replacement decision obviously needs to be made sooner. In either case, determination of the order of system replacement is an important decision and should take into account the following:


The ISTF identified two basic strategies that could be used for future system implementations: a Best of Breed system vendor approach and a Single Vendor Partnership approach. Each represents a vision that would dramatically shape our future mode of operation and the product of our efforts. As the ISTF conducted its study, confusion arose from time to time over exactly what these strategies entailed. To ensure these very different strategies are completely understood, definitions are provided in the following paragraphs.

Single Vendor Partnership Strategy

The ISTF quickly recognized the potential advantages of fully integrating the University's core administrative systems. Using this strategy, what is now a "patchwork quilt" of independent systems would be replaced with a suite of systems built by one vendor with common design and technical principles. This system suite would appear and behave like a single system from both an end-user and technical perspective. An ISTF study group developed a detailed definition of an integrated system environment. Some of the key characteristics mentioned were:

This particular strategy is essentially one of partnering with a single vendor with the intent, but not the contractual obligation, to purchase all core administrative systems from that vendor.

A true partnership with the vendor could be established that went beyond the normal buyer/seller relationship. An agreement would be built around activities of interest to both parties, and implementation risks would be shared. For example, the University might agree to develop and/or test certain technical features for the vendor in exchange for vendor software discounts, and payments to the vendor might be tied to our success in implementing the vendor's product.

A partnership does mean adopting the vendor's products wherever possible. However this does not create a situation where we would be forced to accept a system that does not meet functional needs. For each project implementation, the University would define non-negotiable functional requirements and examine the vendor partner's software to determine if these requirements were included. If they were included, the University might implement the partner's software. If they were not included and the University was unable to change policies and practices and unable to tailor the vendor partner's software to meet the requirements, the University might choose another vendor's product or develop the software in-house. Consideration would have to be given to the costs of losing integrated functionality. In cases where the vendor partner had the needed software under development, the University would participate in the definition of requirements and would plan to implement the software if mandatory requirements were incorporated in the final product.

This strategy does not imply that all systems would be replaced at once or any individual system would be replaced before the University was ready to commit to such a project. Instead, it would be a declared intention -- a vision -- that would take years to fully realize.

Best of Breed Strategy

This is the University's current system implementation strategy, and it is more oriented toward the use of niche software vendors. The University contracts on a case-by-case basis with a variety of vendors as needed to meet requirements for new applications. For each project implementation, requirements are defined and a vendor selection is made based upon the degree to which these requirements are met. If no viable vendor is found, the software is developed in-house. In evaluating software vendors, little, if any, consideration is given to the potential of the vendor to supply other software to the University. Also, incompatibilities with the existing supported technical environment and machine-to-user interfaces would be tolerated to a great extent.

The primary benefit of this approach is that it would provide each central operating unit with greater freedom to choose the best product on the market to meet its specific system needs. While this approach would not alleviate the current frustrating array of methods for inputting transactions to and retrieving information from administrative applications, the University would continue it's Web-based electronic forms and Information Warehouse strategies and possibly begin other strategies to help isolate casual users from some of these differences. The level of complexity in the technical environment supported by the University would unavoidably increase as more systems with unique technical architectures are implemented and additional software is put in place to isolate end users as much as possible from problems caused by the lack of systems integration.

There have been discussions among the ISTF about three additional ways this strategy could play out:

The ISTF technical study group advised that supporting more than one integrated systems' client/server environment would be unworkable. The vendor products evaluated include tools for creating new software, for tailoring business rules, reports, and screens, and for managing the ongoing production operation of applications. The total packages are complex and would require significant training to learn and use. Providing technical support for multiple comprehensive environments such as these would be quite difficult and would require more dedicated staff resources than are allocated today.


Addressing These Issues

The choice of which implementation strategy would be better for the University is a complicated and extremely important one. To assist the Senior Cabinet in making this decision, in May 1996 the ISTF began the process of educating itself on the issues and conducting detailed studies in several areas. To date the following questions have been addressed:

The advantages and disadvantages of the two strategies from these and other perspectives will all need to be factored into the final decision. This section identifies decision criteria defined to date and provides commentary on the degree to which each criterion is met by the two strategies.

In evaluating the possible strategies for the institution, we identified eight key criteria that need to be considered. Those criteria are:

We then ranked whether the proposed strategy (Best of Breed or Single Vendor Partnership) met those criteria. A "LOW" ranking means that the strategy did not address the criteria to any great extent, a "HIGH" ranking indicates a close match by the strategy in meeting the criteria. The results of this ranking are then summarized in the following grid. Explanations of each of the criteria and how we arrived at each ranking are found in the pages following the grid.

We deliberately did not "weight" the various attributes in the grid and tables. It is a matter of opinion as to which elements are most important to the University. Overall, the information suggests that a Single Vendor Partnership approach is the most beneficial. However, depending on the weights that others might assign to the various factors, that course of action may not be in the best interest of the institution.

Best of Breed
Single Vendor Partnership

Institution-wide Strategic Needs Met


Core Administrative Functional Needs Met


Technical Strategies Met


Current Product Availability


Overall Cost Savings


Fit to Current Culture


Long-term Technical Viability


Long-term Financial Viability


Explanation of Key Criteria and Ratings

Institution Wide Strategic Needs Met

This attribute addresses how well the proposed solution (Best of Breed or Single Vendor Partnership) enables the institution to accomplish its mission as well as any long-term goals. Service to our students, faculty and staff are components of this attribute along with improving process flows, receiving increased autonomy from the state and cutting costs, distributing responsibility within the University and increasing access to data.

Best of Breed: (LOW) With a Best of Breed solution, institution-wide strategic needs are less likely to be met. Inefficiencies would continue to occur in our systems. For example, data would have to be entered and maintained in several locations, interfaces between the systems would continue to be cumbersome, and employees would have to be trained on/be familiar with several differing systems.

Single Vendor Partnership: (HIGH) With a Single Vendor Partnership solution, it is more likely that institution-wide strategic needs would be met. For example, employees would have tools to extract information from a single data base, changes affecting one system would be immediately reflected in other systems, thereby minimizing reconciliations between the systems, and data elements in the systems would have common definitions/names.

Core Administrative Functional Needs

This attribute addresses how well the proposed solution (Best of Breed or Single Vendor Partnership) satisfies the essential operational requirements of the core functional areas.

Best of Breed: (HIGH) With a Best of Breed solution, a high degree of central and field user satisfaction should be obtained. The system that best meets the requirements of a particular functional area (such as payroll or general ledger) would be selected. Functional areas would not have to compromise functionality in deference to the overall strategic choice of the institution.

Single Vendor Partnership: (MEDIUM) With a Single Vendor Partnership solution it is less likely that all essential functional requirements will be met fully in comparison to a Best of Breed solution.  A single vendor's product may provide approaches that are compatible with current operating practices for some functional areas but not for others. Therefore, it may be necessary to modify certain institution-wide functional processes in very significant ways.

Technical Strategies Met

This attribute deals with how well the proposed approach (Best of Breed or Single Vendor Partnership) addresses defined institutional technical strategies, such as a move to technologies that would enable, and enhance institutional strategies and a desire to reduce complexity.

Best of Breed: (LOW) It is believed that a Best of Breed solution (in the proposed client/server environment) would be more difficult to maintain than any other solution. Expertise in many different applications would have to be obtained and maintained, multiple interfaces would need to be developed and troubleshooting could be expected to be more difficult. No efficiencies would be attained by information technology staff; end users would have to be trained to use the various systems.

Single Vendor Partnership: (HIGH) It is believed that a Single Vendor Partnership solution would be the most desirable from a technical strategies' standpoint. The institution could eliminate several of the multiple programming languages, tools and file structures. When problems occurred with the system, one vendor could be held responsible for finding a solution. If constructed well, an integrated system will share code across software components, making it possible to make changes in a single location and have those changes be in effect for the entire system. End users would be able to more easily extract/consolidate information that they needed to manage their operations

Current Product Availability

This attribute measures whether or not there are vendors within each strategy (Best of Breed or Single Vendor Partnership) who can currently supply or co-develop a product(s) that will meet the majority of the needs of a major research institution, such as UVA.

Best of Breed: (HIGH) The Best of Breed strategy offers the highest number of products available to meet operating needs. Not only are there niche vendors with specialized products to provide customized solutions, but modules from the integrated system vendors might also be available to meet any unique business requirements.

Single Vendor Partnership:(LOW) Our brief review of vendors and peer institutions has raised some concerns about the ability of vendors to meet our needs with their base products. We have not seen a fully integrated system at a major public research institution. Many vendors are close to having a fully integrated system, or may have integrated systems that support less complex institutions. We are not aware of any major research institution where their systems have been fully integrated by a single vendor. However, it appears that some of our peer institutions are confident that such a solution is possible.

Overall Cost Savings

This attribute compares the cost of the proposed strategy (Best of Breed or Single Vendor Partnership) in relation to the costs currently incurred.

Best of Breed: (LOW) Based on the difficulty/complexity of maintaining separate systems, continuing on a Best of Breed path would not result in any savings above the costs currently incurred. It is even possible that in a client/server environment, the costs of maintaining a Best of Breed approach may increase. Efficiencies would not be realized in the training of institutional staff (both technical and field users), and troubleshooting among different systems would continue and perhaps increase.

Single Vendor Partnership: (MEDIUM) As evidenced by the Study Group 3 report, a Single Vendor Partnership is expected to cost less over the long term than a Best of Breed strategy. However, an integrated system is not cheap to purchase or to maintain (e.g. the continued licensing fees). Therefore, while some savings will occur, the savings will not be overwhelming. Savings will occur in the training of personnel, decreased troubleshooting costs, and software maintenance costs.

Fit to Current Culture

This attribute examines how likely it is that the proposed approach (Best of Breed or Single Vendor Partnership) will match how the institution currently does business. This could be perceived as positively or negatively depending on our desire for change.

Best of Breed: (HIGH) A Best of Breed approach allows most business units to have more of what they want. However, selection of a vendor under this strategy may not encourage the institution to rethink how it does business.

Single Vendor Partnership:(MEDIUM) A Single Vendor Partnership system may require the institution to modify its business practices. If the new system does not meet the needs of the users, shadow systems may be developed because people will not want to change their current methods of operating. On the other hand, shadow systems will not be needed to integrate information currently on separate systems. An integrated system may be a catalyst to encourage the institution to evaluate and change the way it currently does business.

Long Term Technical Viability

This attribute deals with how likely the chosen approach (Best of Breed or Single Vendor Partnership) will support new, yet-to-be developed technology.

Best of Breed: (LOW) Continuing on a Best of Breed path would most likely result in ongoing, divergent technologies. Even if some standardization in technical architectures was required, there would still be major differences in the way the systems were designed. The University will need to shoulder the full burden of integrating the diverse technical strategies of various vendors and the cost of keeping all the individual products technically current will grow.

Single Vendor Partnership: (HIGH) An integrated system would allow the highest maximization of technical resources. Knowledge of differing hardware standards would be minimized as well as the need for knowledge of diverse systems. The University could rely on the vendor partner to conduct much of the technology research, software modification and testing necessary to keep its applications technically current.

Long Term Financial Viability

This attribute estimates the likelihood that the vendor will be able to deliver a fully functional product on a timely basis and will continue to provide support for the long term. Components of this attribute include: 1) the viability of the vendors, 2) the vendors' commitments to the higher education market, and 3) where the vendors are in the development of needed packages/modules.

Best of Breed: (HIGH) Generally the Best of Breed products have track records that can be more easily evaluated and assessed. References from higher education institutions utilizing the applications can be obtained. Past and probable commitment to the higher education market can be more readily determined.

Single Vendor Partnership: (MEDIUM) It is more difficult to assess the long-term financial viability of some of the integrated products. Because all modules of their systems are not developed, it is possible that some vendors will not remain committed to the higher education market. This could have serious implications if our selected partner were to abandon the higher education market. However, many of the vendors have proven track records in other industries.


In analyzing the two strategies, Best of Breed and Single Vendor Partnership, the Study Group tried to envision how the environment at the University would change under each approach. We assessed where we were now and then where each strategy would put us in the future. We also evaluated each strategy in comparison to the other. The following tables and graphs summarize the results of those analyses in three areas, 1)Technical Complexity, 2) Overall Ongoing Costs, and
3) Institution Wide Functionality.

The major assumption made in these analyses was that we were estimating the future in a post-implementation, production environment. That is, all necessary training had taken place, all needed hardware and software had been purchased, and all systems were up and running. While this approach does not address the situation that would exist during the period of system design, testing, training and implementation, it provided the only feasible way to perform the comparison.

Comparison of Technical Complexity:

Much of our future is being driven by the move to a client/server environment. Because of this decision, maintaining the status quo is not an option. A Best of Breed strategy, in a client/server environment, will result in more complications than either an integrated system in a client/server environment or our current systems in a mainframe environment.

Not only would information technology personnel have to continue dealing with multiple technical designs and tools imposed by application products from many vendors, but they must also cope with these complexities across distributed hardware and software platforms inherent to client/server technology. With a Single Vendor Partnership, a suite of applications would be in place that was built using common technical strategies and tools. These applications would share a common database, making it unnecessary to construct interfaces among applications as we do today. In this consistent environment, ongoing support, production operations, and problem resolution would be far easier.

Technical Complexity

Best of Breed
Single Vendor Partnership

Number of tools to support


More tools than in mainframe due to Client/Server (C/S)

Far fewer tools than current and Best of Breed

Number of file structures


About the same as current

Far fewer file structures than current and Best of Breed

Number of architectures/ design approaches


More due to C/S

Far fewer architectures than current and Best of Breed

System documentation


About the same as current

Far less inconsistency than current

Expertise of end users

Some are very expert, but multiple file structures across systems increases complexity

More complex due to an increase in automation

Less complex than Best of Breed, but more complex than current mainframe environment

Report generation from systems


Less difficult due to report generators in newer systems

Less difficult than current and Best of Breed, due to consistency across all systems

Redundancy of data


About the same as current

Far less complex


Complex; varies from system to system

More complex than current, because it's C/S

Less complex, because security administration and sign-on consistent for all applications

Availability of vendor upgrades to support new versions of system software

Different timelines

About the same as current

Less complex, because all upgrades are simultaneous

Production operation

Moderate; everything is on the same hardware platform, but multiple operating environments

Far more complex than current, due to C/S

More complex than current, but less than Best of Breed due to consistent operating environments


Difficult, due to multiple vendors

Far more complex than current, due to C/S

More complex than current, but less than Best of Breed due to consistent operating environments

Overall Ongoing Costs

Overall costs in an integrated, client/server environment will be lower over the long run than a Best of Breed approach. The institution will gain efficiencies in processing information and in maintaining the systems. Troubleshooting costs will be minimized in an integrated environment as opposed to a Best of Breed environment. Both approaches will require a significant financial and personnel commitment during implementation.

Overall Ongoing Costs

Best of Breed
Single Vendor Partnership

Client hardware

Minimal. PC's not required in most instances

More expensive than current

Same as Best of Breed

Server hardware

High mainframe maintenance cost

Less expensive, due to Client/Server (C/S)

Same as Best of Breed

Client software

Minimal. Client software not required in most instances

More expensive than current

More expensive than current, but less than Best of Breed

Server software

High mainframe software maintenance cost

Less expensive than current

Less expensive than current and best- of-breed (more opportunity for bulk licenses)

Training - Users

Low cost because number of users directly accessing systems is low relative to other strategies

More expensive than current because of a higher number of users and a heightened commitment to do better training

More expensive than current, but less expensive than Best of Breed due to consistency

Training - Technical

High cost because of large number of tools and inconsistent system designs and documentation

Same expense as current

Less expensive than current and Best of Breed, due to consistency across applications

 Support - Users

Relatively low cost because processing occurs primarily on mainframe and number of users is low

More expensive due to C/S, a diverse client environment, and an increased number of users

More expensive than current due to C/S and an increased number of users, but less than Best of Breed because of more consistency

Support - Technical

Relatively low cost because processing occurs primarily on mainframe and number of users is low

More expensive due to C/S and a more distributed support structure

More expensive than current due to C/S, but less expensive than Best of Breed because of more consistency

Technical Infrastructure

Relatively low because most processing centralized on mainframe

More expensive than current due to greater network traffic and many servers

Same as Best of Breed

On-going Customization

Very high due to lack of tools and policy on customization

Less expensive than current due to tools and commitment not to customize

Same as Best of Breed

Estimated Annual Cost

Current cost

Slightly higher than current

Much lower than current

Comparison of Institution Wide Functionality

The institution wide functionality differences between a Best of Breed strategy and a Single Vendor Partnership strategy are not significantly different. With the upcoming Data Warehouse tools, and improved tools from the vendors, it is likely that we can make a Best of Breed approach "work" from the standpoint of the users. An integrated approach however will enable the University to reconcile information between systems and will increase consistency across functional components of the system.


Best of Breed
Single Vendor Partnership

Functional Performance

Central:  Meets fundamental needs
Field:  Mixed; some needs met, others not.

Central:  Better than current

Field:  Better than current

Central:  Unclear if needs will be met in all functional areas
:  Unclear if needs will be met in all functional areas **Unclear because of newness of applications and selection process

Capability for Enhancement (Tools & procedures available)

Central:  Limited

Field:  None

Central:  Better than current, due to C/S and new generation of tools Field: Better than current (but will our culture allow the fields to use them?)

Central: Better than current and Best of Breed
Field: Better than current and Best of Breed (may change culture to allow more use)

Ability to handle the volume of enhancement requests

Limited, due to system constraints and need for changes to be made by IT professionals

Better than current, due to users' capability to make some changes themselves

Same as Best of Breed, but volume may be higher, depending on functional performance

Ease of Use

Central: meets basic needs

Field:  Difficult, but improving due to e-forms and information warehouse

Central:  Better than current due to C/S

Field:  Same as Central

Central:  Better than current and Best of Breed due to integration and consistency
Field: Same as Central

Data Access

Central:  Meets basic needs; cumbersome, but improving with use of information warehouse

Field:  Evolving via information warehouse and web interfaces

Central: Better than current, due to C/S and new generation of tools

Field: Same as Central

Central: Better than current and Best of Breed due to integration and consistency

Field: Same as Central

Flexibility to meet diverse needs in field (elimination of shadow systems)

Extremely limited

Somewhat better than current, due to C/S, but not ideal due to lack of integration (will culture support universal ownership?)

Reduced need for shadow systems due to integration.  Increased need for shadow systems due to functional needs.  (May change the culture to allow the field to "let go" of shadow systems)


So where does the University go from here? What direction is best from an institutional standpoint? Our summary of the tables on technical complexity, overall ongoing costs and institution wide functionality concluded that, in a post-production environment, a Single Vendor Partnership would be the best strategy for UVA. Our review of the information presented in the grid of key criteria, and the tables of technical complexity, overall going cost and institution wide functionality revealed the following:

A Best of Breed strategy rates highly in several areas. Core Administrative Functional Needs are likely to be met and there are a high number of products currently available. We can more accurately assess the long term financial viability of a Best of Breed product vendor. It is also easier to find a better fit with our current culture by utilizing a Best of Breed strategy. This latter point may be a positive or negative depending on the degree to which one feels we should change.

A Single Vendor Partnership approach rates highly in several areas as well but not surprisingly, this approach rates highly in areas where the Best of Breed approach shows signs of weakness. It is more likely that a Single Vendor Partnership approach will enable the institution to meet its strategic needs. We also believe that a Single Vendor partnership approach will be more likely to match the technical strategies of the institution. Maintaining the technical viability of the systems will be much easier in a Single Vendor Partnership approach.

The translation of the tables into a graphical representation was even more revealing. As the University continues its journey from a mainframe environment to one primarily driven by client/server applications, the significance of an integrated system is even more profound. Technical complexity will increase in a best of breed environment while it will decrease with the implementation of integrated systems. This has a far reaching and significant impact on the University's ability to utilize and support its systems in the long run.

In graphing the overall cost of both the Best of Breed and the Single Vendor Partnership approaches, the significance is not as apparent. However, due to the rising slope of the Best of Breed cost line, and the declining cost of the integrated approach, over time an integrated approach should generate significant cost savings for the University.

The combination of an integrated approach and the migration to a client/server platform will yield a higher level of functionality than if the University remains in a Best of Breed environment. Reduced input points, end user flexibility and ease of access are just a few of the advantages that an integrated approach can accomplish.


Choosing an appropriate strategy for the University is a challenging task. Additionally, there is no consistent view on how to best choose the first system for replacement. If we listen to our users, their desire is to replace the Payroll/Human Resources system. If we listen to our peer institutions who have started replacing their systems, they would recommend that we replace the general ledger systems first. But, if we commit to a Single Vendor Partnership, which system we do first and how well the vendor meets the requirements of that particular system, are not the only issues.

What has become evident is the criticality in selecting a vendor. If we commit to a Single Vendor Partnership, significant focus needs to be placed on evaluating vendors on their abilities to be good partners for the University.  Partnership qualities that are desirable would include: 1) the vendor's commitment to higher education, 2) the vendor's willingness to share (development) risks with the University, 3) the vendor's history of successful implementation, and 4) the progressiveness of the vendor. This vendor selection decision cannot be made hastily nor can it be held hostage to a detailed and lengthy analysis of system requirements.

A suggested approach would be to decide which core administrative system has the greatest impact to the successful operation of the University. Once we have decided which system is most critical, we would then develop a partnership with the vendor who best meets the needs of the selected core administrative system and exhibits the qualities of a partnership that we desire. This does not imply or require that the selected core administrative system is the first one to be replaced; only that it would help influence the determination of which vendor with whom we partner.

As always, obtaining input from the many users of the system will increase the likelihood of success upon implementation. Extensive user involvement will extend the selection and implementation process but we believe these phases of the project should not be shortchanged.

Parting Thoughts

Because choosing a Single Vendor Partnership is such a divergence from our current practice we offer the following parting thoughts:

If the University chooses the strategy of a Single Vendor Partnership, it must be with an understanding of the major commitment required to implement this change. There are massive efforts currently in progress at Michigan and Cornell to implement this approach (refer to project status reports in Appendix A). Commitment will be necessary in terms of both personnel and financial resources. Even though the required commitment is great, it appears that the Single Vendor Partnership approach will enable the University to leap the chasm that is represented by the status quo and reach greener pastures with new and exciting possibilities. After all, we don't know what we don't know.

1University of Virginia President's Report 1995-96, p. 29.

2"Distributed Computing at UVA", Committee On Information Technology and Communication's Administrative Advisory Sub-committee, March 2, 1994, p. 4.


Current Status of University of Michigan and Cornell Projects

Stated Goals

Both the University of Michigan and Cornell University define their projects as major efforts to redesign business processes and put new technical infrastructure and application systems in place to support these processes. Cornell has the additional stated goal of saving $20 million in administrative costs in five years. It is clear from publicized information about the projects that they are considered critically important to these universities. Michigan states that its project "is a commitment to find a better way to do our day to day tasks. It means sweeping change." Cornell states that its project's goal "is nothing short of changing the way we do business, reinforcing Cornell's commitment to academic primacy, institutional vitality, service quality, and employee excellence."

These are university-wide projects involving large numbers of people from across the institutions. Business process re-engineering is an integral part of both projects. The universities are committed to single vendor partnerships, in both cases with PeopleSoft, to obtain an integrated suite of software products on a schedule that meets their needs.

Current Project Status At Michigan


General Ledger - Phase I to be implemented Summer 1997. Final phase completed Summer 1998.

Purchasing and Accounts Payable - Phase I to be implemented Summer 1997. Final phase completed Summer 1998

Inventory - Project will begin after January 1997. Implementation target dates not available

Accounts Receivables - Project will begin after January 1997. Implementation target dates not available

Budgeting - Project will begin after January 1997. Implementation target dates not available

Human Resources: Process re-engineering completed. Pilot of selected human resources modules scheduled for 1997. All human resources and payroll modules in production by fall 1998.

Student Administration: Pilot in place for Law and Medical Schools by Fall 1997. All campus converted by April 1998, except for financial aid modules which will be implemented in January 1999.

Research Administration: Michigan is currently a member of the GAMS consortium that uses software from an IBM business partner, but is considering working with PeopleSoft to develop grant's management software.

Physical Resource Management: Asset management pilot in place in Hospital, with campus-wide use planned by Summer 1997. PeopleSoft does not have space management software, but Michigan is using development tools provided by PeopleSoft to build its own system and implement it by Summer 1997.

Current Project Status At Cornell

Financials: Cornell is just beginning to formulate plans for this area. Areas included are general ledger, budgeting, purchasing, accounts payable, asset management, billing, accounts receivables, inventory, project costing, and treasury management. Full production of these systems is expected in 1999.

Human Resources: A comparison of desired processes and ability of "vanilla version" of PeopleSoft products to support these processes have been completed. Phase I to replace the existing payroll system and the data collection mechanisms that feed it is scheduled for 1997. Remaining human resource modules will be phased in 1998 and 1999.

Student Administration: Cornell is currently working with PeopleSoft on developing the system. Partial implementation is planned in 1998 and full implementation is expected in 1999.

Research Administration: Cornell is currently working with PeopleSoft on developing the system. Partial implementation is planned in 1998 and full implementation is expected in 1999.

Alumni Affairs & Development: Cornell may work with PeopleSoft to develop this system, with implementation expected in 1999.


Return to the Integrated Systems Project Home Page

Site maintained by
Updated January 12, 1999