Portals: Necessary But Not Self-sufficient

Portals: Necessary But Not Self-Sufficient

Previously, portals were merely Web "super-sites" offering a broad array of resources and services, such as (free) e-mail, forums/discussion groups, search engines, on-line shopping malls, news, white and yellow pages directories, and links to other sites. Now they are pervasive in the business world and used at the departmental and corporate levels. The major, general-purpose Web portals are still Yahoo!, Excite, MSN, and America On-Line (AOL) and are the Web equivalent of the original, pre-Web on-line services such as CompuServe and AOL, which initially was only an Internet provider. Now most of these traditional search engines have transformed themselves into Web portals to attract and keep a larger audience.

However, one should differentiate between a public portal, which is a high-traffic Web site with a wide range of content, services, and vendor links; and an enterprise or corporate portal, which is a Web-based presentation and interaction interface for users of enterprise applications and resources. In other words, a corporate portal is an internal Web site (intranet) that provides proprietary, enterprise-wide information to company employees, selected trading partners, and selected public and vertical-market Web sites. It typically includes a search engine for internal documents and the ability to customize the portal page for different user groups and individuals. It is the internal equivalent of the general-purpose portal on a company's corporate Web site.

Aptly named, portals open a window of communication between enterprise applications and communities of customers, partners, content providers, advertisers, and, in most cases, the general public. Furthermore, enterprise information portals (EIP) provide windows into enterprise information, applications, and processes Leading enterprise applications vendors have made moves to adopt Internet portal strategies. The basic goal is to create a virtual workplace and marketplace for users, where enterprise applications, disparate back-end systems, and external content and services (catalogs, directories, travel services, benefits administration, etc.) can be seamlessly and transparently accessed by users via the Web. From this emerges the term business intelligence (BI) portal, which is a corporate portal that enables users to query and produce reports on enterprise-wide databases.

By personalizing, profiling, and presenting information, business applications, and inter-organizational interfaces in the context of roles and work processes, an enterprise portal provides a thin-client, Web-based link to work-based resources within the enterprise. On the Web, personalization means returning a page that has been customized for the user, taking into consideration that person's habits and preferences. Customization may be done by the user, appear on the Web site, or both and may be aimed at the general public or at company employees.

Portals are a natural result of increased global competition, the need for better and faster customer support, and the Internet phenomenon. If nothing else, they also afford technology-challenged suppliers a low cost, low risk entry into the Internet marketplace ("the global village"). Portals also allow software vendors to reach a greater number of power and casual users alike, which increases system usage and creates the opportunity for higher license revenues.

However, while there has been a cornucopia of portal applications (including Web-based interfaces into any number of enterprise-level applications) within any given enterprise, there has been a tendency for tying all the necessary capabilities within a single framework. Namely, this is seen in customer- and consumer-facing portals, where usability focuses on developers and features like personalization come notably into play. This differs from employee- or supplier-facing portals, where usability focuses on end users, with their need for collaboration, search, and content management features. In other words, the higher one goes in the hierarchy of portal architecture, the fewer vendors will offer a single portal framework accommodating most of these capabilities. As satisfied as they may have been with the particular standalone portal applications, over time users begin to seek fewer vendors and gravitate toward those with the firmest strategic position and long-term viability.

Evolution of the Portal Market

At its peak, the portal market had around 30 portal start-ups and full-fledged independent software vendors (ISV), and attracted larger information technology (IT) players like Sybase, SAP, IBM, Computer Associates, Oracle, Vignette, and Hummingbird (some of which once even took the daring step of reinventing themselves as portal companies only to make u-turns soon thereafter). However, because customers were looking for established vendors, the portal markets has reached the end of its life as a standalone market, which was symbolically marked by BEA Systems' recent acquisition of the last standing portal vendor Plumtree, which pioneered portal software that connects workgroups, computer systems, and multi-channel processes back in 1996. Given the earlier disappearance of portal pure-player like Epicentric and Corechange, many now recognize that portal technology should be included as part of infrastructure— specifically application servers that bundle together different software programs in order to work with each other.

Having moved beyond its original role as a standalone presentation layer to become a part of a larger technology stack, the portal is now considered part of a larger offering, be it in collaboration, vertical-specific applications, or application infrastructure and middleware. Even the recent, much talked about composite applications have promoted the portal as kind of lightweight integration layer for people, data, and processes.

Yet, niche portal vendors have had difficulties with the best example being Plumtreee. Despite fine-tuning its product strategy towards syndicated portal services, the enterprise web, activity management, and composite applications development, Plumtree has struggled to sustain momentum and growth in the market. It found itself squeezed by the strategic infrastructure aspect of portal frameworks, which the likes of Microsoft and IBM tend to dominate. It also had to contend with enterprise application portal heavy-weights, such as SAP and Oracle, being ill-able to make the same types of investments in development. However, even SAP, with its vast install base and research and development (R&D) resources, still hasd to resort to acquiring TopTier, a specialist vendor, in order to deliver SAP Enterprise Portal (see SAP Acquires TopTier to Further Broaden Its Horizons).

These developments have been in tune with the continual blurring of the traditional lines and layers which have demarked middleware applications and their underlying infrastructure. This has created the so-called "appli-structure" (see SOA-based Applications and Infrastructure--The Next Frontier?). The middleware stack is being squeezed, and application integration and configuration management is becoming rooted in both the application and infrastructure layers. Also, in most existing and prospective user enterprises, application vendors own business relationships, while infrastructure providers have IT relationships. But these large vendors cover both bases and will naturally have the most influence during the selection and implementation of applications and middleware/infrastructure.

Partner Rather Than Compete for the Portal Commodity?

Thus it is only logical to see many mid-market enterprise applications vendors ally with the providers of the highest-level portal framework, rather than to waste precious and scarce resources on "reinventing the wheel". This approach should help their bid to increase the use of Web-based portals among their enterprise customers while, at the same time, make more efficient and pointed use of their own R&D resources. In addition, some acquisitive ERP vendors with multiple product lines should be able to make new features and, at the same, improve the "look-and-feel" of their assorted ERP product lines faster and concurrently.

Given the "commoditization of technology" (which is not a disparaging term for the likes of IBM and especially Microsoft, which has been thriving on high-volume software sales), vendors that sell Java 2 Enterprise Edition (J2EE) or Microsoft .NET-based applications to a J2EE or Microsoft shop will pragmatically begin accommodating IBM WebSphere or Microsoft SharePoint Portal frameworks, respectively.

Enterprise applications vendors SSA Global and Epicor Software have recently debuted new versions of their portals for their primarily mid-market customers. Respectively, these vendors are working with IBM and Microsoft so that portal adopters can benefit from WebSphere's and SharePoint's models and access other enterprise data. At the same time, customers can continue to approach diverse applications, such as SSA Global and Epicor through individual SSA Global or Epicor portals. This should appeal to existing IBM and Microsoft shops that are thinking of adopting these vendors' applications for their particular industry fit, it may also be a bonus for existing customers that are loath to unnecessarily "graft" an unproven proprietary n application-centric portal onto a well-known portal framework they may already have in place.

For example, soon after Epicor introduced its own portal applications in 1999, nearly half of Epicor ERP accounts jumped at the opportunity and licensed the portals. Yet, more recently, that number has dropped significantly to less than 15 percent of user companies licensing portals for their initial deployments. The vendor hopes to reverse this negative trend by piggybacking on Microsoft's uncontested popularity on the desktop-side (see The Technology Choices), and use its high, mid-market popularity on the server-side.

In general, portal server is an application that is used to develop, deliver, and maintain a Web portal, which typically includes a variety of tools and functions, including user authentication, identity management, personalization, a search facility, and content aggregation capabilities. To that end, the Epicor Portal Server component of Epicor Portal will leverage Microsoft SharePortal's commoditized features to provide secure role-based access to Epicor and other business applications. It will also provide self-guided discovery and data visualization, targeted content through personalization, Web-query access for application integration, and schemas for the Epicor Enterprise, Manufacturing, and iScala products.

Although Epicor increasingly competes with Microsoft Business Solutions' (MBS) mid-market ERP products, such as Great Plains, Navision, and Axapta (recently renamed into Microsoft Dynamics GP, Dynamics NAV, and Dynamics AX, respectively), there is no severe risk of Epicor closely tying its portal strategy with Microsoft. This is really another case of "co-opetition," where competitors come together for a particular product or concept, yet still remain competitive in the market. Such practices have become common in the industry, and are not particular to Microsoft, especially given Oracle's foray in the database, middleware, and applications markets, and IBM's presence everywhere except for applications. It would be detrimental (if not foolish) for any underlying technology provider (however powerful it might be) to sabotage a partner-competitor applications vendor.

Microsoft should be a winner in this race, even if its applications do not win a particular selection gig against Epicor; Microsoft Information Worker and Server & Platform divisions will still benefit indirectly from every instance of Epicor's deployment. After all, MBS is only a minor (however important) part of Microsoft, with still fledgling revenues compared to its sister divisions. Certainly, Microsoft would not want to alienate its ISV partners and push them into the embrace of IBM, BEA, or Oracle.

Ironically, like in the case of embracing .NET, Epicor will likely offer a more complete implementation of SharePoint technologies across its business application products than Microsoft offers, given that Microsoft Axapta product does not yet leverage SharePoint portal technologies. The win-win situation extends to Epicor too, as it will still have its hands full to populate the Epicor Portal Content component with pre-packaged workflows, key performance indicators (KPI), strategic operations for specific industries, process flows, and organizational structures. Multiple, diverse audience targets have to be provided with collaborative workspaces and document management solutions. There is also a significant opportunity (but also impending development work) to provide composite applications that link Epicor Web parts (transactional portlets), multiple Epicor BI, Web parts (for online analytic processing [OLAP] cube analysis), and various Epicor and third-party applications, with reporting, SharePoint discussions, and other pertinent components, in a best-of-breed fashion.

To put it into context, portlet is a mechanism used to more readily integrate content, applications, and processes into portals via providing a low-level, point-to-point integration approach by accessing application programming interfaces (API), structured query language (SQL) statements, Web services, and more. Web services and Java provide mechanisms for enabling portlets written for one vendor's portal to run unchanged in another vendor's portal. Emerging standards that promise to enable this portlet interoperability include Java Specification Request (JSR) 168 and Web Services for Remote Portlets (WSRP). JSR 168 is a specification from the Java Community Process (JCP) organization designed to enable interoperability between portals and portlets. It defines a set of APIs for portal computing, addressing areas such as aggregation, personalization, presentation, and security. On the other hand, WSRP is a specification designed to establish a common means for portals to obtain and display information reaped from Web services, and it was approved as a standard of the Organization for the Advancement of Structured Information Standards (OASIS) in 2003. By embracing these facilities, Epicor (and SSA Global from the IBM/J2EE camp) might actually remain as mainstream portal technology where its products should become more attractive for environments with diverse systems.

Much like Epicor, SSA Global's mission for its portal solutions is to increase productivity and effectiveness by providing every employee, customer, supplier, and partner with easy access to all the information and tools they need to do their jobs. The strategy is to

• Improve productivity by providing each person with immediate access to aggregated content from their most relevant SSA Global application pages
  
  
• Improve alignment by highlighting the most important business information, including KPIs, for each user role
  
  
• Improve responsiveness by enabling end users to drill into information and take action
  
  
• Improve agility by enabling customers and end users to easily personalize their portals
  
  
• Increase institutional knowledge by facilitating collaboration

The vendor's portal solutions are service-oriented composite applications that should enable customers to combine their existing IT assets in new ways to better support their changing business processes. SSA Global's most recent portal solution is a financial management portal that provides a near optimal user experience for seventeen different financial user roles ranging from chief financial officer (CFO) to billing clerk. The vendor's product roadmap calls for a steady stream of portal solutions being released every quarter. Next up are a human capital management (HCM) portal and an industry-oriented portal for the consumer packaged goods (CPG) industry. SSA Global also has a strategic partnership with IBM and leverages the renowned IBM WebSphere Portal server for its solutions.