Products like Adobe LiveCycle help the automatic generation and dynamic delivery of personalized documents, usually for customer communications such as insurance quotes or e-bills sent by your telco. 

Adobe's LiveCycle's customers who wanted ECM capabilities had an option of using an embedded Alfresco repository. But now they will also be able to use Day's CRX as well as have tighter integration with Day's Digital Asset Management and Social Collaboration offerings. The announcement does not say anything about whether Alfresco will be replaced by CRX in LiveCycle, so if you are an existing customer of this offering, you'll need to wait and see what the implications may be. 

Existing Day customers may better benefit from the acquisition as they will likely be able to use some of Adobe's personalization capabilities (such as clickstream cloud) in conjunction with LiveCycle as well as have a tighter integration with Adobe's Flash, Flex and other technologies.

The deal will conclude in December 2010 and the FAQ mentions that the current management of Day will continue through 2011. But we recommend you ask for a detailed roadmap from your rep.

The deal also has a significance in terms of the general marketplace. For many organizations, the content lifecycle includes much more than what is "typically" considered part of ECM. In many cases, the end document (e.g., policy or bill) consists of some standard elements such as salutation and greetings along with elements that are specific to you. In the case of a policy, the specific elements could be based on your risk profile or legal terms based on your state or country of residence. In the case of a bill, these specific elements could be new tariff plans or campaigns based on your past history. In these examples, the organization needs to collect information (such as demographics), take it through a business process and then based on some rules, dynamically generate and publish the end result. 

We believe that all of these should be part of content lifecycle and that is the reason why in our ECM & Document Management Marketplace 2010, we've argued that features such as document assembly and dynamic publishing will get increased attention from mainstream ECM vendors in the future. Many other vendors that we cover in our ECM research, such as EMC (with Document Sciences),  HP (with Exstream), Oracle (with Documaker) already have offerings that strive to bring together these two aspects. We plan to include a separate section on Dynamic Publishing and review many such products in our next version of the ECM Report.

As for Adobe and Day, the question that nobody can answer at present is whether Adobe can really sell enterprise-grade customizable software. Their history of selling shrink-wrapped, lower-priced, high-volume software has built the firm into a Silicon Valley giant, but their ability to sell small-scale but very high-value enterprise software deals remains untested. The biggest danger for current Day customers may be that Adobe will want to take the technology, and over time commoditize it into shrink wrapped low-cost functionality bundles. But again, at this stage we can only speculate. And you as a buyer and user of the technology can do no more than act with extreme caution and ensure that any promises made by the Day and Adobe are solid and verifiable.

However, the greatest focus of this upgrade has been addition of a new "App Store" functionality that allows you to create enterprise-specific App Stores from where authorized users can download and apply applications for their own use.

JackBe's marketing would like you to believe that they are the first ones to bring this App Store concept -- popularized on the consumer side by Apple -- to the enterprise. However, they are not. Most Portal vendors we cover in our research already have some sort of catalog from where users can pick and choose components and assemble new pages or even applications. Among the Mashup vendors, IBM Mashup Center also offers a catalog for your users to search for, browse, categorize, rate, and tag components.

However, JackBe does deserve credit for bringing this functionality into focus. One of the key expectations of modern day enterprise software, including Portals and Mashup software is the ability to shorten time to market. This can be done if you are able to increase reuse rather than reinvent the wheel every time, which in turn means you need to have better facilities for managing reusable assets: the ability to share, search, tag and categorize, tracking the life cycle of those assets, measuring the effectiveness of reuse, and finally the ability to extend them and use them for use cases for which they were not built originally.

We cover the reuse aspect in a dedicated section in our research and have found that most products are not up to the mark here. Most of them are plagued by poor usability of their interfaces, inflexible nature of finding assets, and no ability to define a process for accepting a resuable asset. In most cases, even though you can pick a component from a catalog, there's very little you can do in terms of extending those components.

But make sure you test any mashup service -- including Presto and its new App Store --  for your scenario. Find out how easy is it to customize things such as modifying the process for adding components or creating a new category for your assets.

The platform has many new features such as:

• Plug-in based architecture allowing you to host multiple portal type applications or add on other components to your Portal infrastructure
• A complete new user interface that is based on the GateIn Portal. The UI is based on Groovy framework and replaces the existing JSF based interface
• It uses a different page model in which each page is stored in a Java Content Repository (based on eXo JCR)
• An in-built gadget container based on Apache's Shindig allowing you to host and run gadgets along with portlets
• Some of the other features are support for Right to Left (RTL) languages, a new identity manager, and a cache implementation

Many of these features above are not just enhancements but completely new development efforts. While it is called EPP 5 and targeted as a next release of their existing EPP 4.x, remember that it is really a new product for all practical purposes. We describe some of the platform's other demerits in our Portals and Content Integration evaluation research.

Along with updates to the individual portal vendor evaluations, we have expanded the scope of our research to include a new category of related solutions that enable you to integrate and aggregate content from multiple sources. While these are not as feature rich as Portal products, they do enable you to create "Portal-like" applications for certain use cases that require mashing up content from other data sources. Such lightweight content integration services often work with other simpler presentation technologies such as gadgets to create such applications.

The new name of our research stream, "Portals and Content Integration" reflects this.

In this release, we add evaluations of four new solutions: WSO2 Mashup Server, IBM Mashup Center, Kapow Web Data Server and JackBe Presto.

As always, our subscribers receive immediate access to the updates.  Curious? You can also download a free sample here.

In our recently released advisory paper, we explain the key considerations when delivering content and services to mobile visitors. Based on these considerations, we've also proposed three broad alternative approaches, depending on how finely-grained targeting your require.

Here's the table of contents of the advisory paper Adapting Your Content Management Platform for Mobile Delivery:

• Key Takeaways
• Introduction
• Key Considerations
  • Adapting Your Publishing Model: Pages vs. Components
  • Adapting for Device-Specific Capabilities and Limitations
  • Adapting Your Content to a Specific Device
  • Adapting Your Templates for Mobile
  • Adapting to Place, with Location-Based Services (LBS)
  • Adapting Your Services
  • Adapting Your Media Assets with Proper Formats
  • Content Aggregation
  • Adapting Your Content Production for Mobile Contributors
  • Setting Policies
• Conclusion

The advisory briefing is available to subscribers of our Web CMS, Collaboration & Community, Portals, and Web Analytics streams.

This is an accurate visualization in many cases.  Yet it's important to remember there are really two different pieces here: One is related to back-end content integration and the ability to access content from multiple sources, while the other is related to the presentation layer and displaying content.

A Mashup is about content and data integration. While there are many ways of integrating content, Mashup products try to make it easier, especially if the external source exposes content in web-friendly ways such as RSS feeds, REST calls, or formal Web Services. Once you establish a base connection to the external source, these products also provide a designer (usually visual) to model how content will flow, along with the ability to transform, manipulate, filter, and extract stuff from these feeds. You can also join multiple feeds and manipulate them.

The result is then published as yet another Web Service or RSS feed. You can now take this feed and display it via your Portal or another application.

You can then use Gadgets to display these feeds.

Where things can get interesting is when you employ a Gadget to aggregate content from multiple sources to create a composite application. Some Gadget products provide you a client-based event framework where one Gadget can communicate with another (such as when you enter an address in one window and it shows that address in Yahoo maps in another window).  But other than that there's no real mashing up happening here.

As you can see, there's some degree of overlap between the two categories of tools. Mashup tools provide support for these presentation components using some sort of Gadget-like technology and on the other hand, Gadget tools provide a way to wire together Gadgets using an event framework. While some people call this behavior "client-side Mashups," we consider Mashup services as quite distinct from Gadget capabilities. And so should you, regardless of what your vendor tells you.

We will be reviewing the major Mashup platforms in our forthcoming update to the Portals research.

For an open source project, that's a lot of time between two versions. There have also been concerns raised about transparency and governance within Open Source Matters (OSM), the not-for-profit that manages the Joomla! project. However, with a new leadership team and much awaited release of Joomla 1.6, things seem to be back on track for the project.

First, the good things. The new release has made numerous improvements, many of which are subtle - enhancements to extensions manager, new templates out-of-the-box, newly written menu system, general refactoring, and performance improvements, among others.

However, some bigger changes - about which we have detailed in our WCM research before -- and the ones that add some enterprise capabilities to Joomla are:

1. New Access Control System: In Joomla 1.5, you had fixed Groups, fixed access levels, and a fixed relationship between Groups and Access Levels. A user could only be assigned to one Group. Version 1.6 changes all that - you can have any number of Groups, Access Levels and can assign your users to multiple groups. There are also changes to how permissions work and in particular, the way you can inherit permissions and have a hierarchy could be very useful for more advanced scenarios.
2. No more Sections: In Joomla 1.5, the way to categorize content was based on Category and Sections. 1.6 does away with Sections but you can have a category tree - as deep as you want to organize your content. However, the old limitation that one article can only belong to one category still remains.
3. Form API: A new form API allows developers to customize the forms that makeup the back-end. So now you can have your own custom fields in forms such as the content entry form. While this in no way comes close to the ability to define custom content types (such as those in Drupal using CCK), it does make it easy for an extension developer to create an extension that allows you to customize your content entry screens.

And now the not so good things. If you are currently running Joomla 1.5, now is the time to start thinking of implications and things that you need to plan for. Consider the following changes:

• Joomla 1.5 supported a legacy mode that allowed you to run extensions written for older versions. This will no longer be supported and you will need to ensure all your extensions support the new version. So start pushing the individual extension developers to make sure the extensions are upgraded.
• Joomla 1.6 requires considerably higher resources in terms of PHP and MySQL. So make sure your host supports the new requirements
• While having nested categories is a good addition, the fact that there will be no sections means the URLs will have to undergo a change. There might be implications on your SEO initiatives and general content migration issues.
• The new ACL and Security system allows for a very fine grained access control mechanism. But with flexibility comes complexity and you will need to invest significant efforts to plan how you would want to structure who can view what. And if you are an Joomla 1.5 and want to take advantage of the new access control mechanism, you will need to map your existing users/roles to the new ones in Joomla 1.6 and this could again have an impact on your migration planning

So while the new release does add a lot of new features, make sure you plan well in advance, especially if you are dependent on third party developers for extensions or have a lot of content to migrate.

Perhaps more generally, this release takes Joomla! more in the direction of enterprisey use-cases.  However, to the extent that it doesn't quite get there on several fronts -- and yet has become more complicated -- Joomla! risks becoming a kind of uncomfortable middle for you: no longer the simple product its many adherents love, but not quite durable enough for most larger organizational scenarios. 

We cover more details about this as well as about the forthcoming releases of other Open Source products including eXo, JBoss and GateIn in our regular updates to the Portals and WCM evaluation research.

To quote from the article,

Most businesses assume that compliance costs money and does not improve their bottom line. Because of this, there is often a reluctance to invest in compliance initiatives. While it is indeed true that it does cost money, you should also remember that by being compliant, you can improve your processes, make you business not only more agile, but also more consistent. So despite the initial pain, compliance initiatives can make a positive impact to your bottom line as well as top line. Companies here in India sadly tend to lag behind their global counterparts when it comes to implementing compliance initiatives. However, to be more competitive, they will have no choice in the future but to invest in compliance.

With the Satyam and IPL scandals rocking India, there couldn't be a better time to think about Compliance. As for how ECM technologies can provide a platform for  your compliance-related initiatives, maybe we can help...

Most organizations do not undertake a migration effort with the rigor and discipline that they normally would for a software project. The result is often a failed migration. You should treat a content migration project like any other major software project in terms of execution. What this means is that you should deploy a proper methodology for implementing migrations.

A typical software development methodology has the following phases at a high level:

• Analysis
• Design
• Implementation
• Testing
• Deployment

The following table maps the activities that you carry out in a software development phase with the activities that should be carried out for a migration project. Remember though that depending on your chosen methodology, there may often be some overlap of activities between different project phases. As an example, a prototype or a PoC will usually start in the Design phase but will continue even in the implementation phase. Also, the table does not map all the possible activities but only high level ones in an attempt to map them with a formal SDLC.

Depending on whether you use Waterfall, Iterative, RUP, Agile or some other methodology, there will be variations in the way you carry out some of the migration activities. However, the point is that you should treat content migration just like you would treat any other project and give it the respect it deserves.

The last few weeks has seen a drama, albeit not a Bollywood one, unfold. It all started when the IPL chairman cum commissioner Mr. Modi fired the first salvo on Twitter about a new IPL franchise which was being "mentored" by a ruling party MP. The MP, Mr.Tharoor, quickly tweeted back to start a scandal now being called by various names such as IPL-Gate, Modi-Gate, and Tharoor-Gate. An alert media was quick to latch onto it and generate breaking news, eventually revealing much more than the shenanigans of Modi and Tharoor.

We next saw the two protagonists leaving their coveted positions: Tharoor resigning on an emotional note in the Parliament and Modi being suspended -- ironically via e-mail -- by IPL's governing council.

This is certainly good news for Twitter: people in India who have no clue of the web now want to tweet. But what has this got to do with Content Management?

Well, the IPL scandal that's rocking the Indian Parliament and cricketing world revolves essentially around the issue of compliance. Let us examine how many of the problems could have been avoided had the IPL followed good compliance practices.

And what constitutes good compliance practices? We offer a short online course that lays them out. Let's review some important compliance considerations in the context of this scandal:

1. Executive sponsorship: IPL is a sub-committee of Board of Control for Cricket in India (BCCI). On the face of it, IPL had it's own CEO, Chairman, as well as a Governing Council (GC) of 12 members. So it appears there was a suitable level of top management support. However, it now turns out that the CEO was just a figurehead with most of the decisions being taken by a proxy. The BCCI and the GC assumed that the CEO would do his job and were caught wrong-footed.
2. Well defined governance procedures: Okay, so they created a governing council (GC). The GC boasts eminent members, including well respected cricketers, politicians, and administrators -- but all without any accountability. And just like the CEO, the GC remained a silent spectator to all the wrongdoing, never consulted on important matters. In fact, the GC members remained unaware of major transactions involving billions of dollars, since all of these were handled by just one single person. No procedures existed to ensure the placement of suitable checks and balances.
3. Identified (and prioritized) compliance requirements: What's that? Since everyone involved was making big money, no one in their wildest dreams thought they'd need to comply with legal and ethical rules. The current scandal have revealed (among other things): inconsistencies in shareholding patterns, bid and contract documents gone missing, and some suspect funding sources. No processes were defined to approve contract documents or to keep an audit trail of transactions.
4. Ability to manage change as a result new business processes: Processes were non-existent and every activity was handled in an ad-hoc manner, depending on whims and fancies of individuals.
5. Systems to monitor, audit, and enforce compliance: There were no systems and more importantly no desire to enforce compliance. Everyone was in for the love of money, not for the love of the game
6. Right tools – such as those for managing content and records – to optimize your compliance efforts: The parent body, BCCI is the richest sports body in India and also the richest cricket board in the world. One would assume that a cash-rich cricket board would invest in technology that would help them in managing records and documents, enabling processes for tracking bids and contracts and other dealings. Yet, the BCCI doesn't even have a decent web presence. Use of technology could have facilitated transparency, something they evidently wanted to avoid.

Will applying proper Content Management practices and following the steps above in and of themselves enable organizations to avoid tax evasion, illegal betting, bribes, suspect shareholding patterns and so forth? Of course not. If you have people of questionable integrity and ethics running an organization, no amount of management practices will help.

Nevertheless, technology can help uncover and document misdeeds. If IPL had followed basic compliance principles, things would not have gotten so far out of hand. And we would have enjoyed our greatest passions - cricket and bollywood -- even more.

(Special thanks to Siddharth Gongala for supplying background info. Sid is a Sports Producer for an online channel.)

Both these applications run on FatWire's Content Server platform that we cover in our Web Content Management research. Although FatWire claims you can deploy these products independently, I am skeptical of the value proposition of running them independently even if it were possible. Both these products tie into Content Server via FatWire's "WEM" -- not the marketing acronym that is getting popular these days -- but an integration framework the company released sometime back. This framework essentially allows you to create applications on top of Content Server and provides features like single sign-on, unified interface, and a single administration window. Just like Drupal, FatWire wants to target those social use cases that are driven largely by content.

However, don't assume that adding a new product such as Community Server onto your Content Server installation will in itself convert your existing application to a community platform. Technical and functional considerations might require you redesign your application. In our WCM evaluation research we lay out some important architectural options and considerations for managing user-generated content (hint: neither FatWire nor Drupal's approach is ideal).

FatWire's Gadget Server is based on Apache's Shindig project. It allows you to create gadgets based on Google's Open Social standard. Your site visitors then can pick and choose the gadgets they want and personalize their interface. As of now, there are only a few gadgets available out-of-the-box, and the percentage of visitors who will actively modify page functionality or layout tends to be very low.

Perhaps more usefully, the new module now provides an additional delivery channel to FatWire content because you can embed an Open Social gadget on any web page, including those not driven by FatWire, and therefore more easily distribute content.

Nevertheless, you may be disappointed to learn that these gadgets are only for site visitor related functionality and not for editorial functionality, at a time when many competitors are employing gadgets to offer different content contributors the exact functionality they need, in lieu of struggling with one complex interface that everyone uses.

In any case, just like with Community Server, consider architectural implications carefully before deciding whether you want a completely gadget-based front end or a hybrid front end where only some functionality gets driven by gadgets.

Frankly speaking, the new features offered by these products are not very complex to implement. You could always create a new asset type, such as "comment," and associate it with another asset type such as "news" to achieve the desired functionality. In fact, FatWire has been offering a separate Blog module, free of cost, for some time. What's more important in my view is the the new administrative and configuration capabilities to manage these modules from a familiar interface. You can also take advantage of some of Content Server's scalability and integration services with these new products.

Overall, both the new products provide a useful set of features. With Community Server, FatWire is probably playing catch-up, since this functionality has been offered by many other products for some time. With Gadget Server, FatWire becomes one of the very few vendors to offer in-built gadget services that allow you to run third-party Open Social Gadgets on your infrastructure.

We're working on a deeper critique of these two new modules for our regular Web CMS updates to our subscribers.

Let's consider an example. You need to display a list of all new auto insurance claims to an agent. It's a fairly trivial task to do this with a gadget utilizing an RSS feed of new claims that displays using a colorful tabular format. A vendor might claim that most business users understand RSS and could create such a gadget.

However, someone actually needs to create that feed in the first place. And that is by no means trivial, because you will need to create integrations to one or more back-end systems such as a customer information system, policy management system, a customer correspondence system, and a document management system. When you integrate with these back-end systems, you will also need to consider all standard application development needs -- such as transactions, exception handling, scalability, logging, and so forth. This may in turn require the development of new service interfaces.  Plenty of code to write.

Second, I am not convinced that most business users understand feeds in a way that's required to create these applications. Even if we assume they are, you will probably need to filter or extract the right information out of the feed, and I don't think it's likely that your business users will understand the complex regular expressions needed to do that.

So before you choose to use something that promises "increased productivity" because of "zero coding" always consider the whole application and not just the functionality required for displaying feeds. It is possible that for your use cases, such a solution would be a good fit. But if a no code front end solution needs huge amounts of application development effort, you should be prepared for that as well.

We covered several such issues in our recent advisory and will continue to expand these in our Portals and Content Integration research.  In the meantime, remember that "simple to use" seldom is...

Should you consider Mashup offerings for building Portal-like applications?  And if so, when?

We examine these and other related questions in our latest advisory, "Complementing Portals with Enterprise Mashups." Our Portals stream research subscribers can download the paper, as well as comment or ask questions directly on the page, after logging in. 

We will also be expanding our Portals research to include more of such content integration and aggregation mechanisms as Mashups and Gadgets. If you're a technology buyer, feel free to let us know if there's something important you think we should cover. You can leave a comment below or if you are a subscriber, you can also provide input via private discussion forums.

In other words, it's been useful -- if something of a hidden gem.

Click to enlarge

Here at the Real Story Group we have also used it with our customers. As an example, see the picture above that shows how we applied it to help track the progress of a client over the course of a year.

We found that this type of visualization is a great way to quickly spot which areas need maximum attention and  you can then easily prioritize your efforts.

Do you have any experiences with the model to share? We'd love to know your story and/or any feedback. Some anecdotal feedback we have received has been quite amazing, with some of the world's largest public organizations making use of it. And that is the whole point of us releasing it under community commons:  You can adapt it and adopt it, you can do what you will.

As my colleague, Jarrod mentioned in his post, we are working presently to update the model, incorporating community feedback. Truth be told we are rather overdue here, but it a voluntary effort and we have had other fish to fry, such as launching the Real Story Group!

Going forward, we also plan to add some tool-kits to the model. The tool-kits will include questionnaires and templates that provide you with a starting point to translate the model theory into practice. But we welcome your participation to make this a truly community driven initiative. So, watch this space -- and let us know your experiences with the ECM3 Maturity Model.

A web-based IDE features a browser-based code development environment in lieu of a thick client on your developer machine. Many CMS tools have attempted before to offer such web-based IDEs and some of them are quite good. Others are just text fields to dump managed code that you wrote offline. Plone is a good example of the latter, and it bothers developers for obvious reasons, though some just use automated WebDAV to synch code. Some, like CrownPeak evolved into almost full-blown browser IDEs, but tellingly, most vendors stepped back from them in favor of plug-ins for traditional IDEs like Visual Studio.

One of the big reasons those vendors walked away from web-based environments was that development teams also had separate SCM tools and repositories that they wanted to use, which offered the extra value of reporting, auditing, cross-project management and code-sharing, metadata, and perhaps links to ancillary testing and security tools

However, a new breed of online IDEs is yet again becoming popular. In fact, there are two categories of such IDEs:

• Vendor Specific IDE: Such an IDE is often exposed as a widget or a portlet and can be added to a page in that particular product's management or admin interface. It is something more than a text box, and allows you to dispense with your own local developer instances of a database and application server, because you are accessing your product's instance of those in a test environment. Both Day CQ5 and GateIn Project (and consequently JBoss and eXo Platform) offer such a web-based IDE.
   
• General Purpose IDE: A more general-purpose web application that simulates an IDE such as Eclipse or Visual Studio, or is a web-based version of one of those. It is not tied to a single vendor and binds the web interface of the IDE to a server instance. There have been some initiatives from Mozilla and Eclipse, both of whom provide an experimental browser-based IDE.

(There's also an emerging third category in which a complete development environment can be based off a private or public cloud, but that's a separate blog post.)

I see several advantages to using a web-based IDE:

• You don't need to install anything on your local developer workstation. This in itself is a huge advantage in terms of reduced hardware costs and management overhead of ensuring everyone has the latest version and patches. Consequently, you can make code changes from anywhere, using any machine.
   
• You can collaborate with another developer on the same code block. Two or more developers making simultaneous changes to the same code file could be rare but it certainly provides a good mechanism while debugging or code reviews.
   
• It can facilitate quick and dirty updates, without having to fire up a slew of local services, compilers, etc.

In spite of these advantages, don't rush to retire your development environments just yet. There are still obvious drawbacks:

• Web based IDEs don't yet compare favorably to their desktop-based counterparts when it comes to features like debugging and integration with other tools that you might require for source control and builds
   
• Web-based environments often prove sufficient to write simple code using JavaScript, HTML, CSS, XML, and Groovy, there is still a long way to go before they can be used for more involved server-side development
   
• Sometimes, you actually need processes to ensure quality of code and making changes directly on a dev server might not make sense
   
• The environment may not have sufficient tools to deploy to a clustered, load balanced environment with multiple instances of an application

I'm sure you could list many more advantages as well as drawbacks, but the fact remains that  web-based IDEs are maturing and will become increasingly useful. But for now, when your vendor pushes their slick new code editor, think of it only as an add-on that is useful for creating Gadget/Widget-based applications, and not something that will change core enterprise development practices....yet.

The announcement does corroborate a few things that we've been saying for a while. The first one is that EMC seems to have accepted what our subscribers knew already - that  WCM is a different domain and Documentum's toolset  doesn't compare favorably with competitors. So they've decided to replace their Web Publisher with FatWire's Content Server.  Secondly, this also shows that  "an overarching approach to managing all forms of content" is not something that most customers want or need.

It does change market dynamics a bit. There will be one player less in your short-lists and the quadrants will be less crowded. It also probably means more business for both vendors and indeed makes a lot of sense for them as both vendors get to extend their offerings.

But what about customers?

I am not sure if it will make too much of a positive difference to customers. After all, both of these are completely different product stacks with different content models, different architectures, publishing, workflows, and such. That will not change easily. In the best case scenario, what might happen is that FatWire's existing Documentum connector (which is part of its content integration platform) will be improved to offer better bi-directional integration.  Currently, the Documentum connector allows you to surface Documentum content via FatWire but not the other way round. When and if they make the connecter bi-directional, you will be able to archive your FatWire content in Documentum for compliance or e-discovery.

Let's look at some of the possibilities:

1. If you are an existing FatWire customer, FatWire sales folks are probably going to try and cross sell some of the EMC products to you.  There is  some level of integration between FatWire Content Server and EMC's DAM products that FatWire will resell but they are still very different products. You should consider these products purely based on your requirements and not just because of this partnership. Check out this post by my colleague Kas Thomas on what it means for DAM customers.
2. If you are an existing EMC customer and use Web Publisher, you will probably be most impacted. EMC will not be putting new resources on Web Publisher and so you will need to migrate to...some alternative. Migration is never easy and just defaulting to FatWire is really a rebuild. You'd have to map your Documentum content model to FatWire's asset model and rewrite your delivery tier from scratch.
3. If you are an existing EMC customer and need WCM, you can probably negotiate a better deal with EMC for FatWire licenses. However, unless you have a solid reason to have some integration between FatWire and Documentum,  you should remember that EMC is only reselling FatWire and that it is essentially a non-EMC product. So you should evaluate other WCM products as well, especially if your WCM needs are lighterweight. In any case, the upcoming CMIS standard will make it easy to integrate Documentum with other WCM products

Similar re-seller deals have happened in the past -- and typically not amounted to much. In this case, EMC has also acquired a "significant but non controlling" stake. It's a little odd that EMC did not go for an outright acquisition but we don't know the exact terms of EMC's investments. Perhaps, just like trial versions of software,  they will use this as an opportunity to evaluate each other? We'll be sharing all the important details with our CMS research subscribers.

As subscribers to our Portals research know, the eXo JCR is a part of the GateIn project that forms the basis of future portal platforms from both eXo and JBoss. So if your IT landscape has a heterogeneous environment that includes these products, then this could be good news for your IT director, as xCMIS will in theory at least make it easier for both JBoss and eXo to co-exist with other products. 

However, remember that in such situations, CMIS will be much more useful if you are actually using either of them (eXo or JBoss) as a content repository, something that is not very common given that both these products typically sell as portal platforms. The other alternative is to use xCMIS directly as a content repository in your environment and expose the stored content via another portal using CMIS.

While it is too early to say how good the xCMIS implementation is (CMIS itself is not yet a ratified standard), it is a small bit of good news for CMIS proponents, since standards depend on popularity to drive adoption. 

Enterprises have traditionally used portal technology to aggregate content and functionality from different applications. In that sense, portals have typically been consumers of services.

Nevertheless, despite what vendors may tell you, it's very rare that a single portal instance becomes the only place where you access all your enterprise information.  Most enterprises support multiple portals (or delivery environments) in an organization, and so a single portal server becomes just one component of the enterprise technology landscape.

This means that any portal must not only consume services but also expose its own services in a manner that other components of your enterprise architecture can consume.

Why would you want to do that? Well, many enterprise portal software products have services or functionality that could work well across your enterprise (i.e., not just within the portal). As an example, you might want to use a portal's in-built search engine to be able to index your Web CMS or you might want to use your portal's wiki services more broadly across your intranet.

Of course there may be licensing implications here, but in general you get the idea: de-coupling a portal service so that you can "white label" it or extend its functionality to suit a different environment.

How do you do this?  For starters, you can choose among many standard integration mechanisms to integrate portal services with other applications.  Among others, you can use Web Services, iFrames, Web Clipping, directly access a Portal's data source, or employ an Enterprise Service Bus (ESB) to access the relevant functionality. All of these have their drawbacks and are typically very complex to implement, especially if you want to access a "service" rather than just a "page."

Other approaches are potentially promising.  The Oasis standard, Web Services for Remote Portlets (WSRP), provides a mechanism to expose portlets to other delivery engines. However, while many portal tools can consume WSRP, they do not often comply with WSRP for exposing their own functionality.

Some portal products now expose their services using simpler mechanisms like REST-based APIs, which provide a URI-based way to access a specific feature or subset of a functionality For example, you could obtain a list of top 10 blog posts using a URL from a portal's built-in blogging engine.

The other alternative that some vendors have implemented is the ability to expose every portlet as a "gadget" that you can then include in another web page using simple JavaScript.

As you can see, there are many ways of exposing a Portal's functionality and I'll not go into all the details in a short blog post. Obviously you face trade-offs, as some of these approaches are more complex than others, while some are more presentation-oriented than others.

So if you're evaluating portal products, make sure to understand how the product exposes its services and not just how it consumes services from other applications. We delve into the pros and cons of these different approaches -- and how each vendor covers them -- in our Portals research.

Last week we released some significant updates to our Enterprise Portals Research. The latest research reflects significant changes among new versions of several portal platforms, as well as additional details for all the products we cover.

Our research found the market in a particularly unusual state. Buyers should exercise particular caution as many portal software vendors are significantly updating their software. You can read more about the market’s state of limbo in the press release. As our Cross-Check below illustrates, IBM, Oracle, and Microsoft, along with open source options, are all at an overhaul and refresh stage.

Click to enlarge

IT Executives who are procuring a new portal solution typically do not want to be the first to deploy brand new software. Rather, they prefer a product that has somewhat matured. With so many major vendors in transition, the market has entered a kind of limbo phase.

Our research also found a healthy open source market (almost half of the portal products we cover are open source).  We also track some new technical developments, such as whether and how different portal tools integrate with other applications as both consumers and producers of services. If you are not currently a subscriber, you can download a free sample here.

While Steve Jobs was introducing Apple's iPad, Oracle was explaining its own approach to hybrid hardware/software offerings. Oracle yesterday announced that it has completed its acquisition of Sun Microsystems. Oracle now provides a complete stack consisting of Storage, Server Hardware, Operating Systems (Linux and Solaris), Database (Oracle and MySQL), Middleware (Fusion), Programing Language (Java), and Applications.

In general across the Java and Middleware areas, other than Java, most incumbent Oracle offerings will remain "strategic," whereas their counterparts from Sun will be merely supported. Here's a quick take on some of the announcements that might impact content technology users:

• Oracle will keep investing in Java and plans to unify J2ME (for mobile) and J2SE. Currently it is not easily possible to create applications in Java that will run uniformly on computers and mobile devices. So this will help take Java closer to the "write once, run anywhere" promise.  Oracle also plans to include support for IPTV and Blueray devices in Java.
• On the application server front, Oracle will share some technology pieces between WebLogic and Glassfish. Oracle WebLogic continues as the strategic application server platform and Sun's Glassfish will serve as the reference implementation for "tactical applications." Similarly, Sun's NetBeans will focus on "lightweight development," whereas Oracle's JDeveloper will be Oracle's IDE of choice for enterprise application development.
• As expected, Oracle's WebCenter Suite (we cover it in our Enterprise Portals Research) will remain the company's strategic Portal offering. Sun had previously announced a partnership with Liferay for their own version of Portal (called Sun Glassfish Webspace Server) based on Liferay's codebase. Oracle says it will continue to maintain that initiative and contribute  extensions back to the community.
• Oracle will also retain Open Office and come up with a web-based office suite. There is obvious potential to integrate with Oracle's Content Management suite here.
• MySQL will become part of a separate Open Source business unit within Oracle. The company discussed plans for some integration between the Oracle database and MySQL, probably in the area of management services.

These announcements did not hold any big surprises. Oracle's approach is edging closer to "everything in a box," something I mentioned on my personal blog last year.  From Oracle's perspective, it gives them an opportunity to align  engineering efforts to make their middleware perform optimally on their hardware and OS.

For customers, it could work both ways -- depending on your exposure to Oracle. On the one hand, you only have to deal with one vendor for support of your entire IT landscape.  But on the other hand, by hedging all your bets on one vendor, you're increasing vendor lock-in.

In his address, Thomas Kurian of Oracle mentioned "...our middleware strategy has been simple and clear..."  Well, if by "simple" Oracle means they will support every acquired product, resulting in a potpourri of applications, it is indeed straightforward.  For customers, the line between "supported" and "promoted and enhanced" is quite important.

As with every acquisitive vendor, Oracle is talking a lot about interoperability among its various components. In fact, Oracle says it will spend $4.3 Billion on R&D in the first year to try to make sure the complete stack delivers. We will be watching, and sharing key advice with our research customers.

Both Red Hat and eXo will use GateIn in their respective offerings.  Just to clear some confusion, Red Hat's commercially supported Portal product is called JBoss Enterprise Portal Platform (EPP). EPP has many other components like the Portal CMS module, Enterprise Application Platform (EAP), Identity Module, and the JBoss Portal Project. It is this last Portal Project component that will get replaced by a version of GateIn project in the next version of EPP (version 5). EPP 5, which is slated to be released by May 2010, will also use eXo JCR (an implementation of JSR 170 by eXo), and will also later integrate eXo's Web Content Management.

Similarly, eXo Platform will replace eXo Portal with GateIn project and will eventually certify all their other components to work with GateIn (and EPP).  This means that all their applications like eXo Social, eXo Collaboration, and so forth will use GateIn as the Portal runtime instead of the existing eXo Portal.

So what's the big deal?

There are a couple of reasons that make this interesting. GateIn is not just a low-level framework like Struts or even a simple Portlet container, but a complete portal runtime, complete with bells and whistles getting reused across two platforms. The portal is now slowly becoming one component of an overall platform and in that sense getting "commoditized."  The partnership between Sun and Liferay under which Sun was planning to use Liferay's Portal Server for their own version of Portal was another example. With Oracle acquiring Sun though, the future of that initiative is not clear.

If base portal functionality is becoming a commodity, how do vendors differentiate? (That's a question many people ask when talking about standards as well.) Well, one way they differentiate is by building around the common component (or standard in case of discussion around that). In this case, JBoss differentiates by bringing in its middleware expertise and tighter integration with JBoss infrastructure, whereas eXo differentiates by building applications on top of this platform.

Finally, as I mentioned on twitter, this is a rather unique situation that has an impact on both vendors (and hence their customers). Red Hat for its part has committed to support its existing platform for five years (four more to go now) but the fact remains that they will not be doing any new development (apart from upgrading the Portlet Bridge) on JBoss Portal (the project) as Red Hat focuses on GateIn. Remember, GateIn is quite different from JBoss Portal and so for existing JBoss Portal customers its means a migration effort or committing to a legacy platform that will not see any new advancement.

So if you are evaluating Portal platforms, keep this in mind and make sure you understand clearly the respective vendors' road maps and how they align with your requirements. We cover more details in our Portals evaluation research.

From multiple vendors using the same portal as a component to one vendor offering multiple different portals, these are interesting times for the portal marketplace...

Not all vendors offer in-context editing, and many do so only partially.  You can find more about different vendors' support for in-context editing in our Web CMS Report.

To be sure, many products have allowed you perform in-context editing for some time now. However, the difference is that in the past, clicking on "edit" in the site would open up the back-end form, whereas now, you can typically make in-place changes right on the page.

From the point of view of usability and convenience, this is certainly useful. In fact, I see in-page editing actually becoming a "preferred content contributor interface" rather than just a "casual business user content contributor interface" of yesteryear.

The main problem I have with this approach, if used exclusively as recommended by some vendors, is that it goes against a basic tenet of Content Management -- to separate content from its presentation. Basically when you create content based on how it looks, you tend to think about only those fields that appear on that specific page. Consider the implications:

• What happens to those extra fields that do not appear but exist because of other reasons - administration, reporting, analytics, personalization, search and so on? They would either take default values or be ignored. Or perhaps someone else will enter those values later.
• When you enter content in context of a page, what happens if the content appears at different destinations with a different look and feel - say an intranet and public website? Even worse, what if the fields that appear on the Intranet are different from those that appear in the public website?
• Similarly, if an article appears on the home page with a few fields and on a detailed page with many other fields?
• And then what do you do if the look and feel is changed due to a redesign?

There are many other implications that we detail in our research reports.  Like everything else, there are obvious work-arounds as well as trade-off here, and the trick is to maintain a balance between in-context content contribution and more traditional content contribution.

Make sure that the WCM products you are evaluating support different mechanisms of content contribution: from form based, to in-context authorship, to integration with external products and automated ingestion. Also consider very carefully the scenarios and then enable appropriate roles with the right corresponding content entry mechanisms.  Not all contributors will require in-context editing.

I say "seems to have been released" because Autonomy has been strangely quiet about it. Typically, when vendors release a new product or a major upgrade, there's a lot of noise: press releases, demos, conferences and so on. Nothing of this sort happened when Autonomy released upgrades to version 7.0 of TeamSite, LiveSite, and OpenDeploy.  This is not typical of Autonomy Marketing and so the question emerges....have they actually released it? The new version is available, but many customers as well as partners aren't even aware of it.

So whether you are a prospective customer planning to evaluate new products or an existing customer planning an upgrade, we would recommend that instead of moving to a dot zero release you hold on for a while or at least till the next point release of version 7 is announced. We'll have more to share in the coming months with our research subscribers.

Microsoft has incorporated feedback from over 17000 customers and 4000 partners for SharePoint 2010 which is due in the middle of 2010. From rebranding (no Office and no MOSS is the name) to usability improvements to functionality changes, you can expect many things.

One of the major shortcomings of MOSS, as our readers of the SharePoint and other reports know is that you can only work with a specific document and not with a collection of documents. So as an example, you cannot have a process flow for an RFP that consists of a Word document, an Excel spreadsheet and a PowerPoint presentation. You have to instead work with each individual document.  In SharePoint Twenty-Ten, you will actually be able to work on “Document Sets” and be able to start a new process right from Microsoft Word. We will of course closely look at this and other similar changes in our ECM report.

There are some major improvements expected in Collaboration and Compliance areas as well. Microsoft has also made major investments in other areas such as Taxonomy, Content Processing rules, distributed deployment and so on.

Microsoft is also projecting SharePoint as an Internet Development platform. There’s some interesting work happening in integration of Visio with SharePoint designer that will make it easier to create workflow based applications.

However, like all roadmaps, no one can be sure of what actually makes it to the final release. This will be a major release, going much beyond cosmetic name changes and rebranding. Microsoft’s marketing will have you believe that because it’s one single platform consisting of Sites (Portal), Communities (Collaboration), Content (ECM and WCM), Insights (Analytics), Composites (Mashups) and Search, your TCO will be lower as compared to that of competition. But make sure you evaluate carefully. We will be closely watching and reporting.