10 comments posted · 4 followers · following 0
Nice list, could you elaborate on the "Abdication at the very top end of the marketplace" - what do you mean by that?
"What I'd like to see is a short list of features that a WEM/CEM platform needs to support, and highlight those that are new to WEM/CEM, not the traditional CMS/Search/Analytics/etc we all know so well."
WEM (whether the E is experience or the engagement) needs to be defined, work like this for example - if RSG will forgive me quoting Forrester: http://www.forrester.com/rb/Research/online_custo...
I do think there is more to engagement than having a WCM that publishes pages, but (as I've written before) this is being hijacked somewhat.
Firstly, thank you for the opportunity to brief you, although I am of course a little disappointed that you took away such a level of concern from our positive conversation.
This long term strategy is something that we've done in close consultation with analysts, customers and partners and in recent months we have been very transparent about it - talking about it publically at our customer and partner events in November last year.
As CMSWire observed, the standard release cycle of our products means that we were due to develop a major release for both - this strategy means that we are able to develop and build that next generation product to our entire market - making the best use of our R&D investment to bring new functionality to the platform, rather than building standard features twice.
This idea that a major release of software benefits the vendor is of course true, but if this doesn't show value to our customers and prospective customers then we are unlikely to realize that benefit in maintaining the relationship we have with our current customers or attracting new ones.
Our commitment to CMC, both in terms of the product and the corporate or mid-sized enterprise market, remains undimmed. The current product is incredibly capable and we maintain an R&D investment in it, but looking to the future we want to ensure we are best placed to satisfy the needs of that market and our customers, where the needs for web engagement requirements are growing more sophisticated.
Of course there are going to be architectural differences, as with any major software release and - as we discussed on the phone - the upgrade, especially for our CMC customers has been a core part of this project from day one. But, it's business as usual for a major release.
Part of those changes will indeed affect custom plug-ins, but as we reveal the detail of the new product, we will be including more of this functionality as core and will be launching an updated plug-in or component architecture with a raft of 'out of the box' components.
The fact that the architecture is based on CME has reassured many that I have spoken to, it is a proven technology and we have developed a track record and references on our ASP.NET delivery platform. It is a clear indication of what we can bring to the corporate market with CM7.
For our CME customers this gives us a great opportunity to address some of these concerns that CMSWatch have shared, with user interface consolidation and a new workflow engine - plus the ability to deliver a broader product with deeper integration to our WebJourney, SM2 and Dynamic Messenger products.
In this we also haven't forgotten the developers, we are building a community around the components architecture and investing in the web application development and delivery platform. Adhering to best practice for our technical community, with, for example, a 100% ASP.NET development platform (alongside our Java delivery capability).
In our experience so far (with partners and our own professional services) the technical transition from CMC and CME on ASP.NET is trivial for a skilled ASP.NET developer.
Only last week I was with three customers and a partner who, when the detail of our plans were shared with them, were very excited to get onto our planned beta program.
I would encourage anyone who has any concerns to please contact their Alterian contact, or me directly firstname.lastname@example.org / Twitter: @iantruscott.
But, we do need to identify the business value of the difficulty of doing a sophisticated job of this, before we apply the technology and Tony is right we need to look at who's doing it now and how - then empower them with tools that the business will recognise as core to a content strategy.
Yet, folks are now tweeting that this article as endorsement of CMIS, although you say "example of an attempt" which sounds very cautious - what's your view?
I think to Tony's point: "I think content managers want to access analytics in a place where they can take action" - I think you can extend that to lots more folks in an organisation, as web derived data is so valuable to marketing, operations, etc etc.
But... there is a bigger issue than just looking at pretty graphs, or frustrations over an API to import data into other systems - it's about taking action on that insight, for example personalisation - in web time. Right now (as Darren Guarnaccia points out in his blog post) with the constraints on realtime data from conventional web analytics vendors you need to 'own the data' to be able to fully leverage it during content delivery.