Vern Imrich is Chief Technical Officer at Percussion Software where he is responsible for assessing market needs and creating the long term strategic vision for Percussion products and technology. In his 13 years at Percussion, he has defined or guided the product direction of virtually every Percussion product, including a foundational role in the Percussion CM System. He frequently speaks and writes on web best practices and technologies such as the use of social media, content and XML.

FCM: Percussion takes a somewhat unique view for web content management by separating the presentation layer, the website itself, from the underlying management core. Without getting too much into your product, can you discuss why this approach is better?

VI This really gets to the heart of our fundamental beliefs about the overall evolution of the web and the pace of change online, or what we call the "Web rate of change."  There are three basic tenets in our view as to why using a truly decoupled architecture is a more strategic approach, particularly for large scale, high volume web properties. 

• First, separating content from delivery is sound content strategy and is critical in today's world of ever-expanding delivery "channels." The more new technologies (such as mobile and social networks) and new web strategies proliferate, the idea of being locked into a single vendor or platform really limits your ability to innovate online. Decoupling removes that platform and vendor lock-in.
• Secondly, decoupling allows you to invest in advancing your delivery tier without concern over the impact on your content strategy. The ability to innovate in the delivery tier is where most online companies differentiate themselves, and they are not interested in having a third party dictate to them how they should run their site. One of our clients, Weather.com, told us emphatically that we could not touch anything at the delivery tier level, "just send our platform the content." Only a truly decoupled architecture can handle that. 
• The third component is scale. If you are running a high volume, high availability site, you don't want to be forced to over-invest in WCM infrastructure, and you want to be able to throttle that up or down, based on your business. Content Delivery Networks and cloud infrastructure can be deployed without having to ramp up costly WCM licenses on servers, and have them sitting idle waiting for a content surge. Percussion customers like USA.gov and Healthcare.gov are able to efficiently manage their WCM infrastructure despite serving hundreds of thousands of content items and routinely getting millions of visitors per day. 

But this doesn't mean you can't do advanced personalization and content targeting. Dynamic delivery services are able to operate at the delivery level and communicate with the WCM without requiring you to extend the WCM infrastructure to the delivery tier. 

FCM: How does Percussion make use of XML publishing?

VI: There are two ways to consider XML publishing. The first is inputting content into the system as XML, and the second is publishing XML files to be processed in the delivery tier. Both have been possible with Percussion's web content management products for over a decade. The approach is largely dependent on how our clients have chosen to leverage XML as part of their overall content strategy. To enable inputting content in XML, clients typically create an XML-based template. If they have a sophisticated content authoring process these clients will be well versed in how to either author directly in XML, or use an XML conversion tool. In our experience only the most sophisticated technical documentation teams are likely to consider this approach. 

On the side of publishing XML to the delivery tier, Percussion allows you to specify what kind of output you prefer when setting up the publishing process, no matter how the content was entered. This provides our customers with unlimited flexibility in how they structure the delivery tier; it merely becomes a configuration within the web content management platform rather than requiring a re-architecting of the delivery tier. For example, the content could be entered in a simple form, but come out of the system as well formed XML.

FCM: How do you hide the complexity of XML from end users?

VI: One of our goals in creating a web content management system is to make it as easy as possible for content contributors to put content into the system. To that end, we spend a lot of time thinking about the content template and making sure that end-users have a streamlined content process. 

We have an extensible library of input controls that hide all the complexity from the user. Whether it is HTML, XML, dates  or text, we provide organizations the flexibility to author content in whichever format works for them, all from a common UI framework. This template flexibility provides our clients with the ability to easily expand the number of contributors. 

FCM: If decoupling is such an efficient approach, why do you think more companies don't do it?

VI: The siren song of technology has always been "one system" whether it's one vendor, one platform or one technology stack. One box seems simpler and faster on a white board. But that is only true for areas of IT where predictability is high. Large single systems never work in a "high rate of change" environment like the web, where predictability is very low.

In fact, when "agility" is the main cost factor for companies trying to keep up (by adapting their systems to change), having many diverse systems is a far more efficient architecture because the cost and speed of adaptation is significantly lower. Decoupling is fundamentally the ability to embrace the uncertainty of the web. Organizations that "get it" understand that the web is going to change, and it's better to have the freedom to move with that change, and to keep the cost of change as low as possible.

That old school thinking is definitely starting to shift. As the web site rapidly becomes "just another node" on the organization's digital network strategy rather than at its center, people are being forced to adapt accordingly. If a piece of content is going to live in various web-based communities or on disparate platforms, such as Facebook; community portals; blogs; topical microsites; Google+; mobile phone apps; mobile sites; or somewhere else; starting with the static web site page as the context doesn't make sense. 

FCM: A recent Forrester report stated that basic WCM functionality has become commoditized and the big differentiator now is customer experience management. Do you agree with this? Why or why not?

VI: We are amazed at this notion that the WCM functionality has somehow become a commodity. If it was truly a commodity, then nobody would still be trying to build it themselves. You would simply buy the product off the shelf, configure it for your network and turn your attention to the things that truly differentiate you online. Anyone who has used an enterprise-class WCM product knows that's just not where the market is right now.

In fact, it's not a stretch to say that most companies do not like their WCM system no matter which vendor they purchased it from, even if it was Open Source--and it's all because of this massive complexity. In this quest for the next big thing, vendors, and even the Open Source communities skip over what remains a fundamental problem in the market - it's incredibly difficult to get systems up and running in the kind of time and budget that is allowed. When companies get close, they still can't upgrade the platform because of how massively customized it is, so it quickly becomes out of date, forcing them to start the cycle all over again. The web is just too fast and too elusive for all this custom code.