[Viewpoint] The Right and Wrong of Quark and Adobe Strategies

By Eric Kuhnen, Focal Partners, special to The Content Wrangler

Quark and Adobe have been after each for a long time, and there are metaphors aplenty to overlay this conflict. First, it was attrition warfare between QuarkXPress and PageMaker, which embroiled Adobe after its 1995 acquisition of Aldus Corporation. QuarkXPress won out when Adobe realized that PageMaker’s software was a Gordian Knot of entangled code. Adobe employed the so-called “Alexandrian Solution” by simply cotton the knot; that is, by jettisoning the PageMaker product to build a new product, InDesign, from the ground up.

Next, it was Greco-Roman wrestling between QuarkXPress versus InDesign. By the time InDesign debuted in 1999, QuarkXPress was the industry standard for every publishing related activity. Thus commenced a barrage of throws, arm drags, bear hugs, and headlocks by QuarkXPress in an effort to pin the upstart InDesign to the mat. But fate intervened. Adobe and Quark launched new versions of their respective products in the same week of January 2002. The key difference? InDesign 2.0 supported MacOS X; QuarkXPress did not. This oversight is reminiscent of the 2000 Summer Olympics in Sydney in which the young Rulon Gardner exploited a momentary lapse in heavily favored Aleksander Karelin’s defense to win the gold medal in Greco-Roman wrestling. Similarly, InDesign escaped the clutches of QuarkXPress, and began a steady assault against its once-unbeatable opponent. In 2007, Quark CEO Ray Schiavone conceded defeat in a September 2007 interview withPariah S. Burke, editor of QuarkVSInDesign.com.

Now, it’s “The Road Not Taken” as InDesign expands within the context of Adobe Creative Suite 3 while QuarkXPress morphs into a component of Quark’s Dynamic Publishing Solution. What distinguishes the underlying strategies of these two products is the absence or presence of a content management system (CMS). And like that favorite theme of Frost and Peck, each company asserts that it’s following the less-traveled road.

The problem is they’re both taking roads most traveled because of their respective stances towards integrated content management systems, and I’ll show you how after looking at their respective strategies. Let’s start with Adobe.

Adobe: Everything but the CMS

Adobe’s entire strategy is to engage its customers at the boundary between users and their ideas and information. To that end, Adobe offers a line of creative, business and mobile software and services for creating, managing, delivering, and “engaging” with compelling content and experiences across multiple operating systems, devices and media. (NOTE: I pulled that tidy little summary from Adobe’s 2007 Form 10-K on file with the US Government’s Securities and Exchange Commission [SEC].) And it’s a pretty long line, too. According to its SEC filing, Adobe sells 39 products classified as “Creative Solutions”, 8 classified as “Knowledge Worker Products”, 14 classified as “Enterprise and Developer Solutions Products”, 5 products aimed at “Mobile and Device Solutions”, and a further 24 products serving platform, PostScript, and print-publishing sectors. Of the 90 products produced by Adobe, three claim to interface well with a CMS (Graphics Server, Acrobat Connect, and RoboHelp), and one claims to compete with other web content management systems (Adobe Contribute). Finally, the CFO, Mark Garrett, came from EMC/Documentum, but that’s as far as Adobe’s CMS interests extend. Beyond that, the effort to deliver software and services for creating, managing, and delivering compelling content does not include offering a content management system per se.

Adobe hopes it’s on to something here. It has turned that line of products into a circle. The circle circumscribes a set of components that Adobe has no interest in building itself, such as printers, operating systems, and content management systems. A user exploring a line of creative thought intersects the circle at the Adobe product employed to express that thought on its way to the medium within the circle for storing that thought. In this way, Adobe can focus on being the means by which all creative thought is expressed without suffering the distractions of competitors (like Microsoft) who try to sell something on the circle and something inside the circle at the same time.

Another plausible explanation is that building and selling a content management system is hard work in a business with shrinking margins. After Open Text, there are no independent enterprise content management vendors. Smaller vendors exist (consult the exhaustive list of vendors compiled by CMS Matrix) but they have little chance to grow beyond the niche markets they serve. Adobe may thinking that so many companies have trod the path of the CMS that it’s simply wiser to exchange curiosity (in building a CMS) for prudence by leaving the CMS to someone else.

Whether or not Adobe has the right strategy is the point at issue in the market because Quark (not to mention Microsoft) is bundling a CMS with its offering. So let’s look at Quark.

Quark: Again with the Publishing Revolution

Quark’s present strategy is to give customers seamless, productive control over the creation, management, publication and delivery of creative content. To deliver on this promise, they’ve woven XML into all of their products to allow for much greater automation and to deal more effectively with components of media-independent information. Also, they’ve either partnered with XML content providers, such as In.vision Research (makes the Xpress Author plug-in to Microsoft Word), or they’ve built integrations to some of Adobe’s own products, such as InDesign and InCopy. To prove it all works, they’ve built the Quark Dynamic Publishing Solution (DPS), which accepts input from content creation tools like QuarkXPress and Xpress Author, prepares the content for publication with the Quark Transformation Engine, and spits out rendered content with QuarkXPress Server. The key component that differentiates Quark’s approach from Adobe’s strategy is the presence of the Alfresco CMS, an open-source enterprise content management (ECM) system. With Alfresco in the mix, Quark can also manage the lifecycle of the created content so that customers can improve information quality, increase efficient content reuse, and drive down the overall costs to produce content for new and existing markets. All of these additional benefits derive from the decision to include a CMS in the product strategy.

If the phrase “Dynamic Publishing Solution” sounds familiar, it’s because the publishing revolution going on at Quark already happened at PTC/Arbortext two years ago. Back then it was called “dynamic enterprise publishing” or simply “dynamic publishing”, but the message was the same: “with our content and process system married to our authoring and publishing system, you will enjoy lower costs, greater accuracy, up-to-date information, and happy customers.” In time, the revolutionaries found their way to Quark (five of the senior team, including the CEO, are ex-Arbortext) and viola! Revolution! Again.

Quark and Adobe: Roads Traveled Often

To follow the strategic road less traveled, you can’t take the paths chosen by Adobe or Quark. Adobe asserts its uniqueness by choosing to omit the CMS from its product strategy. As I showed earlier, there is some logic in that thinking, but it’s misguided. Here’s why: the CMS is the key to efficient content creation, which is what enterprises want. Consider Adobe’s chief competitor, Microsoft. Look at the cool stuff Adobe touts and you’ll find Microsoft products as alternatives. I’m thinking of AIR versus Silverlight; Buzzword versus Office Live. However, Adobe says “no CMS” and Microsoft says “SharePoint” and they’ve promoted SharePoint to become the platform around which people collaborate and manage the content they create. Since enterprise customers understand the cost savings that an ECM offers, they give Microsoft a chance to pitch other content creation tools, tools which happen to compete with Adobe’s tools. Adobe, lacking a CMS component, cannot compete effectively with Microsoft, and so they look elsewhere; i.e., the SMB market. But, there’s nothing new in that strategy; Adobe has been in the SMB market for years. So, Adobe cuts itself out of the Enterprise market by asserting its unique, non-CMS approach. And that is the well traveled road to irrelevancy.

Quark is no better. Leaving aside the Arbortext strategy redux, Quark executives seem to have forgotten two important lessons the industry learned about selling a CMS-enabled solution. The first lesson learned is that cost efficiencies wrung from a CMS don’t show up very much in the SMB market. To get the biggest bang for ECM buck, a customer has to have lots of products coming to market at ever increasing rates of speed and deployed into global and local niche markets with minor but important variations. Customers with these kinds are problems are found on the Forbes Global 2000 list of companies. Quark sells good products, but they would need some heavy muscle to displace EMC/Documentum or Open Text as a corporate ECM, and they’re trying to get there with an open-source CMS they don’t own. No way.

The second lesson is that a CMS is complicated software. There’s some kind of database management system (DBMS) deep in the product--either relational or object-oriented, or a cross between the two--that has to interact with the operating system and the file system. There are content relationships to manage, particularly with respect to content reuse, that get very cumbersome when the number of content objects under management gets very high. This means that the underlying DBMS has to be tuned and retuned to keep the system within an optimal or even acceptable performance envelope. Object version control can be a nightmare. For any of these reasons, customers sometimes prefer a simple file system as the default CMS. It’s simple for the IT department to manage, users know how a file system takes care of files.

Quark, in proposing to integrate a CMS into its Dynamic Publishing Solution, has just added a well known set of problems to their offering. There are literally dozens of CMS-enabled solutions on the market already; Quark’s entry is nothing new (well, it is to Quark but not to its customers). It’s not that adding the CMS itself is the wrong idea, but that incorporating a traditional CMS will yield fewer benefits to the customers in the markets it serves, and will not do much to displace the leading ECM vendors in the markets it would like to serve. So, Quark will follow the road it has always taken.

The one less traveled by...has made all the difference

Incorporating a CMS into one’s product strategy is the right approach, but the road less traveled would require some radical thinking about what constitutes a CMS. My favorite approach is turning the underlying file system into a CMS, as follows:

Extend the file attributes to allow all of the metadata possibilities found in a traditional CMS.
Use Google Desktop, X1, or any other desktop search engine to provide the file system search index; these are far better than any search engine provided by a file system vendor.
Build an extension to the desktop search engine that indexed all of the metadata.
Develop a file versioning capability similar to Apple’s “Time Machine” concept in OS X Leopard.
Employ existing enterprise-grade solutions for increasing the size of the file system, such as employing network-attached storage devices or storage-area networks. Similarly, use existing enterprise-grade solutions for managing the file-system-cum-CMS.

This kind of system would have a number of benefits to both users and vendors; namely:

No distinction between file objects and content objects. One of the highest hurdles to clear for content authors is that content stored on a CMS somehow differs from content stored in a file. The only reason this distinction exists is because a file system typically doesn’t support the metadata and versioning capabilities of a CMS. With the above system in place, those distinctions disappear.
Decreased data storage complexity. IT departments charged with maintaining the file system CMS would use tools and techniques that are no more complex than what they use today for managing just file systems.
Increased CMS reliability. The absence of a heavy-weight CMS means fewer “moving parts”, so to speak, which translates into fewer modules that can fail; ergo, higher reliability.
Improved and innovative collaboration tools. Breaking the close ties between content management systems and collaboration tools would allow vendors to innovate new means and methods for helping people to work together.
Here’s the conundrum. Quark understands the value of a CMS but doesn’t have the vision to build the right kind of CMS. Adobe could build a file-system CMS but doesn’t understand the fundamental role a CMS needs to play in its strategy. Each will take the path most traveled, and neither will make a difference.

About the Author
Eric Kuhnen is Managing Partner at Focal Partners. He can be reached at .

Filed under: Content Management : Dynamic Content : Technological Innovation

E-mail Article Print version Tag it
del.icio.us | Digg | Netvouz | Reddit | Facebook

Comments

By M Pinault on May 7, 2008 -- 8:06am

Informative article, especially concerning how “to get the biggest bang for ECM buck.” The companies that I work with typically want a publishing solution with content management capabilities, but they have a small number of documents and are in reality are unwilling to pay for and maintain what they ideally want. One organization used Quark XPress for years to handle their 50-paged customer handout, but even though they want to content re-use, I think that a “Dynamic Publishing Solution” is overkill.

By Eric Kuhnen on May 7, 2008 -- 12:19pm

M Pinault,

You’ve cited a fine example and it dovetails with my experience. One of my clients considered offering its CMS to the SMB market, but found that the value proposition SMB customers wasn’t as dramatic as its was to a global enterprise customers.

In your example, a 50-page customer hand-out does not have enough complexity, variety, distribution to warrant the up-front and on-going expenditures of an RDBMS-based ECM.

Now, if Quark built a file-system CMS as part of their DPS solution, your client could have embarked on a campaign to increase reuse without the overhead of learning to use an ECM. In that way, DPS would not be overkill, if I understand the implication of your comment.

Thanks,

Eric

Leave a comment

Name:

Email:

Location:

URL:

Remember my personal information

Notify me of follow-up comments?

Please enter the word you see in the image below: