Tight-vs-Loose Integration

Updated: 2017

I started working with XML and single-sourcing systems in 1999. Although both SGML and XML had been around a long time, vendors were still figuring out a lot about how the overall process should work because every implementation was different: DocBook did both too much and too little and was frequently customized. DITA was just coming into being. Content management systems were fairly new and not yet sophisticated. They, too, were dealing with specific, specialized problems (translation vs supply chain vs software configuration management).

And in 2005, I got caught working on a migration project from Interleaf and RDM (the Interleaf CMS) to SGML and LiveLink.  Interleaf and RDM ran only on Windows NT, which had reached the end of support from Microsoft (the true EOL). They had to get content out of RDM, out of Interleaf, and to something that wouldn't take out all of their business assets if the system crashed.

End of life for software is serious. In some ways, there's no way around it. As a profession, software vendors haven't solved this problem but they're also not motivated to do so (the money is in the upgrades). We can't fault them, that's how it is.

Smart purchasers take this into account and think about the issues of tight vs loose integration and vendor lock in when they're looking at investing in an enterprise tool.

Here's what I was up against (from my journal in 2005):

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. It's all due to how tightly they were integrated by Interleaf to start with. Interleaf integrated their authoring tool and their content management tool tightly, because they knew how both sides were implemented (and were doing both). They took shortcuts and hid things from the users. Now, the users can't make the shift because they never saw the lines between the products.

You need to know where products start and end. So do your users.

If you have a CMS from one vendor and a publishing tool from another and an authoring tool from a third. You absolutely must know where each vendor draws the lines for their responsibility. When push comes to shove and you've got a deadline and money at risk if you don't meet that deadline, you need to know how to determine which vendor to call based on where the problem is and where they believe their responsibility starts and ends.

I can't tell you how often I've heard frustration from people who have mixed systems and can't get a problem fixed because all the vendors are pointing fingers at each other.

It's impossible to diagnose a problem if you don't understand where your vendors draw their lines in the sand.

At one company, I supported a team of 25-30 writers using Arbortext Editor on a flat file system. On any given day a writer would come to me and say Arbortext wasn't working. And every single time it wasn't working because the writer hadn't mapped the server drive to their windows machine before getting started. Arbortext was working fine but because the writer associated it all as one system (one process from their point of view) they didn't notice that the problem wasn't with Arbortext at all: It was an OS issue. Arbortext doesn't map drives; Windows maps drives.

The experience of end users is better when they are not faced with complicated manual procedures to get their jobs done.

Avoiding vendor lock-in does not mean mix-and-match and building glue code. Building glue code actually ties you tighter to both sides: Glue code is 100% application specific.

In 2005, when things were new, you didn't really have a choice. In 2017, vendors have learned a lot. Products are much more mature. Users are savvier. We don't have to do today, what we did then.

(In fact, if you ask any of us who have been around a long time and who have been on the purchasing end of big IT systems, we'll tell you that it's totally worth doing, just NOT the way we did it.)

When you mix-and-match application vendors, or choose a tool that's more toolkit than professional, it's instinctive to start down the road to the glue code that bridges systems together.

Unfortunately, many implementers grow their consultancy by building tools (typically over and over again, by hand each time).

I was guilty of this myself, back in 2005 when the field was new and applications were still figuring things out:

I like being able to develop custom tools that can automating the systems as much as the systems automate process, without being overly toolkit-y. The one thing we all know is that no vendor lasts forever, so I try to avoid vendor lock-in and tight vendor integration as much as possible. There's all kinds of space when products aren't tied together.

Today, things are so very different than they were and my view of vendor lock-in is not so pedestrian.

Open standards matter most where there is stability and asset control.

I still have old 3.5" floppy disks with Word 6 documents on them. I'll never be able to get at that content. First, who has a 3.5" disk drive anymore? And, second, Word 6?

Word 2017 has the ability to output both HTML and XML. Two forms that are great for archival purposes. XML and HTML are ascii. We'll always be able to get at that.

Publishing? Well, that's a bit trickier. There are open standards for publishing XML content. However, publishing is a transformative process. It's not an archival process. It takes one structure (XML) and turns it into something viewable by some technology. Over the last 10 years we've seen brand new display technology (mobile phones, tablets).

For new technology what matters is the Beginning Format (get to the content asset) and the End Result (display format). The path to get from one to the other isn't what's important. As long as you can get from one to the other and provide your asset in the format your customer needs, that's what matters.

Products, like Arbortext, that support access to their application through open-standard, common programming language, and a supported, professional API can only help you along the way. You can always replace the transformer path (and you will because none of us know the future).

Problems with tight integration come when you can't get your asset out of the starting format (Word 6). So you're stuck. You can't get at what you need in the first place. Forget about taking it anywhere...

When you sit down to decide your enterprise implementation make sure you're looking at the right things when you're evaluating vendor lock-in, tight integration, and longevity.