December 29, 2003

Some Important Considerations for Web Delivery

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 1:17 PM

December 17, 2003

Presentations from XML 2003

I am starting to pull together the presentations from XML 2003. I will update this entry and this list as I get them all in one place.

The presentations include:


This is complete as of Friday, February 16, 2004.

Posted by Bill Trippe at 4:53 PM

December 15, 2003

Financial Communications Forum

Gosh, I have been busy lately. So much so that I have done a terrible job of keeping the blog up to date. Here is one thing I have done recently. I gave a talk today on Evaluating Your Content Management Needs at the Financial Communications Forum in Boston.

Posted by Bill Trippe at 10:05 PM

December 11, 2003

Gilbane Report Tutorial on XML in Content Management

We made it through the blizzard on Saturday to get to Philadelphia on time for the XML 2003 tutorial. It turned out to be a productive day—all the speakers and most of then attendees made it. Watch this space. I will be posting copies of the presentations shortly.

Posted by Bill Trippe at 10:13 PM

December 3, 2003

A Brief Microsoft Rant

I am generally neutral about Microsoft. That is, I don't see them either as an evil empire or as the greatest technology company ever. If anything, I like their office products, worry about the dominance of Windows, and keep wishing for better security from them. Overall, Microsoft has received more of my software dollars than any other company (go figure!), and I have been satisfied with what I get for the money. But I was stunned by my recent experience with the end of the Beta period for Microsoft Office. On Monday morning, which was December 1st and apparently D-day for the Beta to end, Microsoft left me high and dry.

I paid for and installed the Beta sometime in June as I recall. I remember noting that it would expire in or around November, but I assumed there would be some orderly transition to the full product. I also assumed, apparently incorrectly, that I would be informed of the need to upgrade or uninstall the Beta in advance of its expiration. Perhaps an email would arrive, or some sort of pop-up would appear informing me of my options.

Sadly, no. Instead, Monday morning comes, I turn on Outlook, and I get a message informing me that I need to upgrade the Beta, or remove it. The pop-up, as I recall, offered no other information. There was a link in the Help area to the Beta web site. Silly me, I figured it would have information about how to purchase the upgrade.

Sadly, no again. Not a word (pun intended).

I then went to the main site for Microsoft Office. Still nothing.

I then went to the main site for Microsoft support. Still nothing.

Now, I will admit that I was not my normally patient self. I had work to get done, and my "productivity" software was dead in its tracks. So I put away my credit card, and went with option B: uninstalling the software.

It was simple enough to uninstall, and it was clear that my (earlier) Office 2000 was still on the computer—at least according to the Control Panel function.

But, guess what? With the Beta uninstalled, Office 2000 no longer worked. Dead in the water. Up the creek without a paddle. (Had enough water analogies yet?)

So I had to reinstall Office 2000. For me, this means reinstalling Office 97 (full version) and then installing the Office 2000 upgrade (both bought and paid for, still in their original jewel case, etc. and never installed anywhere else but on my own machine).

I then faced a small series of problems that you get when you do this kind of thing. First I couldn't properly synchronize my Treo with Outlook. I had to settle for a synchronization that puked some redundant records into both my Outlook and my Treo. Then I had to get email to actually work in Outlook again—a controlling .dat file had been corrupted in the process. This last problem I solved myself through the knowledge base on the Microsoft support site. By the end of the day, I was back to normal, sort of, but a full day behind on my work.

Isn't software wonderful?

I was comparing this to other bad days I have had. For instance, the subzero February morning when, recovering from the flu, I discover one of my tires is flat. I try to change it myself, but between the cold and my weakened condition, I almost snap in half trying to loosen the first lug nut. I retire to my warm kitchen, call AAA, and wait 40 minutes until they show up with a big honking jack and a power tool to remove and replace the tire. Next thing I know, I am motoring off to work.

Cars were very hard to maintain when they were first introduced. I understand that early owners of automobiles had to be just as skilled at fixing their machines as they were at driving them. The prognosis at the time was that automobiles would never thrive with such a burden. Eventually, cars became nearly automatic. As have refrigerators, TVs, microwave ovens, and virtually every other device and appliance. Isn't it time we expected that of basic computers and productivity tools?

At they very least, couldn't Microsoft have made it easier for me to give them my credit card number?

(For the record, I am now two days into using my older version of Office, and I only miss a couple of things—a nice auto-fill feature in the Outlook "To" window, and the way that Word allows you better control over formatting when you cut and paste between different documents and applications. I am going to live without them for now. Microsoft is free to call, though, if they have an easy way for me to upgrade.)

Bill Trippe
btrippe@nmpub.com

Posted by Bill Trippe at 4:44 PM

support this blog