Is a tool agnostic content architecture best?
I had a conversation today where I was discussing strategies for content architecture with a Fortune 100 high tech company. The person I was speaking with stated that they wanted to create a strategy where the content was completely independent of the tool set used to create and process it.
I believe his premise was that by making the content tool agnostic, that it enables independence from tools, and allows different parts of the organization to choose different tool sets independently to meet their specific requirements. Provided all the tools can magically inter-operate and just load and save the content in the same model everything will be wonderful.
So my question is. Is this really feasible, or is it just a flight of fancy?
My opinion is that if you are focused on satisfying the actual business requirements of users who are authoring, managing, translating, and publishing that content you cannot practically separate the tools from the content because the requirements themselves are not satisfied by either the content model or the tools, but the combination of both.
This is why you never see this type of separation in other software categories like CRM, Financials, or ERP.
If your organization was looking for a new CRM, would they design an independent data model and strategy around managing client information, then find tools that will use the model? I doubt it.
Instead they would most likely gather their business requirements, which by definition need to be independent of implementation, then go to the market with an RFI or RFP. This enables them to consider all the possible ways and technologies available to solve their problems.
I would love to hear your opinions and feedback on this subject.
Paul Trotter
Founder and CEO
Author-it Software Corporation
Yes, this is part of the XML gospel. The idea is that content should be portable across different tools rather than locked into a proprietary format. (That is an issue for other types of applications as well; we’ve had conversations with clients about order management systems and other Enterprise applications that make it hard to find and consolidate customer relationship info.) But when keeping content completely tool neutral becomes an article of religious dogma, it is counterproductive.
In practice, changing tools can be pretty daunting once you’ve got a working implementation, even if you are using a “portable” technology like XML. Once you’re locked into an XML authoring tool or an XML database solution, changing tools is still a big effort. Not to mention changing XML schemas or DTDs.
As you point out, defining requirements in a way that keeps you open to the best solution is key.
For Author-it, I think the most important concept here is that content created in Author-it can be easily ported to other applications via Word, XML, or a truly elegant object-oriented XML. Further, content exchange with other applications is available through the API and optional modules such as the Localization Manager.
Finally, there is also a tradeoff that organizations make among several factors: content consistency; ease of authoring, publishing and management; support for reuse; support for structure and metadata; portability; and other factors. Elevating portability to religious doctrine doesn’t help strike the right balance.
Comment by John Hawkins — January 13, 2010 @ 12:58 pm
I think that you can start a content strategy being as tool agnostic as possible. What you don’t want to do is start a strategy with a tool in mind. After you have an idea of the content and the processes surrounding the content, then you can decide which tool set best meets the needs of your content and your process. Then you need to roll that strategy out to the entire organization and make sure you manage compliance with the entire strategy.
Comment by Julio Vazquez — January 13, 2010 @ 3:34 pm
Great points John! Unfortunately most organizations fail to understand the lock-in to a tool or technology is an inevitable consequence of implementation, regardless of whether the tool or technology is Open Source or based on open standards.
It is not until they are far down the track, and the individuals responsible for the implementation have moved on that they realize how alone and locked-in they are.
Comment by ptrotter — January 13, 2010 @ 4:07 pm
Hi Julio,
I would argue that you should not build a content strategy or content model, but identify business requirements first. Then go out and seek tools, Open Source or commercial, standards based or not, that best meet these requirements. The technology behind these tools becomes less relevant if the business requirements are met.
Remember that things like content portability, scalability, and implementation of a specific standard like DITA, SD1000D, or SCORM can also be requirements.
Paul
Comment by ptrotter — January 13, 2010 @ 6:19 pm
Hi Paul,
Business requirements are definitely an integral part of a content strategy. I suppose that I assume that before you embark on defining the strategy that those have already been gathered because otherwise you’re working in a vacuum and that path leads to disaster. In fact, the requirements should look at the entire information development process from inception to consumption by all stakeholders.
Julio
Comment by Julio Vazquez — January 15, 2010 @ 7:55 am