One of the fastest ways to mobilize your existing websites is to license special mobile middleware tools.  These tools access source content on your existing site but then apply a mobile-friendly layout to it. Key players include Dudamobile (also offered by Google via its GoMo initiative), dotMobi (offered by many hosting providers like GoDaddy) and many others of various types including open source libraries.

Most such "mobilize-an-existing-site" approaches work in a similar way. They act as a proxy between the visitor and your site and then perform what was classically called screen-scraping or web-clipping. Once they scrape content, they can then re-purpose and serve it to mobile devices.

Besides being a quick approach, proponents argue that you can reuse your existing site without making any major changes and thus save money, time, and hassle. I don't disagree with that conclusion, but I see this only as a short-term stopgap that you should consider while you evaluate a long-term approach.

The reason is, there are several problems with this quick-fix approach:

1. You've added an additional layer between your visitor and content. This obviously has performance implications because typically, screen-scraping happens on the fly. Sure, you can optimize and cache some of it, but you still have an additional layer to worry about.
2. This one proxy can become a single point of failure that's probably outside of your control, despite your other investments in rendundancy and reliability that you or your hosting partner have made. 
3. There are many problems with screen scraping itself. The quality of results will depend on the nature of the JavaScript, AJAX, CSS, and Forms code you've applied.  Your mileage will vary.

Besides these technical issues, my bigger problem is that this approach considers mobile as an "add-on" and not necessarily a channel becoming as important or more so than desktop access.

My recommendation to to our subscribers who are evaluating how to mobilize their web presence is to certainly consider this approach -- but only as a quick-and-dirty solution. If required, you should go back to the basics and evolve a strategy that treats mobile users with respect they deserve. This will inevitably require taking a hard look at your content strategy and your CMS technology. In fact, our recently released version 21 of Web Content and Experience Management (WCXM) Evaluation Stream specifically covers mobile capabilities of all the tools covered in that stream.

If you are an RSG subscriber looking for more personalized guidance, you can place an advisory session request here.

They pointed out that, like SharePoint of yore, Drupal was becoming all the rage among US federal web managers under the current administration. So naturally, this SI went looking for experienced Drupal talent. And could not find any. You see, as readers of our WCXM or Social Collaboration evaluations know, experienced Drupal talent comes in short supply, especially since Drupal fanboys promote it as the hammer for every nail (which it certainly is not). 

So what were these SI managers going to do? What nearly everyone else does: find some PHP developers, train them up on Drupal for several months, and hope they stick around for at least a year. That's exciting for the developer community, but what about you the customer? This sort of dislocation can be very jarring to your project and is something to consider when selecting tools.

No, I'm not suggesting you select some dullard WCXM product so that you can find cheap, unemployed developers. Rather, I'm suggesting that you build hype coefficients into your longterm total-cost-of-ownership calcuations. The more hyped the tool, the more you'll have to spend to get foundational advice. In some cases, a lot more.

And foundational advice is critical to any longterm investment. Ask a developer or architect to talk about their first two implementations with any tool. They'll roll their eyes and explain what they'd do differently if they had it all over again. Fine for them -- they got paid. Tough for you the customer.

Be sure to contract with seasoned implementers with at least 3 projects under their belt with any particular vendor. That's meaningful experience. And with Drupal, it's very hard to find today...

Reportedly, the so called "Apple Tax" -- whereby developers pay 30% of revenues to Apple -- along with lack of access to customer data, are the main reasons prompting FT.com to follow others (including Amazon who did the same thing with their Kindle app).

Many argue that the 30% revenue share for Apple is reasonable in exchange for providing a storefront and app store management. I agree with that, and suspect this tax may not be a big reason. In any case, without Apple's app store, developers will need to manage their own download facilities and storefronts (and spend money doing that).  The 30% fee for repeat subscribers, though could be tougher to swallow.

A more important rationale for FT's move may lie in having no access to subscriber information -- something anathema to any publisher.

However, commercial considerations aside, there are more practical and technical reasons as well.

As we pointed out here and here, native apps have an edge over web apps for many scenarios when it comes to user experience and performance. However, native apps bring many challenges in a world of diverse device types and operating systems. The two dominant platforms -- iOS and Android -- themselves have many variations in terms of screen sizes and device capabilities. For example, the recently released "new iPad" may be the state of the art iOS device, but you will also need to support iPad 1 and iPad 2. On top of it, there are constant rumors of a different-sized iPad. The android-based device marketplace is even more fragmented. Now add Microsoft's Windows and RIM's Blackberry to the mix and you can easily see that having to develop and maintain native applications for all these is not a scalable proposition.

Having a standards-based (read: HTML5-based) app, either a web app or a hybrid app, will allow FT.com to target a much wider reader base with only an incremental effort required to support another device/OS variation in future.

To be sure, there are still advantages of native apps, but many of those are slowly getting eroded, at least for the most common scenarios such as news and content consumption. So if like many of our subscribers, you too are evaluating your mobile development strategies, do consider a web based app for your scenario and then decide whether you still need a native app. We explore this topic further in a recent advisory briefing.

Probably the best primer on that subject -- how the internet works the way it does -- is John Naughton's "A Brief History of the Future: Origins of the Internet." Straightforward without being over-basic, it traces the history of the internet from ARPAnet, through NSFnet, to the internet that we are familiar with today. It might be over a decade since it was published, but it's still one I recommend to people interested in internet history.

Predicting the future often involves a good grasp on the past, and in that vein Naughton's recent column "Graphic designers are ruining the web" in the Observer newspaper brought back an old topic of web page weight to the fore. 

He cites a statistic that "[between] 2003 to 2011, the average web page grew from 93.7kB to over 679kB." He goes go on to blame this on what he terms "graphic designers" (falling into that trap of conflating graphic design with web design). Naturally this brought on a bit of a backlash, not least from his own publication's tech team.

It's a good time to have this debate.   The real challenge here for digital managers -- performance for the end-user -- is not going away.  I've just written an advisory briefing for our subscribers, "Address Emerging Threats to Website Performance," which reviews some web development trends that are increasingly having a negative effect upon website user experience.

While Naughton cites images as being the baddies, the real performance culprit lies to a great extent with the vast number of remote elements that go together to make up contemporary pages -- such as advertising and analytics calls. The performance of these elements is difficut to predict, yet all go together to produce the final page render time.

Add to that the increasing complexity and dependency placed upon JavaScript and the yawning gap between available broadband and mobile bandwidths, it must make digital professionals yearn for the days when all they did have to worry about in terms of site performance was image optimization!

As I point out in today's release, the key is to carefully balance web architectures with data architectures...

The answer that most portal vendors give you may not be very satisfying. You see, most portal solutions display chunks of information and services (portlets or web parts) via some sort of "theming" mechanism that lays those chunks out on a page. Naturally, their typical answer to the mobile challenge is to develop "mobile themes."

Mobile themes typically work like this. The portal detects the device or mobile operating system and streams your portlets one by one in a different order, perhaps leaving some of them out entirely. That's a nice short-cut for a hard problem, but note that it's not true adaptive design.

Consider for a moment the home page of noted portal vendor, Liferay. Here's the default view in a desktop browser.

Now let's look at the series of screens for that same URL that get presented by Liferay's mobile-aware theme.  You'll see that they stripped out some extraneous or not-mobile-ready portlets.  Here they are, top to bottom.

* * *

* * *

It's essentially a subset of portlets that have been concatenated vertically as I scroll down my iPhone. That's not a bad solution. It allows you to easily re-use existing components and prioritize them in different ways. I recently talked to one intranet manager who gloried in excising various lame-but-company-mandated web parts (e.g., CEO's speech) from her SharePoint mobile site.

The problem here is that stacking portlets and web parts does not necessarily lead to a great mobile experience. The same goes for simplistic mobile templates in a Web Content & Experience Management (WCXM) platform that simply streams down existing page elements in a specific order. The advantage to a WCXM platform, though, is that you typically have simple programmatic access to individual data fields, which means that you can modify the mobile experience at a much finer level.

Meanwhile, back on Liferay's inner pages, their default theme breaks down a bit. The first two screens on any inner page are always the top- and sub-nav respectively, which kind of gets in the way of the real content. To be sure, Liferay could create a different mobile theme for inner pages, though here again, that approach would probably require breaking out of the portlet motif.

In the end, there's two ways to think about mobile web experience:

1. From the top down, taking a subset of your existing, pre-built components and ordering them in a sensible way
2. From the bottom up, rethinking what content and services (and their associated display) make the most sense for your mobile visitors, and re-assembling from scratch

The former is much easier. The latter is much more valuable.

To be sure, other portal vendors suffer from similar deficiencies. For more details on how the top Portal vendors differ in their support for mobile-enablement, consult our detailed Enterprise Portal vendor evaluations.

Of course, one of the most satisfying parts of building with Lego is the interoperability of the parts, the way they snap together with a real feeling of rigidity. You can mix and match parts from different kits to create your own designs whenever inspiration takes you. I do wonder whether if that's why I took to being a developer with great enthuiasm.

A few weeks ago, before the London weather decided to bring us a year's rainfall in less than a week, I spent a sunny weekday lunchtime catching up with an old colleague. Before long, conversation turned -- as it generally does with nerds -- to development. One thing that came up in that discussion stuck with me: "I wish people would remember that APIs are not Lego."

Software vendors are very fond of APIs. So fond that they often see the mere existence of an API in their product as a fait accompli in and of itself. However, what this really means in practical terms is, "We're giving you a way of making our product work with others you might already own employing code you'll to have to build and maintain yourself. Oh, and it's going to be pretty-much proprietary. Maybe you'd like to buy some training?"

Not only are APIs certainly not like Lego, they are not equal. Talk to a developer and you'll find out pretty quickly that they range from the well-formed and functional to the fiendishly complex and arcane. Then ask about the documentation. Then probably buy them a beer to recover from having to relive personal nightmares.

The chances are that every piece of software you purchase is going to have to work with a range of others that you already own. Unlike Lego, they won't snap together simply. You'll have to tease them in place via an integration.

The good news is that you probably know well in advance how you like this to work at a business process level -- e.g., content from System A should be sent to System B under circumstances XYZ --- long before you start any purchase cycle. This should become one of your test scenarios that you can subsequently use to help decide which supplier offers the best  technical fit. (Vendor fit is another thing.)

So when you ask "How?" and a prospective supplier answers with, "...via our extensive range of APIs," be sure to request documentation to illustrate their answer. And then validate with developers or with your systems integrator. 

Whilst accidentally treading on a Lego brick in bare feet is one of life's more painful experiences, relying on an unknown and untested API to meet a critical need to your business can bring about much more lasting pain...

We recommend that you make Content Migration a part of your overall project and start planning for it from the very outset. This will allow you analyze your content and make improvements to overall content quality. You will also have better chance of keeping your project on track and avoid any major cost or schedule overruns.

In our recent advisory briefing, Start Your Content Migration Planning Early, we lay out what migration activities you need to plan or execute at each stage in a project, from team selection to piloting.

This advisory is for subscribers to our Collaboration, DAM, ECM, SharePoint, Search, CMS or Portals streams.

For more about content migration, you should also check out our earlier advisory, A Guide to Successful Content Migration in conjunction with this one.

However, as we all know, that's not really very practical (both for technical and organizational reasons), and multiple portal platforms have always proliferated within organizations.

To be sure, there are many disadvantages to running more than one portal tool. For example,

• There are integration challenges between multiple portal tools.
• You need different skill sets and resources. Even if each Portal platform you deploy is based on same broad technology (such as Java), you still need people who know the intricacies of individual tools. The problem becomes more complex when your Portal tools are based on different technologies (such as SharePoint and WebSphere).
• You also have to manage multiple different environments, hardware, software, licensing issues, vendors, and integrators.

However, in spite of these disadvantages, certain tools are better suited than others for specific scenarios and we often recommend deploying more than one portal technology to our larger advisory subscribers.

So if you are considering supporting multiple portal tools in your organization, make sure they each play well being just one component of the overall architecture.

For example, most Portal tools expect other applications to expose functionality in a well-defined way so they can consume it easily. However, when it comes to them exposing their own functionality in a similar way, they don't do a very good job of it. So make sure the tools not only can act as consumers but also producers of functionality that can be consumed by other portal platforms.

Specifically, this means they offer some sort of interfaces (APIs), so that external applications (portals or otherwise) can access those APIs for specific functionality. This will help you sharing functionality from one tool (such as its employee directory) as a service to get presented in another portal.

Standards play an important role here. Explore if the tools you are considering support some major standards like WSRP, JSR, CMIS and so on. Support for standards will save you from writing proprietary extensions and reduce maintenance overheads.

Each of the tools should support other common applications that you have. These are mostly those that provide directory services SSO and content management. Also consider how difficult or easy is it to replicate your branding, look and feel across different tools. Typically, each of them have their own way to create "Portal Themes" but you should explore if you can reuse CSS and layouts without making major changes.

Stick to platforms that are based on similar technologies. Even within the Java world, there are many options. SAP's NetWeaver Portal and Oracle's WebCenter are both based on Java but employ their own extensions that aren't supported in other Portal tools.

What I've also often seen in larger organizations is standardization on two Portal tools: One a traditional heavy-weight platform such as that from IBM or Oracle, and second, lighterweight offering, such as that from Liferay, Red Hat JBoss or eXo. This allows organizations to mix and match tools depending on factors such as features, reliability, scalability, and time to market.

You can read a summary of all these tools in our forthcoming Portals Marketplace overview for 2012 or for in-depth reviews, you can subscribe to out portals evaluation research.

The reason is not difficult to find.

Many Portal tools have built some basic capabilities for managing content. In the same way, many Web Content Management tools have built capabilities for managing web site experience and thus evolving into what we term as Web Content and Experience Management (WXCM) offerings.

Because of this convergence (at least in terms of broad features), there are cases you could employ either a portal tool such as IBM WebSphere, Liferay, Microsoft SharePoint or many of the tools we evaluate in our Portals and Content Integration stream, as well as use a WXCM tool such as Oracle Fatwire, Adobe Day, Sitecore or one of the other 42 tools we evaluate in our WXCM stream.

Nevertheless, while it may be theoretically possible to swap a portal or a WCXM tool, usually one offers a better fit than the other. You must consider the subtle differences between these two types of technologies, since each one provides a different approach to building and managing digital environments. You should also understand that there are rare occasions when you may need both a portal and WCXM platform.

In our recently released advisory briefing,"Portal or Web CMS: Which One Makes Sense for Your Use Case?," we explore this very topic and provide some guidance on when to use which approach. The table of contents for the advisory is as follows:

• Key Takeaways
• Introduction
• Example Dilemma: A Self-Service Employee Intranet
• When to Use Portal Technology
• When to Use a WCXM System
• Summary
• Additional Notes

The advisory briefing is available to our Portal and Web CMS research stream subscribers.

It happens on an ad-hoc basis now. Collaboration adherents and community facilitators (or just enlightened employees) at Alcatel-Lucent will tell email correspondents to "move" certain conversations to a community space that offers threaded discussions. Or just they just start a new thread themselves. It's a manual process, but when it happens, it seems to work well.

This approach makes all sorts of sense. Moving email to collaboration spaces can:

• Reduce email volume (hooray!) -- maybe not number of messages, but volume of body content to parse
• Make information more searchable and open
• Make conversations more understandable, especially for someone jumping in the middle

Like some other tech firms, Alcatel-Lucent is comparatively sophisticated in this regard. They have a mature implementation and Colombe and his colleagues have worked hard to educate and support their peers.

So what could work for the rest of us?

Here's what I'd like to see collaboration vendors implement: integration at the mail server level that automatically inserts a link to your community platform in certain internal email messages, according to filters you set. That way employees would be encouraged to migrate conversations to your community spaces -- and more importantly, have a really simple means to do so. Ideally the system would already pre-populate the first forum post with the original email subject and content.

For example, you could set rules to insert the move-to-community link into the top of a message body when someone:

• Replies-all to a message
• Receives any message sent to multiple recipients
• Receives any message at all from a colleague

To be sure, I'm leaving out some important technical details. You'd need some signalling downstream to email recipients who didn't know the conversation had moved. And the integration could get tricky -- though not impossible, especially if you just target Exchange for starters.

To my knowledge, none of the social and collaboration tools we evaluate can do this natively today. That's a pity. But perhaps we could all start asking...

Now, if you're an industry insider or have been following this blog for a long time, that might seem like old news. We were among the first analyst firms to point to Redmond's own calculations of customers spending six-to-nine dollars on professional services for every dollar spent on SharePoint licensing. We've also consistently pointed out the necessity of corollary information and process management in any SharePoint-sized engagement.

Unfortunately, those details often get lost in the push to get SharePoint "stood up." You can understand why. For most enterprises, it takes herculean effort just to obtain...

• Consensus on basing their collaboration services on SharePoint
• Funding to license the platform across growing ranks of knowledge workers (or wherewithal to finally upgrade from MOSS 2007 to the modern version)
• Resources to implement baseline functionality
• Support to combine myriad departmental initiatives into some sort of enterprise whole
• Savvy business analysts to apply the requisite soft skills
• Large-scale education, training, and team-lead support
• And so on...

So you can probably empathize when, at the end of that process the collaboration manager says, "Phew, we made it!"

Except, of course, they have made almost nothing. And here comes the surprise. Colleagues who were expecting finished applications (like ideation communities) respond, "Is that all?" Some of you cleverly budgeted for add-on tools and services. Many of you didn't, and now have to go back, hat in hand, to sponsors. Ouch.

The most important thing to remember is that outside some very basic functionality, SharePoint is a platform. With enough time, money, and painkillers, you can get it to do almost anything. But then you or your integrator fall into the business of software development (and maintenance).

I sympathize with enterprise architects who argue that their burden becomes an almost impossible knot: business units bring intense integration needs, but those same units don't want an integration platform. They want productized solutions. That's a tough knot for sure. But I've seen first hand that it's a knot you can untie with a clear upfront strategy. Not a "SharePoint strategy," but a collaboration and information management strategy. Make sure you craft one, and let us know if we can help.

For better or worse, the lineage of software gamification dates to the video game industry.  Video games are a serious business with global sales of $56 billion -- double the size of the music industry.  Closely related to social networking, gamification refers (roughly) to applying the techniques of video games to make software more engaging, work more interesting, and the world a funner place. Doing so will increase user participation -- so the theory goes -- and turn customers more loyal and make employees less disgruntled.

Some examples of gamification techniques include honor badges, achievement levels / laddering, loyalty points, leader boards, and challenges. These tap the intrinsic and extrinsic human motivations/behaviors to encourage contributions, while rewarding -- or at least recognizing -- participation.

If this reminds you enough of employee-of-the-month schemes, happy hours, airline loyalty programs, and the like to consider gamification old wine in new bottles, you’re right, at least to an extent. Companies have always been trying to influence customers and modify their behavior, and gamification itself heavily borrows from the field of psychology. What’s novel is consciously trying to embed these principles into work-routines, business processes, and software design.

As you’d expect, there are both external and internal use cases for gamification, targeted at your end-customers and your employees respectively.

Currently, most vendor solutions are focused on external use cases that try to increase brand loyalty. Examples include start-ups (almost all the gamification vendors are start-ups, pointing to the recency of the field) like Badgeville, BigDoor, Gigya, and Bunchball .

For internal use cases, (e.g., if you want to gamify your digital workplace), there are not many out-of-the-box solutions available. Bunchball has released apps that integrate with Jive and Salesforce software. Attini has a badges application for Sharepoint. Rypple, which had apps for gamifying internal HR applications, was acquired by Salesforce. None of the larger enterprisey vendors (IBM, Oracle, Microsoft, SAP, et. al.) nor WCM vendors (Adobe, OpenText, etc.,) nor major social software suite vendors (Telligent, Jive, Socialtext, etc.) natively provide packaged gamification features.

However, if you want to experiment, you could start by adding game-like dynamics such as leader boards to your Intranet, with a bit of custom development.  Just make sure you haven't skipped some essential social networking and project support services first.  Your colleague Claire doesn't need game dynamics to help her find out what her predecessors have done on the Penske account she just inherited. She wants her intranet to either connect her with the right information so she can track down the right people, or connect her with right people so they can point her to the right information. Ideally both. 

Indeed, while cheerleaders (vendors and consultants) drum up the hype, gamification is not without its pitfalls. Without a clear “what’s-in-it-for-me” proposition, people will eventually see through institutional ploys. Also, gamification adherents frequently underestimate the difference between workplace and consumer environments.  In the workplace, for example, recognition typically trumps rewards, and the quality of participation will almost always trump quantity (something many vendors haven't grasped).

Your chances of success will be higher if you follow a well-reasoned approach that respects your users, be they customers or employees. Gamification can easily deliver instant gratification, but creating lasting satisfaction is no child’s play.

Many factors account for the ubiquitous role that video plays in the contemporary enterprise. Whether it’s a movie studio’s cinematic masterpiece, a broadcaster’s news clip, an animation studio’s cartoon, a university’s lecture, or video content in support of an agency-created brand strategy, video has become quite commonplace. From a consumer standpoint, the power of broadband, the capabilities of hand-held devices, and the recognition of the power of video all contribute to the explosion of video assets. Enterprise production and distribution of time-based media (video in particular) calls for specialized technology to support the process.

We're increasingly asked about CDNs and OVPs by our customers who are in the process of selecting a DAM or a MAM system, so in this Advisory Paper, we provide essential definitions and vendor categories, as well as present key factors to consider when selecting Content Delivery Networks (CDNs) and Online Video Platforms (OVPs).

As always, please feel free to send me your questions.

Yet despite the interest, one area I find few buyers investigate thoroughly enough is that of file encryption.  Presumably you make the assumption that if you are going to pay a third party service to manage your electronic files that they will do so in a safe and secure manner, and most times they will.

Managing data securely involves many things, but one element that suppliers make quite a song and dance about is the fact that they encrypt your documents/data, making it "100% secure." But things are not quite that simple, and you need to ask some more probing questions before taking that sort of claim at face value.

For example:

• Are my documents encrypted whilst "at rest" in your system?
• Are my documents encrypted whilst "in transit" to your system?

In most cases you'll find that documents are not encrypted whilst "at rest," and even where this gets presented an option, there are often sound technical reasons why any hosted or cloud service would rather not encrypt everything all the time, not least of which would be the impact on processing and delivery times of your data. In most cases documents only get encrypted whilst "in transit" -- in other words whilst they are passing through the internet to and from your premises.

You may also want to ask who has access to the keys to encrypt your documents. Is it just you or does the service provider also have access to the keys? That will likely start up a whole new conversation with some surprises, not all of which may be pleasant.

It doesn't matter whether you are considering contracting with an industry Goliath like EMC, Amazon, or IBM, or new upstart like Box, Huddle, or Oxygen. The fact is there are plenty of questions you will want to ask of any service provider before committing to any kind of contract; yet in our experience even simple questions like those above are often overlooked. 

Over the past few of years we have advised many organizations who are considering handing their corporate assets to a cloud-based service, and it's a trend that will surely grow in 2012. It is also one that as buyer advocates we worry about, for buyers themselves need to make the effort to dig deeper.  Suppliers are unlikely to be falling over themselves anytime soon to lift any fog of confusion that currently exists.

I know however that I am in the minority -- in previous jobs I have argued with fellow managers about the educational qualifications of the people we hired. ("I don't care if she's a certified PMP, has a PhD, and 5 other professional certificates. Has she ever actually managed a large, successful project? Can she inspire a team? Is she an effective communicator?") Education only gets you so far: what matters in my book is real experience and results. (Note, I have 3 PhDs in my immediate family, so I may now be uninvited to the holiday events.)

Recently I had an advisory session about web content quality control with a large, global Real Story Group research customer who adopted a new web content management system a year ago. They wanted to establish a culture of quality among their web content managers, and champion those who not only understood the system designed to manage dozens of global websites, but also possessed a certain level of experience and inherent attitude towards quality.

I suggested adopting a six-sigma-like / karate-oriented "belt" system that, after a base level of system training, was focused on levels of experience-based knowledge and, equally important, positive attitude and focus on content quality. 

Here's a short summary of a longer deliverable:

WCMS yellow belt:

• Has taken 3 days initial WCMS training, is willing to ask for advice, proactive curiosity about WCM and how it works

WCMS blue belt:

• Minimum of 3 months using the system, showing inherent interest in the "health" of the system, proactive constructive attitude about content quality
• Understands the ramifications of content type changes, tagging, and other content editing tasks
• Takes responsibility at at a local level and derives improvement ideas for both the site(s) and the WCMS from experience

WCMS black belt:

• At least 6 months using the system, daily exposure to the WCMS, experienced as an admin
• Omniscience of the "big picture" of how the WCMS effects sites, knows and understands why it's important to do things correctly, encourages others to maintain quality 
• Leads, delegates, and maintains content quality at a global level

One key question came up during the planning: "should we hire or promote someone into the black belt role?" Promote, promote, promote. Again, since this is about real-world experience in a particular environment and a particular company, it's like learning a language. Even if you learn to speak Spanish in Madrid, that doesn't cut it in Mexico City or the Andes. Black belts vary from dojo to dojo; the same should be true for WCMS black belts.

As such, there were many more criteria specific to the organization that defined these different levels, which I won't share here. Creating an operational framework that rewards system users based on their real-world experience, dedication to web content quality, and proactive attitudes towards system and content improvement is one way to make WCM a core part of how your team is evaluated. This approach can be adopted regardless of what platform you use, and also adapted for other types of technology.

As always, let us know if you need help.

The project in question has weathered some turbulence – execution delays, budget overruns and most critically, lack of end user enthusiasm for the delivered solution.  

At the surface level, they seemingly did everything right and all the boxes can be safely checked off. However, careful reflection reveals that they ended up where they ended up and not where they wanted because of the disconnect between Marketing and IT. In this instance, marketing drove the project with the assistance of a 3rd party integrator, and the internal IT team was not fully on-board till very late in the game. Important issues like global training, scaling up, ongoing support and service levels were left as an afterthought.

Suffice it to say a sound DAM (or for that matter, any IT) project requires all stakeholders to be aligned from the beginning or else you'll end up with bad karma, and a system that is not fully adopted.

In addition to our cornerstone evaluations of technology vendors, in our DAM Report you will also find sage counsel about the pitfalls that you'll encounter during your DAM project life cycle. While attaining DAM Nirvana is a difficult goal, we at RSG do our bit by at least pointing you in the right direction.

Had any enlightenment of your own recently? Tell us about your experience.

1) "Bring Your Own Device" policies will push HTML5 adoption for mobile access to enterprise applications
This has definitely happened, although HTML5 adoption remains quite incomplete.

2) Content-rich customers will rebel against Web CMS marketing spins
The key phrase here is "content-rich." We've definitely seen some disappointment among high-volume publishers (e.g., media), who don't want e-marketing and other corollary services from their WCM vendor.

3) Microsoft will turn to partners to fix SharePoint shortcomings
Yep. It's an old story. As a SharePoint version ages, Redmond stops arguing that it's feature-complete and encourages customers to seek out supplementary tools from partners.

4) The top end of the Web CMS market will be redefined
This happened. OpenText/Vignette and IBM continue to fade. EMC gave up on Documentum Web Publisher, Oracle is effectively deprecating its UCM (neé Stellent) WCM in favor of its new FatWire acquisition, and the future of Interwoven TeamSite/LiveSite has gotten even dicier with HP's acquisition of Autonomy. The big boys, long fading, have almost disappeared, getting replaced by a bevy of more focused alternatives.

5) Intranet community managers will adopt public social functionality
We've definitely seen more of this, though it's still not pervasive.

6) SaaS vendors will try to separate from "The Cloud"
Nope, we were wrong. If anything the opposite: SaaS vendors have uniformly embraced fluffy Cloud terminology to ride that wave of hype. This was the case even among those SaaS players that don't actually employ Cloud-based technology.

7) Buyers will have a greater acceptance of newer standards
In some cases (CMIS, HTML5) yes, but in other cases (activitystrea.ms, OpenSocial) not so much, yet.

8) Case Management will become the leading application from high-end ECM vendors
Absolutely. Case management actually constitutes a family of applications relevant to many different types of organizations. It's where much of the non-SharePoint ECM action lies today.

9) Digital Asset Management vendors will greatly expand video management capabilities
This happened, though perhaps not as heavily as we predicted. It remains unclear whether traditional DAM players have the chops to compete effectively with more video-oriented vendors.

10) E-mail will remain the world's de-facto enterprise document repository and workflow system
Alas, we were correct. Companies ditching e-mail remain very much the exception and not the rule.

11) Portal software will increasingly produce services for other portals
Hard to know exactly. Major enterprise software gets talked about more than implemented, but portals seem the opposite. Enterprises who have committed heavily to portal technology continue to invest in those platforms -- or perhaps more tellingly -- in the systems around those platforms. Yet more enterprises are getting comfortable with multiple portals, including "portal lite" applications.

12) Specialized talent around managing content will begin to migrate out of large corporations
This is an organic trend that's difficult to track, but we saw increasing evidence of it last year, as consultancies and integrators desperate for more talent continued to comb the ranks of enterprises for experienced specialists. There's no recession in information management technology right now...

By my count, we were about 9 out of 12, or 75%. Not bad, not awesome. About the same rate as previous years -- and a reasonable co-efficient to add to our 2012 predictions. Look for those new predictions from us in the next few days....

Sure, in the back end you may have a million moving pieces, but the point is that your content publishers must have an easy time publishing workaday content.  Failing that, you risk many problems in a CMS implementation, like CMS user revolt (or at least high agitation), inconsistent content (by non-standard workarounds being used), and an unsustainable system (by concentrating too much on the one-offs).

Before diving into this more, note that concentrating on the simple use case is important for even the most complex implementations.  This isn't just a small site issue.  In fact, small sites can probably get along fine with a clunky publishing process.

Assuming you are following the Real Story Group's suggested approach for selecting a CMS by evaluating against use cases, some of the characteristics of a good publishing use case include:

• Start with where most publishers will start.  If you are in a high volume publishing environment, then perhaps you can assume everyone is already logged in and at the right place.  Usually, though, this isn't the case, and have to consider the log in process up to getting to the right place for publishing the content (sometimes placing the content can take time).
• Do not include any side-tracks, but do list the activities that will routinely occur.  If a publisher always has to include an image, then include that in the process.  If they rarely do, then exclude it.  If you plan on restricting what styling can be applied to the text, then include it.  If you plan on leaving this wide open, then this should be the same in the use case.  In other words, there isn't a one-size-fits-all use case, but needs to reflect your needs.
• Include the preview process.
• End with content being published to the live production environment, and viewed by an external site visitor. If multi-site publishing is a key part of your vision, then the content should appear on all the relevant sites.

Another key is to keep a razor focus on the maximum end-to-end elapsed time that elapses here.  In a news environment, perhaps the whole process needs to take less than a couple minutes.  In other situations, an hour may be acceptable.  In all cases, you obviously want to ensure that the publisher knows where they are in the process and what the next step is.

So where does this use case come into play?

• CMS selection.  CMS vendors usually want to emphasize the flexibility in their platform, but you need to keep your eyes away from the glitter at least long enough to make sure the simple publishing process is indeed simple.  Even if you have a simple use case, CMS vendors will want to emphasize all the bells and whistles during demonstrations.  Be bold and make sure that you see a walk through of your simple use case without all the possibilities thrown in.  In many cases, you will find that the straight through process is actually more crooked than it seems when looking at all the what-ifs.  
• Implementation.  Our attraction to complexity will perhaps spike during implementation, and so you need to make sure the implemented system successfully results in a simple publishing process.
• Training.  Training needs to be particularly high quality for this most common use case.

In sum, implementing your simplest publishing process may actually prove difficult, but at least you should be aware of this as early as possible...

As corporate requirements for search and content management have intensified, so has the demand for tools that help organizations create, administer, and publish semantic structures.

You the customer can choose from among several fully-featured taxonomy management tools, yet each vendor has tackled the problem of managing vocabularies from a different angle. So how do you figure out which one is right for your context?

I've just authored an advisory paper that evaluates a collection of leading enterprise-level taxonomy management tools head to head:
·    Sempahore Ontology Manager (Smartlogic)
·    Synaptica
·    Data Harmony Thesaurus Master
·    TopBraid Enterprise Vocabulary Net (TopQuadrant)
·    Intelligent Topic Manager (Mondeca)

Learn about each tool's key strengths and weaknesses, add-on modules available, and SharePoint integration capabilities. Find out which vendors excel in multilingual vocabularies, ontologies, governance, and cross-mapping.

Subscribers to the RSG Enterprise Search stream have automatic access to the evaluations.  Others can purchase it online here.

• Complex
• Viral
• Collaboration
• Clunky
• Misrepresented
• Social
• Bottomless Pit

This is typically a pretty pro-SharePoint audience, and in terms of research for our buyer-focused subscription ECM and SharePoint research services it has been a reliable source of peer information over the years.

But I have no doubt at all if we had asked the same question in previous years, we would have seen a more positive list of answers.  Further discussion revealed that SharePoint buyers and users in the room had been caught between a bottom up / top down approach to deployment.  Bottom up in that IT had thrown the problem of SharePoint over the wall and left users to self provision, or business users had simple gone off and acquired SharePoint on their own. Top down in that IT had provided very elementary and unusable SharePoint environments with insufficient education and training.  What was missing in both approaches was:

• Business Analysis
• Process Analysis
• Change Management
• Information Management

Neither the business groups that had SharePoint unleashed on them (or unleashed it themselves), nor the IT department that technically owned SharePoint offers those kind of skills anymore. Yet both assume somehow that the other will figure it all out. It's not so much that SharePoint is at fault; rather that growing SharePoint installations reveal the dearth of supporting resource, and their criticality.

We can call this a lack of skills, but that's not the real issue: it's a lack of enterprise commitment to the "soft" resources required for success here. Remember that SharePoint is like any other enterprise platform: you can't install and forget.  Adherents of SharePoint in the cloud would do well to note this too...

OK, this is partly an argument about labels, but labels matter. What most employees understand as their "intranet" -- updates from corporate communications, some HR forms, and a mountain of outdated docs -- is increasingly irrelevant.

The issue here is not that traditional intranet services have somehow lost value. Rather, it's that business units are moving on. They don't want to be "lured" to your vision of an intranet. They want some fairly specific services. From what I can see, there is a confluence of factors here:

Applications over platforms
Platforms are good for the kind of long-term planning and prep where IT excels. Unfortunately, platforms are less amenable to delivering short-term benefits to business units. Put another way, your colleagues don't need "SharePoint." They want a contracts management system, or a project scheduling utility, or any one of thousands of practical business services.

Ability to self-provision and employ SaaS-based solutions
This can be a tough one to swallow at an enterprise level, and you'll want to keep some controls in place. Yet, you also need to get ahead of practical business needs by offering some real alternatives, or your business colleagues will simply use their credit cards to buy what they need in the cloud.

Rise of Portal Lite
Rather than a big, heavy, developer-intensive enterprise portal, business units are increasingly seeking simpler forms of integration: basic dashboards / health meters, simple mash-ups, activity stream aggregation, and so on. And they want these services available ubiquitously, and not just in a corporate-wide portal. The good news is that some vendors are adapting. Are you?

Emphasis on collaboration and social
If you've spent the past three recessionary years trying to automate processes to cut costs, you're only getting half the picture. Sales, Marketing, R&D, Product Development, and other revenue-generating units want to be more agile, more innovative, and work more closely across silos. It takes much more than technology to do that successfully, but the right collaboration/social toolset is a key part of the overall solution here. When intranet teams deliver the wrong tools or approach, business units take matters into their own hands.

Blurring lines between enterprise applications and enterprise information
Employees don't want services bereft of supporting content; nor do they want content delivered in a way that's not immediately actionable. The sharp divide between applications and documents on most intranets is becoming anachronistic. Savvy intranet managers are focusing on content-enriched applications. The rise of mobile is really pushing this. Even the simplest static intranet "websites" make more sense as applications on mobile devices.

* * *

Let's not have a funeral. The death of the intranet heralds the re-birth of something better: a more practical set of tools that help people get their work done. Intranet managers should re-align with this new world and focus on services that businesspeople can use in the flow of their daily work. The digital workplace is actually less a specific place, but rather a mindset that creates services so badly needed that you'll never have to complain about "poor adoption" ever again.

That's hard, and you may skin your knees at first. Age-old challenges of security and interoperability can get tougher before they get better. Yet your colleagues are already looking way beyond your official intranet. It's worse to be irrelevant than to have experimented and failed. If we can help you, let us know...

* * *

P.S. This post was informed by some great chats at the recent KMWorld event with two of my favorite Digital Workplace gurus, Jane McConnell and Martin White.

Kurt DelBene (Microsoft President of the Office Group) fielded harsh criticism regarding the lack of "new" information or big product announcements during the conference. His response was blunt: our product teams haven't been sitting around for two years, it's just too early to share.  In fact, Microsoft went out of their way to focus on what the core product does today and "remind" everyone in attendance (some 7,500 people) that SharePoint 2010 is still thoroughly relevant.  Jeff Teper (VP, SharePoint Product Group) even went as far as to claim that he didn't want anyone at the conference to walk away and say "I didn't know SharePoint could do that."

On balance, this message isn't exactly a disappointment.  In my experience talking about SharePoint as well as building solutions on the platform virtually everyday, it's not all that hard to miss less-used or less "popular" features.  SharePoint, as I've said before, is a vast software platform that can be used to develop many different solutions.  Consultants, like customers, tend to focus on those features and functions that support common business scenarios.  Less frequently used features often get forgotten.

For example, most firms are familiar with Excel Services; it provides a way to surface an Excel workbook in a web interface and enable some limited editing.   This service has been around since SharePoint 2007 and it works well.   However, what is less used is the REST programming interface (introduced in 2010) for accessing both charts and data in that workbook.  With this interface (which is merely a series of URLs), you can dynamically or statically embed an Excel chart (or other data) in a blog post, Word document or PowerPoint presentation without programming.  You can also keep that embedded chart in sync with the source chart in that workbook without having to do more than update the workbook.   While I've seen many customers use Google or Yahoo for creating dynamic charts, SharePoint buyers have this capability in-house and don't seem to know it.

It's easy for gurus to get frustrated by the lack of news, but for SharePoint customers, I think the messages that Microsoft is promoting for this conference are relevant, even if predictable.  Many enterprises are still struggling with SharePoint 2007 or just starting to deploy SharePoint 2010.  One typical SharePoint customer I spoke with has had their 2010 solution in place for only five months, while others are just starting their migration.  Too many customers have multiple technologies simply sitting on the shelf; you should look at what you already own before buying the next shiny object.

A few interesting tid-bits did emerge:

• Redmond announced a partnership with WebTrends to bolster analytics.  SharePoint 2010 has some basic analytics in the box, but they're just that: basic.  The WebTrends deal sparks hope that we'll see higher-grade analytic capabilities not only around the typical internet-facing sites, but also deeper insight into internal behaviors as well.
• Office 365 is getting more functionality.  Microsoft is finally adding support for Business Connectivity Services in the cloud.  This means that customers on SharePoint Online can begin to connect their O365 SharePoint sites to external data sources, assuming that data is Web Service enabled.  While BCS isn't a new feature to SharePoint, it is bringing O365 and the on-premise versions closer to parity.
• Kurt DelBene seemed to suggest that Microsoft is also evaluating different release cycles; they want to commit to a quarterly release cycle on O365 and may experiment with new ways to deliver features for on-premise implementations outside of the typical 36-month cycle.  He was, however, careful to say they don't have anything formalized and are still working on the details. (We've heard this before.)

Outside of the reminders and some minor announcements, Microsoft was again promoting its ecosystem.  This is something I and others at RSG have discussed at length; SharePoint has an enviable collection of independent software vendors (ISVs) that build add-ons, systems integrators that develop customer implementations, and a developer community that virtually no other platform can equal.  As such, Microsoft did a bit of promoting both during the conference and through a blog post welcoming folks to the conference.  With a Microsoft-reported 700,000 developers and more than 1,000 ISV solutions (read: add-ons), the momentum seems to continue to build around the product.  That post also included some interesting statistics on the customer base, including a breakout of pure SharePoint 2010 licenses.

While pure-play vendors will continue to outshine SharePoint in specific functional categories, the platform continues to maintain a unique market position based on the breadth of functionality and depth of its ecosystem.  SharePoint 2010 can be a viable answer for many different problems, but there's still much to be learned about the platform before we all start musing about SharePoint 2013.

Fortunately, portal platforms offer multiple approaches to addressing this challenge. The trick is to decide which approach makes best sense for your scenarios. These approaches differ from each other in terms of cost, ease and speed of implementation as well as in terms of the range of scenarios they can address.

In our recently released advisory, Eight Ways to Integrate Content into Your Portal, we examine different ways - ranging from completely decoupled ways to very tightly coupled ways of doing just this. The table of contents is as follows:

• Key Takeaways
• Introduction
• Eight Integration Approaches
• Displaying Integrated Content
• Conclusion: Which is the Right Option?
• Additional Notes

The advisory briefing is available to our Web CMS and Portals & Content Integration research stream subscribers.

Here’s a picture of the Farmer’s Market in nearby Woodstock, VT, where I do most of my grocery shopping:

Directly behind that building to the left is the office of the Vermont Standard newspaper. Forty years of print archives went under water, and are completely destroyed.

Now, unlike my colleague Alan Pelz-Sharpe, I don’t specialize in archiving – but customers often ask me if it’s worth the effort. This picture answers that question.

As Irene crawled up the coast, we Vermonters were ready for high winds and power outages, but never expected our rivers to crest beyond historic levels. Just about every story of data, information, or historic loss starts with the phrase “we never expected.” I never expected to experience an earthquake when I was in Virginia last week, either. But there it was, shaking a room full of brand managers near Richmond (close to the epicenter), as we discussed digital asset management over afternoon coffee.

I admit feeling complete rage upon seeing comments on social media sites to the effect that historic bridges washing away “doesn’t really matter.” Some might say the same about a newspaper’s archives, or even a major corporation’s records. This is short-sighted and ignorant thinking. Don’t be afraid to say the same to your boss (in a more diplomatic fashion) if he tells you a proper archiving plan isn’t worth the investment. Archiving goes beyond records management, compliance, or other everyday business matters -- it is also about preserving culture and history. One of our CIO customers refers to it as "collective cumulative knowledge," built up over time. And really, how many more natural disasters or other tragedies should it take before this becomes a no-brainer?

In Vermont, several of our historic bridges will have to be rebuilt. I don’t know if the state has the original plans for those bridges, enabling us to reconstruct them as originally built more than a hundred years ago. But if I were to build one of those bridges today, I’d make sure someone 100 years from now could reconstruct it in the exact same way, again.