Skip to main content
January 20, 2015

XML overview for executives

Over the past year or two, our typical XML customer has changed. Until recently, most XML publishing efforts were driven by marketing communications, technical publications, or IT, usually by a technical expert. But today’s customer is much more likely to be an executive who understands the potential business benefits of XML publishing but not the technical details. This article provides an XML overview for executives. What do you need to know before you decide to lead your organization into an XML world?

1. What is the actual problem?

What is the problem that you are solving? The answer is not “we want XML.” Why do you want XML? Are there other ways of solving the business problem? Make sure that the organization has a solid content strategy. At a minimum, the strategy document should include the following:

  • Business goals
  • A description of how the content strategy will achieve the business goals
  • High-level plan: resources, timelines, and budget
  • ROI

2. Technology is the easiest part.

As with most projects, early tool selection is appealing. It’s a concrete task, there are lots of choices, and choosing a content management system or an XML authoring tool feels like progress. Unfortunately, choosing tools too early can lead to problems downstream, when you discover that your selected toolset can’t actually meet your requirements.

Before tool selection, you should have the following:

  • A general idea of how all the moving pieces and parts will be connected (systems architecture overview)
  • Estimate of business benefits, such as $100K in yearly cost savings or faster time to global markets (four months instead of eight months)
  • A list of constraints (required/rejected operating systems, SaaS or not?, language support requirements)

3. Separation of content and formatting

You’ve probably heard this one. Storing content in XML makes it possible to deliver multiple output formats, such as HTML and PDF, from a single set of source files. This statement is true, but it glosses over a lot of hard work. Many designers are not prepared to let go of their preferred tools for building web sites or printed documents. When you separate content and formatting, you remove the designer’s ability to “tweak” their layouts. The transition from a hand-crafted page (web or print) to automatically generated pages is challenging. For some document types, the final polish you get from manual layout may not be optional. In this case, you have to think hard about what value you get from XML. You can also consider a middle ground, in which you publish into an intermediate format, do some final cleaning up, and then render the final version.

Separation of content and formatting provides for complete automation and huge cost savings, but it is not the right choice for all document types.

4. What is your organization’s capacity for change?

The best solution is the one that your organization can master. Make sure that you assess the following before making any permanent decisions:

  • Corporate culture: Is the organization typically risk-averse? Is it an early or late adopter?
  • Change management: How do employees handle change? How is change communicated? Is change resistance a common concern?
  • Leadership: Does your organization have leaders who can manage change?
  • Technical expertise: Is the solution a good fit for the technical expertise of the staff? If not, what is the plan to address this issue?
  • Executive leadership: Will executive management support this change?
  • Risk mitigation: What are the risks? What is the risk mitigation plan?