1
CONtENTS Advances in Technology have Profoundly Changed Publishing...3 Document Management: As It Used to be Done (prior to 2005)...4 The Advent of XML and Native XML Databases (2005 2012)...5 Putting the C into a Component Content Management System.6 Keep it Simple... 7 Transformation-based Development (2013 and Beyond)...7 Less Customization and More Innovation...8 Time to Market...8 Conclusions...9 Choose a Solution Provider Different from the Product Vendor...9 Ensure Technology and Content Model are Standards Based...10 Limit Customization to Transforms Whenever Possible...10 Limit Your Technology Stack...11 Your Editorial Team Should Not Need Excessive Training...11 2
ADVANCES IN TECHNOLOGY HAVE PROFOUNDLY CHANGED PUBLISHING In a sense, advances in technology have been paired with publishing since the 1400s. From the first flatbed printing presses, to lithography, to color printing and desktop publishing, and most recently to digital publishing and open access, the publishing process is and always has been an evolving and dynamic medium. However, never have changes in publishing been so profound and rapid, with new products continuously arriving in the marketplace. Likewise, with the barriers to publish materials flattened by technology, an explosion in digital content has produced an ocean of new authored works, some vetted and others less so, flooding the marketplace and presenting challenges to both traditional publishing houses and consumers. Publishers that are agile and that can properly evaluate and adopt new technologies have been able to produce new revenue streams, improving the efficiency of their process and reaching new consumers and markets. This paper focuses on one important aspect of this publishing revolution, content management, and how it has evolved rapidly from Document Management (DMS) to Content Management (CMS) through to Component Content Management (CCMS). 3
DOCUMENT MANAGEMENT: AS IT USED TO BE DONE (PRIOR TO 2005) In the early days of digital publishing, particularly in academic publishing, content management was document management. While formats such as SGML, and later XML, existed as early as the mid 70s, nearly all publishers worked with authors to submit hand-written manuscripts, which were scanned and keyed into a word processor, then later into a design tool for layout and finally into an Adobe PDF for print. These documents were stored in a traditional document management system, where they were tagged with relational metadata for later search and retrieval from the system. Though this mechanism represented a great advance over the prior, manual intensive process of producing published material, it presented a new set of challenges. Powered by relational databases and with a static, rigid methodology for modeling metadata, content retrieval was cumbersome and difficult. The content itself was often stored in Adobe PDF format, an inflexible medium that did not easily permit the changes common in post-production publishing. When the content management category first emerged, no one had heard of that category, either, and the early CMS systems had to differentiate themselves from Document Management systems. Howard Schwartz, June 2010 Such solutions also typically involved a workflow component. However, more often than not, these were difficult to create and even more difficult to use. Most publishers resigned themselves to maintaining their workflow process as they always had, shuffling papers back and forth among staff with handwritten annotations on hard-copy print outs of PDFs. Finally, and most importantly, these constructs were developed to manage documents and not content. Assets within content, including image files, citations, figures and tables, were either ignored or placed into third-party databases where they were left isolated. 4
THE ADVENT OF XML AND NATIVE XML DATABASES (2005 2012) XML has been a part of the publishing industry since the 20th century, first arriving as SGML, then later a myriad of XML schemas created for and by each publisher to correspond to its content. XML fundamentally changed how publishers think about their content. Now, rich tags could be used to describe sections of content and make it more discoverable. However, the advent of native XML databases once again changed the paradigm. Content, rather than documents, became more important. No longer was there a need to break documents into chunks and place them into relational databases. Instead, content could live in a native format within the database and new query formats such as XQUERY and XPATH could be used to search seamlessly across the content set. We started to realize that SGML, with its focus on syntax and its many features designed to make the syntax easy to type, made SGML difficult to process in the context of things like visual editors and content management systems. W. Eliot Kimber, August 2013 While early content management system implementations were significantly faster and more flexible than traditional document management systems, the technology stack on which they resided still presented challenges. These solutions had to incorporate a heavy technology stack to supplement the shortcomings of early XML databases. Things like metadata management and document workflows were not in the scope of these databases, and thus had to be addressed with a more classic approach, including adjacent relational databases and traditional application stacks like Java. This heavy technology stack introduced new problems, including the challenge of querying the different databases for data and a marked increase in maintenance efforts. One additional challenge presented by these early CMS implementations was the need for non-technical users, such as authors and editors, to become deeply knowledgeable in XML. The use of XML introduced a whole new way to represent familiar abstractions. Now, in addition to thinking about the content, users needed to think about how to express its structure in XML. In the end, while some publishers met success with these solutions, many were disillusioned. Implementing a content management system was an expensive endeavor, with a long-term commitment to a system that would forever require maintenance and specialized expertise. True content management remained an enigma. 5
PUTTING THE C INTO A COMPONENT CONTENT MANAGEMENT SYSTEM As always with the evolution of technology, early adopters who deployed early CMS solutions challenged the existing paradigm. Why is it that publishers need to understand technology, or even XML, in order to deploy a successful content solution? And how could we deploy technology to solve these problems in a more generic way, reducing the cost and making products accessible to everyone? Ann Rockley, founder of The Rockley Group, describes a CCMS in this way: Component Content Management is the practice of creating and managing content as building blocks or components of content rather than documents or pages. 1 Starting in 2012, new products and services arrived on the market that resolved these difficulties. These solutions, called Component Content Management Systems (CCMS), leveraged native XML databases without a complicated technology stack. Search and retrieval, content modeling, versioning and re-use were available but abstracted under easyto-use, dynamic interfaces. A universal digital publishing format for the open web benefits the entire industry and ultimately consumers, who want the freedom to read on their choice of applications and devices. Bill McCoy, February 2012 Building on the work of many industry working groups, these solutions moved to adopt open standards. In this way, they facilitate automatic conversions from Microsoft Word or LATEX and allow authors to continue working with authoring tools that make them the most comfortable. When these authors or editors do need to make changes in the system, they do so in a web-based interface that modifies the underlying XML without ever seeing or touching it. Publishers could now access their content faster and dynamically assemble their content into new products that can be quickly taken to market. Streamlined tools allowed publishers to retain all the advantages of XML without ever needing to see or understand it. This approach, called transformation-based development, is quickly becoming the industry norm. 1 CCM Takes Center Stage: Report Evaluates Component Content Management Systems and XML Editors http://thecontentwrangler.com/2008/05/15/ccm_takes_center_stage_report_evaluates_component_content_management_system/ 6
KEEP IT SIMPLE As the industry began to embrace open standards for authoring and publishing digital content, systems evolved to specifically implement these standards. The result was systems with a significantly lower cost point and less customization effort required. In this section, I discuss this in more detail. TRANSFORMATION-BASED DEVELOPMENT (2013 AND BEYOND) At its core, Transformation-Based Development has a simple concept use and deploy open standards and tools to abstract the complexity of CMS technology such that customizations to a CMS do not require custom software development. This results in a more intuitive system, a low cost to deploy and an even lower cost to maintain. This methodology is possible for several reasons. First, content loaded into the CCMS Microsoft Word, for example is based on open standards (sometimes even XML) and can be transformed automatically. Second, output formats such as InDesign, HTML and EPUB also have defined, tagged formats and likewise can be generated through a transformation. These inputs and outputs are tied together by the adoption of an open-source XML standard within the software such as DITA, DOCBOOK or NLM. With out-of-the-box solutions that transform between these formats, most of the work is done. Underlying XML can be displayed in a screen-friendly format for publishers. The XML, however, persists within the native XML database, allowing content to be easily searched, re-used and assembled on the fly. 7
LESS CUSTOMIZATION AND MORE INNOVATION Innovation is not derived from custom features it is derived through the creativity of your product managers and their ability to rapidly find and re-use content in your repository. This is only achieved by leveraging open standards, off-the-shelf tools and a streamlined process knitted together through an easy-to-use, intuitive and responsive interface. TIME TO MARKET One of the most crucial aspects of deploying a CCMS is time to market. A CCMS allows a non-technical product manager to find assets within the system and quickly re-use them to create new digital offerings. Within that context, it is important to understand that these product creation processes simply must allow for rapid development of products without any intervention from IT staff, let alone external technical solution providers. How does a CCMS do this? In utilizing open standards, a CCMS can allow rapid search and navigation of system assets not just content, but images, audio, video and other related content, and drag-anddrop re-use. While these systems certainly make full use of underlying XML constructs, the visual interface itself should not show tags or XML of any kind. 8
CONCLU- SIONS While technologists dominated early digital publishing, advances in technology have opened digital publishing to everyone. If your organization failed to embrace content management because of costs and specialized knowledge, now is the time to look again. Publishers implementing CMS solutions in recent years have a significant advantage, as commercial software is available that can be deployed to get them started within weeks, if not days. Unfortunately, too many publishers are implementing large-scale, custom solutions that are difficult to manage, non-intuitive, and require costly ongoing support and maintenance. Below are a few simple rules of thumb that publishers can follow to ensure a cost-effective and efficient component content management solution that produces new products without significant customization. 9
ENSURE TECHNOLOGY AND CONTENT MODEL ARE STANDARDS BASED Simply put, by embracing standards, publishers invite lower long-term maintenance costs. Adoption of a standard is paramount to creating a more flexible framework and easier integrations with other applications within your ecosystem. LIMIT CUSTOMIZATION TO TRANSFORMS WHENEVER POSSIBLE Publishers often believe that their needs are unique, and sometimes they are correct. However, before embarking upon a custom software solution, it is imperative that each organization looks deeply at its needs and evaluates whether those needs can be met without such development. With the abundance of available software, both commercial and open source, the creation of custom software is rarely necessary. Heavy customization, particularly with compiled languages such as Java and C#, result in long-term maintenance of custom solutions that well outweigh any possible benefits. 10
LIMIT YOUR TECHNOLOGY STACK From a practical standpoint, collecting all of your content into a single data source is highly advantageous. Workflow metadata is a prime example if it is not contained in your principal database, multiple queries using multiple query languages are necessary to not only interrogate that data, but then to properly merge it. These queries are difficult, slow, and sometimes impossible. YOUR EDITORIAL TEAM SHOULD NOT NEED EXCESSIVE TRAINING CMS implementations should be simple and intuitive for your users. A training program is reasonable, of course. However, if your editorial team is being required to understand terms such as DTD, Schema, DITA or Action Handler, they are effectively being transitioned into new roles that will at best create inefficiency, and at worst create an ongoing support issue. Here, we must emphasize the value of intuitive editorial tools. If your editors typically work in Microsoft Word, then why force them into an XML editor? Word is, after all, the world s best-known XML editor yes, an XML editor, as DOCX is a compressed XML format. With proper styling, Word documents can be easily converted into the XML flavor of your choice within the CMS. 11
12