Single-Sourcing Blog

Moving Day!

2009-05-24T13:32:00.001-07:00

This blog is moving to http://blog.single-sourcing.com. Please reset your feeds.

Growing Arbortext craftsmen

2009-05-24T10:27:00.001-07:00

Arbortext knowledge has traditionally been very tribal in nature. Like Oracle DBAs, what is not learned through trial by fire, is passed down user to user, developer to developer.

We've been thinking about how to change that. We're helping found a formal user group -- working through the PTC/User organization -- that's focused strictly on Arbortext. We're thinking about how best to achieve that goal with members spread out all over the world.

We've been thinking about this for more than a year it took us about that long to figure out what we wanted to tell the world about what we do and how to provide real value and relevance to the Arbortext community.

We've had a lot of members looking for a way to share knowledge and benefit from what others are learning. For example, when Oracle merged with PeopleSoft, there were Arbortext implementation teams on both sides. When they got together, they found they'd fought the same battles and could have shortened their implementation time, could have made the lives of the Arbortext users in their own communities stronger, if they'd had a forum where they could share.

In addition to this blog, we're about to start podcasting. The podcasts are our attempt to bring tribal knowledge to light. We'll be talking with PTC customers -- real users from the Arbortext Community -- because, at Single-Sourcing Solutions, we all started as customers. And we all learned from other people: other customers, other users, and internal PTC/Arbortext resources.

We have found that people who learn Arbortext are premium resources to their companies. Nearly no Arbortext specialists are out in the wild. Every new customer has to grow a specialist from scratch. And it’s not easy to do. The learning curve is high. You need to learn a new product and to learn how to implement it well. That takes time and resources.

Consultants play a part similar to that of the journeymen of the guild systems: they often travel a lot, work at many different companies and spread new practices and knowledge between companies and corporations.

To become a journeyman, an apprentice must first become a craftsman.

Our goal here is to is to expand the resources available to everyone in the community. If you’re working with the product — or just want to learn about it — please join us!

We’ll respond to feedback from our audience so we can all achieve what we all want to do: to be masters of our craft.

Going enterprise vs going toolbox

2009-05-12T05:57:00.000-07:00

Recently I've had the opportunity to think about my first single-sourcing project, specifically the way we went about it.

Silicon Valley is notorious for being a difficult place to sell software into: You can't throw a rock on the street without hitting 10 software engineers (today, 3 of them are looking for work). And, as a result, there's culture of do-it-yourself that is magnified because implementation and customization work is work that software engineers do.

Although this situation is magnified in the valley, it's not unique to it. In this economic climate, the pressure to leverage existing resources is tremendous everywhere.

So I took the time to sit back, think about what our true costs were to do things the way we did. It's the classic discussion: build vs buy. And, until the last several years, I'd thought we'd done it right.

Now, I'm convinced we didn't.

As a full-time employee, hired to make the project come together, I saw the cost of the tools as the only cost. I saw the resources at my disposal -- me, IT, people I knew in engineering, the skills and technical bent of the writers in the group -- and I saw the cost of tools vs the cost of the enterprise system.

While I can say I learned a lot through trial by fire, the full cost of implementing the system the way we did was a lot higher than the cost of purchase would have been.

Most Techpubs departments don't get the luxury of having a software engineer dedicated to their needs. Writers are typically tasked to add tool admin and implementation to their ever growing list of responsibilities. Many writers stop being writers entirely. The don't get to generate, architect, and design the company's information strategy, they end up tied to implementing and maintaining the toolset.

This gets more and more difficult the more content you have. As the need for a real information architect grows -- as it always does -- the ability for that tools-focused writer to have any part of the content side of things falls away to nothing.

It took 4 years from concept to stable, production environment. The costs included my salary over those years. The time from several IT staff members at the beginning and over time sustaining and making process changes. The time from engineering staff who were co-opted here and there along the way. The time from engineering staff was an invisible cost -- it didn't show but it diverted their much more valuable time from product development to tool implementation and maintenance.

This is an extremely expensive to the company that we're all quick to ignore when we're not thinking of the larger business needs.

If we had gone the enterprise route, bought a 'system' that we could leverage out of the box, we'd have seen ROI in 2.

4 vs. 2: That's an expensive lesson.

In this economic climate, it's very easy to ignore the hidden costs of toolbox solutions. Enterprise solutions are more expensive than toolbox solutions, but they have a different goal -- for a reason.

They're value is in are things like these:
* Eliminating manual effort
* Simplifying product version– or configuration-specific deliverables
* Tracking when product changes requires documentation updates
* Automatically identifying all affected documents when changes occur
* Integrating all of the components up front and building solutions that work together out of the box.

Every situation is different. If you've got a software engineer, or a writer that wants to be one, then your choices are different from the group that doesn't have the funding to get support from IT. Doing more with less applies to products as much as to staff members. Less hassle, less implementation work, less sustaining costs year after year all mean that you are doing more with less.

In an enterprise solution, everything is tested together, deployed together, and upgraded together. In other words, enterprise software vendors have done the work of building the system so that you don’t have to.

Arbortext User Group - Public Chat

2009-01-23T15:10:00.001-08:00

With everyone spread out all over the place, several of us have been working together to figure out a way to have user group meetings online. We are thinking that a group chat + conference call will be our first attempt:

Arbortext User Group hosted by lizfraley.

Join now

Chat about what's on your mind. More about public chats.

Podcast of Content Management Strategies Presentation

2008-09-19T16:44:00.000-07:00

Thursday, 18 September 2008, I was at the Intermountain Chapter of the STC. I spoke about “Repurposing Content for Multichannel Publishing.”, the presentation I gave at the Content Management Strategies conference earlier this year. Tom Johnson, one of the members, kindly taped and posted a podcastof the presentation. Accompanying slides can be found here.

My thanks to the Intermountain STC Chapter for allowing me to come speak to them. Extra thanks to Tom for taping, editing, and preparing the podcast. We had a good discussion following the presentation. Everyone asked really strong questions and provided a lot of insight into what they were doing and the issues they were facing.

Part 4: Top Three Resources for Arbortext Users

2008-07-29T15:29:00.000-07:00

This is part four of the four-part series

If you're an Arbortext User, you should know about these resources:

Mailing list hosted by PTC/User

The PTC/User portal (http://www.ptcuser.org) hosts the long-running Adepters mailing list. Arbortext engineers monitor the list as well as many long-time users and tools folks. If you have a question, it's a really good resource.

The List Email Address is: adepters@lists.ptcuser.org

You can join the list from the PTC/User portal: http://portal.ptcuser.org/index.php?mo=fo&op=si

The Adepters Information Archive

The Adepters Information archive is located here http://www.adepters.org.

Many Arbortext users regularly search it for help with difficult to solve issues. The archive was started by Karl Johan Kleist. In 2008, Karl changed career paths, and I've been maintaining it ever since..

Mailing List hosted by Yahoo Groups

Yahoo Group Name: 3b2users

3b2users is a list for users of Advent 3B2, now called Arbortext Advanced Print Publisher, for the exchange of information, hints and tips.

Introduction to DITA: A User Guide to the Darwin Information Typing Architecture Arbortext Edition - JoAnn Hackos

Although not an online resource, this is Arbortext-specific. Procedures and Examples in this book use Arbortext Editor.

Read the complete series:

Part 1: Resources for folks doing single-sourcing projects

Part 2: Top 6 book choices

Part 3: Top 12 online topic-specific resources

Part 4: Top 4 resources for Arbortext users.

Part 3: Top 12 resources for XML authoring and publishing projects

2008-06-29T15:35:00.000-07:00

This is part three of a four-part series.

These resources are good for folks who are getting started on XML or SGML authoring and publishing projects or who are in the middle of one.

singlesourcing-mgmt

Singlesourcing-mgmt is a moderated mailing list for those interested in the management of single sourcing and related topics Single-Sourcing

xml-doc

xml-doc is a mailing list where writers, developers, product and service vendors, and others discuss the application of XML, SGML, and related technologies to structured authoring, particularly authoring of documentation for computer software and hardware.

comp.text.xml

The Extensible Markup Language (XML).

comp.text.sgml

ISO 8879 SGML, structured documents, markup languages

dita-users

This group supports users of DITA.

Docbook.org

This is the official home page for all things Docbook.

S1000D Users

S1000D Users Google Group is an online community for people who want to learn more about S1000D and related standards from other professionals. The idea is to form a peer organization focusing on the practice of sharing experiences, issues and collaborating with members worldwide.

svg-developers

This is a mailing list for anyone who is interested in developing SVG content, or in helping others solve development problems in either the SVG format or in scripting. Discussions tend to be very technical.

XSL Mailing List

The open forum for the discussion of XSL -- Extensible Stylesheet Language.

XSL-FO

XSL Formatting Objects discussion group. All questions are welcome. As the group grows hopefully we can share our experience and growing knowledge.

ZVON Repository

The best online library for specific XML-related technology. They have a Reference Library and Tutorials.

svdig

Although this is the mailing list for the local Silicon Valley DITA Interest Group (SVDIG), lots of good information shows up here as well.

BONUS: FOSI Tutorials

People were always looking for FOSI information and it's been nearly impossible to find useful stuff until this became available.

Read the complete series:

Part 1: Resources for folks doing single-sourcing projects

Part 2: Top 6 book choices

Part 3: Top 10 online topic-specific resources

Part 4: Top 4 resources for Arbortext users.

Part 2: Top 6 books for people starting XML/SGML publishing projects

2008-05-29T16:00:00.000-07:00

This is part two of a four-part series.

I have never found the one book that describes how to put it all together. These are the top 5 books, I'd recommend to anyone starting a single-sourcing project. They're a selection of books from both sides of the issue: the writing side and the programming side. Together, they begin to bring any project into focus.

The XML Handbook (2nd Edition) - Charles Goldfarb & Paul Prescod (Prentice Hall:2000) (ISBN: 0130147141)

All about XML.

Definitive XSLT and XPath - G. Ken Holman (Prentice Hall:2002) (ISBN: 0130651966)

This is the ultimate xlst & xpath book.

Definitive XSL-FO (Charles F. Goldfarb Definitive XML Series) - G. Ken Holman (Pearson Education:2003) (ISBN: 0131403745)

The authority for learning XSL-FO

Developing SGML DTDs: From Text to Model to Markup - Eve Maler & Jeanne El Andaloussi (Prentice Hall PTR:1996) (ISBN: 0133098818)

Although this book is written about SGML, the basics for data modeling are all here and apply to XML projects as much as to SGML projects. This is a great basic data modeling beginner's book.

Single Sourcing: Building Modular Documentation - Kurt Ament (Noyes Data Corporation/Noyes Publications:2002) (ISBN: 0815514913)

An excellent book for people staring single-sourcing projects. How to plan and implement as well as how to handle the inevitable staff issues.

Introduction to DITA: A User Guide to the Darwin Information Typing Architecture Arbortext Edition - JoAnn Hackos

Procedures and Examples in this book use Arbortext Editor.

Read the complete series:

Part 1: Resources for folks doing single-sourcing projects

Part 2: Top 6 book choices

Part 3: Top 12 online topic-specific resources

Part 4: Top 4 resources for Arbortext users.

Resources for Single-Sourcing Projects (Part 1 of 4)

2008-04-29T16:38:00.000-07:00

This is the first post in a four-part series.

Folks starting single-sourcing projects are faced with insufficient resources. The biggest problem with the existing literature is that nearly all of it is theoretical in nature. Most books on single sourcing contain advice about planning, managing, and creating modular projects and documentation. At this, they are very good. What they’re all missing is the bridge between theory and practice. And they’re not alone.

I have found that most of the single-sourcing literature is aimed at writers or managers, not implementers. I created this list when I was hired on my first single-sourcing project. I was hired to design and implement not to manage. I wouldn’t be selling upwards: my director was championing this project throughout the company. Someone else would be doing that. Someone else would be determining ROI and measuring success. Nor was I the project manager, even though I would help determine which tools we eventually choose.

What was not aimed at managers was aimed at writers: guidelines for writing and designing modular documentation. This is something else that I would not be part of and should not be. The writers who would be using the single sourcing system would be planning their documentation, just as they always did. This sort of information was valuable as a look at the point of view of the user, but it wasn’t what I was looking for as an implementer. But I knew that these books would be essential for training the writers to write and think modularly.

The programming literature is nearly as bad. The XML programming book that don’t describe its implementation as a language describe the multitude of ways you can use XML. They tell you how to write the XML and how to process it: They do not tell you how to make XML work in a single sourcing environment. In addition, the programmer-oriented books are not aimed at either of the groups that the single sourcing documentation targets. XML authors assume their readers have a programming background and already understand programming concepts.

I have never found the one book that describes how to put it all together. You make choices—good and bad—along the way that influences the way you implemented particular pieces. You choose a set of tools. You do as much or as little customization as you're comfortable with and as your goals require.

My goal has always been to provide specific examples that can serve spark ideas to solve someone else’s real problems. That is the best any case study can do: Give you an idea about what you can try. Hopefully, all together, these resources will help bring your project into focus.

Stay tuned for the next parts in the series:

Part 2: Top 6 book choices

Part 3: Top 12 online topic-specific resources

Part 4: Top 4 resources for Arbortext users.

Starting a User Group

2008-03-12T13:37:00.000-07:00

We're doing our best to start a local PTC/User chapter in the San Francisco Bay Area. We have setup a MeetUp page and are preparing to launch this organization in coordination with the national PTC/User organization. When Arbortext was acquired by PTC, a lot of things changed for existing Arbortext customers. We were used to speaking directly with Project Management and with Developers (when necessary), and we had a strong and successful relationship with our Sales Representatives. After the acquisition, this changed dramatically. Sales Reps were replaced by VARs and many support calls were replaced by proposals for consulting work by PTC.

A lot of this has to do with the way PTC has traditionally done business. It also has to do with the separation between PTC and PTC/User. In this new structure, PTC expected that much of the user support and interaction for simple questions and implementation issues would be handled between users at local RUGs (Regional User Groups), through mailing lists, and the online PTC/User bulletin board.

After two years of adapting to the PTC world view and after becoming a PTC partner, we finally understand how to improve the experience of PTC/Arbortext users: We have decided to start one or more local user groups, to support the regions that our partnership with PTC defines. The SFBay RUG is the first. If you're in the SFBay, and you want to be a part of this group, please see the meetup page. Local customers will also be receiving an invitation from the PTC Channel Sales manager. If you're in another region, we'll do what we can to help you get a RUG started in your area, too!

SF Bay Meetup Page

PTC Technical Committee Meetings

2008-01-17T17:32:00.000-08:00

I recently joined the Technical Committee for the PTC Arbortext product line. The technical committee is a customer-focused mini-conference where the attendees are customers of PTC and PTC project managers.

In addition to the Arbortext TC meetings, I attended two meetings for the other product lines -- Windchill and MathCad.

The Arbortext meetings were each hosted by two PTC project managers. One PM presented a particular feature ("Review") or product (Styler) or application (S1000D); the other would record, take notes, and run the projector (as most presenters were remote). The discussions were geared at finding how customers are using the product, what work-arounds they're doing, so PTC can address these as necessary. As in, what prompted the work-around and can they improve that experience?

The Windchill meeting had 4 user presenters who got 30 minutes each to present an issue and answer questions. These sessions were also hosted by a PTC PM, but the presentations were by user/customers. After talking to the Windchill users, this appears to have been the standard for the Windchill presentations. They said there was only one that was driven by PTC.

The MathCad meeting was similar to the Arbortext meeting, in that it was PM driven/presented. These guys are a lively group of users! I did some usability testing for the next release of the MathCad product. It's very friendly to new users. I haven't used MathCad (or maybe it was MathLab) since my Calc 3 class in college nearly 20 years ago. I had no problems writing or changing equations or doing simple problems (provided by the usability test).

Over the last two years, as PTC/User has taken over the annual conference, Arbortext users have been consistently disappointed by the lack of PTC presence there. We were used to having developers and product managers there to talk to, discuss issues and problems with, and discover strategies for handling particularly tricky requirements that weren't so easy to do. The Technical Committee structure appears to be the forum for that sort of interaction between customers and PTC. The focus was very much on finding out what issues customers have in the product and what the nice-to-haves and must-haves are. At the end of each session (not including Windchill), there was a prioritization of issues that came out during the session discussions.

We also got a bit of a preview of what's to come (to be updated in 6 months at the TC meetings in June).

Keep the Control in Your Hands

2008-01-03T14:03:00.000-08:00

While I'm writing about S1000D, the same philosophy applies for transferring DITA, Docbook, and XSL/XSL-FO knowledge to your staff:

Our goal is to provide expertise to help customers grow to proficiency. We find that companies rarely need an expert on-staff. Expertise is expensive, especially when used for tasks that go beyond that initial expertise need. Experts are doubly expensive when paid to do tasks that do not truly require that proficiency. For example, why pay an expert on S1000D to write about airplanes just because the format is S1000D. A writer, who is an expert on airplanes, is much more competent to do the writing; the writer (significantly less expensive than the S1000D expert) just needs some training in using S1000D; they already have the subject matter expertise to do the actual writing task. In addition, the a writer, now trained in multiple doctypes, is a much more valuable, and flexible resource for you in the end.

As a result, our approach has been to provide the expertise and skills to companies who need intermittent expertise or who want a long-term relationship with an expert who can be available when necessary and who goes away when they're not. Intense training, implementation, and knowledge during the early stages of a project that helps our customers get customers.
We can participate as a de-facto member of your team and:

* Participate as a de-facto member of your team. We would participate as a technical expert in early project calls with your customer, lending you our credentials and experience so you have a better chance winning over your customers.
* Assist in implementing PTC's Arbortext products. We are an authorized PTC reseller and have more than 8 years implementing the PTC Arbortext product line for publishing.
* Mentor your staff. We assume that our customers do not want to be dependent on us. Part of our culture is to teach our customers to do everything necessary to do the current project and all similar project they undertake in the future. We truly act as mentors, teaching staff not only to do the work, but how to think about how to do the work, so they will be able to do the same kinds of projects independently in the future.
* Provide a jump-start for your staff. We provide a project-ready foundation, not just basic training. Our training and mentoring is always centered on your project. We help develop the work-product for your customer during the initial stages of the project while your staff continues to comes up to speed. This way, your customer sees immediate productivity and your staff has a usable basis for the ongoing product that they used to learn on.

In short, as a retainer-based consultant, we provide all the benefits of having an expert on staff without incurring the cost of having that full-time expert on permanent staff. We:

* Give you S1000D productivity immediately, giving your staff the time and space to come up to speed
* Train your staff in understanding, learning, and developing content that is S1000D-compliant
* Teach your staff to analyze and implement customer business rules in general
* Discover serious gaps in the any business rules you have received that will impact your ability to deliver content to them and drive resolutions to your customer
* Provide long-term on-call expertise, allowing you to amortize the cost over the length of the relationship and bill to actual need

Although expensive, the expert consultant is available over the entire project lifetime, and the cost can be amortized over the length of the project. Costs are billed only as used and have a guaranteed, built-in cap that corresponds to the proficiency of your staff--your ultimate goal. This method provides a guaranteed mentor and long-term resource for staff members to query and learn from, as they come across particular tricky or rarely-used content models over the lifetime of the project.

We typically propose a intensive training period at the beginning of a project. We us your data (or your customer's data), so your staff learns and produces at the same time.

Our retainer-style mentoring and training program stretches over the lifetime of your project and has a possibility of coming in well below the estimated costs. Final cost is completely based on your staff's progress and feelings of proficiency. By working with us, and amortizing your cost over time, you have the ability to improve your profit margin. The faster your staff progresses, the sooner your need for us ends, and the lower your final cost will be.

The progress your staff makes is completely with their own control. The more they work with the technology, the better foundation they start with, the more comfortable they'll be, and the sooner they'll stop feeling the need for an on-call expert to assist them.

The control remains in your hands, rather than ours.

And we like it that way.

Helping Arbortext Customers Get Started

2007-12-28T10:39:00.000-08:00

After years of impartiality, we've decided to focus on what we do best: helping people get started. Regardless of your choice of doctype, we know that writers and publishers still need the right tools to be successful. We want to help people learn to take charge of their xml publishing projects.

After the acquisition of Arbortext by PTC, we saw an steady increase of new customers having problems implementing Arbortext based on insufficient information from inexperienced PTC sales staff and reseller-partners.

When I started working with Arbortext products, I was also learning XML, XSLT, publishing, content management, all at the same time. I was lucky enough to have a part-time expert consultant available to me to help get me started. She did the initial print stylesheet development, and taught me as she went. I was learning the technology while learning on a concrete example that, more importantly, was an actual deliverable! None of the training was generic or unrelated to what, eventually, I needed in order to deliver published documents on-time and with high quality print composition.

In addition, I was able to apply the lessons to begin the rest of the multi-channel outputs (3 versions of HTML, Palm Reader, and eReader) and have the expert consultant review my early work, help with hints to better optimize my code and polish my final output, as I took over and she phased out.

The expert was expensive, but we came in far, far under budget with respect to her. Having an expert do intensive training for me (as well as the early authoring staff), on our data, producing product-ready deliverables went a long way to getting me ready to maintain and enhance our publishing environment long-term.

It also got me ready a lot faster than we expected. We kept her on retainer for a period of time after the intensive training period. And we got our money's worth out of her. We were able to control our costs with regard to her: she was never sitting around or doing work that I was destined to do, or doing work that wasn't a product of her expertise.

It was a system that worked so well, we've been doing the same for our customers ever since.

We joined with PTC as a direct result of hearing customers cry out for temporary expertise that would help them get their staff proficient in the Arbortext products and technology. These were customers with limited budgets, that wanted to keep the work in-house, and grow the necessary expertise with existing staff resources.

We decided that we would answer the call and help customers who wanted what we wanted: working, polished, resusable content that could be published easily and efficiently with staff resources who were capable of making it happen.

The Complete Triangle

2007-12-21T11:53:00.000-08:00

Attempting single sourcing with help from only one side is a recipe for disaster: Customers spend large amounts of money, resources and effort but don't get the system they expect. Customers should plan to research all three sides of the triangle and do a lot of planning from the start. Only then will they get a complete, extendable, and workable solution that benefits their entire company and sees return-on-investment from the very beginning.

Single-Source Solutions experts have implemented successful solutions by paying attention to all three sides of the triangle. Our implementers have presented at conferences and written papers about their previous experiences.

The Product Side: Vendors and Application-Specific Specialists

2007-12-18T16:28:00.000-08:00

Product companies focus on developing full product suites to cover every possible customer. Their literature focuses on amazing application-specific features and why their products are the best choice for any environment. These companies work hard to sell products and consulting services to implement their full-scale systems.

Several vendors sponsor think tanks and white papers that help implementers understand the components to any single-sourcing system. Many provide resources for information on single sourcing and XML. Often these resources surpass the boundaries of their product line.

Some of the major players in the single-sourcing product space are:

* Arbortext
* Documentum
* XyVision
* More Vendors

The only problem with this side of the triangle is the problem that faces nearly every vendor. Competition is fierce. Products are expensive and generally so generic that it takes a considerable amount of customization before you have any sort of working environment. These companies do their best to make sure their products fit your requirements—rather than making sure that your requirements fit their product suites. It's a rare vendor indeed that recommends a competitive product instead of one of their own.

In the end, with any of these companies, customers will get an implementation that works. They all have professional services that provide expert implementation assistance. So, at that, they are very good. But this group too is missing the rest of the triangle. Often solutions are awkward and don't scale well to meet changing requirements as companies grow: they're focused on sales rather than the general theory and technology that are essential for a well-designed customer-specific solution. They miss the application-sepcific opportunities where documentation meets source development because they're desiging a system for the here-and-now. So again, we find that they are not alone.

The Technology Side: Programming Nuts and Bolts

2007-12-15T13:08:00.000-08:00

The technology companies focus on XML as a programming language. The methods for code reuse, found in Object-Oriented programming literature, are similar to the methods used to achieve modular writing. Code reuse is the assertion that if you build generic objects they can be used and reused. It is the idea that you can isolate functionality into a module (function) and then use that module rather than rewriting the code. The ideas are the same. Unfortunately, the programming literature faces the same implementation gap, from the other side.

The XML programming books, which don’t describe its implementation as a language, describe the multitude of ways you can use XML. They tell you how to write the XML and how to process it: They do not tell you how to make XML work in a single sourcing environment. In addition, these books are not aimed at either of the groups that the single sourcing documentation targets. XML authors assume their readers have a programming background and already understand programming concepts.

* Books
* Online Resources

The only problem with this side of the triangle is that nearly all of the literature is technical in nature. Most books on XML contain information about programming XML applications—from programming XML compilers to web-services. At this, they are very good. But this group too is missing the rest of the triangle. The components that bridge the nuts and bolts of technology and real-world practice. And, once again, we find that they are not alone.

The Theory Side: The Information Management Consulting Companies

2007-12-10T15:05:00.000-08:00

There are a lot management consultanting companies who specialize in best practices: the theory of singlesourcing. Their literature is full of information about strategies, document design techniques, and how to choose a tool or evaluate a product. These companies work to create standards and generalized rules for making single-sourcing work in traditional publishing environments.

These companies have excellent information on their websites about how to get cost savings through single-sourcing, how to write modularly, or how to structure your documentation. When you're first learning about single sourcing, you can't find better resources:

* S1000D Technical Publications Specification Maintenance Group (TPSMG) TPSMG is responsible for the development and maintenance of the ASD/A1A S1000D international specifications. S1000D describes a standard for the creation and publication for technical publications utilizing a common source database

* The Center for Information-Development Management Founded by Joann Hackos, the CIDM provides "a focused, expert, and progressive forum to support documentation, training, and customer service managers in creating high performance teams that produce effective and appropriate deliverables."

* The Rockley Group Members of the Rockley group work with clients to develop "information solutions through a unified content strategy, either for a particular project or across an enterprise. "

* Single Sourcing: Building Modular Documentation by Kurt Ament This is one of the only books that attempts to bridge the gap between the single-sourcing theorists and the technology developers.

Hackos, Rockley, Ament are, to a significant extent, the existing authorities in theoretical single-sourcing and information design. Their websites have everything the beginning single-sourcer could need. Their books (and conferences) are extremely useful. They are full of detailed information to teach managers, writers, and document designers how to think about single sourcing.

The only problem with this side of the triangle is that nearly all of the literature is theoretical in nature. Most books on single sourcing contain advice about planning, managing, and creating modular projects and documentation. At this, they are very good. What they’re all missing is the rest of the triangle. The components that bridge theory and practice. And they’re not alone.

The Single-Sourcing Triangle

2007-12-03T20:05:00.001-08:00

Single sourcing is a simple idea that requires a very complex implementation. Single sourcing is a methodology, not a technology. XML is a technology, not a methodology. Bringing the two together is not obvious or well-defined. No one system that works for every customer. No one book describes how to put it all together. On this page, you will find places that will help you figure out where to start.

One of our goals is to help customers make the choices that will allow them to implement a system that scales. Necessarily, for any concrete project we must choose a set of tools and we must decide how to implement particular components.

At Single-Sourcing Solutions, we remain vendor-neutral and platform-agnostic. Most importantly, we avoid unnecessary customization, so that our customers can take advantage of new products and new technology down the road.

The Single-sourcing triangle includes the Information Management folks (theory), the Programming folks (technology), and the Vendors (products).

What we do

2007-11-30T15:15:00.000-08:00

Single-Sourcing Solutions experts bring XML technology and single-sourcing theory together to make "write once, publish everywhere" a reality.

The goal of any single-sourcing project always the same: To increase the efficiency of the entire staff as the demand for documentation increases while staffing and resources do not.

Successful single-sourcing solutions address several key needs:

* The authoring environment must be user-friendly and easy to learn.
* The look and feel of the published documents must be comparable to the existing published documentation.
* The environment must scale easily, so that it can be altered and enhanced without major infrastructure changes going forward.
* The tools and processes must fit customer project needs.

For us, single sourcing is more than just theory. It's a practical, reachable goal for any company.

Single-sourcing environments promote efficiency and productivity by reducing maintenance and overhead. Our team looks for the tools that support scaling and productivity. We tune existing skills, workflow, and processes to new tools that help single-sourcing efforts achieve success in their environments.

What we do:

* Full-Gamut Single Sourcing: Code, Definition, Help, Documentation
* Automated publishing to multiple media: print, PDF, Web, Palm, eBook, CD-ROM, wireless
* Develop tools to facilitate document creation and editing tasks
* Deliver classroom instruction with sample documents and exercises tailored to your business
* Assist legacy documentation conversion
* Application-specific XML tools development

To customize or not to customize

2007-11-08T16:33:00.000-08:00

The Arbortext product line is not a turn-key solution. Through no fault of the software itself, there remains a certain amount of work that must be done before the whole solution will deliver production-ready documents. The fault lies in the intersection with available XML technology and customer-specific needs and requirements. We encourage our customers to pursue standards-based, customization-free (or -light) implementations. Standards-based solutions ensure customer's get the best for their needs.

Application-specific XML tools development

2007-10-10T17:06:00.000-07:00

"Any Application, Any Industry, Any Project, Any Platform"

Opportunities for application-specific XML integration exist everywhere in the product-production life-cycle. Technical Publications organizations have been pursuing single-source solutions primarily to solve issues of quality and production of multiple-output formats. As these organizations mature, many look at ways to automate document creation as well. The tools and applications that we provide are true cross-industry applications.

And, if single-sourcing for reuse and automatic documentation production is the first step, then the exporting of content to other business organizations is only the second. The third step is to look at the entire product development process to identify opportunities for automatic content creation because mechanically-produced schema languages can be converted automatically into documentation and documentation templates.

This means that opportunities for practical XML development and deployment include:

* Full-Gamut Single Sourcing: Code, Definition, Help, Documentation
* Revision Management: Where Source Development Meets Documentation
* Application-specific XML tools development

For example, many applications have XML interfaces. For products that take advantage of XML as part of their implementation, creating tools that can automatically generate documentation is an obvious target for integration into a single-sourcing solution. For products that don't, tools can be created that transform native programming languages into XML, as needed for documentation purposes.

More on application-specific XML tools development

2007-09-05T12:27:00.000-07:00

Auto-Generate Content From Documentation

Documentation is the foundation for a product collateral and for support reference material. Information about specific technical requirements and product specifications is duplicated in technical manuals, marketing collateral and support knowlege bases. Keeping information current and in synch in all of these places is an enormous task when all these systems are isolated, separate systems.

Customers get better, more accurate, and more consistent information when the information creation and publication is tightly woven together in a single-sourcing system.

* Improved Customer Relationships
* Improved Data Integrity
* Consistent, Accurate Information across the business

Application-specific XML tools development can improve accuracy and information integrity for customers. By developing tools to integrated independent business systems into a larger single-sourcing environment, you see an immediate improvement in data integrity. And customers see an immediate improvement in their relationship with your company.

These are just some of the many ways that other organizations with your company can benefit from content generated from Technical Documentation are:

* Online help required in the Product Source Code
* Technical Support Knowlege Base Articles
* Marketing Whitepapers and Data Sheets
* Customer and Partner Portal Content

Benefits of application-specific XML tools development

2007-08-03T09:46:00.000-07:00

Auto-Generate Content For Documentation

Documentation for technical manuals can be generated directly from the product source code or other engineering systems. Technical requirements and product specifications can be found in source control repositories in varying formats. Product-specific information may exist in operations databases, price lists or manufacturing database systems.

* Unlock Isolated Business Systems
* Auto-Generate Content
* Simultaneously Generate Content

Writers in Marketing, Technical Publications and Technical Support Groups all independently generate all of the the same content from all of the same business systems across the Organization. Without a single-sourcing environment, all these groups generate the this content repeatedly as the details change and the information, locked in the various business systems, gets updated over time.

Application-specific XML tools can unlock the isolated business systems and compile information to auto-generate content simultaneously for:

* Technical Reference Manuals
* Time-Sensitive Release Notes
* API-Specific Implementation Information

Revision management

2007-07-09T16:44:00.000-07:00

Where Source Development Meets Documentation.

In traditional publishing environments, source control is minimal if it exists at all, and often follows the lock-modify-unlock model that prevents simultaneous, collaborative, content authoring.

Single-sourcing environments require source control management to manage the reusable content stored in topology-specific libraries (including images).

* Independent Change Tracking
* Historical Change-Tracking Reporting
* Simultaneous, Collaborative Document Authoring
* Partial-Regeneration for Fully Updated Output
* Multiple Documents Created from One Source
* Reduced Translation Costs

Source Control and Content Management. The best content management system is the one that matches your business requirements and your information model. Choosing a content management system can be easy or hard, expensive or cheap. If your analysis is sound, and your information model well developed, you can always avoid both expensive and hard.

Multiple-Document Profiling. XML technology and metadata provide a way to create multiple virtual documents from one original source document.

Reduced Translation and Localization Costs. XML is ideal for reducing translation and localization costs. Because information authored in XML is in a structured, non-proprietary format, translators can get document fragments that show only the changes between one revision of a document and another. Translators only translate the changed parts.

Integration with Product Development. In some cases, the document creation and publishing process can be integrated directly into the source development system. In other cases, the source development system may be an output target of the publishing process. With proper planning, the single-sourcing system can be integrated directly into the source development system.

Full-Gamut Single-Source Solutions

2007-06-04T09:42:00.000-07:00

Code, Definition, Help, Documentation and Training

Single sourcing is a simple idea that requires a very complex implementation. By leveraging XML technologies and single-sourcing methodologies, our experts develop the systems that support every member of the technical publications team.

Mission-Critical, Custom XML Applications in single-sourcing environments can help all the members of the technical publications team:

* Authors can write content once and use it everywhere
* Editors can run reports on content before sitting down with a hard copy
* Production editors can automate production tasks
* Everyone can Focus on Content, not Formatting

Single-sourcing makes reuse possible. Content can be used multiple times within a single book or multiple times across multiple books. Writers and editors can focus on writing content, rather than formatting content. Reuse, automation, and the separation of content from format, improves the efficiency of every member of the technical publications team.

One Source, Many Outputs. Single-Sourcing Solutions consultants help customers output for all required mainstream output formats including: Web, CD-ROM, Palm, ebook, and Online Help. Through application-specific XML application development, we can produce other output formats tailored to your specific business requirements.

Vendor-Neutral, Platform-Agnostic. Our vendor-neutral, platform-agnostic approach guarantees that we design a system that is specifically tailored to your business needs.Single-Sourcing Solutions helps customers make the right choices every step of the way.We help you define requirements that let us choose the best tools and the best way to implement particular components.

From Analysis to Training. Our team begins with a complete analysis of your existing documenation set and business processes. We develop all initial applications and content management repositories, and then train your people on every component and every tool.