Technical skills for publishers using a CMS and XML

Publishers often ask us what skills they should have on staff in order to be ready to use a CMS and XML. Our response is that publishers will be more effective if they have staff with the technical skills tied most closely to their content and products. Not every publisher needs to be able to perform RSuite customizations using Java. (In fact, few publishers need or have this.) But every publisher should know their own content and publishing processes. This is especially important when a system is first rolled out, but continues to be useful for normal system maintenance and for those occasional unexpected problems when you need help fast to get your product out the door. It’s not that you can’t outsource these skills; it’s that you will be more nimble with them.

Identifying Your Content Architect Candidates

At RSI we usually refer to someone with these skills as a “content architect”. In most cases, our customers already have one or more staff members poised to take on deeper content architecture expertise, and hiring isn’t necessary.  You’ll recognize these colleagues as the ones you already turn to for answers about why and how things get done.

• They know your content and products deeply.
• They know your processes backwards and forwards.
• They are naturally interested in the under-the-cover details of your existing systems.
• They have technical aptitude – an intuition for how software works or might work. They might also have a background in scripting or another software development area.

Most often (but not always!) these colleagues will be on your print or digital production teams.

Skills and Knowledge Areas to Consider

The following are typical areas of focus for content architects. Each item’s relative importance depends on factors like the volume and pace of your publishing schedule and the complexity of your content and processes. While you don’t necessarily need the same person to be expert in all these areas, having one or two people with broad knowledge across the areas provides the shortest path to solving problems and planning system improvements.

DTD/XSD maintenance

Publishers rarely need staff who can develop an XML schema (DTD or XSD) from scratch, but someone on staff should be able to read your schemas, understand how they are used to mark up your content, and talk in detail with partners, vendors, or other departments who need to use them. This is crucial because you need this skill to manage your vendors (e.g., Is the XML created by your vendor good enough?).

Sometimes it’s useful if your content architect can make minor schema changes and deploy updates to RSuite, but since such changes are rare and rarely time-sensitive, you can usually do without this skill on staff.

Metadata maintenance

Metadata is all the data you use to manage your content and to enable findability and usability on the web and elsewhere. It drives many internal and customer-facing publishing systems. Content architects can help you plan how to build in metadata quality aids and checks, and can diagnose problems when something goes wrong. For example, if topical metadata is missing, content might not be findable on your website or might not be delivered to a partner. How might your CMS help avoid this problem? How can you tell when a problem has occurred?

Transformation knowledge and technical skills

Transformations are the automated or semi-automated steps that convert content from one form to another, such as from Word to XML or XML to ePUB. Transformations are responsible for much of the efficiency gains and product improvements CMS and XML bring.

But here’s the thing: Unless you have products that are very high volume and can be held to extraordinary consistency standards (think “dictionaries”), then your transformations will never really be finished. No sooner will you get one issue or book out the door then you will realize that your next project is just a little different. You need a new type of article, or a new type of layout element. This is normal and this is okay – as long as you can quickly and affordably adjust your transformations for minor changes.

When using RSuite, this means someone on staff (or at least on call) should be able to maintain Word-to-XML mappings and XSLT scripts and the mappings and XSLT scripts responsible for generating outputs from XML. Our most successful customers do light maintenance themselves and call us or other experts only for more complex changes.

Template maintenance

Most of our customers use two types of templates: those for Microsoft Word, and those for their page production systems (e.g., InDesign). Templates define many of the inputs and outputs of your CMS. Along with transformations, they enable you to work predictably and, therefore, efficiently. A staff content architect should understand how templates must be used to ensure successful transformations, and ideally will be able to make minor changes to templates to correspond with maintenance level transformation changes.

Workflow and content lifecycle management

“Workflow and content lifecycle management” is a fancy way of saying someone needs an understanding of the changes content goes through over time, from creation/acquisition through to delivery to all targets, and who or what is making those changes. While the prior areas focus on the technical details of the content and software, lifecycle management adds in knowledge of who (or what system) is doing what when. This holistic understanding is required to quickly debug and correct problems when they occur, and to know when outside help is and isn’t needed.

How to Start?

The best way to prepare someone to be a content architect after your CMS launches is to make them one of the primary participants in CMS implementation. They will naturally learn most or all they need to know through the project. If your content architect is going especially deep with transformations or schema management, then formal training might be desirable, but in most cases it’s not needed. What they will need is some time to gain experience while still being backed up by outside experts.

Your content architect will also need some of his or her ongoing work hours freed up. For some publishers, this work represents only a minutes each day. In other cases, such as when significant new product development goals are being rolled out concurrently with the CMS, this could turn into a fulltime job. Your RSI project manager can help you think through what is most likely in your organization.

In summary, you need a content architect for light maintenance, to solve unexpected problems, and to help plan for content and CMS changes over time. The good news is you probably already have the  right person on staff!

 

RSI began as a consulting company for publishers. In that role, we were often asked by our customers to document their as-is workflows and recommend new ones that would drive electronic product development and efficiency. We spent a lot of time creating massive diagrams. A lot of time. These projects were sometimes useful, and sometimes not. They were useful when we and our customer stopped analysis and documentation before the point of diminishing returns and turned our focus instead to implementing real change and on breaking down barriers to it. They were not useful when our customer was more focused on the perfection of the workflow documentation than on what they could learn from it. (Like, “Whoa, do we really need three different people to perform the same review cycle?” or “Does the author really need a print-perfect PDF proof?”)

As we transitioned to becoming a software solutions provider, workflow analysis was one of the more interesting and challenging areas because we had to actually make those new workflows work in the real world. The timing of this shift for us was accompanied by a shift in perspective by many publishers. Most of our business sponsors no longer have patience (or budget!) for extended analysis projects. They want change, and they are willing to take on some risk to make it happen. Fortunately, what our customers want and what we’ve found really works align nicely. 

Bottom line: Most teams come to us already knowing what they want to change about their business processes (at a high level), can list their most obvious inefficiencies, and have no way of knowing about the other ones that lurk until they move to an environment where they can measure them. Sometimes this is because another consultancy has helped them plan, but usually it’s because they are smart people and they know their own processes because they live with them every day. (Sometimes teams don’t know these things, but that points to management and staffing problems and that’s a post for another day…)

Because most of the teams we work with already know, roughly speaking, what they need and want to do, our job is to guide them towards a workflow implementation that reflects their big goals for change (usually being digitally-driven rather than print-driven), works for every day users, is flexible, and provides enough reporting to inform ongoing improvement. And to get it in their hands quickly. 

Even though we and our customers are smarter than we were ten years ago, there are still plenty of pitfalls in implementing workflow. This is especially true of a system that enables automation of content transformation, product delivery, and other common publishing tasks. Everyone is looking for the Easy Button.

Here are the best practices we follow when implementing RSuite workflow.

1. Keep it simple, keep it loose. Our customers today are mostly willing to forego months of analysis, but they often still want to reflect hundreds of discrete steps in their CMS workflow. Unless you have a legal compliancy concern, this is a waste of effort and will make your team nuts. System workflows with a small number of milestone steps give human beings flexibility in working out the daily details of their jobs and avoid the feeling of a police state. Few publishing processes really follow the documented 500 steps, and often that is for good reason. Don’t hem in your staff with a rigid implementation.
2. Automate, but avoid automation dependencies for your workflows. A business process often has several predictable points at which automation is needed (e.g., conversion of a manuscript from Word to XML, generation of author proofs, delivery). It’s tempting to want to plug those steps tightly into your workflow. In the past few years we’ve taken a different approach. We give users tools to run or rerun automations whenever they need to, but don’t have the workflow engine itself initiate the conversion, delivery, and so on. This simplifies (read, cheaper, shorter) workflow implementation and also gives the publisher the opportunity to change a workflow on a one-off basis or permanently with minimal or no configuration changes. 
3. Don’t forget reporting! During a project it’s easy to get caught up in workflow process implementation and not spend enough time creating truly useful reports. Which leads to…
4. Remember that change isn’t a switch you flip. Rolling out your new CMS and workflows is the beginning of change, not the end. Expect that over time you will want to adjust not only the offline details of how you’re working, but also the workflow itself. Create a habit of reviewing reports and looking for bottlenecks and points of frustrations. Make sure you have a staffing plan that enables you to make small changes quickly. This best practice also means you have permission NOT to rationalize all your business processes on day one of CMS launch. Management often has the goal of getting rid of all the unnecessary inconsistencies among teams, and this is a worthy goal. But sometimes it makes sense to step into that level of change incrementally.

The success of a CMS implementation is ultimately determined by thousands of individual choices made every day by team members - developers, PMs, analysts, and so on. Many of these choices are based on design principles with which business managers might strongly disagree but of which they are often unaware. Occasionally one of these decisions has inordinate impact - a complexity of design that results in a complexity of implementation, testing, and maintenance that is radically inappropriate relative to the value of the feature in question.

Managers who aren't deeply engaged with their teams tend to over-simplify such discussions by saying things like, "So-and-so engineer always makes things more complicated than they need to be." It's true some engineers are hard to manage (and that some managers start almost every new project with unrealistic expectations, and that some users won't give up complicated requirements). But I believe this difference in philosophy is also in play, and a PM or other manager would do well to understand and talk about how a team's varying philosophies impact its members' choices, and where change might be in order.

An interesting article on this topic by Eliot Kimber is here.

Such discussions might seem esoteric, but they absolutely are not.

This Salon interview with Geoffrey Nunberg about Google Books' unfortunate use of metadata is fascinating as an illustration of why a publisher implementing a CMS should focus as much (maybe more) on metadata as on anything else. Bad metadata leads to all sorts of problems, and unfortunately it's a self-reinforcing problem - bad leads to worse as users repeat mistakes, act on inaccurate search results, and ultimately come to distrust the system. By "focus on metadata" I mean publishers implementing CMS should take care in:

• modeling metadata
• the creation of controlled lists and taxonomies
• the design of automated and manual tools for assigning metadata
• the development of automated validation tools to ensure quality
• the development of search that leverages metadata
• user interface design to make metadata easily visible in various contexts (browse, edit, search results, ...) to encourage consistent usage and metadata correction/entry whenever it's convenient to the user

Here's Nunberg's original article in the Chronicle of Higher Education from August 2009 and a related blog post. This topic is obviously fascinating at face value as well - as it relates to the usefulness of Google Books for different usages by different users with different expectations. The comments to Nunberg's article/blog posts illustrate effectively that smart, well-intentioned people strongly disagree on the value of metadata or of particular types of metadata as compared to the benefits of "simply" making content available through fulltext search. This basic disagreement often shows up during design projects for RSuite CMS implementation. Leaders within a publisher need to reach agreement about which metadata will truly be of value internally and to readers and about which types of usage are most important to support. They also need to determine the cost/benefit ratio (metadata is often relatively expensive to do right). If they can't reach such agreements, then it's also unlikely they will consistently and usefully build and leverage tools for metadata in the first place - thus leading to a self-fulfilling prophecy on the part of the fulltext-instead-of-metadata advocates.

Of course, there's also a role here for the technology vendor like Really Strategies - we need to make it as easy as possible for publishers to take the steps on the bulleted list at the top of this post, so that the human effort required to make metadata really valuable is also really efficient.