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.

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.

Many commentators compare Drive with Dropbox and to some extent Microsoft's SkyDrive and Apple's iCloud. However, you should remember that you have many, many more choices.

On the face of it, most such services appear similar. They usually provide:

• Space for storing files (free up to a limit and then for-pay based on tiers)
• Syncing files with your various devices so you can access them on the move

However, once you move beyond the "mine is bigger than yours" debate, you will notice there are subtle differences among these services.

At a high level, I see four categories of services here:

1. Consumer oriented: Services like iCloud, Dropbox, and SugarSync are really focused on end users and have built some differentiating features. Dropbox, for example even has a Linux client and SugarSync allows you to sync any folder on your desktop and not just the one dedicated folder that most other services mandate.
    
2. File shares with document creation: Google Drive and Microsoft SkyDrive fall in this category. They are still focused on end consumers but allow more than just file sharing and storage. With Drive, you can edit and create documents using Google Docs, while with SkyDrive, you can access Microsoft Office WebApps.
    
3. Enterprise Focused: This category includes services like Box, Huddle, Oxygen, Citrix ShareFile, Glasscubes, Skydox and many others. These really focus on the enterprise segment. Box (like most others in this category) for example, provides granular controls for administrators to maintain access control for files and directories.
    
4. File shares with light collaboration: This category includes tools such as Alfresco and eXo which have traditionally focused on other enterprise needs (Alfresco does Document Management while eXo is a Portal platform), but have now started offering a cloud service that has some bit of file sharing. You could also consider SharePoint Online / Office365 in this camp.  These tools, however, typically lack advanced capabilities, such as file sync across devices.

Doubtless some of these services could be placed into multiple categories, and some will eventually evolve to provide services focused on more than one category.

But if you are an enterprise evaluating these sort of services for your needs, remember to look beyond the hype. Our forthcoming Cloud File Share evaluation research will look at such issues more closely and provide detailed evaluations of these vendors. Meanwhile, if you have any feedback on these categories, please feel free to contact me or leave a comment below.

To date, the native gamification functionality in Jive (even in the latest version 5.0) was very limited, with basic functionality you would expect in such tools going missing.

The Bunchball add-on is meant to plug such gaps, ideally increasing adoption and engagement of the social network. Users can be awarded points for different actions (e.g., comment on documents, write a blog, answer questions) they perform in the Jive-Bunchball powered social networks, with points getting tallied in different ways (leader boards, status levels).  In theory this is supposed to spur collaboration.

In our evaluation of Jive software in the Enterprise Collaboration and Social Software research stream, we note that Jive is known to OEM third party modules in its platform at a fast pace and swap them out at an even faster pace. Jive is sticking to the script. Much before the current announcement and as early as October 2011, a similar app "Nitro for Jive" had been available. Details and documentation are still scarce, but the new, new module seems to be the next version of the older app.

The jury may still be out on gamification and its merits, but enterprises looking to experiment should note that this is an optional module that costs extra license fees and most likely some custom development to work it into your applications.

It's also worth mentioning that similar Bunchball modules to gamify your social network are available for IBM Connections and Salesforce Chatter as well.

In other words, a predominantly micro-blogging oriented software without other collaboration oriented features / applications risks becoming a social ghetto. Yammer often becomes such a social silo today: employees can take notice of different conversations happening in the enterprise, but to act upon them and to get any meaningful work done, they have to shift to different applications / systems.  In short, easy to talk, harder to act.

Now, Yammer is taking baby steps towards enabling document-centric collaboration. It has acquired oneDrum, (a UK based company with less than 10 employees) for an application that lets multiple users edit Word, Excel, and PowerPoint files at the same time. According to a Techcrunch report, the oneDrum features will get added to Yammer in a few months time.  In theory the user experience for collaborative editing will go something like this: folders corresponding to your Yammer groups get created on your desktop and any edits you make to the files in the desktop will get synced to Yammer as well as your coworkers in those groups.

In this day of the cloud and GoogleDocs with their models of centrally hosted documents, a peer-to-peer fileshare model does feel a bit quaint. Certain questions about architecture, network capacity, security, and scalability also come to mind, but I'll hold them back until we see the product in action later this year.

Essentially, this acquisition signals Yammer's intent to break out of its silo and expand its footprint into the bigger world of enterprise collaboration, where documents, workflows, and business processes rule roost. That is already a crowded field with both

• Traditional collaboration vendors, who're busy applying fresh coats of social paint to their software
• Social platform / suite vendors, who also have a head start over Yammer in this respect

Only time will tell if Yammer can acquire new stripes and become a social software suite, but it won't be an easy transition.

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.

To that end, Google has won a handful of big deals, but in discussions with some larger early adopters, a hype cycle appears to be playing out:

1. Customer leadership gets excited about "Cloud"
2. They make a big splash by outsourcing key functionality to Google Apps
3. It turns out later that Google's approach doesn't always work well for the entire enterprise
4. Customer quietly dials back to core GMail offering, plus perhaps a few related Apps

This hasn't happened to every large Google Apps customer -- and other vendors frequently hype their wares too -- but it has repeated itself in several cases.

This hype cycle most recently played out with City of Los Angeles, who as it turns out received a $250k discount to help sway others that Google could sweep large enterprises. I missed some of the fall-out that transpired during the winter holidays, but the intrepid Mary Jander did not. Read her detailed exposé here.

Subscribers to our Enteprise Collaboration & Social vendor evalutions know that Google's critical early architectural assumptions have bequeathed Apps with a legacy of suitability for some small- and medium-sized business scenarios, but also made it less amenable to major enterprises.

To be sure, Google Apps could present a good fit for you, especially if you crave GMail. But don't just "go Google" in some quixotic attempt to cloudify your business or wipe your aging IT investments away in one swoop. Consider Google Apps like you would any other vendor's offering -- which means: test first, test broadly, and test competitively against other solutions. Let us know if we can help.

Those are important topics, but I think an even bigger to-do for enterprises is to bring the right skill sets to bear. One key skill set to engage here is enterprise architecture.

If you examine the individual applications and platforms that employees access to complete work every day, you end up charting myriad of different systems in the typical enterprise. Some of these may be loosely aggregated within a portal, while others may not. The digital workplace concept, though, helpfully turns the table around by looking at it from the standpoint of the employee, rather than the enterprise. There's clearly an opportunity to apply well-known user experience methodologies -- such as User Centered Design (UCD) -- to improve your colleagues' effectiveness here.

But as you dig deeper into the employee digital experience, you'll discover more than just clunky, freestanding applications. You'll find:

• Information and process flows that span multiple systems
• Siloed data and content
• COTS vendors pushing their own separate mobile apps
• Diverse security and information access needs

Cataloging and understanding the business value of all these systems is the job of an enterprise architect. If you are trying to transform your digital workplace, then you'd do well to engage your enterprise architecture team -- you have one, right? -- in reconstructing the pieces into a greater whole.

Just remember that the point is not to re-arrange boxes and arrows to work your way forward from back-end systems to employees, but rather to re-arrange what happens on your colleagues' screens by working your way backwards. Is it too simple to say, UCD + EA = New Digital Workplace ?

If you're an enterprise architect tackling some of these issues, I'd love to hear from you.

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...

I am conducting a free webinar this Wednesday that will help you make sense of different content technologies. In this webinar, I will look at the requirements for a range of scenarios while explaining the differences among web content management (WCM), document management (DM or ECM), portals, collaboration, and digital & media asset management (DAM & MAM) systems.

The webinar will be fast and informative. I invite you to join me. If you have questions that you want addressed in the webinar, please feel free to email me, leave a comment below, or tweet me.

Webinar details: 7 March 2012 at 12:00 noon EST (17:00 UTC).

Register for the webinar.

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.

The open source eXo portal platform  released their latest version 3.5 last week. eXo platform is a "portal-like" offering that we cover in our Portals and Content Integration report. It's based on the GateIn open source portal container that eXo co-developed with Red Hat JBoss.

You'll find a few new features in the latest release (e.g., a wiki module), an updated look and feel, as well as various functional improvements. However, as with so many vendors, the focus here is really on cloud and mobile.

First, mobile: eXo released mobile clients for Android and iOS devices. Fine.

The bigger story is around cloud. The new version of eXo supports multi-tenancy, and can be used by organizations to white-label as a service. eXo says they plan to offer their own cloud service later this year. Calling it User Experience Platform As a Service (UXPaaS), eXo will be offering it as "eXo Cloud Workspace" (currently in private beta). It's not clear yet if their partner JBoss will also provide that service or not. eXo could also end up competing with other vendors who chose to white-label it as their own service, which could get tricky for you the customer.

eXo claims to be the first "cloud ready" portal platform. That's only partially true because their cloud offering will not contain a full set of portal features. In the initial release, the cloud version only offers a subset, under the auspices of what it calls Social Intranet. That's not too bad, though, because it aggregates some useful services: a wiki, discussion forum, document libraries, and shared workspaces. You will also be able to do some development using eXo's web-based IDE. But the more advanced features of eXo's portal platform (such as web publishing) will not be available.

You may note a few similarities between what eXo has done and Alfresco's new release that I just blogged about (both of them, incidentally, are commercial open source platforms).

Both of their cloud offerings are expected to have similar features that include activity streams, dashboards, workspaces, document libraries, and a wiki. Both of them also follow a similar  membership model resembling that used by Yammer, based on your email domain. So for example, I can create a workspace based on adurga @ realstorygroup . com ID, and my colleagues can join that workspace.

The other interesting similarity comes in mobile offerings. Both have chosen to go with native apps and not HTML5-based web apps. They're concluding that for document- and collaboration-heavy scenarios, native still rules over web. Just remember that this strategy can run counter to enterprise bring-your-own-device policies.

While both vendors produce a different messaging, the products themselves contain overlapping features. So the lesson here is to look beyond the marketing hype and check out the real functionality (not to mention the vendor itself!). We will of course dig deeper to uncover the real customer experience, and provide more details in our reports and advisory papers.

But now Jive has IPO'ed, and customers have reasonable expectations about understanding where the company will go after transitioning beyond it's venture-fueled youth. Financial analysts seem to expect more of same regarding the company's stock price, but if you know us, then you know that we don't focus on that. What matters is vendor "fit" for you the software buyer.

And in that regard I think Jive's biggest challenges going forward will prove institutional. Jive's a "tweener" vendor: no longer small and agile, but lacking the huge resources to execute globally in way that, say, an IBM can. Moreover, Jive's offerings are divided among significantly different use-cases (external communities and internal collaboration), and delivery models (hosted and on-premise). Doubtless this diversifies revenue streams in  ways that appeal to equity markets, but is this strategy best for customers? I have my doubts. It's very hard to reconcile the inevitable codebase forks.

Meantime, customers have hinted to us that they wish Jive would invest more in refactoring the underlying platform itself. Jive's core, Java-based platform is rich and therefore complicated -- and thus prone to some of same problems that the big players experience. Case in point: readers of our evaluation report know that many Jive customers remain stuck on previous versions because extensive customization can make upgrades unusually fraught.

Of course, refactoring a codebase while maintaining backwards compatibility with a large, diverse installed base is an unusually complex undertaking for any vendor. But now that Jive has grown up, customers should reasonably expect them to be able to pull it off. It's where the question gets called of finding sufficient resources while also scratching Wall Street's quarterly itch. We'll keep watching, on your behalf.

Our subscribers will see several new vendors under review as well as an overhauled set of evaluation criteria. More about those in the coming weeks.

For now I'd like to share one of the big themes of the report: customer disappointment with major platform vendors.

Why? It turns out that business units want....ready-made business applications, not the promise of a development platform. And while major platform vendors (IBM, Microsoft, Oracle) can check numerous functional boxes for collaboration and social networking, they don't provide many polished applications out-of-the-box.

Some commentators have suggested that the real answer here lies in broader ecosystems, and I believe there's some truth to that. But "ecosystem" for platform vendors today primarily means armies of systems integrators willing to write one-off extensions to the base code, at no small fee. This becomes yet another dimension to the disappointment customers are sharing with us.

I'm not suggesting that an all best-of-breed approach is nirvana. To quote my colleague Kashyap from our media release yesterday:

To be sure, a mixed vendor strategy presents near-term challenges for enterprise systems architectures, as well as long-term challenges for business users, who may later confront splintered profiles and disconnected activity streams.

The good news is that, in this maturing Enterprise 2.0 marketplace, you have a wide array of plausible choices.

Subscribers can find the latest updates here. To download a free sample, click here.

We will provide more detailed guidance about these in a future advisory paper, but in the meantime, here are the key points to consider:

1. Which Devices to target: This obviously depends on your target audience and what constitutes a mobile device for you. While simple cell phones, PDAs, smartphones, and tablets are quite obvious, what may be less obvious are devices such as gaming consoles or even the good old television that can act as delivery channels in some contexts. In my previous organization, I worked on developing a strategy for a hospital that wanted to be able to stream patient data on a linux-based handheld device carried by docs. Even without going that deep into what constitutes a mobile device, at the very minimum, you will need to decide what kinds of phones and tablets you want to target. This includes both the form factor (or the size) and operating systems (iOS, Android, et.al.). We've discussed this issue in these blogs before:
   • Thinking Holistically Beyond the Smart Phone
   • Android Tablet or iPad
2. Mobile Apps, Web Apps, or Hybrids: There are many ways to develop applications and sites for mobile devices. So you'll need to decide whether you'll stick to browser-based web apps, create downloadable applications, or use both for different use cases. We provide some guidance on which option is suitable for specific use cases in our advisory paper Mobile-Enabling Enterprise Applications: Browser or Downloadable Apps? as well as number of blog posts like:
   • Different Ways for Building Mobile Apps
   • Mobile Apps are Dead. Long Live the Mobile Web
   • Mobile brings site-building tools back from the dead
   • Mobile - the Next Web CMS Frontier
   • DAM and mobile: should you go with a dedicated mobile app?
3. Existing tools or new ones: You probably already have numerous enterprise applications that  provide some sort of capabilities for building mobile applications or web sites. For example, many Document Management vendors provide device specific applications to access a subset of functionality provided by their tools. Similarly, for a mobile website, you could possibly use your existing Web Content Management (WCM) tool or a Portal tool. Alternatively, depending on your scenario, you could invest in a sophisticated mobile middleware framework:
   • Advisory: Adapting Your Content Management Platform for Mobile Delivery
   • Blog: An iPad for DM and RM?
   • Blog: FileNet P8 on your iPhone
4. Managing content for mobile site and related architectural Issues: Publishing a mobile site will raise additional issues related to content duplication, publishing, workflows, and presentation. So you will need to have a handle on technical issues such as:
   • Do you employ a separate repository for mobile content (and this duplicate content) or do you use a common content repository?
   • How do you publish content from your regular web production environment to mobile environment?
   • Do you repurpose or recreate content?
   • How do features such as in-context editing and rich text editors work for mobile websites?
5. What happens to existing websites and content:  You obviously would not want to throw away your existing site, especially if it was not developed a long ago. So it'll be important to understand how you'd reuse existing content or mobilize an existing website. There are many approaches and tools to do that but if you've followed some basic principals of content management -- such as separating your content from its presentation -- you should experience fewer problems here.

There are many more considerations -- such as information architecture and user experience in a mobile context, content migration, alternative development approaches, and so forth. Yet, addressing the key starter issues above will give you a good launch point in your mobile roadmap.

What has been your experience and what are the key issues you've faced? Please feel free to comment below, email or tweet me.

SharePoint licensees seeking to deliver on the promise of social networking and more advanced collaboration applications must therefore choose among three alternative approaches to close the gap:

1. Complement
2. Supplement
3. Extend

Each alternative carries specific benefits and demerits in terms of cost, time to market, long-term adaptability, mobile enablement, user experience, external access, and other dimensions. This recent briefing carefully examines the pros and cons to help you make the best decision.  It concludes with an analysis of a bonus fourth option -- do nothing and wait for SharePoint 2013 -- as well as a handy comparison chart to guide your decision-making.

It's available to our Collaboration and SharePoint research stream subscribers.  If you're not a subscriber, you can also purchase the briefing à la carte.

This is our sixth year in a row doing this humbling exercise. If you'd like to see how we've done previously, you can view past predictions here: 2011, 2010, 2009, 2008, and 2007.

Here's our 2012 technology predictions:

1. Big data meets web marketing
Digital marketing systems -- from analytics, to adaptive personalization, to social media monitoring platforms -- generate huge amounts of data. The ability to extract and leverage meaningful nuggets from these vast stores of information represents a persistent but increasingly important challenge for marketing specialists. 2012 will see specialist (typically SaaS...see below) vendors pull away from the pack of integrated WCM suites and other adjacent technologies that implement e-marketing functionality as a simple, add-on service.



2. Enterprise search marketplace opens up...again
The major vendors in this space are undergoing substantial transformation: FAST is getting sucked into the SharePoint vortex; Autonomy is facing an unclear future under HP; and Endeca remains fitful and distracted. Look for upstart vendors to fill the void as they did earlier this decade when the market was more open. In particular, look for specific applications based on the open source platform, Lucene.



3. Social services get called on the carpet in SharePoint
SharePoint has seen stratospheric, often viral growth in enterprises around the world. Licensees are beginning to discover, however, that its lack of contemporary social networking services and polished collaboration applications are limiting its effectiveness and driving business units to self-provision other tools. 2012 will see the rise of a variety of SharePoint-specific, supplementary offerings, from new and existing vendors alike.



4. CRM and CMS on a collision course
Customer Relationship Management (CRM) and Content Management Systems (CMS) have long been central pieces in the digital marketing toolkit; however the lines between these two systems will continue to blur in 2012. More and more, marketers want to set content and interaction experiences based on customer interaction, so CMS vendors continue to add CRM features, while CRM systems add more web publishing features. In the long run, we think integration is more promising than convergence; in the meantime, expect some messy collisions.

5. Death of the intranet as we know it
Intranet managers still have a key role to play in enterprise collaboration and information management, but employee expectations and the role of the intranet have changed dramatically over the past few years. Savvy companies will focus on the broader employee experience in a mobile, "digital workplace." 2012 will see a significant reallocation of resources from corporate communications to more business-oriented functionality.

6. BPM springs back to life
Process still matters, and workflow applications continue to dominate enterprise document and records management efforts. 2012 will see a renewed interest in good, old-fashioned BPM, as enterprises seek to orchestrate activities across organizational boundaries, including partner and supplier systems.

7. Rich media goes mainstream in the enterprise
Video is no longer an emerging technology for the enterprise. New social initiatives in particular will bring more media into internal systems. To be sure, a gulf remains in production quality (between professional and amateur), and employees will continue to look for increasingly sophisticated capabilities as both media producers and consumers. In 2012, enterprises will respond with specific, rich-media initiatives.

8. Big data blows into the cloud
More and more information management systems are generating or leveraging "big data." Yet, many enterprises don't have the resources, capacity, or expertise to properly store and mine this data. Fortunately, "big data" characteristics (such as unpredictable data inflow rates and the need for elastic processing capacity) make it a natural fit for the cloud. As a result, data-rich applications -- such as social media monitoring -- will increasingly go to market with SaaS-only delivery models.

9. Pervasive mobile-only apps
2011's mantra could have been "mobile first." 2012 will see "mobile first and last," as enterprises develop mobile-only interfaces to certain internal applications without focusing any effort on traditional, web-based (desktop/laptop) UIs. Many of these mobile apps will consist of specialized mashups among existing systems. A key driver here is the inexorable rise of tablets. We'll also see interesting examples where enterprises will tweak business processes to leverage tablets (e.g., in-store tablet catalogs).

10. New job titles emerge
Major technical and operational changes are driving new roles -- often informal, hybrid roles -- within the enterprise. 2012 will see the formalization of some of these roles into broadly recognized job titles. Samples include:

• Marketing Technologist - to master the increasingly complex services around e-marketing at scale
• Social Media Monitor - to interpret, understand, learn from, and respond to the fire hose of relevant activity on public social networks
• Enterprise Community Facilitator - to support localized community managers and foster productive cross-silo interaction
• Enterprise Media Producer - to produce or edit high volumes of video for internal and external consumption
• Director or VP of Digital Assets / Digital Media Manager - formal DAM roles emerge to establish ownership -- not just of assets, but of the systems and metadata -- of DAM and MAM

11. Security fears rise: phones, tablets, portable drives, the cloud -- where is our content?
Nearly everyone is a mobile worker. The proliferation of smartphones and tablets means that employees are walking around with disk drives containing company information. A lost or stolen phone or tablet containing sensitive information will likely cause a backlash in enterprise security departments. We've already heard of some highly regulated enterprises banning enterprise access from employee phones. For many employees, 2012 will bring even more rules and regulations around how they can use their mobile devices and renewed enterprise interest in digital rights management applications.

12. Lines blur between commercial and open source technologies
In the WCM and portal marketplaces, major open source projects are "commercializing" fairly rapidly, while many (though certainly not all) commercial vendors are adopting more open development and support models. This means that in 2012, customers will see increasingly less distinction between commercial vendors and "commercial open source" suppliers. The bigger gulf -- though it remains largely one of licensing -- is emerging between commercially-oriented open source projects and community-oriented projects across the WCM and portal landscapes.

Here is RSG's Alan Pelz-Sharpe to shed some more light on our predictions:

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.

Community venues are fast evolving. In the public sphere, the action has transitioned largely (though not completely) to public social networks, where innumerable sub-communities have emerged. Intra-enterprise investments, not surprisingly, have followed more slowly. However, we're seeing enterprises of all stripes paying greater attention to internal communities as key applications within the digital workplace.

But just what constitutes a community? And why is the answer important?

For starters, it's important to distinguish between a community versus simple interaction and feedback. If I comment on an article within my local newspaper website, am I joining a community? The newspaper might think so, but I don't, and it's my opinion as the poster that matters here. A community is something more than a collection of threaded comments -- however valuable those are in their own right -- and that "something more" is where added business value lies.

Intranet guru Jane McConnell defines communities as "Groups of people with a shared interest or practice, who communicate, exchange ideas, and collaborate." This is a great starting point, and I'll extend it with a short list of characteristics that I think make for a real community. If I'm missing some, please chime in with your comments.

Communities have explicit membership. Membership is more than just a login or even a profile, but a sense of belonging and commitment, which is much harder to define but extremely important. One sign of a real community is that members have actively annotated their profiles (with picture, interests, and so on). This in turn conveys obligations for community "owners" to understand members' commitment and manage accordingly -- i.e., with a deft hand that allows membership broad leeway to define where the community goes. By the way, for a great resource on this very issue, consult The Community Roundtable.

Members visit regularly, even without prompting. Members want to participate regularly, to see what the community is up to. Sure, signalling and alerts from the system are essential, and people will want to commune around useful new content, as well. Still, I find it interesting that on media and sports sites, readers will comment on new articles, but communities tend to form around particular stars or personas. Perhaps there are lessons here for internal enterprise communities.

Members have the ability and inclination to connect directly with each other. The nature of those connections will vary, and large communities need to account for a variety of different member-to-member interaction services. Member-to-member interaction separates true communities from workaday user generated content.

Note that I'm not suggesting that digital communities are the shining future of intranet and web interaction. There is a place for ad-hoc interactivity and many people simply don't want to join yet another community, either at work or outside work. The absence of a community does not mean you should forgo the possibility for pervasive interaction with you, the site owner.

Nevertheless, I believe communities are an increasingly important phenomenon, especially within enterprise firewalls. In fact, this phenomenon is one of the key reasons why savvier enterprises are reluctant to commit wholeheartedly to SharePoint (which famously lacks key community services), even as they leverage SharePoint's ample document-sharing and workflow services.

In any event, it's an area we are covering much more closely in our Enterprise Collaboration and Social Software vendor evaluations. And I'm still trying to better understand all the nuances. So keep those questions coming...

More importantly, by my count, this represents the fifth such Oracle announcement in ten years. The company cobbles together and re-brands various enterprise 2.0 offerings, but they never seem to pan out. This must be very frustrating for those of you who actually invested in one of the first four.

Sure, some enterprises will still try it. The tautological we-buy-Oracle-because-it's-Oracle customers still exist -- though they are getting scarcer, at least among our subscribers. If history is any predictor, they could find Oracle's latest offering a bit thin.

You see, Oracle has excellent software development capabilities when it choses to bring them to bear. Yet somehow, in the collaboration and social space, it has tended to favor marketing announcements over the kind of sustained commitment its enterprise customers require. Oracle execs will surely counter that "this time we really mean it." I'll believe it when customers start adopting Oracle Social Networking in droves because it's so good. A prudent enterprise will still let others skin their knees.

I'm not crowing here. Oracle's longterm abdication is mostly just sad -- not because I care about Oracle's success -- but because I believe the marketplace could benefit from a major competitor to SharePoint across all the functionality that Redmond's platform purports to do. If not Oracle, then who?

• Google? Focused too intently on the SMB marketplace
• IBM? Good stuff here and there, but divided and slow overall
• Open source? Promising in some areas but fragmented across technologies and platforms

To be sure, SharePoint has significant shortcomings in terms of social enterprise and collaboration services, there are a wealth of smaller alternatives, and this game is far from over. For Oracle customers, however, the question remains the same: is the company just upselling its WebCenter and database licensees, or delivering business services that can truly stand up to competitors on their own? We'll keep watching...

Luckily, intranet managers have another option. For the sixth year, NetJMC will be conducting their "Digital Workplace Trends Survey." Last year over 440 organizations from around the world participated and they all received a free copy of "Global Intranet Trends for 2011" (commercial value $750 US).

Interested candidates can apply to participate by sending an email to "info@digital-workplace-trends.com" with the information requested on this page:
http://www.digital-workplace-trends.com/sign-up-for-the-2011-12-intranet-trends-survey/join-the-survey

You can read what 2010 participants say about the report:
http://www.digital-workplace-trends.com/reviews-of-2010-report/reviews-by-intranet-managers

Key topics this year are:
    Mobile Strategies & Approaches
    Collaborative & Social Aspects
    Search
    Governance & Management
    Business Value
    Future Scenarios

There's a longstanding question about how effectively Big Blue can evolve Connections. Born as a collection of disparate services, the past few years have seen IBM trying to stabilize and integrate the platform, rather than really push it beyond the wide plethora of smaller competitors with more business-friendly offerings.

To be fair, the latest Connections dot-release provides a few more semi-finished social applications (e.g., for "ideation"). Contrast this with SharePoint, where -- at least until version-next in 2013 -- someone actually has to build social applications for you. Presumably, more Connections applications will be forthcoming.

As a customer investigating this marketplace, though, you should focus primarily on what Connections provides today, rather than dream about potential applications that may or may not pan out. This is a surprisingly complex platform -- and like most IBM software, it will cost you serious implementation multiples.

If you're curious to see more about our Enterprise Collaboration and Social Software comparative evaluations, you can download a sample excerpt.

Let's look at what's driving this. The last decade has seen continuous improvements to search technology. At least in theory, today's search engines can crawl more complex repositories, can handle many more documents, and run faster and more efficiently. All you need -- the story goes -- is the ability to convert search results to an RSS feed, build some kind of a simple widget-based environment that displays those feeds, and you are up and running with a functional portal application.

But don't stop there.  The same logic can also get extended to other web technologies. Search engines can act as replacement to traditional integration mechanisms since they can crawl multiple repositories. They can also handle more sophisticated applications such as e-discovery.  So, why invest in portal or portal-like technologies at all?

My advice: don't buy into this hype.

Before you decide to build a web or portal application that's driven by your search engine's index, first consider if that's the best approach to get at all types of information you want to display. You'll quickly find some inherent limitations.

For example, most search engines make certain assumptions and approximations in the way versions, security, and duplicates get handled. The security profile on the document might have changed after your search engine indexed it. Sure, you can take advantage of your search engine's "late-binding" security capabilities, but that only adds more overhead to processing time.

Moreover, in those cases where your application knows exactly what to get from the repository, using search indexes and queries adds even more overhead. "Showing 1 of 1" is hardly the best way to display the local temperature inside a weather gadget.

The point then is that a search-based query is not the most optimum way to access your back-end data for the typical diversity of enterprise portal scenarios. Before making a major platform decision, be sure to consider alternatives that could prove faster more accurate.