As per the ChangeWave report on software spending, there are major cuts predicted across the broad spectrum for the next 90 days, and the worst hits are ECM and ERP categories with almost 1/4^th decline in spending. Spending cuts prediction is not surprising, if you look at current economy and how every company is trying to deal with shortfalls, you know that software would be impacted.

What surprised me was that ERP is predicted to be one of the worst hit. From customer’s perspective, I have always seen ERP listed as more critical than ECM (or many other softwares for that matter), so why it is at the bottom? I think this has more to do with project lifecycle than with criticality of software. You ask any customer who has gone through or is going through a ERP implementation and they can tell you horror stories on missed deadlines or extremely long project timelines. For many customers, to plan for such long projects may not be a priority and they would rather patch up what they have then spend lot of money on a new software in this environment. This means there is still a decent opportunity for ERP project work.

From ECM perspective, I am not that surprised. ECM products/projects do well when economy is booming, as many customers still view that as secondary to their most critical softwares. They know they have something in place and they can live with it, so they can let new software purchase wait in turbulent times. Another aspect is user interface, most of the ECM products allow you to modify user interface for end-users, so a customer could spend little bit money and do a face lift for end-users, and could live with back-end shortcomings. A customer who has difficulty making the changes to their front end, would be the one who could be spending the money on ECM.

The Economist in its latest edition had an article that caught my eye The paperless office: On its way, at last, here they talked about how information age actually increased the paper consumption rather than decreasing, as many had predicted. The trends in paper consumption show that this may be the year where paper consumption in offices in developed world would decrease and continue to decrease for the foreseeable future.

This could be a sign of sales boost for imaging products in ECM market. When ECM companies would start announcing their quaterly results, I would like to see if their Imaging products are producing more revenue than before, as that would confirm what this article is discussing.

I have met many people from companies/offices who has gone paperless route, they always exclaim how they did what they did before with so much paper, now they can’t live without their imaging solution. I think with these real implementation stories and what main stream media is saying, finally Imaging products could tip the balance against using paper.

As per Wikipedia, Microsite refers to an individual web page or cluster of pages which are meant to function as an auxiliary supplement to a primary website. The Microsite’s main landing page most likely has its own URL.

Microsites are quite effective as information outlet and its use is rising. You could give content authors wide range of freedom on how to create Microsite and what structure they can use. They could use any HTML editor of choice and copy the entire output folder to their Microsite folder on web-server (files including, but limited to images, JS, CSS etc). You point a URL to that folder and you are live! Content authors love this freedom of choosing their own structure, even if they have to comply with certain UI templates, they can still tinker with those templates quite fast.

On one hand this option promotes creativity, on other hand it can lead to stale content/template/message on internet longer than you want. You choose WCM and/or Portal products to help you manage the content life-cycle, so one naturally expect managing Microsites within these products. What happens when you try to manage Microsite using these products, can you still provide same level of freedom to content authors on creating Microsites?

Most of the WCM/Portal products would expect you to create templates and use those templates to deliver the content. If you want to create a new template or change existing ones, it would take time (Product companies may claim otherwise, and even if it is as easy to make template changes in few clicks, how about your governance process and testing the impact of template changes on existing content?). In short, it is not easy to change templates easily and give content authors same level of freedom in creating Microsites. This could create discontentment in content authors towards WCM/Portal tool, as it restricts them to certain existing templates for creating Microsites or makes them wait for the template creation process before they can publish their Microsite.

I have seen many of my clients struggling with this situation, where they have departments who want to rapidly create Microsites for promotions/campaigns and thay don’t want to live within the structure of existing templates. The discussion always boils down to this, IT team would ask how many templates you need and we would provide you the library, and the response would be, we don’t know what all we need, we need to be able to create the Microsites with new templates as we go.

I don’t think there is a perfect solution for this problem, but you can arrive at one which could accommodate majority of creativity requests upfront, but still leave room for one-off situations where you have no option but to allow content to be created on free-form HTML and dropped in web-server. Both sides would have to resist the temptation to follow one or the other route (WCM/Portal Vs. Free Form HTML) for all the Microsites. You would have to create governance process to keep an eye on those sites and regularly review them for their content and message.

I was a bit surprised to see this entry JSR 286: The last portlet standard? at CMSWatch recently, because I have been working with Portals for a long time and I have seen customers waiting for JSR-286 specification due to limitations of JSR-168. Not only that, I see that customers expect more features to be added to portlet specification. JSR-268 makes the portlets work in more cohesive fashion, but it still lack the access to many common Portal services and that is what I believe would be next frontier for portlet standard.

Portlet standard were written keeping Servlet standards in mind, with the notion of Portal Containers providing services similar to what Servlet Containers did. Many servlet container services were standardized (and others are on the way to become standards), making servlets (and JSP) so popular. With portlets, you can create a self-contained application and now with JSR-286, you can interact with other JSR-286 portlets, but what about interaction with Portal itself? Other than running the life-cycle of these portlets, Portals cannot expose their services to these portlets without breaking the spec.

Take an example, I have a shopping cart portlet and I want to display a link to help from my shopping cart. This help page is hosted by portal and the only way I can access it is by hard-coding the URL. I cannot access Portal navigation services to get me the link. It becomes worse when you add the personalization and security on these navigation items. Suppose you want to show different help pages to different customers (based on their profile, spending status etc), now you would need a jump page URL on your portal that this portlet would link to, and that page can figure out which help page is the correct one for this customer. Portals can have multiple pages exposes to different users based on authorization settings, but as these settings are not exposed to portlet, you would have to find a work-around to get your application working.

It may sounds like I am beating up the specification, that is not the case as specifications evolve over the time. When customers run into issues where they have a choice to break the spec or find an alternative way to solve the problem, they are open for alternative ways, as they don’t want to live with all the constraints of spec and add some extra features, they would rather go with fully open alternatives, even if it means their code may not be portable to other Portal servers.

To solve these kind of problems, we would have to start providing more services to these portlets and that would make this standard more attractive. I am positive that there are more releases of this spec in future for us!

This entry is about Web Content Management (WCM) content security (potentially delivered through a Portal) and does not refer to Digital Rights Management (DRM), although I can see this discussion being extended to discuss DRM as well.

When you talk about securing content in WCM world, it could fall under two main categories, content security and content personalization. It could be surprising to see personalization being talked under the security, but some people still blur the difference between two. Here is my definition to differentiate the two; security, when you should not have access to content if it is not meant for your consumption, personalization, when you don’t see the content on your landing pages, but you can access it through some other means.

Any WCM/Portal application designed to provide this feature has to deal with performance of application, as each user is accessing the pages with different combination of security (groups , roles or profile attributes) resulting in different queries to generate the page Vs. each user accessing the same page generated through one query. If the combination of security attributes is small, overall number of queries for all pages would remain in vicinity of non-secured content pages. But, when you talk about thousands (or millions) of end-users hitting the site resulting in millions of page-views, you would have to think about how much hardware you are ready to use for your site that deliver content security and/or personalization. More combinations you use, chances are high you would end-up using more hardware.

Most WCM/Portal solutions have some kind of caching mechanism to reduce the impact on back-end, but they work efficiently when overall cache-hit is high (cache-hit: same page is accessed by multiple users, so only first user hit would create an impact on back-end, rest access would result in serving the content from the cache). In case of content security and/or personalization, these cache hits are reduced, creating an impact on your back-end systems.

In the end, it boils to down to balancing the two, how much functionality you would provide to end user for content security/personalization Vs. how much you would like to spend for delivering that content through your infrastructure. It is not an easy decision, as we move towards more personalized web, every consumer of your site is expecting this feature, at the same time, the relentless cycle of extracting more out of less puts high pressure on delivering this functionality with limited infrastructure.

If you are in a similar position, you could try to limit the scope of personalization/security to certain pages (you would have to analyze overall use-cases to come up with recommendations) or use an intelligent caching solution (either part of WCM/Portal, or built on top of it). This functionality will make more impact on your infrastructure than non-personalized content, although you can limit the impact through judicious business requirements and/or technical design.