Sunday, February 25, 2007

Digging deeper into CMS requirements (#4: Costs)

This is the fourth post about digging deeper into content management requirements. See also

This is perhaps the most important factor for WCMS buyers.

The total cost of an information system is easily displaced as buyers have a tendency to ignore the total lifecycle of the software. A CIO in a small company could explain that she spends zero on web content management since she does it all by herself, but the number of hours she spends updating the web content each week might amount to a significant expense relative to the size of the company.

A WCMS has costs upon acquisition. The software is bought, and additional modules or plug-ins will likely add to the price. It must be tested, deployed and tweaked by developers to fit the company's environment. A web design must be applied to the templates. Users must be instructed on how to use the system. Older content must be imported.

There are maintenance costs to be considered. Content managers receive wages. The WCMS is customized, extended and maintained by developers, adding cost to the investment.

The final step of the lifecycle is migrating away from the WCMS to a newer one, or perhaps the web content is to be absorbed into an enterprise content management system. The content has to exported from the old system and imported into the new system. Finally, the value of the previous investments are nulled as the intellectual capital put into the use of the legacy WCMS is no more.

Depending on the amount web content and the complexity of the software, all these tasks involve considerable costs.

Like in any form of company profiling, there is no immediate return on the investment (ROI). This can lead to an negative process where the WCM division of an organization gets low priority and receives low-funding, the division performs worse web content management, and the web-site returns less revenue. However, many of the WCM systems benefits, like in any IT-investment in general, are intangible and hard to find and measure [Weill & Broadbent, 1998]. Intangible benefits of running an advanced WCMS can include a smaller need for WCM-staff. One less full-time employee could quickly make such a large WCMS investment worthwhile.

Measuring all investment down to an economical figure can prove to be an inaccurate measure of a WCM system's success. There may also be other infrastructural business values which should be investigated. A quality web-site is a crucial part of the identity of a large IT-company. All in all, finding the ROI is a complex task which is not the center focus of this research, but it has been explored in many others [Hallikainen, 2002], [Ward, 2003]. I recommend exploring some of these before planning a CMS acquisition.


Hallikainen, P., Kivijärvi, H., Nurmimäki, K. 2002, "Evaluating Strategic IT Investments: An Assessment of Investment Alternatives for a Web Content Management System", conference proceedings from HICSS-35, IEEE International

Ward, T. 2003, "Find ROI: Measuring Intranet Investments" Retrieved 30. April, 2006

Weill, P., Broadbent, M. 1998, "Creating Business Value through Information Technology & Rethinking Technology Investments: The Information Technology Portfolio", Leveraging the new infrastructure, HBS, ch. 1 & 2, p. 1-4

Sunday, February 18, 2007

Worthless Practices (IBM's list)

I just saw via InfoQ that IBM maintains a list of Java EE best practices.

Now I've never really been good with bile, but there is just so many things wrong with this list on so many levels. Just listen to the title: "IBM WebSphere Developer Technical Journal: The top Java EE best practices". A bit of paradoxial, isn't it?

Let's take a quick look through the list and comment on each point:

1. Always use MVC.
Yeah, right. Always use MVC. Remember to design a rigid 3-tier architecture upfront no matter what sort of application you are going to build. Use Struts, right? Right.

2. Don't reinvent the wheel.
Well, duh. Struts, right? Right.
3. Apply automated unit tests and test harnesses at every layer.
I'd actually support this one if I could append "if possible".

4. Develop to the specifications, not the application server.
Well that certainly was a good tooting from the wrong horn, coming from the deranged nit-wits that gave us WSAS and WSAD.

5. Plan for using Java EE security from Day One.
Yes, and build it into your whole application using WebSphere Application Server's Java EE security(tm). There is no better way to tie yourself to your application server than using the embedded access control and security mechanisms.

6. Build what you know.
Well, duh. Struts, right? Right.

7. Always use session facades whenever you use EJB components.
How bout never using EJB components?

8. Use stateless session beans instead of stateful session beans.
Sounds a lot like Struts action thinking to me. Drink you own poison any way you like, EJB suckers.

9. Use container-managed transactions.
Uh. Yeah, using WSAS Transcation Management(tm)!

10. Prefer JSPs as your first choice of presentation technology.
Indeed! Never mind that JSPs is the most designer and developer unfriendly templating language around. I love having to compile my templates into servlets, then loading them into the application server!

11. When using HttpSessions, store only as much state as you need for the current business transaction and no more.
No kidding. I'll try to remember that session actually uses memory somewhere.

12. Take advantage of application server features that do not require your code to be modified.
Wait, isn't this the same as point 4? Except that it binds you to the functionality of an application server and thereby invalidates the point.

13. Play nice within existing environments.
I guess this means that we should use WSAS. Period.

14. Embrace the qualities of service provided by the application server environment.
Really, how much more of this list is going to be about WSAS ball-licking?

15. Embrace Java EE, don't fake it.
And buy our fully Java EE compatible application server today! Seriously, tell this to the thousands of developers who have uneccesarily suffered under EJB's.

16. Plan for version updates.
Yes, there will always come a patch for your WSAS installation. Usually the one that fixes the bug in WSAS which is paining your development. And the techies will tell you they can't install the patch before 6 months.

17. At all points of interest in your code, log your program state using a standard loggingframework.
Yeah.. WSAS logging is just lovely to look at and modify.

18. Always clean up after yourself.
Now this is the point where I really start getting annoyed. How bout you guys cleaning up after yourself? Your company is largely responsible for soddling the development of Java EE into the state it is today!

19. Follow rigorous procedures for development and testing.
Yes, develop and test as rigorously as the application server and the web framework forces you to. Make sure you have a 100 page testing plan that lines up the procedures.



Summary: Buy IBM, use WSAS and use Struts.

Bile being done, the text actually has some good principles and points, but the concrete solutions so provided are a bit too much 2002 for my taste.

Digging deeper into CMS requirements (#3: End-user Requirements)

This is the third post about digging deeper into content management requirements. See also
Today I'm gonna run through two categories of requirements. They both have to do with how the CMS is portrayed towards the end-user, through translation and delivery.

Globalization

International companies need multilingual web-sites [Huang, 2001] with internationalization and localization features.

Internationalization

This is the concept of having country and language-specific content, essentially having the main content of the web-site translated to one or more languages [Iverson, 2002].

Translation of a WCMS can be divided into two parts. The most important one is how the content itself can be translated by the content managers. The other aspect is the language of the WCMS itself regarding internal interfaces for administration and management.

Localization

This refers to visual effects based on the visitor's locale, like country specific temperature, time, date and currency formats, one example being how certain countries use the 12-hour AM/PM style to define time, while others use 24-hour notation.


I would like to add the following:

Do not internationalize your site if you don't really really need to. If you can get away with it, stick to one language, either English or the local language. Doing i18n and l12n is easy to describe in principle, but oh-so-heavy and difficult to implement and maintain, both technically and content-wise.


Content Delivery

Syndication

To increase the availability of content, larger web-sites feature syndication, or off-site publishing. This can be approached by subscribing to receive new pages through e-mail (newsletters), or as the increasingly popular news-feed (RSS).

As an example, many news-sites have offered the option of subscribing via RSS-feeds. By subscribing to these feeds in RSS-readers or news-aggregators, the process of collecting news from these sites is turned from a pull-protocol, actively browsing for content, into a push-protocol where content is pushed to the reader.

This is related to the idea of the Semantic Web [Berners-Lee, 2001], a set of W3C standards created for enabling data sharing across the Web. One version of the RSS format (1.0) is actually a name-space within the Semantic Web's RDF specification.

Accessibility

Many developers associate accessibility with the extent on which disabled people can use computers. This could be because they lack motoric skills, or because their hearing or eyesight is impaired. For example, certain keyboard shortcuts would not be accessible for a one-handed person, and color-codes can be hard to read for the weak-sighted.

A more generic understanding of accessibility is the limitations readers have accessing content. These limitations can be lack of mouse or keyboard, small sized screen or lack of colors. Limited devices like mobile phones, PDAs and older computers lack the luxury of heavy graphical user interfaces.

Search

The importance of the this requirement is proportional with the size and maneuverability of the web-site. Although a very basic search-engine is sufficient for most sites, it is also possible to implement smarter searches that accord for miss-spelling, try different word ending(s), and use context specific dictionaries. A good search-engine also indexes your online binary files (PDF and Microsoft Office documents for instance).

The intelligence of a search engine increases by the work which is put into configuring it because there are a lot of context related parameters which must be sorted out. The engine must accord with language(s), location of where the searchable information is stored, possibilities for tracking content by URLs with spidering techniques and security. There are many issues which much be situationally decided, like whether hidden files should be search-accessible. Upon installation of the search engine, it will require hours of manual configuration to fit the context. It should be able to monitor the search patterns of the visitor to better tune the searches to yield usable results.

Communication

A powerful mean to further enable existing content is to give the consumer the opportunity to provide feedback to the web-site. This functionality can come in several shapes, including the ability to add comments to web-pages, participate in online surveys and discuss content in forums or chatting consoles.

If the goal is to make it easier for potential customers to contact the business, one could measure the number of visitors compared to the number of visitors who actually fill in some online contact form.

A way to generate income directly this way is to provide the visitor with the option to buy services through a web-shop. Having this channel makes it quite easy to measure how many sales are generated from the business' web front-end.

Feedback from visitors can collected to help improve the web-site, but some sort of incentive is normally required to tempt any visitors into actually completing such a form. If the web-site is of low value to the visitor, chances are slim that the visitor will aid improving the web-site.


References:

Berners-Lee, T., Hendler, J., Lassila, O. 2001, "The Semantic Web" Retrieved 29. April, 2006

Huang, S., Tilley, S. 2001, "Issues of Content and Structure for a Multilingual Web Site", conference proceedings from SIGDOC'01, ACM

Iverson, S. P. 2002, "Content Management Beyond English", conference proceedings from IPCC 2002, IEEE International

Tuesday, February 13, 2007

Finally we're starting to get some real Web 2.0 stuff!

Can't belive I didn't notice Yahoo! Pipes earlier. That site/concept could pretty quickly turn into one of the biggest things in our Web 2.0 craze..

Here, I made one that joins my InfoQ feed and the TSS feed:

My first pipe.

But do I think it's really useful for anything? Nah, don't think so. I'll settle for my bloglines for the time being.

Sunday, February 11, 2007

This tuesday I'm going to do a workshop on wiki for some people in management/business development department. We've been smart enough to choose Confluence for our internal wiki, and its use has been growing steadily ever since last summer, bout the same time as I joined the company.

Over this time I've managed to earn the rep of a wiki-evangelist within the company. This is probably I've taken the time to learn the in's and out's of Confluence content formatting, making pretty layouts with columns and tables, galleries, RSS-feeds, and intranet blogging. Some people think I spend too much time fiddling around with it (see for instance the screenshot of my personal space page), but I think it's fun and interesting to try out. I'm not doing it to evangelize the whole company into going crazy on wiki-usage, I just use the wiki to cover my own butt mostly.



If I didn't write things down in the wiki, I'd very quickly fall into the state of corporate goldfish memory, where the only accessible knowledge would be the one found in my brain, and most of that would be about the projects I'm working on right now. Not half-a-year ago or several years ago.

Instead of trying to remember old projects, I write down stuff every day. It could be anything from 5 to 50 lines, and mostly they're about what I have done, and what I'm going to do. These are for my own reference, not for project documentation. The archive is searchable, and I find my own (and others') notes being more and more useful.

But enough personal motivation. The thing I wanted to write about today is how I'm going to present the use of our beloved wiki for the management.

So, let's start with the cons we've got. These are reasons why management would not like to use the wiki:

  • They've already got an existing intranet. Adding another adds to the complexity of the infrastructure.
  • There is no special interconnection with MS Office/Exchange software.
  • It's another tool to learn (and wiki markup ~> programming language)
  • Suspicion towards wiki access control.
So, to sum up, the Wiki is hard to use, hard to control and does not work well with the existing infrastructure.

So let's start off with these points and break down the wiki-hostility :)

Complexity
The wiki is designed to be a simple tool. It builds on the very basic standards that define the success of the Web today. A wiki does not add much complexity because it is not complicated. It's just a simple web-application that can use your existing user directory service (LDAP), and beyond that it doesn't affect your existing systems (except the competition it adds to your DMS-systems/intranets).

No MS Office collaboration
We'll admit to the fact that there is no special compatibility between the content of your wiki and the content of your Word documents. We (as in us developers) would argue that this is a problem of MS Office not following industry standards, but management hears "bla bla bla our stuff does not work with MS Office", a very bad thing indeed since MS Office is the platform on which they rely to do most of their job.

Now you can upload Office documents as attachments to the wiki, but that's about it. Other than that we can't do much except recommend that management puts their document in explicit, transparent wiki content so they can enjoy the functionality of search, versioning and XML-export.

The learning curve
Once you get into it, wiki-markup is really easy. And if it's still too hard, you can still use the WYSIWYG editor. The issue is also countered by Confluence's excellent documentation.

Access control uncertainties
This is perhaps the most prominent show-stopper for wiki embrace in an organization. It is not only about security and confidentiality. Members of management have a certain.. sovereignity they must perform onto the content they create.

One manager's content is an important artifact. Often it should only be viewed by a select few, and naturally not edited by anyone else than the manager.

The wiki brings with it a message of free access to all content. Everyone can edit everything. This sounds risky to management.

Luckily, Confluence comes with great possibilities for administering access control. Will have to make a point of it on the presentation.



Now I better get started on the presentation. Will include these points, as well as some short history of wiki, the role of wiki (as a Knowledge Management tool?), and finally assignments! (wee, I get to boss management around)

Thursday, February 08, 2007

Mixing Iron and Clay: Implementing CMS and Portal as one product

For the last few weeks I've had the joy of working with a portal solution that also provides excellent CMS features. More often than not, portal meets CMS by being a Portal with some junky editor functionality inside, but there are also some CMS'es that feature bits'n'pieces of functionality like portlets, widgets and plugins.

The portal I've been working seems to strike in the middle. It has the richest CMS interface I've come across in a portal product (content structure, versioning, editing all neatly packed into a comfy filthy fat applet client that actually works), and every bit of content is actually an instance of a portlet by its own right (how they've managed to keep the performance so high is quite impressive, and a mystery to me).

This means that not only can I choose each piece of content from a large variety of portlet packages, but I can also transcend content between different states, which is a very handy portlet feature.

However, there is a flip-side to the coin:

Portlets are tiny web-applications. They are powerful, and great once you have them configured. But this means you have to configure them , states and all. You have to compile them, build them, deploy them into the portal, create instances of them and run them before you get to see results.

Additionally, the only content-level storage supported by the portlet spec is portlet preferences, a simple little rag of string data that is used to reference the content of the portlet instance. The spec is a portal-spec, not a CMS spec.

This annoys me as a developer to some degree because I can't utilize the functionality of the underlying content! I can't iterate over the current collection of content. I can't store data in the portlets other than in the portlet preferences, and I can't retreive data other than using the predefined content-portlets that came with the product.

So when I extend the functionality, customizing the CMS if you will, I have to create entire webapps; verticals: database, control layer, web layer and all, in addition to configuring the portlets, states, and then having the deployment hassle of it all.

And at that point I wonder what is the point of having a portal after all....

The answer lies somewhere in the component architecture of the portal. A portal can use many different verticals throughout the application. A webapplication normally uses only one. Oh allright, the webapp can use several as well, but the configuration is all stuck in one place. A portal can combine many different packages of portlets, each having their own web-app configuration, say for instance using their own MVC framework.

This is great, because by the time people get tired of the portlets using Oracle DB with Struts on top, you can replace it with a new DerbyDB/WebWork vertical, exchanging one component that hopefully does not disturb the others. This great is because.. (dramatic pause for today's word of wisdom)...

A framework or technology has a lifespan of max five years. If you throw out and exchange the old components piece by piece, you have a product that will live forever.

I wish there was some third option, getting nice and clean modular webapps without the heavy portal framework. I know there is a solution out there, we just need somebody to sit down and figure it out, then share the knowledge with the rest of us.

Sunday, February 04, 2007

So you want to get rid of Use Cases?

I'm going to do a lightning talk on this topic at tomorrow's XP-meetup, so if any of you devoted readers are attending you might get away with reading this blog-post. Spend the five minutes going downstairs for a pint, and bring me one while you're at it, please.

I was once in a meeting participated by a team of developers, requirement managers, test managers and project managers. The topic of discussion were how requirement changes should be handled.

The original requirements were described mostly in the form of use-case documents. The problem, and the reason for the meeting, was that the implementation was failing to follow the stuff specified in the use-cases.

The round went around the table with each and every member pledging to read the use-cases more carefully, and the requirement manager promised to clearly highlight changes and references in the documents.

When the turn came around to me I said something along the lines of:

I have read the use-cases already. I'm not going to spend time sitting scrolling through them looking for changes. There must be a better way to instruct changes into the implementation than fishing them out of some bloody Word document.

This didn't go well down with the project manager, and I was (not literally) told to stick to it, keep reading the use-cases like all the others.

Now I know use-cases are supposed to be light, user-story like, but in the hands of document-riders and management they become bloated with design descisions, business rules and interface nit-picking.

It's hard labour to track changes in these documents. I suggested putting them into wiki-format, but that proved to be too much hassle for the requirement manager. Pasting the word documents into the wiki ended up looking really ugly (considering the size of the use-case descriptions).

You can't modularize use case steps, you can't re-use them, and you can't refactor them. All in all, they're a pretty crappy form of requirement specification, especially for us developers that hate Word documents.

Then along came Selenium and showed us that Web-tests that are fun:

They're executable! We could use them as developers to speed up our own tests. We can even stuff them into our automated build/continous integration system.

It's dead easy! It's so easy even the document riders fell in love with them. We even got the testers to report bugs with them (bug traces).

The test managers could use them for acceptance testing and performance testing. So the normally huge acceptance testing phase at the end of the project was reduced to a matter of days.

Sure Selenium tests break easily, but they're easily repaired also. And most of all, when they break you (as either a developer or manager) are forced to recognize that a change has taken place, and you can decide whether this is a faulty test or a faulty implementation.

The flip side is that they're too easy to make. If the developers' test-suite gets bloated with all the tests managers want in, the suite runs too slow for the patience of a test-driven developer.

They are not refactorable, other than in the search-replace meaning of the word. If a change takes place across the entire web application you might have some work ahead of you to get the suite green again.

It can be hard to visualise the steps that will run in a web-test (but isn't it just as hard in a use-case?), so if you insist on creating the Selenium test before you do the implementation you will need some imagination and knowledge of Selenian. One way to work aorund this is to do prototyping of the webapp with static html pages, and record Selenium tests based on these.