Comments on: Is a tool agnostic content architecture best? http://www.author-it.com/blog/2010/01/12/is-a-tool-agnostic-content-architecture-best/ The Author-it Software Corporation Corporate Blog Sun, 22 Jan 2012 20:51:29 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Julio Vazquez http://www.author-it.com/blog/2010/01/12/is-a-tool-agnostic-content-architecture-best/#comment-2882 Julio Vazquez Fri, 15 Jan 2010 12:55:41 +0000 http://www.author-it.com/blog/?p=731#comment-2882 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 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

]]> By: ptrotter http://www.author-it.com/blog/2010/01/12/is-a-tool-agnostic-content-architecture-best/#comment-2877 ptrotter Wed, 13 Jan 2010 23:19:34 +0000 http://www.author-it.com/blog/?p=731#comment-2877 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 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

]]> By: ptrotter http://www.author-it.com/blog/2010/01/12/is-a-tool-agnostic-content-architecture-best/#comment-2876 ptrotter Wed, 13 Jan 2010 21:07:34 +0000 http://www.author-it.com/blog/?p=731#comment-2876 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. 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.

]]> By: Julio Vazquez http://www.author-it.com/blog/2010/01/12/is-a-tool-agnostic-content-architecture-best/#comment-2875 Julio Vazquez Wed, 13 Jan 2010 20:34:26 +0000 http://www.author-it.com/blog/?p=731#comment-2875 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. 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.

]]> By: John Hawkins http://www.author-it.com/blog/2010/01/12/is-a-tool-agnostic-content-architecture-best/#comment-2874 John Hawkins Wed, 13 Jan 2010 17:58:24 +0000 http://www.author-it.com/blog/?p=731#comment-2874 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. 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.

]]>