IST-ASAG Webapp Platform Recommendation FAQ

1. Recommendation Scope and Adoption

1.1. Why should non-IST units align with this IST-AS recommendation?

IST-ASAG intends to provide/identify a rich, well-supported (locally & in the world outside campus) set of tools and methodologies with which to develop web applications. Over time, offerings will include training, toolkits, components, prototypes, automated test frameworks, automated build and deploy scripts, and more. This support will be offered to IT developer groups throughout the campus, in addition to the IST-AS Web Applications unit. The hope and intention is that the campus will find this support does make webapp development easier; and also results in robust, maintainable, appropriately scalable, service-oriented software artifacts. Early adopters will be those units whose managers and/or analysts have reached similar conclusions to IST-ASAG's. The "propagation" of this recommendation beyond IST-AS and early-adopting units is expected to depend on whether, by choosing to develop on a platform supported by IST-ASAG, IT units across the campus will be enabled to increase their ability to deliver IT functionality needed to further UC Berkeley's mission. Once that turns out to be the case, non-IST units will have a good reason to align with this recommendation.

1.2. Where are the resources to convert to a recommended platform going to come from?

Platform conversion is a recurring process everywhere in IT. It is always necessary, eventually. IT managers should have their fingers on the pulse of changing technology environments and business requirements in order to determine when it makes financial and functional sense to migrate applications. IST-AS is taking a cautious tack in this regard: the recommendation IST-ASAG has proposed is for new application/service development. In general, we are looking at "converging toward" rather than "converting to" a smaller set of platforms in which to develop web applications (IST-AS currently supports, in production, web applications developed on ~14 different platforms). By converging toward a more managable number of platforms, managers will have more staff converscent in recommended platforms who can be deployed to project "hot spots." Broadening and deepening a pool of developers who can be assigned to new webapp development work in IST-AS is expected to facilitate project managment and improving our responsiveness to customer needs. At the same time, we intend to continue to support what we have in production through its lifecycle. Where major changes are in the works, IST-AS managers may see good financial and/or functional opportunities to migrate an application to a service-oriented architecture on one of the recommended platforms. IST has no "magic" sources of funds to achieve convergence or conversion. However, we think it would be prudent for IT managers across the campus to evaluate whether direction and support offered by IST argues for parallel convergence and/or conversion efforts in their areas of responsibility.

1.3. Who will be required to conform to this recommendation?

As written, the recommendation is designed for, pertains to, and was developed in consultation with the IST-AS Web Applications unit. The management of that unit is enthusiastic about the direction mapped out by IST-ASAG's recommendation. No one, however - including the IST-AS Web Applications unit - is "required" to conform to the recommendation. IST-AS Web Apps plans to conform to the recommendation if pilots currently in progress bear out the conclusions of IST-ASAG's analysis. Over time, as support incentives are developed and made available, it is hoped that the benefits implicit in conforming with the recommendation will encourage - rather than require - its adoption.

2. Java and Rails: Further Definition

2.1. Java is one of two recommended platforms, but there's no detail in the platform recommendation about which framework(s) are recommended. Where and when will further detail be available?

Please see the Product / Technology Life Cycle Matrix for Java/JEE and its associated "key" document, Technology Life Cycle at UC Berkeley.

2.2. What indications are out there that Ruby and the Rails platform is going to evolve and thrive, rather than flame out in a few months or a year?

Ruby has been around since 1995, and in October 2006 became listed as a "mainstream programming language" on the TIOBE Community Programming Index. There is heavy (and increasing) activity in Rails development, including proliferation of well-crafted open-source implementations, investment by heavyweight technology companies (IBM, Sun), and indicators of community interest among both well-respected software engineers and the "rank and file." Are these indications guarantees of RoR's success? Of course not. But IST-ASAG and much of the software engineering community that we track suggest that Ruby on Rails is a keeper.

2.3. Why the Java and Ruby platforms - what synergies between the two platforms influenced the platform recommendation?

JSR 223 is a specification for scripting integration with the Java platform that has been in development in the Java community for several years; the Java SE 6 platform implements the java.script APIs, which allow integration with script engines that comply with JSR 223. Fall 2006 saw the announcement that Sun hired two principal developers of JRuby, a "100% pure-Java implementation of the Ruby programming language," at release 0.9.1 as of mid-October 2006. There is significant interest in Ruby and Rails within the Java community. For example:

• Trails is a domain-driven development framework for Java modeled on the Ruby on Rails framework.
• Grails brings the "coding by convention" paradigm, a hallmark of the Rails framework, to Groovy, an agile dynamic language for the Java Platform that draws its inspiration from Ruby and other scripting languages.
• Bruce Tate, author of several Java books, recently published From Java to Ruby: Things Every Manager Should Know.
• Martin Fowler, author of seminal books Refactoring and Analysis Patterns (among others), has expressed vocal and articulate interest and support for Ruby and Rails, writing in one of his many posts on Ruby and Rails topics that he has been "a keen rubyist for several years."

2.4. How soon will production quality IST support be available for Ruby on Rails? That is, how long will it take for the four IST units to operationalize these architectural recommendations?

Pilot projects in Ruby on Rails are in the works. Their deployment, expected in early 2007, will signal that infrastructural support is available in the data center for Rails apps. Developer support will continue to evolve and improve over time.

3. About .NET

3.1. Does this recommendation imply that .NET apps will not be hosted in the data center?

This recommendation does not suggest that IST stop hosting or supporting .NET in the data center. There is a strong .NET representation in critical applications on campus, and a strong .NET developer community in certain departments; as well as .NET offerings from commercial vendors and sister-universities that campus customers need or want to use. IST's Infrastructure Services unit has indicated clearly that .NET, IIS, and similar Microsoft offerings will continue to be hosted and supported in the data center.

3.2. There are all kinds of metrics out there that compare Java/J2EE and .NET. How do those metrics figure into IST-ASAG's recommendation?

The recommendation recognizes that Java and .NET are both "well-qualified candidates for implementation of complex, enterprise applications and services at UC Berkeley." We have read some of the vast literature comparing these two platforms in the course of arriving at our conclusions, but the recommendation is not based on an evaluation that one is a "better," "easier," or "more popular" platform than the other. Proceeding from the assumption that Java and .NET are peer platforms, the Java platform was "judged a better fit to UC Berkeley's environment" for a number of reasons - mostly having to do with integration - that are listed in Section VI. of the recommendation document.

3.3. Why can't IST-ASAG support .NET as robustly as it plans to support Java and Ruby on Rails?

It's a resource question. With 2.5 FTE, IST-ASAG can't offer deep, useful, expert support for more than one enterprise platform. Similarly, IST-AS is disadvantaged when its developer expertise is fragmented among multiple platforms: it's much more difficult to deploy staff resources to critical projects when training/expertise issues stand in the way; and IST-ASAG believes that the IST-AS Webapps problem-space can be covered by two platforms, as the recommendation explains. On the other hand, IST-ASAG's provision of support for selected Java frameworks and Rails doesn't prevent other IT shops from providing similar support for different development platforms. Taking .NET as a case that will be of interest to many, just because IST is not sufficiently funded/staffed to offer in-depth webapp developer support on two enterprise platforms doesn't preclude a departmental IT group (or a consortium of such groups) from creating the same type of richly-provisioned, well-documented, carefully architected support in .NET - or in other development platforms that are not among IST-ASAG's strengths.