Once we had the functional specs roughed out along with the rough topology and rough mockups, we needed to settle on a Web Content Management (WCM) system that would meet the needs of our intended scope and budget. We couldn't, in fact, complete the scope and budget without making the choice. This is why it is so critical to have the knowledge of what is available and what directions it is possible to take with a WCM system. This is the point where a typical organization goes through an RFP process or engage a consulting group to gather recommendations and weigh the options. For us the choice was much simpler.
As I mentioned in a previous article, and in my Blog, AceCP already had in mind several options. The Recommendation was a matter of what we could get that might fit within our original rough budget numbers. Like most organizations, we found ourselves looking at a field of different WCM systems with an eye to the possibilities and drawbacks, but unlike other organizations we had prior knowledge to draw upon to help narrow the field. The choice became a short debate with a list of pros and cons, and our choice was quickly narrowed down to two potential options with wildly different potential implementation scenarios.
Consider that the functional specifications for our social marketing experiment included nearly all the social media deliverables (including Blogs, Calendars, Forums, Wiki Pages, Tags, and others), plus back end integration with a marketing workflow product and with SalesForce.com. The site had to integrate with Facebook, Twitter, and Linked In - both from a page basis for site visitors and from a publication bases to post our updates automatically to these sites. Navigation had to be dynamic, and must also support Semantic Navigation features that are built based on how articles and pages are related by tag and topic. In all, the site was defined as a cutting edge and complicated mess of every technology available in the market.
A stack of products rather than a single product was needed to address that kind of progressive set of business requirements. Yet, we felt we were no more demanding of the WCM market than we would expect any customer to be. The only difference between us and a client was agility (we are small with a small set of decision makers) and knowledge (this is our core business, after all). Our WCM choice, just like a clients, had to be validated against our requirements. We could use our knowledge to do this without demonstrations from vendors, RFP responses, or any more research than what we already knew of the industry and products. This is ideally the same services we provide to the clients that hire us to put together their strategy and product choices.
Two of the pitfalls we avoided were making a choice by "industry buzz" and getting talked into a product choice based on an impressive vendor presentation. There would be no influence of our choice other than our own history with the various products. We did not have to worry about whether the consulting company making the choice had our best interest at heart, because we were the consulting company. We always approach our clients in the same manner - specifically as if the decisions were for our own company. Some clients get that, and some do not, but it does not change our dedication to finding the best solution for the circumstances.
Before we started the actual selection process, we needed to identify one extra dimension of the choice that was not in the functional specifications. Since this project was to be a best practice implementation of a WCM with Social Media Marketing, and we wanted to showcase the result, we had to choose a product we would truly recommend to our clients, and that we knew we could create a best practice implementation from (whether that was because we were skilled enough at the technology or because the product had enough to offer that it promoted best practice). In the end, we almost had to compromise this dimension.
After taking everything into account, we started the process by laying out all the contenders. A vast majority of the WCM field could be discounted without wasting time, and we simply listed the major products that we support and with which we have enjoyed some degree of success. That list included the following in alphabetical order:
There are many many others in the market, but these comprise the core of what we see most with our clients. We have worked with each one, and have had successful implementations of each in the last few years. This list took about 30 seconds to put together. We knew that each of these has the capability to deliver, to various degrees, everything that we wanted.
It should be noted that Tridian SDL was also originally a thought for inclusion in the list. We have not worked with it before, but have heard good things. Our inquires to them went unanswered, so we did not pursue it. Ektron was also "a thought" based on its growth in the market, but it was not seriously considered based ont eh fact that its only recently started to come together as a full fledged WCM, and we have no experience in it or relationship with Ektron as a company.
The next step was to discuss and comment on each product. We answered general and specific questions and went through thoughts of the technical implementation. Sparring the details, a summary of the major points of this discussion is listed below:
All the products listed have been or are market leaders in WCM, except for Alfresco (which has a growing demand for its collaboration use). Some products, like Sitecore, scored very high because we had not had a chance to really showcase what we could do on the platform publically before. From this list, we knew that our goals could be met by any one of these.
The following were eliminated based on the product itself:
Under most client circumstances, this is where the vendor would be tapped to provide demonstrations of their ability to meet the needs and goals of the WCM project. In our case, we did not need that step, so we skipped it.
The following products had different reasons for getting scoped out:
Alfresco is not a Cadillac option, and in fact has a lot of drawbacks in its WCM capabilities. It should fall within the first set eliminated based on the product features. However, what it lacks in structure, it makes up for in it's simple contribution to the end result as a Web based editor of content and documents. If you bolt on the Liferay portal to the front end, and build a custom Portlet driven content presentation using the Spring Surf framework, you can provide almost all the features we desired. The work effort is high in order to make this happen (raising the time and human cost), but we've "been there and done that", so we could borrow from past projects to make it a simpler endeavor. Alfresco provides both a Community "free" version and a Commercial version for use by partners, eliminating some of the necessary budget. Alfresco is also a company that has been easy to work with, and this kind of case study would likely be well supported. While the development would take a while, the actual iterative phases of development would provide the appearance that things were rolling out quite quickly.
We made the decision to go with Alfresco. Final Answer! Or so we thought...
Once our decision was made, and we started to provision the virtual machine environment and get all the software installed. We moved the existing sites over to the new host, and began the design phase of the project. As an iterative process, our first deliverables were small, and we began to work out the problems of putting together the heavily featured site into this somewhat difficult environment.
Then out of the blue, we got feedback in email that OpenText was interested in our case study. Many times when working with clients on strategy and product choice, we come across factors that were not previously known by anyone during the review phase. Sometimes a vendor that wants the business will make the deal happen. In this case, OpenText changed the playing field with a deal that made the case for changing our final answer. For us, as resellers, it makes more sense to provide the case study on a platform that we'd likely recommend like Day, Sitecore or, our favorite, OpenText WEM.
The process of going through the review and choosing Alfresco took only a few weeks. The Project phases progress for a short while as we addressed the design and the pulling and tugging Alfresco required to get what we wanted from it before OpenText came back to the table. The timing of the OpenText offer during the iterative implementation we use on projects like this allowed us to pull back losing only install work and some prototype code. Content models, Template designs, and other feature design work that was completed could be reworked easily into WEM. Our expectation was for a much more smoothly successful implementation in Open Text WEM, than we'd expect from the Alfresco platform.
In closing, we evaluated the options quickly, had one false start, and quickly corrected once our ideal platform came within reach. We did not do the choosing and evaluating with an RFP process or any vendor presentations because we have already been through that with our clients many times. Already knowing the features and capabilities of each WCM, our criteria essentially boiled down to time to implement, cost, and ultimately our relationship with the vendor in support of the case study.