feature

The "Ultra-Intra-Content-Knowledge-Net Management Portal Solution:"
Online's New Buzzword

Stephen E. Arnold

ONLINE, May 2001
Copyright © 2001 Information Today, Inc.

To understand any of the latest buzzwords describing intranet portals, ask the person who built an in-house system on-time and on-budget. To be confused about what an "Ultra-Intra-Content-Knowledge-Net Management Portal" solution might be, ask an online solutions provider. The American baseball coach Earl Weaver is believed to have said, "It's what you learn after you know it all that counts." For many venturing in buzzword-charged waters, the sharks will have dined before the swimmer realizes the mistake.

What is being learned at organizations like General Electric is that when one system does not work, get rid of it and replace it with another. SageMaker (Fairfield, Connecticut) has the opportunity to make GE the poster child for content-centric, personalized portals for an organization's intranets–many words, a big job, and a challenging proposition to boot. The flip side is that GE's initial forays into the "Ultra-Portal" pond sank like rocks. GE is a well-informed operation, yet it was not able to get the "Ultra-Portal" solution right the first time or two.

PORTALS ARE PARTIAL SOLUTIONS

The new online outfits are, at this time, partial solutions to a much larger problem: the many disparate and proprietary systems within an organization. The Holy Grail is one seamless system, a bit like the fancy body suits world-class swimmers donned at the Sydney Olympics. To get a multiethnic group of sunbathers speaking one language, such as XML, is a big job. The reality of many organizations is that getting different systems to share a common language is akin to getting dissident groups in the Balkans or the Middle East to forget their animosities and get together for a friendly barbeque after a swim.

Online's 2,001 buzzwords purport to solve some organization-wide issues with a flick of the high-tech flipper. If memory serves, Baan & Company, SAP, J.D. Edwards, and a host of other Enterprise Information Software vendors sell complete solutions, but these firms have focused on manufacturing or traditional businesses. Furthermore, these "solutions" remain expensive, controversial enough to lead to lawsuits in Europe and the United States, and openly require a realignment of the entire organization.

A SHARK BY ANY OTHER NAME

As readers of this journal know, hyperbole is a keystroke away in an online world. Web-ifying solutions shifts hyperbole into hyperdrive. Who knows where the truth is when vendors promise "knowledge management" or "portalization?" And yet, the premises seem very reasonable, very doable. Simply use a common standard to integrate business processes, content, and electronic mail. The reality seems to be that intranets, content management, portals, knowledge management, extranets, and enterprise information systems (EIP) overlap.

A close look at Vignette, Open Market, Broadvision, or Mediasurface, among others, reveals that these systems, when fully implemented, are quite close to EIPs. Why? In order to deliver on their promises, the Tower of Babel must be pulled down and replaced with an infrastructure that plays well with others. The Japanese allegedly have a truism that runs along the lines of, "The nail that sticks up gets pounded down." What gets pounded down are disparate systems that do not exchange information seamlessly. Work processes that do not mesh are "normalized." Islands of data exist only if they are in the lingua franca of the "solution."

The result of fuzzy, almost poetical terminology, is systems that sound very reasonable and practical. The only sticking point is that fully functioning "solutions" are costly, and they have to circle back to the premise of the ERP and EIP vendors. People have to shift to the new platform, or the solution becomes yet another isolated system.

This is a paradox of sorts. By packaging a "solution" as an intranet or portal, the client buys into a "solution" of a trendier sort. However, to get the full benefits, a larger solution is eventually required. The client is right back looking at the financial and human costs for shifting business operations from something that seems to work, though not perfectly, to a platform that may not work at all. New terms, new spins, and new packaging are wrapped around using Internet technology for business processes. Little wonder that Vignette has had to move from churning out Web pages to the deep waters of enterprise systems where Baan's One World and SAP R/3 swim.

THREE PREPARATORY TASKS

First, the person with the responsibility to implement an "Ultra-Intra-Content-Knowledge-Net Management Portal" system has to figure out exactly what the organization requires. Then, agreement must be reached that the solution will solve the problem. Then the hard part–matching the problem to what vendors can do within the time and budget available.

Second, the client team must assist the vendor or, more likely, vendors to implement the system.

Third, the system must be deployed, staff trained or induced to use the system, and bugs chased and killed.

Note that the outcome of this process does not guarantee that the project will be completed on time and budget. Nor does the process take the ultimate step toward the Software Hall of Fame, and get users to embrace the new solution. But forewarned is forearmed. The three preliminary steps provide some preparation for handling solution pitfalls.

CHALLENGES OF PORTAL DELIVERY

• Budgeting and justifying the continuing costs of scaling the infrastructure as demand grows over time and technology continues to change
• The time required to fix bugs, obtain licenses for additional content, and add new features and functions
• Integration of this solution with other organizational software; that is, making certain that the portal or content management solution continues to play well with others
• The workflow issues that surface when a user says, "This is not how I do my job," or when a customer says, "We want you to do it this way to keep our business."

Assume that management is convinced, funds approved, and internal team members are clutching their mouses in anticipation. What are the principal ways to deliver a portal, a content management solution, or a knowledge net?

FOUR WAYS TO DELIVER PORTALS

First, a portal can be constructed using the do-it-yourself method. The internal team says, "We can do it; no problem." License a toolset from Microsoft or SilverStream, take a class or two, and code up a portal. The upside of this approach is control. The information technology department owns the project. The finance officer can depend on existing reporting procedures to track costs. The management team knows to whom to look for explanations. The downside is that the project may never be completed or when finished, does not work. The costs, depending on the accounting method, can be reduced to almost zero. Resources are easily allocated to other budget line items.

The second approach is to outsource the project. Companies like Plumtree Software stand ready to deploy a portal for a department or an entire enterprise. The upside of this approach is that the responsibility for getting the job done is shifted to another organization and reinforced with a contract. The downside of the approach is that what is built may not match the work processes and flows of the organization. The costs for outsourcing can be as low as a few hundred dollars a month plus a set up fee, or as much as $50,000 per month. The variability in monthly costs are determined by support, maintenance, and training. The upfront set up fees can range from $30,000 to as much as $200,000, depending on the particular requirements of the portal customer.

Third, an ASP solution with help from an internal management team offers another option. The term ASP has been popular for a year or two. The fuzziness of the phrase Applications Service Provider has not been helped by these variants: FSP or Full Service Provider, EBIP or Electronic Business Infrastructure Provider, aggregator or company that assembles services from multiple ASPs and offers a single point of contact, MSP or Management Service Provider, NSP or Network Service Provider, or HSP or Hosting Service Provider. Regardless of description, the idea is that the portal function resides on a computer located at a remote facility or the portal computer is located at the client's network center, but managed and maintained by the service provider's staff.

The essence of the approach is that a third party does the coding, fixing, and maintaining. The internal client team oversees the project and learns the ins and outs of the portal implementation. The upside of this approach is that responsibility is shared, but the contract with the service provider specifies minimum levels of performance in an SLA or Service Level Agreement. For many companies, the internal oversight, the basic contract for the portal implementation, and the SLA provide a lower level of risk and thus a higher level of comfort for the senior managers who must sign the checks. The cost for ASP portals can range from $2,000 or $3,000 per month to $10,000 per month and higher, depending on the specifics of the project. The upfront licensing, set up, and consulting fees usually begin in the $30,000 range and can easily rise to six figures.

REINVENTING TO FIT THE PORTAL

The internal team for this approach includes representatives from all functional units. The delivery cycle is rarely measured in units smaller than a three-month block of time. The advantage of this choice is that a Fortune 1000 corporation needs this type of approach to overcome the inertia that exists in a large, distributed organization. The downside is that if the implementation is botched, the portal initiative can fail. The cost for this type of project is typically measured in the high six figures to millions of dollars. Planning, training, licensing, coding, and deploying services are required to move the portal from the drawing board to the doorway of the client. An example is the difficulties Petsmart (Phoenix, Arizona) experienced with its SAP portalization effort.

BEFORE YOU SIGN FOR AN ULTRA-INTRA-PORTAL SOLUTION

First, cutting through the hyperbole with some real thought and an objective assessment of what is needed, what tools and approaches are right for a particular situation, and what has worked at one's organization in the past. If the company is profitable, and systems in general okay, weigh the consequences of flashy new technology that is not quite right. Waiting and testing are good options for many organizations.

What business processes must be changed in order to implement the portal? In this initial planning stage, the catchphrase is similar to the adage, "A habit is easy to get into but hard to get out of." Change habit to portal, and the folk wisdom still carries a megabyte of truth.

Next, before diving into a deal with one vendor, use two, possibly three, pilots, not one. Regardless of approach, different hands-on experiences are essential for two reasons. Real-life tests are absolutely essential to ferret out the easily overlooked hidden costs, such as coding a patch to let accounting know that a click on an article costs money in the portal interface. Multiple tests are important to educate those testing the portal about what options are available to them. The reactions of technical and non-technical staff, plus outsiders and customers, are essential. If the report card is poor, fail the portal and try harder next time. Be willing to make the right decision, not the fast and easy decision.

Finally, solicit proposals from a sufficient number of qualified firms, and concentrate on the top two or three responses. Then do a solid pre-contract cost and payoff workup. Itemize licensing, training, support, maintenance, and similar fees. Include estimates for system down time (lost revenue if there is an electronic commerce function in the portal) and for the cost associated with staff training. Essential and quite painful is the calculation of costs associated with upgrad- ing the system to handle additional users, functions, and services. If the portal's response time is too sluggish, it will not be used. The costs for speed can be punishing, and they are routinely pushed aside with the comment, "Performance is certainly not a problem." Bug fixes and middleware costs must be included since software is rarely flawless, and systems from different vendors on different platforms are known to be at odds the moment they come into contact with one another.

FLEXIBLE SWIMMERS

This portal "thing" is a big job. The key is to use flexible, open architectures. Portalization may be an organization's first step to a true distributed architecture. The future of enterprise computing is "standard" plumbing that easily accepts plug-in modules. The digital framework must allow new services to be added with the same ease with which a 13-year-old changes surfboards. All interfaces must expose content in the context of work tasks. Automation via agents and "bots" seems to be the surest way to slash some costs. The framework must allow these digital servants to thrive without special recoding. In short, the portal will work when the business task comes first and buzzword second.

Concentrate on swim strokes, not the color of the new outfit or the sleek design of the swim fins. Performance, not buzzwords, is what counts in the online world.

Stephen E. Arnold (sa@arnoldit.com) provides professional services in business and information technology consulting to clients throughout the world. The information in this article is taken from The New Trajectory of the Internet: Umbrellas, Traction, and Lift in 2001-2002 (Infonortics, Ltd., Tetbury, England, March 2001: http://www.infonortics.com).

Comments? Email letters to the Editor at marydee@infotoday.com.