<!-- Content Here -->

Flexibility. It's a matter of perspective.

In my many years of collecting requirements for content management systems, I can't think of a single project where the word "flexibility" wasn't on the initial list of requirements. This "requirement" seems harmless enough. What could be wrong with the system being flexible? Flexibility seems like the perfect thing to ask for when you don't really know what you want. But it's a trap. Here is why.

Everyone who hears the word "flexibility" takes it to mean "being able to do whatever I want with the platform." But what that means depends on who you are and what you are personally capable of. For example:

• If you are a content creator, "flexibility" may conjure up an image of MS PowerPoint where you can make text boxes and pictures wherever you want on the page.

• If you are a web designer, you might imagine being able to edit pages as if they were static HTML where you could write whatever markup, CSS, or Javascript that you wanted. And every page could be a unique creation.

• If you are a print designer, you might picture editing one big image in Photoshop where you have precise control over every pixel and don't have to worry about annoyances like browser support or different displays.

• If you are developer might think about structured data that is re-usable and can be controlled by display template logic.

The interesting thing is that these expectations are usually mutually exclusive. The content producer's unstructured PowerPoint document is garbage to a template developer who whats to make global changes or adapt the display of the content for different contexts and audiences. The structured content model and display templates are inflexible to the content producer who doesn't know HTML and doesn't have access to develop and test code. An image produced by a graphic designer is a black box to anyone who doesn't have the source file and the right software to edit it.

And this is why everyone consider's their current CMS inflexible and tries to prioritize flexibility the next time around. But the process just repeats itself again and again.

The first step to breaking out of this cycle is to strike the term "flexibility" from the conversation entirely. Every time someone says the word, he needs to put a dollar in a jar. You can't move forward together if your interpretations of a word are diverging. After that, start talking about "balance of control" as in who controls what on the page. Stake out your territories. This doesn't have to be a land grab. Have mature discussions about control vs. responsibility and the ongoing maintenance implications of these decisions. Educate each other about your different perspectives. Talk through scenarios of what might need to change and who should need to participate in that change.

Most importantly, you should avoid thinking in absolutes like "flexible" or "inflexible." When you talk about balance of control, you are more likely to have productive discussions about moving boundaries rather scraping the whole system because it is "inflexible."

Drupal not listed as an alternative to Wordpress

Anthony Myers (@xanthonysfx) , from CMSWire, recently posted an article listing "Five Alternatives to Wordpress." His list was really interesting. First, he openly left off Drupal, putting Plone there instead. I really like Plone but I would have to say that Drupal is a much closer analog to the core functionality of Wordpress. The projects even have an ongoing rivalry with each other as shown by Dries's April Fools post "The Red Press of Drupal" where he announces that Wordpress is moving onto Drupal.

Second, the author didn't include blogging products like Expression Engine, MovableType (which, I hear, is improving), and SquareSpace. The products that he listed (Adobe Business Catalyst, Plone, Typo (I have a feeling Anthony meant Typo3, not this relatively obscure Rails blogging platform), Umbraco, and eZ Publish) are all traditional, page-oriented (as opposed to post-oriented) platforms. This shows that Wordpress, at least in Anthony's eyes, has grown out of its blogging roots and readers would be considering it for traditional web content management. I would have to agree with Anthony on this.

The third interesting thing about this article is that the various software communities didn't flood it with comments and other reactions. I would at least expect the very large Drupal community to dive in and lobby for their inclusion. Maybe the link-bait title of this post will change that. :)

Hosting a CMS Panel at CMS Expo

On May 8th, I will be hosting a panel at CMS Expo called "CMS Review - Compare CMSs For Web Design Studios & Development Firms." The panel is designed to help web design and development shops build their CMS portfolios. Selecting the right platforms to take to market is extremely important because building competency with these technologies takes time and your projects are risky until you do.

In the panel, we will be focusing on the topics most relevant to studios and integrators:

• The types of sites that the platform is best suited for.

• Market awareness in industry verticals.

• Availability and quality of training and support.

This session would also be useful for an internal services group that does web design and development projects for departments within the organization.

I will be around pretty much the whole conference. Look for me if you want to chat about CMS selection, localization, or marketing operations. If you haven't registered yet, use the code Seth2012 for a 10% off discount.

Digital Asset Management: Inventory or Production?

I have been doing a lot of work in digital asset management (DAM) over the past several months. One thing that strikes me about digital asset management software is that a majority of the market focuses on solving the problem of organizing and finding digital assets rather than the problem of producing assets. This is understandable. After all, digital assets (like images, videos, and audio recordings) pose a real problem for organizations. Digital assets are bulky (take a lot of storage), hard to find (at least without metadata), and expensive to produce (you need software, skills, and most importantly, taste to develop these things). Without a digital asset management system, these valuable assets get lost in a chaos of local and shared folder structures with no identifiers other than arbitrarily assigned file names.

The promise of alleviating the pain of losing and duplicating digital assets is compelling and has driven growth in the DAM segment of content technologies. DAM also nicely complements Web Content Management (WCM) because digital assets are so often used in web publishing. In fact, you see lots of WCM platforms integrating with DAM software or adding light DAM capabilities (basically a folder structure of assets with searchable metadata) to their solutions.

But what of the other side of management? The DAM market is considerably weaker in solving the problem of managing the production of digital assets. Products that were designed as digital libraries typically lack robust functionality for workflow, versioning, and managing the raw materials that are required to generate digital assets (filters, fonts, effects, etc.). This type of functionality is critical for large marketing departments within global organizations that are constantly producing, localizing, and publishing digital assets such as videos, images, banner ads, and flash movies. This was the business problem I was trying to solve.

After some research, I found two products that excel in managing digital asset production: ADAM and Vyre (I am looking forward to seeing Vyre's new Creative Workflow product). I shied away from Documentum for other reasons. Adobe CQ DAM probably has the most promise for digital asset production because of its upcoming integration with the market-dominating Creative Suite (Bridge and Drive in particular). That said, when you buy CQ DAM today, you are getting more of a platform than a DAM application. The "Press Center" application, which Adobe demos as its DAM, is essentially a website (built on CQ WCM) for browsing digital assets. The building blocks for digital asset production (versioning, workflows, triggers, etc.) are all there, but it takes a lot of services work to build a digital asset production management system. Look for some changes in the upcoming 5.5 release.

Another interesting technology in this area is Saepio MarketPort. The best way to describe MarketPort is that it is like those websites that allow you to build your own greeting card, photo-book, T-Shirt, or mug. You select a template and then input text and images to fill the placeholders. But instead of creating a T-Shirt or mug, you are creating a marketing asset like a flyer or banner advertisement. This is great for franchise or distributed companies that want to empower their subsidiaries with self-service creation of marketing assets. But it is very different from the creative workflow that I was discussing earlier.

There is also a category of software called Marketing Resource Management (MRM) but I found that market to be fragmented and poorly defined. The products that claim to be part of the MRM segment do very different things. Some focus on planning and reporting. Others focus on project management. The content repository functionality in these products tends to be on the weak side. Plus, they tend to require large amounts of implementation work to deploy.

The DAM (and MRM) market is broad and can be confusing. The good news is that if you are just looking for a system that will centralize the storage of digital assets and allow users to easily organize, find, re-use, and repurpose existing assets, there are a lot of viable options. You can focus your selection on aspects such as usability and price. But if you are looking for a platform to coordinate a large team of digital asset producers, the market gets a lot thinner. When evaluating DAM products, make sure that you know what scenarios you are trying to support. Demonstrations of search, renditioning, and cropping are compelling; but do they do not fully address the needs of a large, specialized production team.

CMS Selection Workshop Handout Published on Scribd

I just published my CMS Selection Workshop handout on Scribd. The handout contains:

• Examples of how to specify content types

• Example usage scenarios

• An example RFP table of contents

• An example vendor demo agenda

Enjoy!

CMS Selection Handout

Why CMS Implementations Are Getting More Expensive

Adriaan Bloem is starting to hear both customers and vendors estimate implementation costs to be 7-8 times software licensing costs. That is a big increase over the old budgeting rule of thumb which was 4-5 times licensing fees. I am not saying that there was a sudden increase, but I had been holding onto that old number for a long time so the new number came as a bit of a shock.

My immediate reaction was to try to explain the increase and I thought I would share some of my ideas here.

• Sites and technologies are getting more sophisticated. We have come a long way from the old world of static publishing. Now we are building interactive content applications that can be constantly tuned to optimize visitor experience and maximize business value. The tools have come a long way to support this but that doesn't mean that everything comes out of the box. Every new feature and option requires design, configuration/customization, testing, and management. The market is buying potential and the vendors are selling it — but realizing that potential isn't free.

• Document management is no longer bringing down the average. Back when I heard the 4-5x estimate, it seemed that was across web content management, document management, and digital asset management. Back then many document management projects had minimal implementation effort. There was basic functionality that came out of the box that didn't need to be (or couldn't be) configured. You just had to configure what metadata was captured, roles and permissions, and, for that nice touch of customization, add the client logo. That was OK because it didn't really matter if Company A's document management system looked nearly identical to Company B's. Not only am I seeing more web content management these days, but document management is getting more web-like. Leading the charge is SharePoint, which you use to create an interactive web site out of your documents (plus a whole lot more). Understandably, SharePoint implementations are very expensive. I am seeing the same thing with digital asset management systems that allow you to create an eCommerce-like site to browse through and collect assets.

• The technologies are getting cheaper. Content technologies are coming down in price — not just because of the pricing pressure from open source. The market is maturing and that leads to commoditization and competition. The super high-end products which commanded ridiculously high license fees are quickly becoming irrelevant and being acquired by infrastructure companies for maintenance annuities rather than sales potential. When buyers are using cheaper technologies to build more sophisticated websites, the implementation/license multiplier is going to go up.

The net of all of this is that buyers are seeing the potential of content and are investing in building solutions that can realize that potential. The underlying software products are only part of those solutions, which also require strategy, execution, and continual attention to be successful.

CMS Selection Checklist

A few days ago, I was asked by a potential client to provide documentation on my CMS selection process. As readers of this blog know, I write a LOT of articles on the various aspects of selecting a content management system. Probably the most concise descriptions are these two: "Selecting a CMS" and "How to Select a CMS." These posts go pretty deep and I have many other posts that go deeper into the specific activities. But, I still felt like I was missing a nice clean (less bloggy) overview. To solve that problem, I put together this CMS Selection Checklist. The most fun part of writing the checklist was finding all the articles that I wrote over the years that discussed each element of the process. I also see areas where I can write more.

CMS Selection Checklist

Enjoy!

Publishing to mobile is more execution than platform

Mobile publishing functionality is becoming an increasingly important requirement for web content management (WCM) selections and I am starting to hear more customers ask "can this product do mobile?" The fact is, most WCMS have that core functionality built into their DNA since multi-format publishing has been going on since the beginning of time. In the early days it was publishing "printer friendly" versions, PDFs, portlets, or RSS (we only dreamed of mobile). Now we are talking layouts and navigation that are optimized for smaller screens. In fact, what differentiates a WCMS from a document management system is the "rendering" or "presentation" tier that takes structured content and applies a layout template to generate a formatted output. The specific purpose of the rendering tier is to be able to reuse content and publish to different formats.

Just because nearly all WCMSs have the foundation to support a decent experience for a mobile user, it doesn't mean mobile will come easily to your solution. Why? Because WCMSs are also very flexible and give you plenty of opportunity to shoot yourself in the foot. WCMSs allow you to model your content with enough structure to make it reusable, but they don't require it. You can still use a single generic content type and turn your WCMS into a 6 million dollar WYSIWYG editor. You can fail to keep your content DRY. If you committed these sins, your mobile project is when they will come home to roost.

While structured, reusable content is a key to success in mobile and nearly all WCMSs support some degree of content modeling, there are a few non-universal features that will make supporting mobile easier. Look out for these features when evaluating WCMSs.

• Configurable template selection rules. All WCMS should be able to associate presentation templates to content types. You should look for a platform that allows you to configure template selection rules based on criteria like the section of the site or the user agent (browser). Otherwise, you need to build complex switching logic into your display templates.

• Themes. A theme is a collection of templates that define a comprehensive style (layouts, behavior, font, palette, images, etc.) of the site. A theming model allows you to group templates that are used for a style. This makes themes interchangeable and selectable so you can manage a mobile theme (or multiple mobile themes for different devices). It is particularly helpful if the platform allows themes to override each other — similar to cascading style sheets. For example, you could have a base theme and specific themes that override selective elements of the base theme.

• Multi-site content sharing. Designing for mobile is not limited to layouts and styling. There is growing consensus around the value of having a separate site with content that mobile visitors are likely to want. This doesn't have to be fresh, mobile-only content. Rather, it is a subset of the main content with a simplified navigation. Some WCMSs will represent this mobile area as a different "site." Others will represent it as a folder in the hierarchy. Regardless of the semantics, you need to be able to have the same piece of content exist in both of those places at once. Different WCMSs use different metaphors to allow contributors to manage these placements: "locations," "aliases," "references." Some metaphors come more easily to contributors than others but all contributors need training to get it right.

Those are the key CMS features to look for. The rest is in the execution. In addition to content modeling, make sure you are working with a competent designer than knows mobile and web developers that know how to implement the design to make pages lightweight (for example: compressing HTML, CSS, and Javascript; using sprites for buttons and logos; and effective placement of script references to prevent blocking). Also don't forget to account for increased testing.

The Risk of Static-ness

The Real Story Group recently published an interesting diagram showing one of the ways that their 2011 Web Content Management report views the marketplace. Overall, I really like the approach of looking at the dual dimensions of the product and the supplier and it is interesting how the various products are placed on the diagram.

The one aspect that doesn't quite sit right with me is the implication that less investment in the product translates into less risk for the customers. In my opinion, there is extreme risk in products that are getting minimal development. Static-ness can be the first sign of decline. The supplier (be it a commercial software vendor or open source development community) may be losing interest in the product and is reducing investment. You could say that this risk is captured in the vendor restructuring dimension as downsizing the group managing the product. Still, I think that risk on the product development axis is higher on both extremes. In the example of the diagram, if Microsoft invested even less in their WCM Platform, I think risk would increase. Anyone remember Microsoft Content Management Server 2002?

BTW, I tried to add this as a comment to the post IntenseDebate appeared to be swallowing my comments :)

CMS Pricing

Over the years, I have had a number of really interesting discussions about software pricing with both vendors and customers. Pricing software (be it a license fee, an annual subscription price, or whatever other source of revenue) is a complex problem on both sides of the transaction. Vendors are always trying to tweak their pricing to increase sales and revenue. Customers are constantly trying to figure out what prices mean in terms of value and overall costs. The results of these efforts are that prices overly complicated and never seem fair.

One of the best explanations of software economics is Joel Spolsky's epic article Camels and Rubber Duckies. To quote:

One of the biggest questions you're going to be asking now is, "How much should I charge for my software?" When you ask the experts they don't seem to know. Pricing is a deep, dark mystery, they tell you. The biggest mistake software companies make is charging too little, so they don't get enough income, and they have to go out of business. An even bigger mistake, yes, even bigger than the biggest mistake, is charging too much, so they don't get enough customers, and they have to go out of business.
Joel goes on to talk about microeconomic theory of demand and supply and discusses how software is tricky because there is no intrinsic limit on supply. Which brings him to the classic Joel conclusion.
Take my advice, offered about 20 pages back: charge $0.05 for your software. Unless it does bug tracking, in which case the correct price is $30,000,000. Thank you for your time, and I apologize for leaving you even less able to price software than you were when you started reading this.

As great as Joel's article is, it only focuses on keeping the financials of a software business in the black. The article ignores another important aspect for software vendors: making customers successful. Sure, making a software sale is great. But to be viable in the long term, a software vendor needs to create value for the customer and then capture a reasonable portion of that value (surplus in microeconomic parlance). A good pricing model will charge customers in proportion to the amount of value they get from the software, but measuring value is not easy in content management software. Different pricing models use different data as proxy measures of value. The problem is that these proxies are not an exact representation of value and customers have an incentive to manipulate them to lower the cost of the software. To make matters worse, the behavior that prices encourage is often sub-optimal and risky. Customers consciously underuse or misuse products in order to stay in a lower pricing tier. This undermines the goal of making a customer successful.

Let's dig a little deeper into the unintended consequences of content management software pricing models. In the world of content management, there are essentially three ways software is priced: by named users, by servers (or CPUs) or concurrent users, and by volume of content. All of these models try to get customers who use the software more to pay more. This enables a CMS vendor to sell into small departments as well as make large enterprise-level deals. But all of these models can encourage bad behavior. Lets look into each one.

• By named users. This seems like a great model. When a customer has lots of users on a system, it means it is leveraging the product for high value things like distributed authoring. The product likely has become a critical part of many jobs — making it an important part of the operational infrastructure. Here the value is that lots of people are able to edit content. However, I frequently see this model drive customers to do foolish things like having shared accounts on the system (that is, 10 different people log in as a user named "User1"). I have also seen customers have dedicated content entry people to save on user accounts. If you don't have a user account, you just mail your content to someone who does. Both of these behaviors undermine all sorts of functionality like workflow and auditing. Any sense of accountability is gone.
  
• By servers or concurrent users. I lump these two models together because they both attempt to tap into the intensity of usage. This is slightly better than the first option (named users) because it does not penalize customers who have lots of occasional users. Customers with more activity pay more than customers who are more static. Here the value is the amount of management activity the software enables. If the customer's business depends on actively managing its content, the CMS is creating a lot of value. But these models can encourage users to under-power their implementations. Customers will low-ball their infrastructure. When customer buys too few CPU licenses, the system will be slow (what software vendor wants a reputation for being slow?) or there will no fail-over for upgrades or crashes (what software vendor wants a reputation for being unstable?). When customers have not bought enough concurrent user licenses, I have seen employees repeatedly trying to log in to snatch up a session when one comes available. What a waste of time!
  
• By content volume. While the first two models are common to all types of enterprise software, pricing by volume of content may be unique to content management software. I only know of a few vendors that sell this way but, frankly, I think this may be the best of the three options. Companies with more content derive more value from their CMS — at least they should. If a customer has a large volume of low-value content, maybe that is a problem that should be addressed for other reasons. Additional software fees are trivial compared to the cost of keeping around unneeded content: redundancy, out of date content, and poor findability all add up to great losses in efficiency — a customer will lose more efficiency to these issues than is gained by having the CMS. Bob Boiko's book Laughing at the CIO; A Parable and Prescription for IT Leadership
  gives excellent strategies for thinking about the value of information. If high software costs force a better content management strategy, great! However, things don't always work out that way. I have even seen customers manage content outside of the content management system (like on a file system or in some other CMS) to avoid having it count against quota. I have also seen customers model their content to be coarser-grained to reduce the number of items. For example, rather than create a content item for every glossary term (which would increase reusability) the customer might create one glossary page with terms listed as paragraphs in the rich text editor.
  

All of these pricing models have their benefits and risks but they don't necessarily dictate success or failure. As I often say, a successful software acquisition establishes a partnership that delivers balanced value to both the customer and the supplier. The pricing model is an important aspect of that partnership because it establishes the terms of exchanging that value. But like all terms, pricing is negotiable and negotiation works the best when both sides seek a win-win result. If the customer is sensitive to the vendor's need to generate revenue to sustain its business, and the vendor is sensitive to customer's need to make cost-effective expenditures, mutually beneficial terms can be reached