Some Important Considerations for Web Delivery

December 29, 2003

Nowadays every organization has a presence on the Web, so Web delivery is not a new challenge. But as organizations make more business functions available over the Web, they need to bring more content—and more types of content—to the Web in support of these business functions. This need is common to all types of firms, from the company seeking to enhance product support for retail customers, to the government agency that needs to distribute forms and information to constituents.

Regardless of the pressures that are moving more of your content to the Web, you are likely facing a greater need to automate Web delivery. Given the complexities of content management, this may feel a little bit like opening Pandora’s Box. But fear not. There are some practical considerations that—when kept in mind—will help ensure that your Web delivery initiative is successfully implemented and easily maintained. The first two considerations—determining project scope and deciding whether to build or buy—are paramount, and deserve the most thought. With these issues resolved, you can consider some other important practical tips.

This is an article Jenn Accettola and I wrote.

Determine Scope, and Don't Lose Sight of It

Like the story of the blind men trying to determine the dimensions of an elephant, many web delivery projects fail because the people involved do not completely agree on the size and shape of the animal in the room with them. The first issue to be resolved should be scope. Are you creating a web delivery system for selected, specific information helpful to your end users? Or, are you going to be integrating applications and content from across functions and divisions of your entire company?

Web Content Management (WCM) tends to focus on very specific and similar parts of a much larger animal (say, the legs). This is not a bad choice if you are certain that you will not be seeking to expand your project in the near future.

Enterprise Content Management (ECM), however, is a much more complex proposition. Such an undertaking requires clearly defining the objectives of your project to assess the fulfillment of both internal and external business needs. ECM is a much more inclusive system that allows you to leverage as much corporate information as you need for website production, knowledge management intranets, enterprise portals, and more. ECM projects include functions often provided by separate applications such as content management, messaging & collaboration, workflow & file management, and archiving (records management).

In choosing between the narrower (WCM) and broader (ECM) approaches, don't let vendors frame your problems. Make sure you have a clear idea of what you want, and hammer out information models and processes ahead of time.

Decide Whether to Build or Buy--or Borrow

BUYING A SYSTEM should be based on clearly defined business objectives and processes. You should carefully develop requirements and match requirements to vendors. The more groundwork you do in the requirements building phase, the higher your chances for success with the project. And do keep an open mind as you match your requirements with potential vendors. Don't eliminate vendors based on vague perceptions, anecdotal evidence or incomplete information. The lesser known, specialized vendor may end up being the best fit for you; so too may the larger, more general-purpose vendor. It depends on your requirements.

BUILDING A SYSTEM is a real alternative and easier than it's ever been. In recent years, the spurt of "do-it-yourself" content management activity has resulted in a wide range of mid-to-small-scale content management systems (CMS) as well as many industry-specific systems. Consider your resources and motives for building your own system carefully. Companies often turn to in-house development as a reaction to (or, fear of) weak deployments, failed initiatives and expensive commercial CMS.

In-house development may be your best option if your web delivery initiative applies to limited properties, you don't plan to manage content across an organization, you have a small number of contributors, and you have a well-defined, simple workflow process. Otherwise, you may soon find it difficult to keep up with constant feature requests generated by external market forces or new technology.

Finally, YOU CAN BORROW a web delivery system by leasing it from an Application Service Provider (ASP), a vendor that deploys, hosts and manages access to a packaged application to multiple customers on a subscription basis. This model has become very popular with small-to-medium size businesses, offering lower entry-cost, shorter deployment schedules, and access to more robust networks with specialized technical support.

With the ASP model, companies can focus on their primary business instead of channeling resources into expanding IT budgets, hiring developers, and developing a product that is outside of the core business model. Using an ASP for pilot programs gives companies a better opportunity to test out software packages before making long-term financial commitments.

Selecting an ASP requires the additional steps of performing due diligence on the hosting company, establishing or reviewing service-level agreements, and managing the contract and relationship. The security of your data and the stability of the ASP are also important considerations. Content Management ASPs such as Atomz and CrownPeak Technology are gaining increasing popularity.


Some Additional Considerations

CONSIDER THE ACRONYMS - they're not just clever sets of letters but indications of protocols and technologies that may make your projects more or less successful. Many de facto and official standards (notably XML and related technologies such as XSLT) are quickly becoming "tools of the trade" for developers. In the right hands, XML-based systems can help you realize significant return on investment.

SECURITY AND DIGITAL RIGHTS MANAGEMENT may be of critical importance, but will add extra layers of complexity to your web delivery model and require extra consideration. In your requirements development phase, be sure to lay out what kinds of security your content will require. Will something like single sign-on be sufficient, or is your content valuable enough to require the persistent protection that comes with Digital Rights Management (DRM)?

LEVERAGING CONTENT is often an important part of maximizing ROI. Some organizations now talk about "return on content" when discussing, for example, how an organization benefits from making complete use of internal and external content. Think of the R&D organization that needs ready access to up-to-date research and analysis. On a practical level, this comes down to how your content delivery system deals with syndication--both of your own content, and content that you are getting from third parties.

KISS--WHEN YOU CAN: Keeping it simple is one of the trends of the day, in healthy reaction to the often overly complicated flops that doomed some projects in the early years of CMS development. So, for example, if you have PDF files ready for distribution, and page fidelity is a requirement for your content, don't avoid the obvious solution of simply distributing the PDF.

IF YOUR CONTENT IS TIED TO REVENUE, REVIEW REVENUE MODELS FOR YOUR BUSINESS. Your revenue models may dictate the types of technology, content, services, and nature of your Web delivery processes. This is perhaps obvious for the business that sells content, but is an important consideration for all businesses--especially if you sell over the Web, develop prospects over the Web, educate your customers over the Web, or support your customers over the Web. (Chances are--whomever you, are this means you.)

Conclusions

Web delivery is no longer a brave new world, but it remains a growing one--in both importance and complexity. Yet despite the technical challenges of Web delivery, organizations that keep certain basic considerations in mind will enjoy greater initial success--and greater success in the long-term.

Posted by Bill Trippe at December 29, 2003 1:17 PM

support this blog