LISA Given the array of available products, what prompted you at J.D.Edwards to develop your own content management system?

Ben Martin ECM is a grass roots product that emerged from battling with our own content management nightmare. Once we had solved our problems, we decided to take the system to market because we believe it provides a unique solution.

When I was VP for Product Authoring, I was part of the team trying to manage the nightmare: 25,000 pages of documentation for 90 different complex enterprise products covering information sets of five to 900 pages. We had to keep parity of information in sync first with programmers and then with the translated versions—eight languages for the documentation and 21 for the software. Any change in the English source had to cascade right across every instance of that piece of information in all documents and eventually all languages.

Our starting point was to set up a content authoring methodology for single sourcing, enabling different reconfigurations of the content for different outputs (print, web, CD-ROM and Help files) and over different languages. And part of the initiative involved leveraging all available translation tools that would accelerate this process.

When we looked at the market for suitable authoring solutions that would drive this vision, all we found were XML editing environments. At the time we were using Interleaf for document management and publishing, but it did not have a multilingual authoring environment. What we needed was a system that managed information at the component level, enabling these information chunks to be assembled on request into documents that might be output anywhere—a website here and a Help file there. So we decided to build ECM from the ground up.

LISA How does this in-house need impact the way you handle content for your customers?

Ben Martin We find ourselves increasingly trying to syndicate content (i.e. our guides, training materials, online courses and other enterprise documentation) for our business partners and customers so that they in turn can customize this content into useful, task-tailored documents, and then be able to seamlessly update that content at a later time with newer source data.

For example, they might want to assemble a variety of different topics into an enumeration that reflects their particular business process. Instead of taking the 900-page book about say Accounts Receivable as is, they might need to collect information units from five different sources (inventory management, orders, accounts, etc), reorder and package them, and then push them on to the next level of processing. Then later, they might want to go in and change a given chunk in the documentation to make it corporate-specific, or add in a new piece of content updating the way we delivered their software. What they need is a tool that allows them to manipulate content in relevant ways, and then be able to maintain total information parity when they decide to change one component in the content base.

The most important thing we had to handle when designing the whole process of content management was information updating. And the issue of changing components in documents is of course key to the way the localization industry organizes its workflow.

LISA Effective content change management is high on anyone's agenda when it comes to keeping localization costs down. How does ECM handle this issue?

Ben Martin First and foremost we needed to enable our business partners and customers to adequately document their own implementation of our products. We decided that it was to everyone's advantage to use MS Word as the desktop authoring editor so that any writer could author in a structured environment that puts a certain number of constraints on the content—for example adding metadata and pre-templated tagging to act as a sort of DTD, and thereby simulating an XML editing environment so that we could publish to XML.

Then we had to consider how an authored change in any content would impact on the translation and localization process. Our solution was to focus change in a single place. If you make a change in a single chunk of a document, but that chunk appears in 15 different locations across a content base, then you don't really want to cut and paste the same chunk fifteen times with no heritage links back to the original. Especially if you are then going to translate that changed chunk in sync across a set of languages. You need to ensure that you retain the relationship between localized versions and the original source, and when there is a change to that 'parent' source, know which 'children' and which target languages are associated with it and then launch the translation process from the get-go.

We have also shown that there can be genuine ROI in content localization provided you single source your material in this way

LISA This localization process sounds far easier to manage if you ensure a much closer relationship between content authoring/ management and the translation process.

Ben Martin We're out of the box at J.D.Edwards because we actually have an in-house translation department! We felt this was the only way to continuously improve on the process and observe the evolution of best practice. We have a small translation staff who are trained on our products and participate in the design process. This acts as a laboratory, allowing us to find out how to leverage human skills and then automate the results.

One should remember that, when it comes to localization, most content management systems on the market today simply want to throw the content over the wall to the localization industry and say 'you guys figure it all out and deliver it back in another language.' What we are doing is maintaining the whole family of versions so that an authored change can reverberate through the language versions while ensuring parity of information.

Obviously most people do not do this in-house. We believe in integrating content management into translation memories, so that at a certain stage in the workflow, you can say: I've finished editing the source and it has been approved. Now it's ready for translation, so that the process creates another entity in a new language, but retains its relationship with the original. The file is then sent to the memories which automatically substitute anything previously translated, gets wrapped in XML and handed to a localization provider to finish the translation process. The output then comes back to the corporate warehouse (the CMS) and retains its link to the original, with the metadata and other identity information preserved throughout the cycle.

Single sourcing of content means that a given customer or partner can build a pick list from the knowledge stored in the corporate warehouse, decide that they want the list of topics in a certain order, and ask for it to be saved into Spanish and French. Because of the heritage links, you can specify any content sequence in one language and the system dynamically builds its counterpart in other languages.

LISA ECM's single source strategy for content management focuses responsibility on the authoring stage. How do you relate authoring more closely to localization needs?

Ben Martin We are working internally on another piece of our content management system which is not yet available commercially. This is an innovative attempt to tie terminology management to authoring. Instead of looking at terminology purely as a term look-up task or a translation aid, we are trying to use it to standardize our knowledge taxonomies. The idea is to do a terminological audit on content at check-in time, identify any terms in the new content that are not in the term base and then require at that point that the author uses a pre-approved term or submits their own 'new' term for review.

In our own case, we have cross- language terminologists and we define multilingual terminology up front so that the document author or software developer who is developing the term must take a first cut at what it is used for and have it reviewed by other language specialists right away.

In other words, we are trying to bring the management of multilinguality upstream to the authoring stage, instead of leaving it downstream where you simply become a victim to everything that happens earlier in the process. We believe that there is a clear need for processes that demand the highest integrity both of authoring and at all levels of the translation process. This is true for content that is authored with internationalization in mind, or for a workflow which has globalization processes in place. The content is tied to terminology management and to translation memories and is conceived of as a single whole. The aim is to manage content right from the start with language parity in mind, instead of adding it on as an afterthought. We believe that our strategy of bringing multilanguage management to the forefront throughout the process is unique in the CM industry.

LISA How did J.D.Edwards come to develop such a localization-centric culture at senior management level?

Ben Martin In 1992, our then CEO said: "The word is our number one enemy. If we don't solve it, we'll go out of business." So right from the top there was awareness that unless we controlled our content, we would be unable to scale and survive. But in those days we only had 30 products and one publishing platform, and the only content management was for reference guides, so many of us considered the CEO wrong to worry. We even thought that if we sourced the content just once, we'd get grief all over the place.

Today we have 90 products across multiple platforms and we have scaled to content that feeds training guides, online help and special Help files for specific customers. So it was that original from-the-top decision that led us to develop ECM.

The fact that we in-housed our translation also helped us to look at the content localization problem as an integral part of knowledge management. And one key result of this internal development work is that we can leverage not just the technology but also best practice in content management across languages. And this is crucial to our customer offering.

LISA Who are your ECM customers, technology partners and competitors?

Ben Martin So far we have 28 ECM customers, ranging from Cargill and Gateway to a raft of smaller players who use it in their manufacturing or distribution processes. We have positioned it for the mid-market and see Interwoven and BroadVision as potential partners who would receive our content and do their web magic. An obvious competitor would be Documentum.

Many of our mainstream customers are struggling to get content into other languages. The content people usually say it's some other department's problem, but even their authoring people are increasingly being held accountable for what happens at the translation stage.

Other customers are companies looking to expand from the USA into Mexican or French Canadian or European markets where they find less tolerance for English only. What they are buying with ECM is the promise of building on our best practices. We supply them with our own content as a starter pack, and they can then tailor it to their needs. But some customers are using ECM to single source their own content from scratch.

For example, one client in the cruise business is looking at using ECM to manage its recipes. Authoring information chunks one at a time, they can later pull them together in different combinations and configure them for different cruise populations. Another customer might use single sourcing to handle contracts: individual clauses can be reconfigured by the system to match the local needs of a given party.

We have not yet run any focus groups to find out how it is all working. Most of our know-how comes from building the system for our own needs. But we believe what we have done is ahead of what is currently available, and provides a solution to a widely-ignored part of the content landscape. Most of the current CMS packages are exclusively focused on the web, yet a given chunk of content—say a company overview—may well find its way into the annual report, onto the web site and into any number of marketing brochures. Any efficient localization operation should address this array of outputs and keep language parity across them all, rather than use a system dedicated to triggering change detection only on the web content.

On the technology partnering side, TRADOS is an official development partner. We want to interoperate with all translation tools and we are looking at various vendors in terminology management, memories and machine translation to explore co-development possibilities. In fact we use TRADOS internally, so we are planning to re-license our own translation memories to our customers. Not only will we give them the content, but we can include the French and Spanish versions as well. So our memory content becomes of value to our customer base, and not just to our internal translation operation. We are also a corporate sponsor of LISA's OSCAR SIG: We believe that memories need to serve the business, and by having an interoperable format, this serves everyone.

LISA Next steps?

Ben Martin We shall continue to work on tying terminology management into the upstream authoring process and extend best practice in this area. We are also looking at how to integrate machine translation into a holistic vision for managing multilingual content.

As for emerging content markets, we realize that e-learning offers a very rich store of English only material ripe for localization. If we can tie our processes into online corporate universities and learning spaces, we will also be able to achieve parity of learning content across languages.

More generally there is a huge opportunity for linking unstructured multilingual content into our structured repository data—in other words plugging ECM type processes into ERP systems. For example, one could link employee name and number data to résumé routing so that it channels directly into learning content for skills upgrading; or build a contract system that ties into price format and then goes across languages, with the price format changing as the country and language change.

---

Ben Martin (Ben_Martin@jdedwards.com) is Vice President of Global Content Management for J.D. Edwards, responsible for developing and delivering a new generation of content management solutions to the J.D. Edwards client base as well as to the content management marketplace in general. Prior to joining J.D. Edwards, Martin served as Documentation Manager for New Generation Software and as a technical writer for Davis Oil Company. He also has been a contributing editor to News 34/38, now called 3X/400 Systems Management and is an active member of the Society of Technical Communication.