|
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:
Treat
the Boston College image on the web in the same manner as
university print publications
Allow no control of the main bc.edu domain pages by a vendor
product
Allow no advertising or e-commerce links on bc.edu domain
pages unless they are BC links
Permit advertising on elective links (Those chosen by the
individual)
Require institutional approval and compliance with guidelines
for all contracts with vendors
· · 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:
provide
access to all information and services through a single
graphical interface;
support a single log-on to obtain authentication and authorization
to all information resources and applications;
provide a framework where all elements of the university
(academic, administrative and community) and all business
applications can be integrated;
provide a convenient set of communications services which
are web-based
provide a one-stop place where all members of the university
community can perform all business transactions
provide the ability to present information and access to
services on an individual basis in personalized manner.
provide each member of the community with the ability to
customize the appearance, layout and information on an individual
basis;
grant to the university full control and self-management
of appearance and content;
be vendor independent (not locked into proprietary hardware
and/or software);
be free of commercialization (no advertising or the sale
of products unless university sponsored);
be flexible and be able to absorb new technology advances
and new applications;
be available to all constituents 24 hours a day, 7 days
a week.
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. 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. 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. 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. 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. 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. 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. 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)
Boston
College
Brown
Columbia
Cornell
Dartmouth
East Carolina
Florida State
Georgetown
MIT
Princeton
Univ. of British Columbia
Univ. of California
Univ. of Chicago
Univ. of Delaware
Univ. of Hawaii
Univ. of Minnesota
Univ. of Pennsylvania
Univ. of Texas
Univ. of Washington
Univ. of Wisconsin
Wright State
Yale
|
