Liz Fraley: This is the fourth of a series of articles based on the talk I gave at the Content Management 2005 conference. These articles focus on extending single-sourcing systems and activities to integrate content-generating organizations enterprise-wide.
I started off doing mostly XML and XSL development but have started working more in the advisory space — helping companies figure out what they want to do and what they can do.
Believe it or not, I often find myself trying to explain to people why they should not pursue a project. There is this bubble mentality sometimes to go ahead and XMLize everything. This doesn’t always make sense.
Consider the following Venn Diagram with three intersecting circles: CANs, WANTs, SHOULDs.
CAN you do it? Maybe.
Do you WANT to? That depends a lot on who is answering the question and why they’re motivated to look at XML at all (or unmotivated, sometimes).
SHOULD you? That’s the hard one. It mostly comes down to cost versus benefit.
It’s where these intersect — there in the middle — that I work, and for the remainder of this article, that’s where we are. Answering these gives you the answer to “what gets done?” and “how far do we go?” up front — and that can save people a lot of wasted effort, time, and money because it eliminates the problem of “invisible assumptions.”
Efficiency is in the Tools
Originally my talk was called “Efficiency is in the Tools,” but that title produced an unexpected reaction. Most people thought the talk would be a product presentation or a product set recommendation: what are the “best tools” or which vendor has the “best system.” That couldn’t be farther from the point. By tool, I don’t mean product. I mean the scripts and simple programs that join larger applications together in order to produce an efficiency of work.
I will not espouse any particular vendor, application, technology, or product. I have varying opinions on most of them, and my opinion changes based on the problem space being addressed. A product that is right for one customer may be totally wrong for another customer — even when both companies are producing similar products. There is no ultimate best. All you can hope for is finding the one that best fits your situation at this moment in time.
Situations, companies, and requirements are not static. There’s no guarantee that the requirements you have today will be the same requirements you have tomorrow, or next week, or next year. The only guarantee you really have is that all three of those things will change. No matter what system you choose — and how careful you are with your requirements when you choose it — the best you can do is to make sure that you choose a system that provides you with avenues that give you the flexibility to develop the tools that reflect your changing business needs.
This is not a new concept. Recycling content (chapters, graphics, etc.) is not new. What is new here is the common set of back-end structure in XML form and the fact that more than one set of tools — including small, mission critical custom tools — are explicitly focused on the specific needs of a given project. There is no longer any need for one tool to address all of the needs of every company that purchases a license: Single sourcing is not a tool. It is a community of tools that is easy to expand or customize without long term lock in or breaking the model.
That’s where efficiency comes from. Efficiency comes from the automation, acceleration, and merging of applications, systems, and processes that are business-specific. It lies at the edges of those same applications, systems, and processes. This is the argument that is at the core of the off-the-shelf-ware versus custom tools debate.
In a single-sourcing environment, efficiency centers around content development — source development — and its management.