Cornell OIT IT Architecture Initiative

As part of the IT Architecture Initiative, the Office of Information Technologies (OIT) is producing a series of papers outlining directions in information technology architecture.

In the spirit of RFCs, the papers are intended to facilitate understanding of and open dialogue about information technology trends at Cornell, with the ultimate goal of improving the utilization and interoperability of information technology services throughout Cornell.

Administrative Computing Architecture at Cornell: The Foundation for Cornell's IT Architecture (working draft)

SYNOPSIS

Cornell's administrative computing architecture will be described in three distinct documents. This paper, the first, describes the business architecture. The second paper will describe the technical architecture, and the third the products and standards architecture.

This paper defines the business architecture for administrative computing. It describes the various business activities required to support Cornell's mission and describes a conceptual framework for delivery of transactions and data. This paper outlines in 3 parts:

• The need for and benefits of a common administrative computing architecture at Cornell, and the current state of administrative computing

• A conceptual framework for new Cornell business processes and the administrative computing architecture

It is hoped that many elements of the administrative computing architecture will be the foundation of the larger Cornell IT architecture initiative.

As many at Cornell are aware, the university is reviewing support services through a process generally known as Workforce Planning. Internal executive committees and external professionals have reviewed Cornell's information technology services and recommended ways to improve their cost effectiveness and quality.

One recommendation is to develop a coherent, campuswide IT architecture. An IT architecture contains the standards, practices, and products necessary to support applications and services across the university. For administrative computing alone, Cornell could save millions of dollars per year if it had a common IT architecture.

In response to these recommendations, the Workforce Planning Team has charged OIT with the development of a campuswide IT architecture. OIT believes the best way to do that is to initially focus on an architecture for administrative computing. Once completed and agreed upon, this administrative computing architecture, OIT believes, will encompass many components of the campuswide IT architecture.

A new governance structure for administrative computing is a prerequisite for the success and adoption of the architecture outlined below. As part of Cornell's Workforce Planning review, an external administrative computing review committee recommended "a general governance structure for administrative computing, like FABIT is on the academic side." (1)

Just as FABIT (Faculty Advisory Board on Information Technologies) provides feedback and guidance on academic services to the vice president for information technologies, so will the administrative advisory group become the campus's single, coordinated point of governance for all administrative systems. This approach will ensure the oversight desired without the need to develop independent solutions.

Benefits of a Common Administrative Computing Architecture

Though there is a mandate by the university administration to develop, and in turn abide by, a common IT architecture, there are many other reasons for moving down this path:

Administrative Computing Architecture Issues

Cornell IT service providers already agree on many components of delivering IT services. They also agree that certain components of local IT service needs are the same across campus. However, without standardized approaches, the interoperability and support of selected IT solutions across campus cannot be assured. In addition, the cost of delivering "unique" approaches can be higher since each department operates without the benefit of a larger, integrated pool of institutional knowledge and hardware and software quantity discounts.

Independent solutions are justified in some cases, but most administrative requirements at Cornell today will benefit from having a common and shared architecture and business processes. That said, it is unlikely that either CIT, or those in IT support within independent organizations, will feel 100% comfortable with any architecture defined. It may help to think about it not as a win/lose game but as a partnership. Every service defined "centrally" is not a victory for CIT and a loss for those who once delivered the service locally.

If economies in leveraging a common architecture are found, then departments will be able to afford to enhance services a central organization should never deliver. Each agent on campus must work in concert to provide greater value to the customers all are here to support. The challenge is not to simply provide IT support at Cornell, but to optimize services by consistently challenging old ways and norms as a means to generate greater value to all.

Lack of cross-unit cooperation

Some may view efforts to create a common architecture as an attempt to unilaterally control what has traditionally been done with little oversight. But creating a common architecture is not a dictatorial process -- it is a rational process of discovering how diverse groups can work in concert to derive a greater value than that which can be achieved alone.

The task requires open communication, unbending honesty, service excellence, and, above all, partnership with all at Cornell to meet common, standards-based, IT goals. One important step is to define common architectural components (i.e., those that are used to deliver applications but offer no localized business value) that can be leveraged by decentralized value-added IT providers. This will allow local IT work to add the most value for the effort expended.

Sense of product ownership

Any time an organization explores the potential value of leveraging a common architecture, emotional attachment to "IT innovations" needs to be addressed. IT innovations are the products of individual discovery driven by personal will to get something done . All about Cornell are innovative examples of how bright and dedicated members of our community have created resources that provide valued services, from strategies to deliver mail to security processes.

The creators have great pride and personal stock in their homegrown solutions. In many ways, their products afford and protect the creators' need within the organization. So it is easy to imagine their reaction to any threat to their intellectual creations, regardless of the sound fiscal reasoning behind such threats. Ideally, new local tasks for the creators will be identified as part of developing the common architecture, and IT innovations whose time is up can be laid to a much respected rest.

Local optimization

Another challenge that organizations face when trying to achieve the artful balance between the value of central services and continued support for local alternatives is the tendency to defer to and place greater value on local perspectives (the home team).

Effective managers trust and support their IT staff, and value their advice and institutional knowledge. But administrators also need to consider the bigger picture of the university. Whether deans, department chairs, business officers, or directors of computing, the challenge is the same: Has the best value mix been achieved? Can you get more for what you spend? Can you maintain service levels during times of shrinking budgets?

None of these can be answered if all units spend their efforts protecting local resources. This is by no means to suggest that local resources are not of extreme value, only that attachment to "IT innovations" and the natural desire of administration to support the home team can hinder the ability of those ultimately responsible for fiscal decisions to move forward.

Freedom of choice

The very nature of a single architecture seems antithetical to the principles of academic freedom in that it constrains the set of products that conform. However, these constraints are justified when the institutional costs of supporting "non-standard" technologies are fully considered. We need to step away from the concept of choosing multiple technologies and products simply for the sake of diversity.

Current State of Administrative Computing at Cornell

Cornell stands alone from our Ivy peers in how we approach administrative computing. Those peers, as well as Gartner, Inc. consulting and the external administrative computing review committee, believe our current hardware/ software architecture is expensive, poor in design, inherently difficult to manage, and incapable of meeting evolving customer demands.

Administrative computing at Cornell encompasses at least 3 major database applications, 4 hardware platforms, 4 operating systems, 6 development shops, varied backup processes, and no unified vision or architecture. Our current systems have developed in response to a governance model that places each departmental entity in unilateral control of the technology it chooses to deploy. This governance model, combined with the requirement to support the constantly changing architectures embraced by our major vendors, has resulted in the current state of sub-optimization.

At Cornell, each administrative transaction process has typically evolved independent of others, and with mixed levels of central oversight. As illustrated in this diagram, this approach is often defined as "stove-piped" (forgive the horizontal pipes) because each area evolves in a standalone fashion without taking advantage of larger economies of scale or shared expertise.

As new customer demands have arisen, vested parties have overlaid web-based customer interfaces and read-only aggregated views of data compiled from each unique database. These actions, in turn, have spawned the development of "shadow systems," each another independent "stove pipe" to provide access to administrative data.

Shadow systems are a direct result of the absence of larger architectural planning, central system functionality, and cross-functional cooperation. These local, usually PC or LAN-based, systems extend -- as well as duplicate -- the functionality of central administrative systems. Populated by local data entry and downloading of data from central databases or data warehouses, shadow systems are used to perform local transactions, add data to existing transactions, perform reports needed by a local department, and do data analysis not available from the central systems.

Though shadow systems have added new means of customer access to needed information, this approach has aggravated the cost inefficiency of the larger enterprise and impacted the ability of Cornell's data stewards to control the constancy of data presentation to the larger Cornell customer base.

Many of our transaction procedures were developed before the advent of IT. Business forms carried the transaction information from department to department. Computer-based applications were written to allow the capture of information within the central office only.

As a result, many of our institutional business processes require information from several of our central transaction systems. For example, the process of applying for a grant requires the originator to work with the Office of Sponsored Programs for approvals, the Human Resources/Payroll system to determine funding rates for graduate students to be supported by the project, the Financial system for access to account numbers, and Risk Management if additional subject authorizations are required. Only when complete can the request go to external funding agencies.

Using today's systems, principal investigators (or departmental administrators) have to access each of the corresponding systems independently. Often these systems are implemented using different technologies and the access methods are different, so they have to log in and learn each system separately. This can be frustrating for those who do not use the system on a daily basis. There is also the potential for inefficiency and reduced data integrity.

PART II
Conceptual Framework

Regardless of how Cornell's administrative computing ended up where it is, it is now very clear that we must change the way we do business, forge the trust required, and ensure the business process efficiency demanded. The new architecture must:

Be Customer-Centric

The computing industry has evolved considerably since its inception some 50 years ago. One key driver of this evolution is the role of customers. Back in days of punch cards, when one large computer executed computing batch jobs, the computer served very few people directly. Now, in the wake of the client-server revolution and then the Internet revolution, administrative computing models need to scale to thousands of potential customers.

The customer base is no longer limited to business and clerical staff, and is no longer within the campus boundaries of Ithaca, New York. Administrative computing customers must be seen as faculty, staff, students, alumni, admissions prospects, state residents, and friends of Cornell.

These customers expect to do all of their business via browser-based interaction, with the same ease they have experienced from Internet companies such as Amazon and eBay. A trip to a central office to update an address or drop a course is no longer acceptable. The theme of "anywhere, anyway, anytime" access is a way of life.

The portal as a customer-centric model

To meet the needs of the new customer base, Cornell's administrative computing must shift from being system-centric to being more customer-centric. Most administrative users interact with a variety of systems and need to move seamlessly between all of them.

One way to accomplish this is to implement a suite of applications, from a single vendor, that address all the requirements of the enterprise. This would give us real system integration. However, we do not know of any single vendor that can do that. This being the case, our alternative should be virtual integration, which can be realized through the development of an enterprise portal. A portal can be thought of as a customizable web-based interface that consolidates access to university systems and services. Key features include:

Be Desktop Platform-Neutral

There is ample debate over the value of designing a new administrative computing architecture based on the assumption of a single desktop environment. While to some degree Cornell will be pushed toward a single desktop platform by its current contractual relationships and technology challenges, this is not the best long-term direction because:

To be desktop platform-neutral implies a fairly "thin" desktop client strategy (a web browser) or a protocol that enables OS-agnostic desktop processing via standardized interpretation of delivered data streams, such as is enabled by Java and XML. No other long-term direction is seen as viable for Cornell. However, we acknowledge that certain vendor products may require a fat client that is tightly bound to a particular platform. In these cases the platform dependency may be acceptable.

Thin clients as a platform-neutral solution

Most applications used in administrative computing are distributed; that is, some processing happens on the user's desktop and other work is performed remotely. The ratio of the amount of work performed by the desktop (client) to that performed elsewhere is commonly referred to as the weight of the client. Fat clients do a lot of processing on the desktop. Thin clients have most of the processing happening external to the desktop.

Although fat clients are attractive because they generate very friendly and powerful user interfaces, they are more susceptible to version and platform incompatibilities because of their heavy use of the desktop's resources. For limited distribution, heads-down applications, using a fat client may be the best choice.

The thinnest clients -- those that use only basic browser functionality -- are the most platform-neutral. By not pushing any software to the desktop, the chance of version and platform incompatibilities is minimized. The tradeoff is in the user interface. Thin clients can produce fancier interfaces, but at the cost of requiring downloadable components (plugins and applets), which introduce the potential for incompatibilities. For distribution to large populations, thin clients are typically the best choice. This is especially true as we extend the reach of administrative systems beyond the geographic bounds of the campus.

Enable Business Process Improvement

Creating an administrative computing architecture that reduces the control points and optimizes access between data and customer, by its nature, disintermediates current data access control systems. Traditionally these control points were mediated by installed "stove pipes" or other human or machine processes.

The new architecture needs to recognize the needs of departments, making sure that a large portion of required central transactions are available at the local level without the need for replication. It also needs to recognize and support the need for access to information for better management decision-making. Local purview transactions and data manipulations should be value-added rather than redundant.

A critical component of the new model assumes that the requirements for business processes control and data access control will be accomplished through a single common tool, and governed by a single oversight model. This approach was advocated by the external administrative review committee.

PART III
New Administrative Computing Architecture

This section describes a conceptual model for a new administrative computing architecture. It responds to the identified customer requirements and considers the current state of the practice of technology.

Conceptual Model for the Administrative Computing Architecture

Data warehouse

A data warehouse contains copies of operational data organized to improve casual user access for reporting and analysis. To populate a data warehouse, a process is executed, usually nightly, to extract operational data, transform it into a more de-normalized (logically understandable) model, and store it in a separate database, usually on a separate platform. Data warehouses often contain additional data stores or marts that are aggregates of the atomic-level data to allow even better reporting by affinity group. The goal is ease of use and fast access time.

To support the requirement for cross-functional data aggregation, we need to expand from independent data marts to an enterprise data warehouse architecture. This will eliminate the need to produce layers of executive information systems (EIS) that attempt to do real-time integration, but can produce inconsistent results.

Transaction-processing engines

Central applications are very good at processing a large number of specific transactions. They need to continue to be efficient but also offer specific transaction services to other applications that require official transactions to be processed.

Business process rules/views

A business process view recognizes the entire set of steps in a business process and provides easy access to the components of applications necessary to complete the tasks. After one logon, the casual user is led through the process with ease. When the process requires transaction processing, the transaction engines are invoked.

Customer views

By separating the user interface from the processing, each customer can use components (transactions and/or data) of the administrative computing environment in ways that match their own business needs. As such, they are using officially sanctioned processes and data to streamline their own work.

CONCLUSION

This paper describes a conceptual view of an administrative computing environment and architecture that will meet the needs of the diverse university community. The next paper in the series will define the technical architecture that will be required to accomplish this vision for administrative computing at Cornell.

Benefits of a Common Administrative Computing Architecture

Administrative Computing Architecture Issues

Lack of cross-unit cooperation

Sense of product ownership

Local optimization

Freedom of choice

Current State of Administrative Computing at Cornell

PART II Conceptual Framework

Be Customer-Centric

The portal as a customer-centric model

Be Desktop Platform-Neutral

Thin clients as a platform-neutral solution

Enable Business Process Improvement

PART III New Administrative Computing Architecture

Conceptual Model for the Administrative Computing Architecture

Data warehouse

Transaction-processing engines

Business process rules/views

Customer views

CONCLUSION

PART II
Conceptual Framework

PART III
New Administrative Computing Architecture