Boston College

University-Wide Information Portal

Concepts and Recommended Course of Action

Bernard W. Gleason

January 26, 2000

 

 

Introduction

 

This report provides a set of recommendations for Boston College to follow in the design and implementation of a University-wide Information Portal to support the delivery of personalized web-based services.  The document attempts to frame the recommendations in the context of the existing issues and envisioned web development directions. The document is also intended to introduce the readers to the concept of the enterprise information portal, the underlying technologies, Boston College’s affiliation in a cooperative effort with other institutions, and the impact on the existing web development activities.

 

The document provides some definitive recommendations but it is a report to the Vice-President of Information Technology. It is assumed that the content of the report will be broadly debated within the Information Technology management team before the document is circulated and the recommendations are acted upon.

 

Framing the Issues

 

Over the past year Boston College has been struggling with directions and strategies to service the various publics, both internally and externally, which wish to access information or to interact with the University via the Internet. At Boston College we know that we need to restructure and refocus our institutional web site, but we are dealing with a multitude of pressures, opinions, ideas and suggested directions. What architecture? What technologies? What projects and what priorities? Where do the external vendors fit?  Where does e-business fit? What is the institutional image strategy?

 

Boston College is not alone in trying to plot a proper course. At a recent meeting of a number of universities the discussion of the topic was characterized by one of the representatives as a group therapy session. The issues, the problems and the decisions that we are facing at Boston College are similar, and in many cases identical, to the situation at every college and university. The solution lies in the application of new technologies on a university-wide level and from an enterprise perspective. The popular term that is used in the technology arena to describe the solution or approach is Enterprise Information Portal, or in an academic setting, University-wide Information Portal.

 

This report provides a recommendation that Boston College adopt the enterprise information portal approach as a major strategic direction. The recommendation is accompanied by a set of recommended actions. Included in these recommendations is the affiliation of Boston College with the Java in Administration Special Interest Group (JA-SIG), the implementation of the information portal using the Common Reference Portal being produced cooperatively by JA-SIG, and the establishment of a partnership with Interactive Business Solutions.

 

What is a University-wide Information Portal? What does it mean to Boston College?

 

Information portals are applications that enable universities to unlock all forms of internally and externally stored information, and provide all members of the community with a single gateway to access information. Enterprise portals are derived from their more global counterparts -- e.g., Yahoo!, Netscape-- which aggregate raw information from disparate sources and provide some intuitive and personalized structure for the information.  University portals go one step further. They integrate campus-specific information, which is stored in the campus electronic vaults (i.e., databases, file systems and existing application systems) with unstructured data (text) from on and off campus. Providing a single, personalized interface to all information resources in a secure, consistent and customizable manner is the objective of the Boston College University-wide Information Portal design and the JA-SIG initiative.

 

Clive Finkelstein, Peter G. Aiken, John A. Zachman in their book, Building Corporate Portals With XML (Enterprising Computing), provide an excellent overview of the role of portals in an enterprise environment.

                    

In discussing the emergence of Corporate Information Portals over the coming years in "The Portal is the Desktop", the Director of Knowledge Technologies research at International Data Corporation (IDC) [Murray 1999] says:

 

       "Corporate portals must connect us not only with everything we need, but (also)

       with everyone we need, and provide all the tools we need to work together. This

       means that groupware, e-mail, workflow, and desktop applications -- even critical

       business applications -- must all be accessible through the portal. Thus, the

       portal is the desktop."

 

The University-wide Information Portal will become the desktop for all members of the Boston College community. Unfortunately at Boston College and every college and university there are multiple independent portal projects in process. As a result, there is poor coordination, an absence of a standard technology architecture, and very little management insight and control. This disjointed approach has resulted because there is no clear-cut definition of a University-wide Information Portal, and there is no technical guidance that will help software vendors and their customers to build applications which will interact with these information portals. Boston College and the other participating colleges and universities within the JA-SIG have banded together to provide that guidance and to eliminate duplicity of effort. The group will define a Common Reference Portal (CPR) framework -- a set of technical specifications to construct a university-wide information portal. This is a fast-track effort.

 

This reference framework will be distributed freely to all universities, so that schools can deploy Internet-standard technologies to build and manage their web environment while preserving their identity and institutional values.  The portal architecture will provide the flexibility to integrate all forms of data -- structured and unstructured, internally and externally provided, secured and unsecured – and to present the composite to individuals in a personalized manner. The alpha version of the CPR is due to be released in early March 2000 and Boston College will be an early adopter. Version 1.0 is scheduled for release by July 2000 so that institutions will have the portal available in September for the start of the 2000-2001 academic year. Hence, we will begin immediately to plan for the construction of the Boston College University-wide Information Portal based on the Common Portal Reference (CPR) framework and resuscitate the Boston College web site

 

Why are we building our own portal?  What are the alternatives?

 

Everyone recognizes the rapid growth of the Internet and the increasing reliance on the Internet as the prime source of accessing and processing information. Over the past year the Internet has adopted the e-business model, where information is delivered in a secure and personalized manner, and in a composite presentation (portal page).  The university-wide information portal is going to become the launch point for e-business applications; it will be the page that all community members will access most frequently. There are dozens of vendors who recognize the commercial potential of portals and are offering to provide software and services to gain ownership of an institution’s portal.  The strategy of the vendors is to capture the main web portal to the university and to leverage that position with advertisers and Internet sites selling products. Other vendors are developing and marketing portal frameworks built on the vendor’s proprietary product set.

From the approximately 20 participating institutions in the JA-SIG group, Princeton, Yale, Brown, Delaware, Cornell, Florida State, Georgetown, University of British Columbia, University of Washington and Boston College have committed resources to the development of the Common Reference Framework.  These institutions share a common technology vision, are protective of the institutional image, and recognize the potential of the portal. The University-wide Information Portal should be treated like the “family jewels” and not relinquished to an outside agency.

 

Over the past year Boston College and all of the member schools in the JA-SIG group have been inundated with vendor proposals, some promising to provide their rendition of a campus portal at no charge to the institution. The vendors fall into three categories. The first is the commercial portal vendors (e.g., Jenzabar, MyBytes, Campus Pipeline, etc.) who derive their revenue from selling advertising banners or including prominent links to sites, which in turn sell products. The second group is the application vendors (e.g., Blackboard, Peoplesoft) who are attempting to make their products the campus portal and then assume the same functionality and leverage of the pure commercial portal vendors.  These vendors are also marketing these so-called “good deals” to individual units within the campus in attempt to get a foot in the door. The third group is the portal software vendors (e.g., Plumtree, Brio) who sell portal framework software on a site license or per seat basis – exorbitant pricing models that don’t work for a college or university community.

 

The major marketing pitch of the vendors is that it would be too expensive for an individual institution to develop an enterprise portal on its own. To a certain extent the vendors are correct, and that assessment is acknowledged by the JA-SIG membership. But by acting collectively and sharing the institutional resources of the member schools, the cost no longer becomes the major factor or barrier in developing an information portal.  More importantly, by acting cooperatively institutions will be able to retain their individual identities and total control over their institutional web sites.

 

What level of executive management involvement is need?

 

The portal decision and the future consequences are not well understood by individuals in sub-units of the university or by the executive management at Boston College. The Internet is pervasive and is changing the way all areas of the university function on a daily basis. This change is positive and it presents new and exciting opportunities. The examination of the implications and the endorsement a consistent set of guidelines should be top priority of the executive team. As designers and developers of the information portal, we need the assurance that the enterprise approach is approved and accepted as an institutional strategy. We also need to alert the institution to the importance of an information portal and the impact of the ripple effects. Therefore, our first objective must be to raise the consciousness of the executive management team.

 

At the fall, 1999 administrative retreat a set of recommendations for dealing with the commercialization of the Boston College web site was presented to the President, Vice-Presidents and Deans. The topic of commercialization was enlightening, but there was not a real sense of understanding within the group of the issues and consequences. Specifically, there were no formal measures taken to stop individual departments from cutting deals with vendors and to create a central authority for evaluating proposals. However, there was agreement with the following recommendations:

·        Vendor applications must be able to be integrated into the BC environment, not vice versa

 

The above principles are basically the same principles that are shared by all the member institutions within the JA-SIG.  Boston College is moving in a direction which is consistent with peer institutions, but Boston College needs a central informed authority that understands all the implications, both technical and business. That person does not exist today.

 

What is the Common Reference Portal and what is the role of the JA-SIG in defining specifications?

 

In December 1999 under the sponsorship of Sun Microsystems a group of approximately 20 of the leading colleges and universities (see Appendix C for list of institutions) met to share experiences in the use of Java technology. The group became known as the Java in Administration Special Interest Group (JA-SIG). As a result of the initial meeting and subsequent meetings, JA-SIG has launched a number of cooperative initiatives. The initiative that is of immediate interest to Boston College and most other universities is the Common Portal Reference (CPR) framework. Boston College is among the schools which has accepted the leadership role in the initiative. More information about the cooperative initiatives can be found at the JA-SIG web site: http://www.ja-sig.org/

 

The intention of the JA-SIG is to cooperatively develop the specifications, to provide an operational framework in a few months, and to freely distribute the CPR to all interested institutions at no cost. By having a common reference it is anticipated that institutions will then be able to share components within the group on a plug and play basis. Institutions working cooperatively will not only drastically reduce costs and facilitate sharing, but we will also be able to exert the combined leverage of most of the prestigious colleges and universities. For vendors there will be a strong inducement to provide a single, standards-based interface to the Common Portal Reference framework, thus eliminating further institutional integration costs.

 

Individual institutions will be able to adapt the portal framework to meet the needs of their institutions, but the University-wide Information Portal must comply with the following requirements:

 

The Common Portal Reference is not an application; it is a framework that will support the requirements listed above. The framework will provide interfaces that will permit individual institutions to customize the institutional portal by plugging in components in a well-defined and usable manner. For example, the framework will require individual user authentication, but will not dictate the form of authentication. Hence, an institution could elect to plug in their old mainframe username/password scheme, or they might elect to use LDAP or some other method for authentication. A working group of JA-SIG members will define and publish the detailed specifications of the framework. The only technical and operational restrictions will be the limitations within the technical specifications of the JA-SIG design team. For example, the Common Portal Reference will be based on the Java 2 Enterprise Edition platform. The Common Portal Reference will be portable and will run on any Java 2EE compliant application server, such as Websphere. 

 

Boston College has assumed the role of an early-adopter and a major contributor to the JA-SIG Common Reference Portal initiative.  The support will include a major commitment of time by Bernard Gleason to promoting the initiative, both internally at Boston College and on a national level. Boston College will also make a contribution of programming resources contributions to the JA-SIG portal initiative and the application library. It should be our objective to reinforce and to enhance Boston College’s reputation as a leader in the early adoption and the effective application of information technology to improve the administration of the university.  The time contribution will include attendance at organizational meetings, possible visitations to other interested institutions, and the hosting of visiting institutions. This depth of involvement will also ensure that Boston College’s best interests are being represented in the JA-SIG specifications.

 

What will the University-wide Information Portal look like to Boston College users?

 

As mentioned above, a working group of the JA-SIG will define the specifications. For the purpose of illustration, I have attempted to provide a mock-up of a couple of example pages – see Exhibits A and Exhibit B at the rear of the report.

 

NOTE: The illustrations provide examples of how structured and unstructured data from multiple sources could possibly be presented in a personalized and customizable manner. The examples are not intended to be representative of a planned product.

 

These examples are intended to bring some sense of reality to the discussion. The reader should be able to use these examples as a way to grasp the concepts and  to visualize possible functionality. The reader should not expend any time critiquing layout, colors, navigational structure, or content. The most important concept is that all relevant information and services will be delivered in a personalized and coherent form to the individual, not in the traditional hierarchical structure.

 

After the University-wide Information Portal is fully operational, the portal will become the primary interface for every member of the Boston College community. This statement may seem like a reach, but the capabilities and the technologies are advancing at a pace that will make this reality sooner than one might think. It is not going to happen all at once. The challenge is to position the university correctly and to continually add capabilities and functions to an adaptable framework. The framework must also permit existing applications to continue to run unaltered until components are replaced or refined. The course of action, which is recommended in this report, is a step in the right direction technically and organizationally; it represents a set of natural evolutionary steps.

 

The University-wide Information Portal is consistent with existing Information Technology strategies. From an architectural strategy standpoint, it will require a refocusing of web development efforts within IT. Our direction, going back to the early incarnations of Agora, was to provide personalized portals as the main entry point for all visitors to the Boston College web site. Although the adoption of the Common Reference Portal platform implies the acceptance of Java 2EE as the framework for application development at Boston College, this does not conflict with our strategic direction. This action just adds formality and finality to the strategy.

 

What will happen to Agora and how does the Agora technology mesh with the University-wide Information Portal framework?

 

Agora, which is the ancient Greek word for marketplace, is Boston College’s existing secure Intranet environment. Although Agora is two years old, it still remains a very innovative application.  Agora embodies most of the characteristics of a portal, but it has limitations.  The Agora was built on the technology that was available at the time and the code and framework is proprietary to Boston College. In order to support many new and anticipated customer requests it is will be necessary to expand the capabilities of the Agora engine, or to adopt new technology advances. Most of the required new functions are built into the application server and provided by the J2EE framework services and the Common Portal Reference. It makes sense for Boston College to take advantage of this new opportunity, rather than to continue to develop in our own proprietary development environment.  The timing is “right” and the migration to the University-wide Information Portal is the “right” decision.

 

Agora is not going to go away in the foreseeable future. The university has a significant investment in the Agora applications that have already been developed and deployed. The major architectural change will be in the positioning of Agora. Agora will no longer be the main portal, but rather another application running within the framework of the University-wide Information Portal.

 

Before moving forward with incorporating the Agora into the information portal, an in-depth analysis will need to done to determine the best way, short-term and long-term, to preserve the best features of the Agora engine without disrupting current applications. This analysis and the resulting programming effort are likely to involve the assistance of outside consulting and contract services. However, in the short-term some modifications will need to be made to the Agora engine, particularly in the area of LDAP authentication and profile and session management.  These changes will address some current flaws and facilitate the movement of Agora services to the University-wide Information Portal framework.

 

Can you provide a perspective on where we have been and where we are going?

 

Agora and now the University-wide Information Portal embody the same principles that I originally outlined in 1990 in the CAUSE professional paper titled, Open Access: Use Information System. Boston College has a heritage in being a leader in the provision of user access to personal information and the processing of secure transaction. U-View terminal access, telephone VRU voice-response, ATM access services, which were all devised and implemented in the late 1980s and early 1990s, received national recognition for innovation and service improvement. Our customers (students faculty and staff) long ago became accustomed to easy and convenient forms of access, and it is natural for them to expect the same or improved capabilities via the Web.

 

While the term, portal, has only gained widespread acceptance in the past year, this type of web-based service delivery was first conceived about 4 years ago. In 1996 a small team from Information Technology built a prototype of the Campus of the Future (COF). The mock-up COF provided a visual representation of the integration of structured, unstructured and transactional information on a single web page in a personalized manner.  Agora evolved from this prototype.

 

In 1997 the Information Technology architects designed and developed the technical framework to make the Agora web-based services a reality. The key components of the framework were a processing engine and a development language called XMQL. The Agora engine is a single CGI (Common Gateway Interface) program, which knows how to handle all requests to the Agora and to return dynamic, secure and personalized web content to the client. By the summer of 1998 a group of IT developers, working with customer teams and using XMQL, released the first set of new web-based services to students, faculty and staff.  There was broad acceptance and applause for the new services.

 

The information portal using the Common Reference Portal platform is a natural evolution to Boston College’s longstanding end-user access strategy. As we transition to the next level of exploitation of the capabilities, the focus is going to be on “self-service”, but with an added dimension of “full-service.” The flexibility and scalability of the architecture of the University-wide Information Portal is going to provide for the continuing evolution and inclusion of new capabilities, particularly e-commerce and the netsourcing of internal business functions on an application-by-application basis.

 

The netsourcing of business functions to application service providers (ASPs) will be the next radical change in information technology processing. The University-wide Information Portal will be the means by which netsourced applications are integrated with other services. For example, the portal will be a key component in the integration of U-BUY (Boston College purchasing system) with an Internet-based electronic procurement network. With the Internet time and distance are no longer an issue. The key is going to be standards, particularly directory services, data interchange formats, and communications. It is going to happen in a hurry and we need to be ready to be able to accommodate the new capabilities and the resulting efficiencies. The University Information Portal and standards such as LDAP, XML and asynchronous messaging are required architectural components.

 

Many universities are struggling to move out from under the weight of legacy systems and processes that are not appropriate or responsive. Information portals will enable these enterprises to transform themselves more effectively, without first having to throw all those legacy systems away and develop new systems at great cost. Boston College has proven that we can extend the life and usefulness of legacy applications, such as UIS and Peoplesoft, with the development of Agora services. Now we need to transition those Agora services and the whole Boston College “self-service” approach to a new level – one that is designed with the future in mind. The time lapse since the initial release of Agora services has allowed IT to get a better grasp of how emerging technologies can be incorporated into the Boston College architecture. We are at an important crossroad. It is time to make the leap to a modern technology platform (J2EE), while maintaining the objectives of “self-service” and “full-service.”

 

Java 2 Enterprise Edition

 

Java 2 Enterprise Edition addresses the architectural requirements for a distributed computing environment, which must be secure, reliable, scalable and available. The architecture is based on the 3-tier model where the distributed applications consist of clients on the front-end (usually a browser), data resources on the back-end, and one or more tiers in the middle where all of the application development is performed and the business functions are handled. This middle tier is the environment that is closely controlled by Information Technology.

 

Java 2 Enterprise Edition   J2EE-Compliant Application Model

 

 

The portal application is a server that runs on the middle tier and provides a set of cooperating components and services.  Boston College’s University-wide Information Portal utilizes J2EE and the existing Agora services will be folded into the framework over time. The Boston College team needs to gain a fuller understanding of J2EE specifications and services and the implications of adopting J2EE as the architecture. The Sun web site provides a set of J2EE white papers.  A suggested reading is:

 

“Simplified Guide to the Java 2 Platform Enterprise Edition” -- http://java.sun.com/j2ee/white.html

 

What are the alternatives to the Java 2 Enterprise Edition?

 

There are only two possible alternative approaches -- CORBA or Microsoft – but there is really only one competing technology – Microsoft Distributed Network Application architecture. CORBA and J2EE are complementary rather than competitive; J2EE is built on a CORBA platform and uses standard CORBA protocols. Microsoft, on the other hand, is Windows-centric and relies on Windows services. J2EE and Windows provide similar services but with different components. J2EE is vendor neutral but dependent on the Java language for development. Microsoft is not language dependent but applications must use all Microsoft services. It should be noted, however, that the all Microsoft approach provides guaranteed integration. Is that good or is that bad? Until the advent of J2EE, integration of various vendor products was problematic.

 

From an enterprise perspective an organization needs to choose a single option – J2EE or Microsoft. Long before the submission on this recommendation for the University-wide Information Portal, Boston College had already set out in the J2EE direction.

 

Common Portal Reference

 

The JA-SIG Common Portal Framework provides a J2EE portal server (container) intended to enable the integration of the electronic campus. The underlying model is based on a management structure of publish and subscribe. This allows all members of the campus community to both provide and consume content of interest to the community and to themselves. This includes enterprise applications, channels, publications and links. All publications (content) go through a construct, assuring that the content is properly approved. This means that the institution must employ a set of management practices or rules for publishing content channels.

 

The portal specification provides single sign-on, plug-and-play. It provides ease of use, removing the need to sign-on each time an application is accessed and it allows the given institution to implement single sign-on in a way appropriate to the situation. The portal specification defines interfaces for the content suppliers (publishers). This allows for smooth integration of channels and applications, and makes work such as adding a calendaring component (content) easy. Existing applications can run as-is, though it should be noted that they should honor single sign-on.

 

If we go back and look at Exhibit A and Exhibit B, it will be noted that the example pages are an accumulation of information resources – multiple applications running in the same presentation view. Each of theses boxes or segments can be thought of as a channel, each with its own properties or portal constraints. If we look at the example of the channel below, an example of possible channel characteristics will be observed.

 

NOTE: The following examples provide illustrations of possible channel properties.

 

The channel allows the customer to select favorite bookmarks that he/she wants to appear in the channel.  The channel banner contains 3 buttons:

 

  • Customize (face) content in channel (e.g. what bookmarks?)
  • Display content or just display the channel banner
  • Eliminate (X) the channel so it does not appear at all

 

 

The channel directs the customer to a set of web-based interactive communications services. The channel banner does not contain any buttons. Hence, the customer cannot customize the content and the channel that will always appear on the individual’s portal page.

 

Once the JA-SIG specification is complete Boston College will be in full control of all elements and definitions to customize to BC’s needs. The Common Portal Reference is not an application but a container in the middle tier of J2EE model. The concept of a container may take a while to comprehend – I am still struggling! This is an area where Boston College needs the expertise of outside consulting services. 

 

Interactive Business Solutions

 

Interactive Business Solutions (IBS) is a small consulting and development company with specific expertise in the design and implementation of business solutions utilizing the Java 2 Enterprise Edition (J2EE) technology platform. IBS already has business alliances with many of the institutions involved in the Common Portal Reference initiative. The IBS business plan is very obvious and appreciated by the Java-SIG membership. By contributing a significant amount of programming resources to the CPR framework and to the Java-SIG, IBS will give the members a leg up in getting started and at the same time it will provide IBS with an entry into the institutions to sell and supply additional services.

 

Boston College is seeking an affiliation with a partner who will supplement the skills and needs of the existing Information Technology staff.  IBS has expertise in the area of Java programming and Enterprise Java Beans, skill sets which are necessary but are insufficient within the current Information Technology development staff.  We are looking to IBS to provide architectural guidance and training to the university’s technical staff so that the institution can take full control of our application development needs. IBS’s approach is not to provide end-to-end design and programming support but rather supplement the activities and skills on the IT development staff. 

 

IBS’s technology vision of an Internet-centric computing model and the adoption of the J2EE framework is consistent with Boston College’s architectural strategy and direction.  Member-institutions of the Java Administration Special Interest Group (JA-SIG) share this same vision. IBS provides architecture expertise and distributed-object application development services in the Higher Education market and is a major participant in the JA-SIG. This combination of the right vision, right technology and vertical market (Higher Education) focus are what make IBS an attractive choice as a partner.

 

How should we proceed with Interactive Business Solutions?

 

Assuming that Boston College and the Office of Information Technology accept the principles and vision of the University-wide Information Portal and commit to the design of the portal based on the Java 2 Enterprise Edition platform, Boston College should retain Interactive Business Solutions (IBS) as a design and consulting vendor partner and to provide some jump-start Java programming services. The University-wide Information Portal is a logical first project to engage IBS and to give them a chance to showcase their talents. Not only will we be determining the viability of the University-wide Information Portal approach, but we will also be validating the effectiveness of IBS in the implementation of a limited, low-cost, focused project.

Interactive Business Proposal – Project Plan

 

At the request of Boston College, Interactive Business Solutions was asked to submit a proposal and a project plan. The proposal was not in response to an RFI, so IBS it not responding to a set of BC-supplied questions. Rather, they replied based on their first-hand knowledge of Boston College and their experience at other institutions. In conversation and review of documents IBS has recognized the elegance and innovation of Agora, and the need to structure a migration, not just “rip and replace.”  This proposal can be treated as a document for discussion and negotiation.

 

IBS proposes the following:

 

1.      Investigation and goals definition

 

The existing system is analyzed to determine how and in what order it can be transitioned to the portal.  Essentially, this begins with an overview of Agora. IBS will function primarily as a listener during this phase. One specific focus will be the incorporation of the Agora engine. This engine works well. We will chose between adapting it in its entirety and mapping it to the corresponding HTML/XSL/XML constructs that the portal utilizes.

·        Determine which assets must be preserved

·        Identify system parameters: , performance requirements, resource requirements, servers,…

·        Rank components by importance, criticality

·        Develop timelines, dependencies and constraints

 

2.      Develop the base architecture

 

IBS will provide a document that describes the portal framework as input to this phase.

 

·        Define the development environment

·        Implement an “empty” portal on the selected platform

·        Define the first round of content

·        Define the first round of resources

·        Define common properties

·        Define unsupported interfaces (to legacy etc)

·        Define the component delivery model

 

3.      Define initial components

 

The components that should be part of the initial release will be selected. Their number should be kept small. The initial release is ideally done by a small team and is intended to function as a way to gain the needed development skills as well as a mentoring environment. IBS will provide sample components. This phase is expected to be three weeks long. IBS will provide a UML model that illustrates the portal container and the components to be delivered during the first phase.

 

4.      Define the integration of existing software that works well and can exist within the portal architecture

 

The assets identified as “preserve” (in 1, above) are analyzed to determine how they can be adapted to the portal. The cost of this work is estimated.

 

5.      Obtain agreement on the plan (which will be in phases)

 

At this point the architecture and design is specified. This does not include every component that is expected to be in the system. It does include what is expected to be in the first release.

 

6.      Implement

 

If agreement is reached we expect a first release within six months. Performing the previous steps will refine that estimate. Nonetheless, IBS will be in favor of limiting content such that a six-month timeframe is realistic.

 

7.      Additional development cycles

 

We expect that the first release will provide a useful, functioning campus portal. This does not preclude additional releases to add functionality. IBS sees Boston College as being in a position to be self-sufficient after the first release has burned in.

 

Boston College Recommended Course of Action

 

Enterprise Information Portal -- design, install and maintain a University-wide Information Portal, which represents the university and is owned by the university. Identify a central authority for managing the portal.

 

Executive Approval – make a non-technical presentation to a representative executive team of the university, highlighting the strategic business decisions and opportunities, and receive approval for the enterprise approach.

 

Java 2 Enterprise Edition – implement the Java 2 Enterprise Edition (J2EE) as the underlying architecture for the university’s web environment.

 

Common Portal Reference – base the portal on Common Portal Reference (CPR) framework, which is being defined and developed by the consortium of universities within the Java in Administration Special Interest Group.

 

Java in Administration Special Interest Group  – volunteer to assume a leadership role in the Java in Administration Special Interest Group  and provide support to the JA-SIG in the form of cooperative programming.

 

Early Adopter of Common Portal Reference – install and test the alpha version of the Common Portal Reference, which is scheduled for release in March 2000.

 

Interactive Business Solutions – retain the services of Interactive Business Solutions (IBS) to a) provide architectural consulting, contract programming services and on-site mentoring of Boston College staff in Java 2EE and associated tools and languages, b) provide an analysis and report of the concepts and steps needed to incorporate the existing Boston College web site within the J2EE architecture and the CPR framework; and to assist in the initial implementation of the CPR.

 

Draft Enterprise Information Portal Overview  – Form a team to draft a detailed, conceptual overview of how all structured, unstructured and secure transactional information would be presented and managed within the University Information Portal.

 

Infrastructure Services -- dedicate the resources of IT architects to making required modifications to XMQL and to implementing other required infrastructure services (e.g., directory services, authentication/authorization, corporate data model, profile management, data interchange standards) as a part of the CPR framework.

 

Education and Training – conduct a skills assessment and launch an aggressive and focused education and retraining program to provide all Information Technology developers with the requisite skills to work within the J2EE and CPR environment.

 

Project Team – Create a project team whose leadership has authority over the design of the entire enterprise web environment. Shift the emphasis away from bottoms-up and appearance to an enterprise view.

 

Institutional Web-Site Management – work toward an enterprise-wide view of web-site management and application development. Begin to apply the principles of publish and subscribe and content management.

 

Exhibit A

 

SAMPLE

 

Boston College Enterprise Information Portal

Staff -- Personalized


Exhibit B

 

SAMPLE

Boston College Enterprise Information Portal

Staff -- Personalized

Intranet transaction accessed

        

 

 

 

 

 

 

 

Exhibit C

 

Members of the Java in Administration Special Interest Group (JA-SIG)