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.

So what did we find? On the Enterprise Content Management (ECM) side, SharePoint offers broad functional enhancements along with some some surprising deficiencies. On the Web Content Management (WCM) side, platform improvements have come more in degree than kind.

Subscribers to the relevant evaluation research streams can get immediate access to updates here:

• ECM
• WCM
• Evaluating SharePoint (all our SharePoint reviews)

You can also purchase our evaluations as one-off reports.

Over the past few months we have been looking in detail into product changes across some of the larger and better known ECM suite vendors  (EMC Documentum, IBM FileNet, Alfresco, Open Text along with Microsoft SharePoint 2010).  What has become clear to us is that many of these vendors are themselves going through a period of adjusting to market changes.

From a buyer's perspective, this translates to vendors recognizing (albeit grudgingly at times) that you will likely be reluctant to consolidate all your ECM requirements under a single banner. That when you look at potential suppliers of ECM software you are quite rightly looking ever more closely at integration points, and deciding whether your new ECM system will play nicely in heterogeneous environments. 

You can obtain a free sample of our ECM vendor evaluations here.

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.

Unsurprisingly, in Germany (SAP's home market), two WCM vendors have latched on to this. They offer integrations to publish content from your CMS, instead of using SAP's more complicated tools. e-Spirit's FirstSpirit allows editors to manage content from the CMS interface, which no doubt is more familiar to them than SAP's. eSpirit then publishes the content out to the SAP portal.

Two weeks ago, CoreMedia announced a completely new integration for their CMS. Their method is now the opposite of e-Spirit's: instead of publishing out to the portal, the vendor offers iViews (SAP's equivalent of portlets). These will then serve as dynamic publishing components; in short, this enables in-context editing and staging previews within the SAP portal. This also means you have a lot more freedom in what type of content you publish in the portal: CoreMedia can also do images or video.

The main drawback to CoreMedia's approach, of course, is that the content will stay in the CoreMedia repository, instead of in SAP. (As opposed to FirstSpirit, which stores live content in SAP.) This will mean the initial implementation might be easier with CoreMedia, but getting SAP's TREX search engine to index everything that's visible in the portal will take more effort. (You'll have to feed CoreMedia's content into TREX for SAP to even be aware something's there other than the presentation portlets.) At any rate, how easy or hard the CoreMedia integration will prove to be is something we'll have to see: according to the company, the first two customers will go live with the solution in September.

For NetWeaver portal customers, it's good to have these to differing offerings to contrast to SAP's own editing and publishing tools. And since both CoreMedia and e-Spirit are branching out of their German market, you could consider a closer look, even if you're in the US.

That leaves me with one interesting question though. If you're going to use a CMS to manage the content for your intranet, that makes perfect sense. But do you really want to use NetWeaver Portal, if it's just going to be an expensive and complicated delivery tier? I'd say that if you don't plan to primarily use the portal to expose SAP, you should probably consider this carefully; even if you already have the portal implemented. Carefully weigh the pros and cons of possible mixes of CMS, portal, and SAP whenever you plan big changes. There's plenty of options that might prove more effective than what you currently have.

There are at least five reasons for this phenomenon, and specific steps you can take to mitigate potential problems.

1) RFPs are getting better
In the technologies we cover at least, we're seeing fewer check-list RFPs and more narrative-based requirements. We also see larger enterprises profiting from preliminary RFIs. (Hopefully our advice over the years has played a modest role here -- but many others are offering good counsel as well.)

Good RFPs tend to create more work for the vendor, and if a potential bidder thinks your project is a stretch, they will more readily beg off.

But those who think they offer a good fit -- and it's all about "fit" -- will usually put in the extra effort.

Indeed, the most important by-product of better RFPs is better vendor responses, even if fewer in number. Responses become more targeted and relevant. This makes it easier to discriminate among them. So there's another trend we've noticed: less contentious down-select meetings. When you're clearer about what you want and bidders have to be more specific about their real capabilities and tendencies, decisions come more easily. (Ditto for subsequent down-select decisions, including after the all-important test phases.)

Of course, not all vendor responses will be as targeted as you'd like. And to be sure, vendors still don't have to look far to find horrible RFPs. But this leads me to point #2...

2) Vendors have become more discriminating
The very economic downturn that has you thinking you're in the driver's seat has vendors watching their cost-of-sales more carefully than ever. In short, they're less likely to chase. That's A Good Thing for all concerned, but also should give you some pause. If you're looking for the right fit, you want to appear at your best when soliciting proposals.

So, avoid nebulous, unprioritized requirements, and never use canned RFPs. Above all, figure out a plausible set of candidate suppliers. When vendors see wacky short lists, they typecast you as an amateurish or potentially indecisive prospect, and are more likely to beg off. Do your homework first.

Then inform the targeted bidders that you chose them through a substantive review process. If they haven't met you, they may balk at responding to an RFP over the transom, even though you've spent a lot of effort figuring out that they could offer a good fit. Try to talk to them on the phone before you send an RFP, and invite a preliminary webinar where useful. Which leads me to point #3...

3) Vendors remain a little paranoid
Whether you like it or not, you may need to assure prospective bidders that the deal isn't "wired" for a competitor. Vendors have always been suspicious that they're getting led around by the nose when a decision has already been made -- where the customer just goes through the motions, perhaps using a fake selection process to secure a better price from the chosen supplier.

In my experience, vendors are overly paranoid, and should give more benefit of the doubt. But they've been burned enough that you can understand their fears, especially if they don't have some sort of relationship with you that establishes initial trust.

[As an aside, at The Real Story Group we work only for you the technology buyer, but on principal we won't advise on nominally competitive procurements where the outcome is pre-ordained and bidders are being exploited. We try to explain to any customer issuing a wired solicitation that it's a smaller industry than they think, and in the long run, reputations matter. Vendors need to adhere the same ethical standards as well.]

4) Systems Integrators are always discriminating
In maturing marketplaces, RFPs increasingly target systems integrators (SIs) or other services firms, rather than software vendors. (We've recommended this on several occasions recently.) Also, when deeply vetting open source platforms, you will often need to turn to a consultancy to bid. In any case, the SI must bring a particular solution to the party, but has to justify both the tool and their organizational fit for your needs. This type of combo procurement can become tricky for you, but also potentially very effective.

Although SIs receive the lion's share of global technology spend, they have narrower profit margins and are therefore careful about what they go after. Also, the best ones are busy. Often very busy. That has them looking for engagements that represent a good fit. A carefully-crafted RFP will let them know if they fall in your sweet spot. A loopy RFP will tempt them to perceive you as a "squirrelly" client -- the kind they lose money on -- so they decline to bid.

5) The vendor screwed up
Sometimes vendors fail to bid simply because of bad timing or other mistakes. There may have been a hiccup in their sales process. Maybe the reps and proposal writers in that region were over-committed that month. Maybe they were in the midst of replacing personnel. Maybe they didn't fully grasp the import of your solicitation.

That's all their fault, not yours. So it's tempting to dismiss them as a poor partner as a result. But you shouldn't over-weight a vendor's sales acumen -- or lack of it -- in your decision, especially if you think they might make a good fit against more enduring criteria like functionality, architecture, and TCO.

Here's how to address this. Confirm whether each vendor is going to participate early in the proposal process so you can give them a chance to overcome issues of poor timing, insufficient understanding, or human mistakes. Don't worry that a candid conversation will make you seem weak-kneed or supplicating; it will likely raise the vendor's interest in participating and you can still remain discriminating in your reviews and negotiations going forward.

By the same token, you shouldn't coddle a potential bidder, either. Sometimes non-responsiveness really does indicate deeper incompetence or disinterest. Just take the extra step to find out what's really going on.

At the end of the day...

Fewer bidders isn't necessarily a problem. Among other benefits it means less reading! And better reading, since, done right, the responses should feel more relevant to your concrete needs.

The problem comes when you don't get a sufficiently discriminating set of responses, and/or a particular supplier that you really wanted to participate begged off instead. To avoid this, follow the advice from #2 and #5 above about communicating early with potential bidders.

Also remember that an RFP and attendant proposals -- while critical -- represent only part of the selection process. Our evaluation research identifies empirical, test-based steps (specific to each type of technology) that you should take before making a final decision.

In the end, like so many things, quality is more important than quantity. Vendors who try to be all things for all customers will respond to vague RFPs. The best fit for you will more likely emerge from a stronger, more focused solicitation. If we can help, please let us know.

However just as important is to understand the purpose of the project, and its objectives.

If the objective is to present web pages to explain what it is your department does, then that can be done for a very low cost. But if the goal is to create complex and highly scalable online business applications, then costs will rise steeply. They can soar for a variety of reasons, most importantly that the development work is simply very difficult and time consuming. Just because what the citizen eventually sees is a website does not mean that money got spent solely on some design and a Web CMS; more likely it's extensive back-end business process automation that runs up the costs.

Poring through the detail of the Government's document there are clearly many questions that need to be asked. Questions such as whether current procurement systems that favor huge bundled deals, from equally huge suppliers, really deliver the benefits promised.  Over the past decade there has been a move to consolidate buying activities into as few cycles as possible, ranging from buying government-wide licenses to Microsoft products to mega-deals to build and source online systems through a single vendor.  Though there was likely good logic behind these initial moves, it's time to really examine if the benefits in terms of cost savings and efficiency gains were delivered, or not.

But then that is a different debate to the one emerging in the UK. That debate has collapsed into a a cry from the hordes that if only it had all been done on (take your choice) SharePoint, WordPress, Open Source...then everything would be fine.  Regardless of the fact that the cost of software is typically only a small component of larger projects, and though savings can and should be found, they are seldom anything like as substantial as their proponents would have you believe. The cost of software is not the primary problem.

Delivering online services requires a lot of pre-planning, change management, business analysis, testing and prototyping.  The fact that many e-government services either replace or work in conjunction with existing human/manual services ends up layering complexity on complexity -- plus politics. And when you consider that Government services are expected to meet higher regulatory standards than most (not the least of which accessibility), the costs mount even further. In short the move to electronic services is by its nature costly. What you are doing in reality is building complex business applications for citizens that are exposed through the web.

The move to e-government has been seen as an imperative for the past 10 years. The closing down of locally staffed offices of various government departments has been rapid and the rate of closure continues, to be replaced in many cases by online services.  A more valuable discussion may be had in examining the true value and cost of online services, where they work and where they don't.  At present we seem to be caught between a situation where it is taken to be indisputable that all manual and human based processes are old fashioned and must be automated as soon as possible. Contrast this with the dawning reality that automating  human processes can prove to be hugely expensive, and often less efficient.

The 600,000 employees that the UK government is set to shed in the next year or so will need to be replaced with something. The trouble is that we may not be as far down the technology path as big IT suppliers would have you believe. All we know for sure at this point is that most big e-government exercises have fallen well short of delivering on their promises. Sure we can scale systems to unbelievable heights and deliver speeds and feeds unthinkable just a few years ago, but our ability to navigate and automate well-proven, human oriented tasks hasn't progressed anything like as quickly. The result? Bloated budgets and failed projects.

The topic of search crops up one way or another in nearly all the advisory calls we receive from our research customers -- including inquiries about other technologies, like ECM, Portals, Web CMS, DAM, and so forth. Search is essential; search is omnipresent; but woe to project leader who believes search engines are omniscient. Of course, this doesn't stop enterprise search vendors from claiming omnipotence.

Which brings me back to Autonomy. From an initial focus on enterprise search tools, Autonomy has become a roll-up vendor after acquiring a variety of other information management suppliers such as Interwoven. As a financial strategy this can be successful, and investors seem to cotton to Autonomy.

As a technology strategy, vendor roll-ups are problematic. Autonomy's technology strategy is to rip legacy search subsystems from acquired products, replace them with some pieces from its own IDOL toolset, and then promote its particular approach to search as a distinct advantage for you.

Specifically, Autonomy will try to sell you on the value of "meaning-based computing." Even if you can get your mind around what meaning-based means, you should remain skeptical that Autonomy has technically spectacular or original services here. More importantly, you risk getting sidetracked from your original goal of, say, creating a user-friendly repository for your 50,000 Office documents.

This wouldn't be as big a problem if Autonomy hadn't acquired so many aging technologies, especially in the WCM and DAM segments. Don't be surprised when, upon asking about missing or substandard functionality in these areas, your Autonomy reps deflect with search-oriented -- oops, I mean "meaning-oriented" -- answers.

Now, if you're buying a DAM, Records Management, or Web CMS package, you can't sneeze at better search, but in Autonomy's case it comes with some very complex and maintenance-intensive technology in IDOL. It also invites a slew of upsells of nearly limitless optional modules. Before long, you've turned a content management project into a serious search investment. Autonomy's delighted, but is that what you really intended?

Again, search is important -- but in the context of a broader content management effort, search becomes a complementary service. So when you examine Autonomy's toolsets, best to ignore all the talk about IDOL unless what you're really looking for is an enterprise search platform. When evaluating Autonomy offerings across the many marketplaces where it sell products, we continue to look carefully at what each package was actually intended to do. You should too.

In reality, we’ve seen a lot of enterprises who held off upgrading to Office 2007 from 2003.  However, many of those same organizations moved ahead with SharePoint 2007 implementations for any number of valid reasons. Whatever the case, the version mis-match is real and potentially challenging as those same customers consider skipping Office 2007 and heading straight for 2010.

Witness, for example, the following error -- when I clicked "NEW" from a document library view:

It just so happens that I have a SharePoint 2007 application, but I'm running Office 2010.  Interestingly, this is the same error you might get if you're running anything other than MS Office or on a MAC.  Other integrations between Office 2010 and SharePoint 2010 -- like the Shared Workspace tool pane and basic document management functions do work properly -- but clearly some functions do not.  If you go searching for other challenges related to "unmatched" Office and SharePoint versions, you're likely to find that this issue isn’t the only one plaguing SharePoint users.

As readers of our SharePoint research know, specific versions of Office and SharePoint are not inherently incompatible.  However, as with any set of independently developed tools (even from the same vendor), there is a bit of "buyer beware" to the implementation.  As such, test careful your scenarios before any mass roll-out; you may be surprised at the results.

In fact, it's still not uncommon for authors to have to learn a specific XML syntax in order to be able to write structured content. That may be one of the main reasons standards like DITA have little appeal outside of techdoc. Xopus' web based editor, however, does a reasonable job of keeping the XML abstractions from authors.

That said, any XML editor is far from WYSIWYG. They can't (and maybe shouldn't) be, because structured content tries to take the presentation out of the actual content. So don't be fooled by demos too much -- there are still many challenges in adopting structured authoring.

As for SDL and Xopus, perhaps more importantly: don't think any SDL product now immediately comes with a well-integrated Xopus editor. Integration takes time, and SDL has a lot of very different products. I'm sure they'll be able to demo it soon, but we've noticed that SDL's "integrations" are often quite shallow at first. For now, it's not necessarily an advantage over the competition.

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.

In addition to this, today we reached something of a milestone with more than 4000 people coming to download the ECM Maturity Model, a truly remarkable figure when you stop to think about it. The decision to make the original model completely open source and free was definitely the right one, as public and private sector alike have been able to simply download the free PDF without charge or obstacle, and they have definitely done in style!

All of us here at Real Story Group have been practitioners in our own right prior to becoming analysts, and our work is centered solely on helping buyers and end users so the maturity model makes perfect sense. ECM is complex and bewildering at times, and we have seen an enormous need for a tool that quickly helps you get a grip on where you are now and where you need to go in the future.

Progressing the model further remains a challenge though. We have not always be great at following up with the community as we would have liked. For those willing to roll up their sleeves and help, we do welcome you. Frankly the model is not going to progress much further by our efforts alone. That being said, it's in a pretty good state at the moment, and compared to others out there we can be fairly bold in stating that we believe it to be the deepest and most comprehensive available, and we plan to keep it that way - and keep it free.

So, with your help, a more comprehensive Version 3.0 update will come in time. But for now we will have a little celebration at the milestone, and look forward to hearing more of your stories and feedback regarding your use of the model with anticipation.

But today I was struck all of a sudden by what seems to be something of a change to daily business.  In the past year point releases for many of the more prominent ECM vendors have been much less about fixes and much more about co-existence. To explain...

Though every software firm regales me with tales of how they "replaced" FileNet or EMC or whomever, the truth is usually that they are now installed in the same locations as those legacy vendors.  Gone seem to be the days of "one ECM to rule them all." Instead people want to use multiple ECM applications, and when they introduce the likes of Microsoft SharePoint into the equation it is very seldom to actually replace an incumbent supplier (despite what the vuvuzela-blowing Microsoft channel would have you believe). It is more typically in addition to the incumbent supplier.

For an old-timer like myself (though you would never guess it to look at me) this normally raises concerns,  since the goal for the last 20 years has been to get everything in a single repository, or at least to attempt to. The very idea of multiple ECM suppliers in one location, on the surface at least, flies in the face of this goal, but the reality of the situation is probably somewhat more nuanced.

In the past year increased and expanded support for connectors and adapters of all sorts has been the key theme, and an almost literal acronym soup of protocols are being supported from CMIS to CIFS to IMAP.  What suppliers are slowly coming to accept is that the future is heterogeneous, and that to survive they need to be a team player. If your product doesn't play nicely with the products already in place then you are unlikely to make much progress. This is a good development all round, but its not without its drawbacks.

As a buyer you should absolutely expect any new supplier to be able to technically adapt to and interact with your existing environment. There is often no good reason other than to fatten a suppliers paycheck for you to throw out systems and processes that work perfectly well and replace them with something new.

But be aware that just because a supplier says that their product supports this or that protocol or integration point does not mean that they all do so in the same way.  For example WSDLs (the stuff that describes how a Web Service talks to others) can range from the verbose and barely literate to the simple and profound.  Likewise integrations with common applications such as Word, Outlook or SharePoint can be pug ugly or near transparent. 

Standards are a good thing, and the fact that suppliers are in a rush to adhere to as many as possible is an equally good thing. But don't confuse compliance with a standard as everyone doing things the same way.  They all theoretically reach the same end (hence adherence to the standard) but getting to that point can take many different directions.

So if co-existence of a new application into your existing information management environment is important to you then be sure to test and demo those elements before purchasing. Otherwise you could see your new suppliers' idea of team play akin to the French soccer squad: complete with disagreements, work stoppages, and an early bath becoming the most likely outcome.

In our press release today, we highlight the pros and cons of mashup technology offerings. To quote:

....Mashup tools are not always cheaper or simpler. "Don't assume that mashup technology is always the lighter, easier alternative to enterprise portals," notes Real Story Group Principal Alan Pelz-Sharpe. "In some cases mashup technology is quite expensive, and far from easy to manipulate, especially for the very business users that vendors claim to empower."

You can download a free sample of our Portals and Content Integration research here.

That investment will not be forthcoming in many instances for the next few years. If that were the totality of the Information Managers lot, then things would really not be so terrible. But a big impact of the cuts will be on public (and politicians') expectations regarding access to information -- and will likely cause more grief. 

Demands have never been higher. For example, FOIA (Freedom of Information Act) requests have rocketed in the UK, and they are becoming ever more spurious and costly to fulfill.  Many FOIA requests come from the same small number of newspapers and reporters and amount to little more than wild fishing exercises.  The perception seems to be that if a government department cannot instantly locate and turn over requested information, then they must be trying to hide something. The reality is more prosaic: it is a hugely costly, complex, and tedious process to comb every electronic nook and cranny to unearth information.  From public officials I have spoken to in both local and national government, the reality is that come the cuts, decisions will have to be made whether to undertake essential day to day work, or whether to take staff away from these tasks and minister to FOIA requests. 

Likewise new web-based citizen access portals will in many cases not go ahead at all, or if they do will be unable to afford to make such portals DDA (Disability Discrimination Act) compliant, and accessible to all.

What the move to eGovernement in the UK has shown us is that though there are great benefits to be gained in terms of empowering and providing access via the web to government services to citizens, that this comes at a high cost.  The myth that electronic is by default cheaper has long been discredited. Government departments large and small are struggling to meet an ever longer list of regulatory and political demands, with an ever decreasing budget, whilst dealing with the unremitting growth of information volumes. Something will have to give.

Smarter government employees are already constructing their defenses, painstakingly detailing exactly why they can no longer deliver some services, meet requirements, regulations, and requests.  From what I can see, the politicians making the cuts have not quite grasped the fact that the "do more with less" boundaries were breached some time ago. That moving forward, their needs to be a recognition that the cuts will not just hurt, they will also cause damage. The equation therefore has to be one of short term pain plus mid term loss equals long term gain?

Yet there is money to be saved, Governments around the world are profilgate spenders on technology. The best place to my mind, both in the US as well as the UK, for saving public IT spending would be in identifying shelfware, renegotiating maintenance contracts, and reassessing the value of ELA's (enterprise license agreements). I have no doubt at all that doing so would deliver far more savings than canceling or cutting back on essential information management projects.

So whether you think these cuts are right and justified, or simply "reckless" as the Labour opposition states, the fact is they are going to happen. And as a public sector information manager you will almost certainly be impacted, yet that does not mean that you are powerless. Stalled or cancelled projects have consequences and it will be your job to detail those consequences, and where applicable to redirect cost saving efforts to more relevant and worthy targets where spending has been truly wasteful.

Advice that may be relevant to all....

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.

This year I am a judge for ECM events in both Africa and the UK. Both events promote and encourage organizations to share best practices and success stories, and as so much of our research work focuses on what does not work, it can be something of a relief to study cases where value was delivered.

So if you are a UK-based organization then do check out the DM Awards.

And if you are based in Africa, check out the RIMA Awards.

But I give you fair warning in advance, I am a picky and fierce judge. I gladly take on the mantle of Simon Cowell and Piers Morgan in upholding my fellow Englishmen by delivering unvarnished, sometimes harsh, yet always fair criticisms. Something that doesn't always make me very popular with software firms, but something we always strive for in our buyer focused product evaluation research.

That said, I never go as far as Simon when he infamously said, “If your lifeguard duties were as good as your singing, a lot of people would be drowning.”

Some interesting conversations though.  For example, almost everyone has SharePoint in some form or another, but not one person I spoke to today considers that their main or central means of managing unstructured information. This resonates with not only what we ourselves have heard elsewhere, but also with quantitative research by AIIM.  Again the disconnect between the fever of the Microsoft SharePoint partner channel and more prosaic and measured attitudes of buyers appears acute. SharePoint is pervasive, but it's often more of a part of enterprise information plans, rather than an exclusive solution.

My thanks to everyone that came up and just said hello: those that knew me from my voice (AIIM BPM course), those who patiently listened to the story of why we changed our name from CMS Watch to Real Story Group, and the great many stories and insights you shared this past week. Thanks are also due to the Revolution Events (despite the decapitated rubber duck incident) and the AIIM UK teams -- great folk one and all.

Take for example a recent study by University College London into the UK's groundbreaking transition to electronic patient care records for the National Health Service. This initiative has come at a cost so far of $360 million dollars, and (to quote) "will require a high cost and an enormous effort to fulfill it's potential." That's a nice way of saying that the effort to date has largely been a waste of time.

The problems that have dogged this particular initiative are the same problems that arise in almost all similar projects, regardless of the industry sector or budget size. 

• Undertaking a full content audit, and ensuring that all the original data is not only accurate but also consistent, is difficult, time consuming, and costly
• Migrating content from (often disparate) systems is always a major challenge
• If you have not proven the value of the new system, people with stick with the old
• Validating and continuously improving the new process without full buy-in from the old users is near impossible

Though I do have Luddite tendencies, I am not advocating that you should avoid moving manual and paper-based processes to electronic methods. But I am advocating that you do so with your eyes open to the inherent complexity and difficulties.  Build a business case first, and ensure you have a full grasp on the work involved. Electronic processes are not by default any more efficient or cheaper than manual systems. 

And as for the rather cynical attempt of the ECM industry to push the benefits of Green IT, digital data is often no more "green" than paper. Sometimes it's worse. 

One final consideration is that of confidentiality. If you have highly confidential information remember that it is far easier to inadvertently expose that data to a multitude when it's in electronic form, than paper. 

Again to be clear, great cost and efficiency gains can be got from the move from manual to automated processes. But the move is often far bumpier and less clear-cut in terms of benefits than many think.

I spent this past week at the AIIM UK  Roadshow talking to buyers and end users of ECM technology. My mantra was that we often do not recommend to our research subscribers that they invest in more technology. Rather that you understand better what tools and platforms you own already, and make best use of it. It's an unusual proposition from an industry analyst firm, but as we have 100% independence, it's one we're happy to give.  Likewise we have no problem in advising our customers to think twice before diving headfirst into projects that are based on the belief that automation in itself equals improved business.

Theme of the day?  Difficult to say really, but if I were to choose two it would be the content chaos and archiving.  Where to start in hugely complex, over-running, multiple silo situations, and associated procurement practices.

I confess to being intrigued and a little surprised at how many people were attending the event to gain knowledge for major projects in the pipeline.  I mentioned this before but it bears repeating: the corner does seem to be turned in terms of organizations wanting to address information chaos. Gone is the past attitude that information disarray was either unimportant or too big a situation to take on. Savvy delegates seemed to understand that good information order and process delivers good information management - rather than technology being the starting point.

Story of the day for me though was from a major University that detailed how they manage IT contracts. The long and the short was that they never sign up-front deals, rather only a series of incremental deals and payments based on milestones met. Common enough in the world of consulting but less so for enterprise software.  The important part of this was that they enforced such payment methods without exception.  Where software vendors failed to deliver as promised they relentlessly pursue the vendor for penalty payments. Tough customers, but a practice others may want to consider.

Tomorrow the last and largest event at Earls Court London, so a long drive tonight to drop off the rental car and get to my hotel. This weekend will hopefully involve a great deal of sleep.

Our Web Analytics vendor evaluation customers know that to some extent, this deal has both companies coming full-circle, since Coremetrics acquired some of its technology from IBM in 2006.

The bigger back-story revolves around a longtime partnership between Coremetrics and IBM to provide specialized analytics services for WebSphere Commerce Server. And indeed, Coremetrics will now become part of the WebSphere group going forward.

And therein lies the first of my concerns for Coremetrics customers. WebSphere exerts huge gravitational force within IBM, but it's also where smaller modules can easily get lost. More generally, do you think IBM wants to sell more web analytics, or more WebSphere licenses?

Also, as we argued with Adobe buying Omniture, it's not clear that IBM knows how to run a true SaaS operation, as opposed to than selling and supporting software. The particular ways that Coremetrics works will create some specific challenges for Big Blue here.

We'll keep watching...

Possibly the highlight discussion related to a major university considering a move from LiveLink to SharePoint. Senior management are convinced it will be a simple move and very cost effective, while others have their doubts, on the grounds that 10 years of customization and integration may make the migration phase alone an extraordinarily expensive challenge. I think they may be right...

So, tonight a drive from the northwest to to Birmingham, potentially traffic hell -- but with yet another interesting venue at the end of the drive, the Motorcycle Museum.

With this edition, we inaugurate the "SharePoint Add-ons" line -- software vendors who develop modules that specifically work on top of (or behind) SharePoint.

You can download a higher-resolution version here.

Hope you find it useful. As always, welcome your comments.