DRAFT - For Comment from SSWG Members - DRAFT

DRAFT - Preliminary Recommendations for Application Platforms to Foster Interoperability, Sharing, and Reuse - DRAFT - 1/4/2010 - JMP

Purpose

The purpose of this document is to provide guidance in evaluating and selecting application platforms when purchasing commercial software, customizing off-the-shelf (COTS) software, and/or developing software for use at UC Davis. The primary criteria suggested for making such decisions are:

• Fostering interoperability among UC Davis's software applications to enable integration and realignment of business processes and information exchange, and
• Sharing and reuse of software components.  Sharing and reuse eliminate redundancy of effort, saving resources and allowing development groups to focus on their unique needs. Sharing also can also enforce common implementations of business rules.

Other platform selection criteria are also discussed.

Audience

This document addresses two audiences:

• IT administrators and decision makers who are bringing new applications to the campus, whether purchasing or building.
• Software developers and systems administrators who are responsible for developing, deploying, maintaining and supporting applications for the campus.

Definitions

• Application Platform: For the purposes of this document, "platform" refers to the stack of hardware, operating system, database backends, middleware, programming languages, frameworks, etc. that is required to run an application.  Some platforms are flexible at some layers of the stack, allowing alternative selections for operating system, hardware, etc., and others are less flexible.
• Tier 1 Systems: Applications that are used across the enterprise which serve as systems of record for institutional data, including the financial systems, HR and payroll systems, student information systems and the core middleware and services required to support such systems.
• Service Oriented Architecture (SOA): A set of software development and deployment principles that focus on allowing applications to interoperate by using open standards and to expose functionality for easy integration. For a more thorough definition, see ...

Summary of Recommendations

• All applications that will be integrated into the UC Davis software ecosystem should employ Service Oriented Architecture principles, including not duplicating existing functionality (i.e., sharing or reusing existing services whenever possible) and exposing data and new functionalities as services using open standards for reuse and sharing by other applications.
• In determining the scope of an application (as outlined below), decision makers should consider not just the application scope but also whether the data produced or maintained by the application will have a broader scope than the application itself. Even though a single department may be the primary user of an application, the data may be critical to other areas of the campus. In such cases, the data scope rather than the application scope should determine the interoperability requirements.
• For Tier 1 systems, Java is the preferred platform. Most of the key middleware components and many existing Tier 1 systems deployed on campus provide for rich interoperability using Java APIs and services.
• For applications that cross organizational boundaries (across multiple colleges and/or administrative departments), any platform that supports SOA principles and is acceptable, so other platform selection criteria should be considered. Additionally, such applications should strive to make use of existing services rather than recreating such services.
• For applications that are local to an organization (within a single college or department), platform selection has the least impact to the rest of campus. However, good stewardship of University resources (including development effort) includes minimizing duplication of services and redundancy of data. Additionally, the recommendation regarding data scope should be strongly considered in determining the true scope of an application.

Discussion

The selection of a platform can affect many aspects of the design, implementation, operation, and maintenance of software applications.  This document contains initial recommendations from the Software Standards Work Group (SSWG) for applications developed and operated at UC Davis. For the most part, these recommendations are grounded in UCD's current IT envirnoment; there has not (yet) been extensive discussion of what changes to that environment might be desirable in the future.

There are, of course, factors other than interoperability, sharing and reuse that should be considered when choosing a platform, such as existing infrastructure and expertise, scalability, security, etc., but they are not the focus of this document.

As memtioned above, these recommendations are preliminary, intended to provide quick guidance to application developers in the short term.  See the Future Work section of this document for continuing work the SSWG will do to foster interoperability, sharing, and reuse.

Existing Software Ecosystem at UC Davis

Tier 1 and 2 Applications and Middleware

Platform Component Details

• Here, the terms "SOA consumer" and "SOA provider" indicate strong, native support for SOA principles vs. add-on/after-thought functionality.
• As most modern application servers, database backends, and development platform support multiple hardware/OS combinations, this table focuses on only the higher levels of the platform stack.

When Does Platform Matter for Interoperability, Sharing and Reuse?

In many contexts, platform does not matter.  In particular, interoperability is more the result of the strict adoption of interface protocols and formats, rather than platform.  Some platforms may have features to make the construction of those interfaces easier, but the construction of interfaces is not generally a dominating factor in the overall effort required for an application. Because of its close affinity to interoperability, platform selection also has little effect on the ability to share applications.

Reuse of software, however, has a heavy dependence on platform.  In order for a group to operate an application that has been built elsewhere, a number of conditions must be met:

• The platform's infrastructure must be in place, either locally, or from a service provider.
• The group must have expertise in the management of the platform.
• If the group will be performing development or modification of the application, it must have expertise in the development languages and tools.
• The group must have sufficient resources (human and otherwise) to do all of this.

Acquiring any or all of these can be difficult and costly.  If an application is being designed, and there is an expectation of someone else operating it in the future, care should be taken in platform selection to both minimize custom dependencies and ensure that there is broad platform support and acceptance on campus.

It should be noted that platforms may be assembled from components supported by multiple groups.  For example, the College of Letters and Science's Timesheets system is moving to a three-way partnership where the hardware is managed by Information and Educational Technology, the other software components are managed by the College of Letters & Science, and Administration and Resource Managerment provides end-user support. 

Platform Recommendations

The SSWG considered the following generic platform types:

• Java - Java is probably the most-used platform for large-scale, enterprise administrative applications in the IT industry and within higher education particuarly.  It has been adopted by numerous software development communities, including Kuali, Jasig, Sakai, and Internet2 middleware.  Java applications can be executed on many hardware / operating system configurations.
• .NET - .NET is competitor to Java that is marketed by Microsoft.  It has been used to build many applications, and its development tools are well-suited for quick development of relatively simple applications ranging from medium to high complexity [edited by MTN].  .NET applications must be executed on system configurations that use the Windows operating system. [I'm not aware of .NET / higher education aligned organizations like Kuali, etc.  We should list them, though, assuming they exist.]
• ColdFusion - ColdFusion is a platform that is well-suited for quick develeopment of relatively simple applications.  Historically, it has been popular for use at UC Davis.  The advantage of ColdFusion is that its simple to use language can be learned in a relatively short time. [edited by MTN]  
• Oracle Forms - Oracle Forms is also a platform that is well-suited for quick development of relatively simple applications.  It also has been popular for use at UC Davis, particularly for the Banner student information system. [recommend we delete Oracle Forms]
• PHP [recommend we add PHP]

These represent the principle platforms currently in use at UC Davis.  It should be noted that the SSWG did not consider specific configurations of the components that comprise specific instances of these platforms, although that is work that the SSWG will undertake.

Not all platforms are appropriate for all application contexts.  The SSWG considered the following contexts:

• Core administrative systems of record, such as Banner, DaFIS, or PPS
• Applications that are shared among multiple colleges and departments
• Applications that are reused among multiple colleges and departments
• Applications that are local to a single college or department

The following sections recommend platforms for each of these contexts.

Core Administrative Systems of Record

Because of the crucial need for business continuity associated with these systems, the ability to share services and expertise among core administrative systems is critical.  Cost effectiveness is also crucial. In order to have sharable services and expertise at a minimum cost, Java is the recommended platform.

Most of UC Davis's core systems have a planned migration to Java. It is interesting to note, however, that few of those systems are based on Java at this time.  This is due to historical reasons and is likely to last for a long time, as the high cost of conversion often dominates other considerations. PPS (the Payroll Personnel System) is operated outside of UC Davis, so it is in many ways more similar to shared applications than the other core applications.

Applications that Are Shared among Multiple Colleges and Departments

When the availability of infrastructure and expertise is less of an issue, other platforms are used for shared applications.  Java, .NET, and ColdFusion are recommended for these applications, with ColdFusion more appropriate for less complex applications.  Infrastructure and expertise for all of these platforms is available within UC Davis for these platforms, although that availability may be subject to local priorities.  [Do we really want to recommend ColdFusion?  It seems to me it's not as mainstream these days as, say, PHP.  See "A Comment on Oracle Forms" below.]

From an IT perspective, sharing is the preferred method to avoid duplication of non-core applications across UC Davis.  However, care should be taken to consider the commitment of resources made when offering to share the operation of an application.  There should be clear statements of what the service is, including its expected lifetime and the financial support model.

Applications that Are Reused among Multiple Colleges and Departments

When it is planned or likely that an application will developed by one group will be passed to a different group, there should be consideration of the recipient group's ability to operate the platform (or to have someone operate it for them). For example, if the intent is to expand locally-developed applications for campus-wide deployment supported by IET, the recommendation is Java or one of the other platforms supported by IET. [Define supported by IET?   If IET runs the server only, should the application be written in Java? -MTN]

Applications that Are Local to a Single College or Department

Applications that are not shared or reused may use any platform, although use of UCD-supported platforms is still recommended.  Also, the chance that it will be desirable to share or reuse an application at some time in the future should be considered.

A Comment on Oracle Forms

Historically, Oracle Forms has been used for many applications at UC Davis.  The platform, however, is no longer mainstream and is not recommended for new development unless that development an extension to existing Oracle Forms applications, and the work is being done by a group that already has the requisite infrastructure and expertise.

Future Work

The SSWG plans to undertake the following activities to further our goals of interoperability, sharing, and reuse of software:

• Non-technical advice for colleges and departments that are developing applications they would like to offer for sharing or reuse.  This would include roles and responsibilities, cost sharing models, service expectations, end-user support, etc.
• Interoperability standards, particularly for interactions with core applications and middleware.
• Definitive descriptions of the supported platforms, including configuration, developer support and documentation, etc.