Portal Strategy: One Vendor's Story and What It Means to You
Written By: Predrag Jakovljevic
Published On: October 05 2005
Epicor's announcement to provide rich portal content and create a standardized platform using Microsoft .NET, combined with its overall strategy to burgeoning portal applications, and the dwindling number of viable portal providers, indicates two things: portals are becoming indisputably important, but they are not a viable market on their own—at they will not be able to sustain a vast number of players.
Part two of the Epicor to Give All Its Applications More Than a Pretty Facelift series.
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. As a result, 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, other 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, another new term has entered the portal vernacular: business intelligence (BI) portal, which is a corporate portal that enables users to query and produce reports on enterprise-wide databases.
Having passed from its original role as a standalone presentation layer to become a part of a larger technology stack, the portal has long been considered part of a larger offering, be it in collaboration, vertical-specific applications, or application infrastructure and middleware.
It is thus 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 to "reinvent the wheel." This approach should help their bids 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 research and development (R&D) resources. In addition, some acquisitive enterprise resource planning (ERP) vendors with multiple product lines should be able to make new features with the same "look-and-feel" available across their assorted enterprise resource planning (ERP) product lines, concurrently and faster.
For a more definitive discussion of portals see Portals Necessary But Not Self-Sufficient.
The market is now seeing a growth of co-opetition where competitors are forging partnerships for particular types of technology. Vendors selling Java 2 Enterprise Edition (J2EE) or Microsoft .NET based applications are now accommodating IBM WebSphere and Micrsoft SharePoint Portal frameworks, respectively. For instance, SSA Global and Epicor have recently debuted new versions of their portals and are working with IBM and Microsoft respectively. These partnerships should allow portal adopters to benefit—especially if customers are reluctant to adopt an unproven, proprietary, application-centric portal.
A further interesting note on the Epicor-Microsoft co-opetition, is that Microsoft's own Axapta, a part of the Microsoft Business Solutions (MBS) product line which competes against Epicor, has not yet leveraged the SharePoint Portal solution. In light of this, Epicor will likely "up the ante" and offer a more complete implementation. Also, depending on the implementation of current development work, Epicor may also have notable opportunity to provide composite applications that link the transactional portlets of Epicor Web, multiple Epicor BI, Web parts (for online analytic processing cube analysis), and various Epicor and third-party applications, to reporting, SharePoint discussions, and other pertinent components, in a best-of-breed fashion. Yet Microsoft will not be completely shut out it loses project bids to Epicor, because the co-opetition agreement means that the Microsoft Information Worker and Server & Platform divisions will benefit with each Epicor deployment. Additionally, Epicor Portal Content will still need to be populated with key performance indicators (KPI), and strategic operations for specific industries, process flows, organizational structures, etc.
However, great opportunities customarily do not come without challenges. To further differentiate in the fastidious target market (see Cookie-cutter Solutions Won't Cut It with the Mid-Market), Epicor will have to deliver rich, industry-specific content packs, and "cherry pick" the best capabilities and knowledge from its multiple products. Yet, despite the Microsoft-centric nature of its product lines, and their many common denominators, these products are not on exactly the same architectures. For example, Epicor for Service Enterprises is built with the Epicor Internet Component Environment (ICE), a new toolset (using Microsoft Visual Studio.NET and the .NET Framework). However, within the same product breed, the Clientele CRM.NET suite, which was the first customer relationship management (CRM) application built completely on Microsoft's .NET Platform, also uses Microsoft Visual Studio .NET as its standard customization tool. It can support changes using any of the .NET-compatible programming languages, but uses a rich/smart client. On the other hand, Epicor for Service Enterprises has a Web-based UI. iScala and Epicor Manufacturing products also have their own technical idiosyncrasies.
Certainly, Epicor Portal will help with coalescing these products' architectures into a single product in the future (at least on the UI side, given their architectural differences are nuanced). Nonetheless, its greater problem might lie with the fact that earlier Clientele versions and other Epicor industry-specific products are quite behind when it comes to their migration from "fatter" client/server architectures, such as Microsoft Visual basic for Applications-based (VBA) architectures, to Web Service-based architectures like that of Epicor for Service Enterprises. Given its proclaimed pledge to let customers migrate at their own pace, Epicor will then have to continue to support internally-developed older portal products currently available for its various enterprise application suites, which will draw additional R&D resources. Like its current portal brethren products, Epicor Portal 8.2 will require customers to pay an additional software license above the core application. Those customers who have purchased previous portal applications from Epicor will receive an upgrade path from their current product. Pricing for new customers is per processor for the Epicor Portal Server, but it remains to be seen how the vendor will set the pricing for Epicor Portal Content and persuade customers to opt for solutions in terms of return on investment (ROI).
While popular for ad-hoc workgroups within a firewall, SharePoint is not without drawbacks, especially in terms of limited enterprise content management (ECM) capabilities, scalability and performance issues for implementations across many firewalls and geographies. Time will only tell how and when Microsoft's recent acquisition of Groove Networks and its move to integrate SharePoint Portal Server and Content Management Server will address these concerns. One should note though, that Microsoft recently released information about the investments it is making in ECM in its next wave of Office System products, codenamed O12. This ECM offering will be based on the Windows SharePoint Services platform. Meanwhile, Microsoft will look to the many partners who provide compliance and ECM offerings build on SharePoint Products and Technologies. Still, until then, users might not only lack access to the required set of both structured and unstructured data, but there might be some regulatory compliance repercussions too (see Do You Need a Content Management System?).
Generally speaking, there seems to be an essential change in the way user enterprises approach portal initiatives nowadays. They approach it as a means of enabling consequential IT transformation to support increased global competitiveness, while having a mandated, easy-to-discern business value at the same time. The affinity for a unified portal framework, and the initiatives that will depend on this foundation, has become a strategic long-term need that requires only a few established, viable vendors to support.
Epicor's restored and persevering financial stability and its ability to enhance its products (both in-house and via alliances and acquisitions) and its determination on executing the product and technology strategies outlined in this document deserves praise. Another positive sign is the vendor's more manageable and narrower focus, as demonstrated by its most recent product launches and wins. Current users of all Epicor ERP product lines, but particularly those of iScala, are advised to follow Epicor's new product introductions and check out how quickly, inexpensively, and painlessly Epicor Portal could help them with their competitive initiatives. But for both current and prospective customers, a cohesive portal solution should not be about infrastructure, but rather about addressing the tasks end users deem the most crucial.
Detailed information about Epicor Scala, Epicor Vantage and Epicor Enterprise products is contained in the ERP Evaluation Center http://www.erpevaluation.com/