This paper is the intellectual property of the author(s). It was presented at CAUSE98, an EDUCAUSE conference, and is part of that conference's online proceedings. See for additional copyright information.

Duke University Architecture Planning Process

by Rafael Rodriguez


Changes in information technology are enabling the use of a new business model for conducting operations with institutional stakeholders. A name usually associated with this information technology model is "network computing." The network and associated software link these systems, whether client computers, local and campus servers, or high-performance supercomputing environments, and their associated applications into a cohesive whole.

The challenge in building these network computing systems lies in how to ensure that there is an overall plan so that the various systems and applications are able to work together towards accomplishing the overall institutional objectives., the network and the next generation virtual computing tools link these system and their associated applications together in a continually more ubiquitous manner.

At Duke University we want to ensure that the institution�s goals and objectives are the driving force for any information technology initiative. The following figure was developed to communicate the connection between the information technology infrastructure and the institution�s goals and objectives and their implementation.

The institution�s strategic goals and business drivers are the essential principles that govern all of the institution�s initiatives. The document prepared by the Duke University Strategic Planning Committee entitled Shaping our Future�A Young University Faces a New Century, September, 1994, outlines these principles. These principles guide the initiatives that may be implemented in a centralized or decentralized manner.

There is also the need to provide an infrastructure and a process to enable the effective implementation and deployment of these initiatives, categorized in the above figure as the IT-driven initiatives. This paper describes the process used at Duke to ensure an integrated approach. The Report of the Strategic Planning Committee�Information Technology Advisory Council, Duke University and the Duke University Proposed IT Strategic Plan are foundations for all architectural initiatives.

Architectural Process

Motivational factors

Duke is a large institution comprised of the Duke Health System and Duke University. There are two central information technology organizations and numerous information technology groups within the departments and the schools. Duke is fortunate that the chief information officers for the two central information technology groups have developed a professional relationship that is based on cooperating and collaborating on enterprise issues. Landen Bain is the CIO for the Medical Center Information Systems (MCIS) and Betty Leydon is the CIO for the Office of Information Technology (OIT).

Upon her appointment as CIO for Duke University, Betty Leydon established an Information Technology Advisory Council (ITAC) to reach out to the community to identify needs and to advise her on information technology issues. ITAC has been invaluable in identifying essential issues and in establishing an open collegial environment. As ITAC and Ms. Leydon addressed the new challenges and as she worked with Mr. Bain, it became apparent that important infrastructure issues needed to be addressed from an institutional perspective. However, there was no one person responsible to proactively identify and address these issues.

Duke also has a Systems Integration Coordinating Committee (SICC) to coordinate the activities of the major enterprise applications being deployed. This group is led by the Executive Vice-President and meets on a monthly basis to discuss policies, review progress, and identify major issues. This group has representation from both the University and the Duke Health System. Major decisions on enterprise applications are taken through this committee.

In late 1996 a search was started for a Director of Information Systems Architecture and in June 1997, I started in the new position. To get a better perspective of what was required and the best approach to set up an architectural process, several meetings were held with the ITAC Steering Committee, the CIOs, and key information technology managers. It became clear that the open collegial environment and the strong desire and support by the two CIOs were characteristics to use and build upon in the information technology architectural planning process.

In December, 1997, Landen Bain and Betty Leydon chartered the Technical Architecture Standing Committee. The mission of the group is as follows:

"The purpose of the Technical Architecture Standing Committee is to propose information technology architectural plans, standards, and guidelines to Duke University taking into consideration the role of the University as a leading-edge research institution. The council will work with existing organizations (SICC, ITAC, etc.) to ensure that critical factors are considered. Toward this end it:


Any plan needs to be established in a specific context. As for information technology plans and IT architecture, the context must be the institution�s strategic goals and business drivers. These are stated in the Report of the Strategic Planning Committee�Information Technology Advisory Council, Duke University, and the Duke University Proposed IT Strategic Plan that were discussed in the introduction.

The Report of the Strategic Planning Committee�Information Technology Advisory Council identified ten governing principles. A primary governing principle is to buy rather than build applications. The specific definition of that principle is as follows "The days of writing our own applications from scratch or heavily customizing commercial applications software to match Duke's whims are over. This model is extraordinarily expensive and prevents us from following vendor upgrade paths. Whenever possible, we should buy off shelf software for applications. When business practices conflict with the capabilities of commercial software, we should question and probably modify the business practices rather than the software."

Duke is in the midst of the implementation of several new enterprise application systems. The two primary ones are SAP/R3 (for the procurement, financial, human resources, and payroll operations) and PeopleSoft for the student information systems (enrollment, financial aid, bursar, etc.) These systems are being deployed in a three-tier environment on a UNIX (AIX) platform for the application and database servers. The client environment is primarily Windows for administrators and clinicians. However, there are a large number of other environments (Macintosh and UNIX clients) that end-users are expected to use to access these systems. These applications are being deployed over an open network environment (TCP/IP).

These applications and their topologies are a given part of the landscape at Duke. Therefore, the Technical Architecture Standing Committee has devoted its main activities to the "city planning" architectural issues as opposed to "building" architectural issues. The architectural standards for specific application systems, while important, are not the primary focus of the Technical Architecture Standing Committee except at the boundaries. That is, where the application systems interface with other systems and where there are overriding institution-wide objectives.

Information Systems Architecture Definition

There are probably as many definitions of information systems architecture as there are people who have responsibility for establishing one. Therefore, it is important to establish a working definition of our "architectural" objectives at Duke University.

Dennis A. Stevenson edits a web site on enterprise architecture. The definition that is used by Stevenson is "Enterprise Architecture is a complete model of the enterprise; a master plan which acts as an integrating force between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as application systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks."

Martin Ringle, director of Computing and Information Services at Reed College, and Daniel Updegrove, university director of Information Services at Yale, presented a paper at CAUSE 97 entitled "Is Strategic Planning for Technology an Oxymoron?" They contend that there are two distinct aspects of strategic technology planning�a socioeconomic and a pragmatic/technical one. The socioeconomic objectives are strategic and the technical goals are primarily operational. Using this definition, the Technical Architecture Standing Committee concentrates on the socioeconomic or strategic objectives.

Ringle and Updegrove state that in their work the motivations that were most frequently mentioned for the strategic objectives were:

As the Technical Architecture Standing Committee process has evolved during its first year, the working definition of "information systems architecture" has been a pragmatic hybrid of the master plan used by Stevenson and the socioeconomic or strategic objectives identified by Ringle and Updegrove. The master plan is in reality a set of information system topics that are part of the infrastructure that needs to be built to address the institution�s goals and objectives. Additionally, the Technical Architecture Standing Committee recognizes the need for agility and to provide guidance on the most critical issues.

While communications within the group and with other groups is essential, the emphasis is not on creating voluminous architectural plans or a "master plan" outlining all the architectural elements. The main objective is to implement an open and collegial process that optimizes the opportunity to address the strategic objectives identified by Ringle and Updegrove.

How does it function?

When the Technical Architecture Standing Committee was established, one of the most significant considerations was the composition of its membership. It was imperative to identify key individuals who not only have a good grasp of the technology but also have the ability to bring the perspective of a specific constituency. It was also essential that these individuals while bringing a specific perspective could optimize to the institutional objectives, sometimes at the expense of optimizing to their parochial interests.

Optimizing to the institution�s objectives cannot always be accomplished easily. There are many projects and initiatives that have deadlines that cannot wait until the "master plan" is agreed upon. The challenge is achieving the appropriate balance between the differing needs and maintaining a pragmatic perspective. In some situations, the practical approach is to recognize the risk of having to modify a specific implementation afterwards.

The committee membership consists of technical leaders from the central information technology organizations (MCIS and OIT), the schools (undergraduate and professional), the main enterprise applications (SAP and the student information system), and the faculty. It is important to state that the objective is not so much to have a representative body but to identify individuals that brought the diversity sought while maintaining an institutional perspective. As a result, there are not members from all the schools as there are at ITAC.

The Technical Architecture Standing Committee started meeting on a biweekly basis. Practical considerations of everyone�s busy schedules have taken precedence, and it now meets monthly. However, significant work is done outside the committee. The committee communicates between meetings by posting working papers in a Notes database that is accessible to the committee members and a broader set of subject experts. The papers are posted to a Notes database before the meeting to give committee members the opportunity to come prepared to the meeting, making the time when members meet face-to-face more productive. A web site is also maintained where minutes and the papers that have been reviewed are published. This provides for an effective means of communication to the broader community.

Proposals and recommendations from the committee are taken to a standing monthly meeting by MCIS and OIT that is attended by the two CIOs. Depending on the outcome of the CIO review, these recommendations are reviewed with either ITAC or SICC or both. Additionally, on a periodic basis, the Technical Architecture Standing Committee chair gives a status report to ITAC on the issues that are being investigated. This enhances communications with the broader community and sets an expectation level of when items will be coming up for review at ITAC.

Issues addressed

Several areas had been identified by the CIOs and the ITAC Steering Committee as requiring attention. These were as follows:

Desktop Standards

The first issue addressed was to standards for client systems used by administrative personnel. Addressing the desktop standards for the administrative staff provided the opportunity to get the Technical Architecture Standing Committee focused on a specific problem. People in the departments were aware that new enterprise systems were being developed. Many had express the concern that their budget and purchase plans needed to be compatible with the new enterprise systems. Therefore, many departmental staffs had been asking for guidance in their hardware and software acquisitions.

Additionally, Duke spends over $15 million annually on desktop systems. There was an opportunity to provide a valuable service to our users, while leveraging the purchasing power of the institution. The development of administrative standards allowed Duke to negotiate advantageous price discounts for those systems. At the same time, the standards allowed for the opportunity to preload the systems with the appropriate software. This resulted in a service to the end-users, lower prices, and reduced support costs.

Enterprise Applications

The enterprise applications subject turned out to be a decision where the Technical Architecture Standing Committee played a supporting role rather than a major role. The major open decision that remained when the Technical Architecture Standing Committee was formed was what application package should be purchased for the financial, human resources, and payroll. PeopleSoft had been selected for the Student Information System and SAP had been selected for a pilot installation for procurement the prior year.

The Technical Architecture Standing Committee agreed on a set of principles that enterprise applications should follow. The overlapping membership between the Technical Architecture Standing Committee and the Systems Integration Coordinating Committee (SICC) ensured the linkage of information to the executives driving the decision. The Technical Architecture Standing Committee served as a resource that could investigate vendor claims, find out industry consultants perspectives (e.g., Gartner Group), and follow up with other organizations that were implementing similar systems.


A comprehensive approach to authentication was identified as a very critical issue that could significantly affect the enterprise systems being installed. Significant time was spent within the Technical Architecture Standing Committee outlining the current security system at Duke and reviewing approaches that had been explored. This review helped clarify the issues that had to be addressed and allowed members of the technical staff to explore potential solutions from several vendors.

As a result of this effort, we identified other groups in the medical center that were looking into providing end-users with a "single sign-on" solution. It became clear that a collaborative approach spanning several subject areas would prove beneficial. After several months of work, a comprehensive proposal for an authentication approach has been presented to the CIOs and is currently undergoing the funding approval process.


The network is at the core of the new enterprise applications topology and is fundamental for our students, faculty, physicians and staff. As such, this is an area where Duke has made significant investments over the last four years. However, major questions remain such as what should be our renewal cycle, in which technologies should we be investing, should data and voice networks be combined, etc. Additionally, the implementation of new enterprise systems over the same network used to access the Internet, the dramatic growth in the use of e-mail, remote access, and emerging applications such as distance learning and telemedicine, give rise to a myriad of questions.

This area has received and continues to receive significant attention. Some of the network activities handled include the upgrade plans for our student residential network. Another area that has taken substantial committee time has been remote access. Over the last year, Duke has been involved in ADSL and cable modem trials. The ADSL trial led to an offering for our Durham residents through Durhams telephone service provider.

Recently, a concept paper was presented to the CIOs describing an enterprise server network to support application and database servers. Work is currently underway on the design of the enterprise network, that will be taken through the Technical Architecture Standing Committee for evaluation before broader community review and the seeking of executive support.

Data Administration and Management

One of the governing principles from the Strategic Planning Committee Report for IT reform is to maintain "One master copy of all information. No information (address is an excellent example) should be entered more than once. All systems which need a piece of information should receive it automatically and electronically from a source traceable back to the master copy (eventually via a data warehouse) and never by re keying the data."

Currently at Duke University, there are dozens of overlapping sources of directory information with varying levels of data currency, completeness, quality, integrity, and security. The two primary sources, HR payroll and student systems, are to be replaced within the next two years by enterprise-wide implementation of two separate purchased systems, that were previously mentioned. Both of these application systems are built on highly integrated relational data structures, but the two systems cannot share the same transactional databases.

The Technical Architecture Standing Committee concluded that now is the time, during implementation of these two operational systems, to integrate the two through planning and deployment of an enterprise directory. Creation of an enterprise directory will facilitate elimination of the current online web server directory, the telephone directory master, the many current e-mail directories, as well as the convoluted processes that build them.

The Technical Architecture Standing Committee brought forward the recommendation to establish a working group to develop a detailed enterprise directory requirements document that would be used to develop the technical specification. The requirements document along with the technical specification will be used to identify potential vendor solutions and to bring forward a recommendation with specific costs and timetables. Recently, the requirements phase was concluded and we are into the development of the technical specifications

Other items addressed

Several other items have come before the committee. For example, the committee reviewed the work of a group that had been addressing document imaging. While the Technical Architecture Standing Committee did not spend much time on this subject, it was able to identify areas where the group could link with existing activities (Notes implementation for administrative and clinical staff). The meeting with the Technical Architecture Standing Committee also served as a means to gain support among critical groups at the institution. As a result, the document imaging workgroup was able to obtain the necessary funding to begin the project in 1998.

Web tools was another subject at one of the committee meetings. The review of the current state of the industry and the web tools led to the conclusion that it would be premature to set rigid guidelines or standards in this area. On the other hand, Duke University sponsors "Futures" meetings where sharing of experiences with emerging technologies are discussed. The Technical Architecture Standing Committee identified web tools as a subject area to discuss at one of its Futures Forums.

Upcoming items

There are two major items that the Technical Architecture Standing Committee needs to address in the coming monthssystems management and data marts.

MCIS has been very active in the investigation of reducing the cost of ownership and is seriously looking into systems management tools. MCIS CIO, Landen Bain, is committed to ensuring that this issue is addressed from an institutional perspective. The implementation of the new enterprise systems will provide the opportunity for capturing data that needs to be organized and structured for the appropriate data queries and reports. The initial dialog has begun among the technical owners of the enterprise systems and the director of data administration to identify the requirements and the functional specifications.

Lessons Learned

Ringle and Updegrove have the following quote in their paper on strategic planning:

In preparing for battle I have always found that plans are useless, but planning is indispensableDwight D. Eisenhower

One of the major lessons taken from the implementation of our architecture planning process is that the process and people are as important as the technical subjects being considered. It is imperative that the architectural priorities are aligned with the institutional objectives. It is also critically important to base the process on the value system of the institution. The process that has been implemented is founded on the desire to maintain an open environment where alliances are built and knowledge is disseminated.

Significant progress has been made in the first year, however much remains to be done. The decision to start in an area that was easily definable and relatively, although not totally, non-controversial, proved to be wise. It helped to create the necessary momentum and gave a sense of confidence to the group that this approach would work.

It is essential to identify areas that provide value to the end user community while addressing infrastructure issues. For instance, our approach to security while focusing on the obscure issues of strong authentication and a more manageable security system, also has focused on how we can give the users the benefit of a "single sign-on" to their applications. We have similarly focused on the benefits that a unified enterprise directory can provide the users of our systems.

Approaching the architecture from an enterprise perspective in an environment such as Duke University, with the diverse needs of its health system and its academic mission, is a significant cultural shift for the information technology staff at the two central information technology organizations (MCIS and OIT). The support of the leaders of these functional areas has been fundamental to this approach. Fortunately, at Duke University this collegial atmosphere begins at the very top of the organization. It would be misleading, however, to state that this has not presented some challenges as we modify our culture.

This process, at times, can be slow moving. On the other hand, if essential constituents that the key decision-makers rely upon, are not involved in building support, information technology initiatives can be stalled and if implemented will have difficulty in getting the acceptance required for a successful implementation.