Tight-vs-Loose Integration

Products that support open-standards development are essential for successful single-sourcing projects.

The experience of end users is better when they are not faced with complicated procedures to get their jobs done. Many implementors try to achieve this goal

From a customer's perspective, applications that provide prefer things not to be tightly integrated -- from the vendor. That kind of integration guarantees vendor lock-in. I like being able to develop custom tools that join systems together (automating the systems as much as the systems automate process).

The one thing we all know is that no vendor lasts forever, so I avoid vendor lock-in and tight vendor integration as much as possible.

Sadly, I'm seeing the bad-side of that right now. We had both RDM and Interleaf. IT has just started migrating all the documents out of RDM and into Livelink, but everyone who's ever used RDM + Interleaf is having a horrible time understanding what RDM did and what its purpose was. And it's all due to how tightly they were integrated by Interleaf to start with. They integrated so tightly, because they knew how both sides were implemented (and were doing both) that they took short-cuts and hid things from the users. Now, the users can't make the shift because they never saw the lines between the products.

I prefer applications that support development of application-specific XML tools. Tools that can unlock isolated business systems: for example, import or export data between systems or applications, auto-generate data, automate applications as well as processes.

I'm genuinely afraid that the tight-integration path is the path Arbortext is heading down. Their recent product development (DCAM) coupled with their recent acquisitions point directly to their plan to integrate tightly.

Note that two integrations in two months is very frightening, because it takes way longer to integrate than that. I went through three integrations at Juniper, and I can tell you from experience that it's 6 months to a year before products even start to really plan the integration path.

Personally, I liked that Content@ dropped the raw documents into a catch-all directory. With a situation like that, I can do a lot of pre-processing or post-processing: like generating documents to report errors to writers.

I don't mean XML/DTD errors. I mean errors like .. The style-guide errors that aren't otherwise checkable by the parser alone. For example: I can generate a report to the author that tells them that using two titles in a row without a paragraph between them, or with only an empty para between, is an error.

There's all kinds of space to do this kind of post-processing when products aren't tied together.



Technorati Tag: single-sourcing

Single-Sourcing is a Software Project (not a Documentation Project)

Understanding the staffing requirements for a production quality single-sourcing system depends on two things:

1. understanding the difference between IT and engineering
2. understanding why a group, which has not (at least in recent history) required specialized skills to operate, suddenly does

Think of IT as a mall and TechPubs as a Store in the mall.

Both the mall and the store have specialized staff who help run their business. Both groups have staff members who are responsible for the operation and success or failure of the their particular business. The store depends on the mall to provide a physical location in which the store can do business. The mall depends on the store to provide a source income in order for the mall. The mall depends on the stores it houses to provide attractions that bring consumers to the property. The stores depend on the mall to prived a safe and secure location for customers to do business. Both groups have responsibilities that center around the same customers; both groups work together to achieve the same goal.

But they don't use the same staff to operate both businesses. While the two groups would have several staff members with overlapping skills, these same staff members have completely different focuses. For example, both groups have sales associates. The sales associate for the mall would never be the same sales associate for the store. If the staff for both groups were the same, the mall would be responsible not only for the operation and success or failure of the mall itself, but the success or failure of the stores operating within it as well. This would mean that the mall's sales associates, who would normally be selling space in the mall, would not be doing that because they would be spending their time selling products at every store in the mall.

The focus for each group is fundamentally different. For the mall sales associates, every sale is a single sale: a one-off deal. For the store sales associates, every sale is a repeat sale: every sale is tied to the dynamically changing nature of the rest of the store.

The store can afford to try different approaches, to move products around. If one display works, then everything's great; if it doesn't, then the sales associates change the display and try something else. One failure isn't fundamental to successful operation. More importantly, because of the frequently changing nature of the store, one bad display, particularly one that isn't there very long, isn't visible to customers.

It's different for the mall sales associates. Stores contract locations for long periods of time. Malls cannot afford to have individual store spots empty for long periods of time. One bad contract can mean success or failure: and that success or failure is glaringly obvious to everyone who comes into contact with that mall.

The same things are true of engineering and IT. Engineering groups can try different things out; they can change things on a daily basis in order to improve they way they operate.

IT doesn't have that luxury. IT focuses on projects that support the entire business structure. IT's failures are failures that everyone sees. A failure for IT is a big problem: it's lost money. As a result, IT cannot afford to have people tied up supporting engineering groups on a daily basis. Successful IT organizations bank skills in order to deploy teams to implement and manage the large parts of one-off projects and then move them off to the next one.

TechPubs is one store in the Mall. TechPubs has products and customers and requires a certain amount of infrastructure support from IT, in order to operate effectively. However, in recent history, TechPubs has not required specialized skills, that have overlapped with skills traditionally found in engineering or IT organization. With a single-sourcing system, that's no longer true.

Implementing a single-sourcing system is not a trivial replacement of applications. Since the mid-80s, technical publications departments have been able to trade authoring tools with very little assistance: Let's use Interleaf! Now, let's use FrameMaker! Look, PageMaker! Microsoft Word!
These applications could easily substitute for one another on the author's, editor's, and text processor's desktop computers.

With an XML authoring and production system, this is no longer true.

For example, authoring consistent and publishable documents in Microsoft word requires adherence to a Microsoft Word Template (.DOT) that governs the styles, spacing, and pagination of a document authored in Word. IT would maintain the Word application on each author’s desktop, but it would not normally develop the .DOT template document. Word user specialists would create, maintain, and deploy the .DOT template to the authors using the application. So, just as IT would maintain the authoring application and the publishing application but not maintain or develop the required templates for publishing from a desktop publishing application, they would not do that development for an XML publishing system either.

Look at a typical PeopleSoft implementation. IT would maintain the application, machines, and application specialists. They would typically develop and maintain the workflows that are required for efficient processing. The HR department would also have a PeopleSoft specialist, who would administrate the application, train new users, and provide or restrict access to certain records in the database. In an XML authoring environment, IT would maintain the database and repository, from the application perspective, but someone from TechPubs would have administrate, train, and provide or restrict access to documents in the repository.

In a very general sense, every IT project is a "one-off," a singular project that supports part of the enterprise. IT costs are overhead costs. As a result, if an IT project doesn't work, it's a big problem: the company has lost money on it.

In contrast, functional tools teams can support proactive projects: try something, if it works, good, if it doesn't work, it's not a problem. Engineering organizations are expected to try apply new approaches and new technology to existing problems. Likewise, functional tools teams who support engineering products can also do proactive software development.

For a single-sourcing project to be successful, the way you define the line between the IT team and the functional team (the "tools" team) becomes important. In many ways, this depends on the charer IT has in your enterprise. At Juniper, IT had a very specific job: whenever company purchased a new application, IT would dive in, learn everything there was to know about it, and support it. But they rarely went beyond that point. If an organization needed daily support, they added a functional tools team that took things from there.

IT builds the roads, the functional group buys the cars; the functional tools team customizes and maintains the cars, all while following IT's rules for driving.



Technorati Tag: single-sourcing