Skip to Content

How much do you integrate into SAP NetWeaver and where do you draw the line ?

Web based content management or stand alone client based content management, how do you choose ? Simple question, hard answer. I’ve dealt with this issue since the inception of the myTransAlta portal. To be more specific, does TransAlta stick with its Lotus Notes based content management solution within a Notes Client, or do we build a full-blown, and ever evolving, web-based alternative so users never leave their web browser window ?

This question was somewhat simple to answer back in 2001, when we began work with our myTransAlta portal. Our CIO at the time was pushing hard to ‘webify’ everything – not exactly practical thinking, especially when we’ve hundreds of Lotus Notes databases and custom stand-alone applications that would require literally thousands of man hours to convert to a web-based equivalent.

One of the big initiatives we undertook for our first phase of portal development was to build an Internal News service in the Portal that would replace that which operated under Lotus Notes. We thought we could us KM to provide the solution, but due to its very unstable and unreliable nature as of the GA release of EP5, we had to fall back to a web-ready Lotus Notes alternative. This worked, but had many drawbacks. For one, the Domino web server requires serious infrastructure if it is to be used as a web content management platform, and our infrastructure has not proven to be efficient enough to handle Domino’s requirements. Then, there are the list of features we have to consider both users who simply read content, and those who manage content require. When you’ve spent years working in the Lotus Notes client, will you be comfortable moving to a very limited web based environment ? What I’ve found is the answer to that question is a resounding ‘No’. And, there are many reasons why this answer is valid.

If you are used to composing a document for hours on end, and being able to simply save it when you’re done without any worry of your session with the server timing out, you won’t like content management on the web. With our Domino web content management solution, users often complain of losing their ‘work’ because their session timed out. If you are used to simply inserting graphics and charts and applying this font style and color here and there, you would not appreciate working in a very limited editor environment. The best alternative to the Rich Text Editor that Domino provides is one that leverages the DHTML rich text editing capabilities of Internet Explorer. This is what we’ve used for so long. The problem with it, is you just can’t copy and paste graphics, file attachments and so forth as easy as you could within a content management solution such as the Lotus Notes tool.

So, now in our third phase of development, as the needs of our end users grow, we are faced with a big dilemma. Do we fall back to a Lotus Notes client based solution and allow the users to build their documents the way they want ? Then, when we display this content on the web via our portal, simply wrap around the styles we’ve applied ? This seems to be a very attractive option. Even KM can’t even deliver a fraction of what a stand alone environment, such as Lotus Notes that is so advanced at this stage, can provide. So, does the portal just become a web page full of links to external programs, or does it become the killer application that one day allows you to do everything you need to do to get your job done ? Every scenario will have a different answer to this question. But, I’m more inclined to believe that if the solution is simple enough that it could easily be developed, maintained and supported via the web, then it is worthy of being implemented as part of a portal deliverable. If the solution is far more advanced, and much evolution is anticipated, then some serious foresite must take place to ensure switching technologies back and forth does not become a common practice, because user confidence will diminish and that is not acceptable.


1 Comment
You must be Logged on to comment or reply to a post.
  • Interesting piece – thanks. In my opinion, the approach that says “we want to make things available through a webbrowser” shouldn’t be the tail that wags the development dog, necessarily. If something can be appropriately developed using web-orientated tools (e.g. BSPs in the WAS), then by all means go ahead. But don’t forgo what seems like critical features in non-web-based mechanisms just because they’re not “new”. Wrap them by all means. That’s what the web techologies are good at – wrapping services of all kind.