Tear down the walls: universities are building bridges between their software applications. Will the new links stand the test of time?

Imagine living in a home where every family member speaks a different language--and nobody can track down a translator. Such is the plight facing many universities and colleges that have spent the past decades buying or building applications and databases that often can't speak to one other. Alas, seemingly simple tasks--such as synchronizing data between applications--often involve complicated software fixes.

"There's a lack of a single solution for integrating the plethora of applications our university depends upon to service our constituents," laments Marty Smith, chief information officer at Embry-Riddle Aeronautical University (FL). "Many vendors have part of the answer, but none ties it together yet in a package we can use."

And according to Dinish Bahal, director of Education Solutions at Sun Microsystems Inc. (www.sun.com), "A lot of universities are trying to retrofit applications that weren't designed to work with one another. It's quite a challenge."

That's an understatement. North American businesses, universities, and government organizations will spend $8.4 billion trying to address their application-integration problems by 2006--a 29.6 percent annually compounded growth rate over 2002, according to International Data Corp. (www.idc.com), the market research firm.

What's a university to do? The typical solution involves a mix of Web servers, application servers, and portal software--which provide students and staff members with secure, customized doorways into multiple university databases and network services. Several technology standards--some proven, some emerging--also promise to knock down the wails between isolated applications. Five popular options include LDAP (Lightweight Directory Access Protocol), XML (eXtensible Markup Language), UDDI (Universal Description, Discovery and Integration), SOAP (Simple Object Access Protocol), and WSDL (Web Services Definition Language). Generally speaking, these standards allow all sorts of applications to shake hands and exchange information in a reliable, secure manner. (See "Standards for Success?" right, for a more complete definition of each standard.)

"Without standards like LDAP and XNL, you can't create sustainable, extensible, maintainable architectures," says John Halamka, associate dean of Harvard Medical School (MA) and chief information officer of CareGroup, a healthcare organization that serves several Boston, MA-based hospitals.

LDAP HONOR ROLL

The application-integration movement has plenty of true believers. The University of Michigan was one of LDAP's pioneers in the early 1990s. Duke University (NC), the University of Maryland, Embry-Riddle, and the University of Utah are among LDAP's more recent proponents.

"LDAP and SOAP--for authentication and security, respectively--are emerging as important standards in our back-end integration projects," says Embry-Riddle's Smith. "Single sign-on to all applications and services is likely to be one of the more important areas addressed as we move forward." And for good reason. Without single sign-on, students and staff members are forced to juggle multiple user names and passwords as they struggle to leap from one application silo to another. Managing all of those passwords can be an administration nightmare.

"When 25 percent of your customer base is a freshman class that wants to register for the first time, single sign-on can go a long way toward easing application access and student services," says Sun's Bahal.

Just ask the University of Utah, which uses LDAP as a central directory for its business applications and student administration services, according to Joseph Taylor, director and VP of Administrative Services at the university. The LDAP system provides 27,000 students and 1,800 staff members with a single, secure sign-on to multiple campus applications. The university also has rolled out a Web-based portal that relies heavily on LDAP and connects approved users to Oracle and PeopleSoft applications, Web applications, and e-mail services running on the university's TCP/IP network.

PORTAL PROPHECY

The seeds for University of Utah's portal. were planted in February 2000, when the institution's Information Technology Executive Committee (ITEC) outlined an 11-page strategic plan for integrated applications and improved network services.

The plan identified a "digital divide" within the university, meaning that some departments had inadequate networks and poorly integrated applications. Further complicating matters, a "lack of common standards [made network] security extremely challenging," according to the strategic plan's documentation, which was viewed by University Business.

Eager to address the shortcomings, the ITEC committee recommended the institution deploy a central directory that provides universal network authentication. Ideally, each network user would need only a single name and password to securely access multiple applications. According to financial calculations revealed in the plan, the LDAP server and central directory services had an estimated start-up cost of $450,000. "Money is always a factor, but the biggest issue was the definition of our business processes," says Taylor. "You have to define where the data is, how it will be used and who will use it."

As a starting point, the university organized its applications into two logical groups: (1) An Administration Computing Systems (ACS) group, which includes registration, student records, and payroll applications, and (2) a Network and Communications Services (NetCom) group, which includes Web e-mail, online courses, and network authentication.

Between May 2002 and October 2002, the university's IT team worked to synchronize both application groups with the new central directory. On October 7, 2002, the college's PeopleSoft users went live on the integrated portal and directory system. Early users complained of poor e-mail performance and frequent crashes, but the problems were quickly corrected with a November 2002 upgrade to the LDAP server.

Meanwhile, other universities are striving to open their portals to designated business and education partners. At Embry-Riddle, the university has extended its three-year-old portal, dubbed ERAU-Online, to United States Air Force Academy (CO) cadets, who receive flight training from the university. "We are developing or using portals for nearly every constituent category associated with higher education," says Embry-Riddle's Smith.

Instead of integrating the university's legacy applications, Embry-Riddle is increasingly deploying software from Oracle (www.oracle.com), including the vendor's ERP solution for HR and financials. The university also intends to evaluate and implement the full Oracle Student Suite in the near future. "Our goal is a 24/7, anytime, anywhere environment with seamless integration and services to our worldwide constituency," says Smith.

CAUSE FOR CONCERN?

Despite such lofty goals, many application-integration projects have yet to fulfill their promise. Former Oracle President Ray Lane has repeatedly stated that few businesses and universities can afford to "rip-and-replace" their existing applications for one-size-fits-all packages from Oracle, PeopleSoft (www.peoplesoft.com), SAP (www.sap.com), Siebel Systems Inc. (www.siebel.com), etc.

Taking a different tack, Lane invested in Asera Inc. (recently acquired by SEEC Inc.; www.seec.com), a Silicon Valley start-up that develops application-integration software.

Temple University (PA) used SEEC's software to develop a Web-based portal that allows students to register or change classes, make payments, and view grades, financial aid application status, account balances, billing history, and so forth. Although the Web portion of the application runs on Microsoft's Internet Information Server, it also gathers student information from Temple's IBM mainframe. The solution has allowed Temple to extend the life of its mainframe applications without any major modifications, according to Mike Grady, executive assistant to the vice president for Computer and Information Services at the university.

MORE CONCERNS

Anecdotal success stories notwithstanding, custom software tools can miss the mark if a university's existing applications Lack LDAP and XML support. "LDAP is only as powerful as the number of applications available for it," notes Chellappa Kumar, director of New Technology Initiatives at the New York College of Osteopathic Medicine (NYCOM) in Old Westbury, NY. The college is waiting for one of its key software providers to support LDAP before rotting out a portal later this year or sometime in 2004.

Even if a university's software fully supports LDAP, it can be difficult to fund an application-integration project. Just ask the University of Michigan, which last year closed its student portal, known as my.umich.edu, because of financial concerns. Annual maintenance costs for the portal were about $1 million, according to published estimates.

The University of California, Berkeley, has its own questions about portal integration projects. A group of university employees, known as the e-Berkeley Implementation Task Force, is researching portal options for the university. During a February 2003 meeting of the task force, committee members discussed the perceived Limitations of portals operated by six major universities. So far, none of the six portals offers true single sign-on capabilities--although this remains a goal for all of the universities, according to minutes from the meeting.

On the upside, each of the six portals supports student links to e-mail, calendaring and library catalog services. The e-Berkeley team estimates that each portal six months to two years to develop, with most rollouts completed within a year. The portal projects were staffed by two to four full-time employees.

XML CONNECTS

LDAP isn't the only avenue to application integration. Another key standard, XML, continues to gain momentum as an interface between Web services, databases, and back-end applications.

More than 85 percent of public and private organizations are using XML to build integrated Web services and applications, according to Gartner (www.gartner.com), the technology research firm. Michele Cantara, a principal analyst for Gartner, describes Web services as end-to-end applications that interoperate through XML and its related interfaces (SOAP, UDDI, and WDSL). In many respects, XML has emerged as the lingua franca of application integration since the standard was ratified in 1998 by the World Wide Web Consortium (W3C). To date, hundreds of leading software companies have vowed to support the standard.

Harvard Medical School is among XML's proponents. "All our back-end applications are either XML, SOAP, or standard transaction sets," says Halamka, at the school.

Such is the case with Harvard's HMS Wireless Quad application. The Wi-Fi system allows approved Harvard students--equipped with wireless Laptops and handhelds--to access multiple back-end applications and network services. In fact, more and more universities and businesses are expected to jump on the XML bandwagon. Worldwide sales of XML-based databases, application servers, and content servers are doubling annually and are expected to top $3.5 billion by 2006, according to IDC.

Still, it's important to keep such upbeat forecasts in proper perspective. PeopleSoft Chief Technology Officer Rick Bergquist has compared the emergence of XML, LDAP, SOAP, and UDDI to the early days of the U.S. railroad--when standard gauges were just beginning to allow railway cars to move about the country. The lesson here? If software companies don't fully adhere to the emerging standards, application-integration projects may suffer more derailments. Consider yourself warned.

RELATED ARTICLE: Standards for success?

Universities are embracing several technology standards in their march toward application integration. Here's a look at five such standards that promise to connect the dots between students, faculty, external business partners, and back-end applications.

LDAP--Lightweight Directory Access Protocol, developed in the early 1990s, is a technology standard that allows users to locate organizations, individuals, applications, and network resources. Strengths: Supported by virtually all major software developers; provides single sign-on to approved network resources. Weaknesses: Some smaller software companies that serve the education market have yet to deliver LDAP support because of cost concerns and staffing limitations,

SOAP--Simple Object Access Protocol allows for the exchange of information in a decentralized, distributed network environment. SOAP is an XML-based protocol. Strengths: Particularly strong solution within Microsoft environments. Weaknesses: Immature technology that requires customers to build certain software components from scratch; potential scalability issues.

UDDI--Universal Description, Discovery, and Integration is a technology specification that allows an organization to automatically describe its network services and conduct business with other UDDI-compliant organizations. Strengths: Now overseen by the OASIS standards body, which promises continued advancements. Weaknesses: Early observers say the standard doesn't fulfill its hype. Considerable confusion over UDDI's purpose and direction.

WSDL--As its name suggests, the Web Service Definition Language provides communication links between Web services. Strengths: Broad vendor support across major software platforms. Weaknesses: An immature specification that needs more polish before being accepted as a true software standard.

XML--Extensible Markup Language is a system for defining, validating, and sharing document formats across TCP/IP networks. Strengths: Simplifies data integration, provides easy analysis of underlying data, enjoys broad software developer support. Weaknesses: Potential customers may be confused about the relationship of XML to SOAP and other emerging standards.

Sources: Gartner Inc., IDC, and various university officials

RELATED ARTICLE: Tricks of the trade.

From early adopters of online portals and emerging application-integration standards: guidance to heed.

Pardon me, Mr. President ... Make sure you have buy-in from the university's top administration, up to and including the president.

Start early. Form a steering committee that has the authority to prioritize application-integration needs. Determine your priority list by interviewing deans, key business users, and selected students who crave better and more simplified network services.

Who owns this? Define exactly who will drive each standard and integration project within the university. Outline clear action items and deadlines for each person involved in the project.

Get a briefing. Ask your database suppliers for a roadmap describing their respective XML integration plans. Try to time your upgrades to coincide with major XML enhancements from your suppliers.

Keep an Open Mind. Try to avoid closed, vendor-specific standards that lock you into one company's architecture. Be wary of vendor "enhancements" that lack cress-platform support for Windows, Unix, Linux, and Mac OS.

Exercise Caution. Integrating your applications provides hackers, irate employees, and disgruntled students with a single doorway to attack multiple university systems. Explore how intrusion detection, spam filtering, virus protection, firewalls, and virtual private networks can safeguard your integrated systems.

Find the $$. In addition to quantifying the start-up costs, identify the ongoing annual costs associated with an application-integration project. Consider how many full-time employees will need to support the system. Communicate these ongoing costs to university management prior to breaking ground on the project.

Browse frequently. Test portals and integrated applications across multiple browsers (Internet Explorer, Netscape, Opera, etc.) on both PCs and Macintoshes. Consider standardizing on a single browser to fully fine-tune the application's performance. Shocking as it seems, Internet Explorer now controls more than 95 percent of the browser market.

Imitate the best. Form a small intelligence-gathering committee, which will study at least five competing universities to identify best--and worst--practices for various application-integration projects.

Define your metrics for success. Identify how you will measure the project's outcome. Options include customer feedback surveys, delivering certain cost reductions, and/or increasing online transactions by a specified figure.

Sources: University of Utah, Harvard Medical School, and Embry-Riddle Aeronautical University.

RELATED ARTICLE: Batch vs. real-time data integration.

IT staffs must choose between real-time or batch updates when integrating data among campus systems and applications. With real-time integration, changes made in one system are instantly updated in other locations. Batch integration synchronizes data at a set time, perhaps once a day, or once a week.

Deciding which process to use depends on the applications, the type of API support they offer, and the shared data. It also depends on the problems caused by having data out of sync, on whether pulling together disparate systems used during a single business process can increase efficiency, and how important it is to improve the quality of the user experience.

In order to decide which type of integration is best for a given environment, an institution must analyze the business processes and ask the following questions:

* What manual processes could be reduced or eliminated if applications could automatically complete transactions with one another?

* Would business process friction be reduced if the data were updated in real time?

* Would the return on investment from operational efficiencies, resource savings, increased satisfaction, etc., justify the IT costs of enabling real-time integration?

Both batch and real-time integration are valid choices, depending on the environment and business need. However, constituent expectations for better and more integrated services are growing. Satisfying these expectations requires going beyond real-time data synchronization and enabling better cress-system transactional type integration.

       Batch                           Real Time

Pros   * Quick and relatively easy     * Event driven, allowing for
         to write scripts for doing      unified applications that
         exports and imports.            support a business
       * Does not usually require        process that fits how
         additional hardware.            people really want to work.
       * Almost all applications       * Systems can interact in
         provide utilities for           a transactional manner,
         exporting and importing.        providing true synergy.

Cons   * Not event driven--does        * Usually requires additional
         not facilitate notification     hardware, software, and
         or change in another            expertise.
         application at the time of    * Some applications do
         a change in first               not provide APIs or
         application.                    interfaces needed for
       * Business processes that         real-time integration.
         span applications are         * Cost.
         clumsy and do not
         behave as one.

Source: SCT (www.sct.com)

Joseph Panettieri is the editorial director at the New York Institute of Technology, and a freelance writer. He is a contributor to Fortune Small Business, InformationWeek, end other leading publications.