May 22, 2003
By Pat McGrew, EDP
Welcome to the HVCO Data Management Pavilion of OutputLinks.com!
We have been talking about the relevance of transform programs. We started a few columns back with a discussion started on a popular forum by a vendor who proudly announced that print streams should not be converted. We explained the flaws in his reasoning in previous columns.
He ended his discussion by saying that if you had to convert a print stream or you had to extract data from a print stream, your best solution was to do it yourself. That's where we pick up the thread this time.
I have to start by saying that I am a proponent of in-house programming organizations building applications and being masters of the data universe when appropriate. Often, an in-house programming group has the best understanding of the company business as well as the stress points in the organization. Because they live with the business problems they are able to craft solutions that might not be possible with off-the-shelf solutions from vendors.
However, when it comes to the task of working with print datastreams it is a rare corporate programming group that is prepared to take on the requirements of understanding all of the datastream variations, historical nuances, resource management issues, data placement variations, and the inevitable feature enhancement that comes with deploying any product in the enterprise.
Considering vendor offerings to meet the requirements to transform composed print streams, extract data from composed print streams, or manipulate composed print streams is often the most cost effective and time effective approach, and comes with a number of benefits. First, vendors typically see a much wider range of print streams than the typical enterprise, so their programs are designed to handle those challenges. In fact, you'll often find vendors soliciting for poorly formed print files and problem files on industry forums so that they can test their parsers against them.
Vendors also provide support. While you might not consider this a key feature, think about the current load on your internal programming groups and the programs and processes they currently support. In most enterprises they are already overloaded, and each time they are called on to add a new program to the in-house arsenal the load on their time increases. For these types of transform programs, when there is a problem the application owner needs help fast, and vendors are typically equipped to meet that goal.
Then there is the question of time to implement. As noted in previous columns, programs that transform common HVCO print formats to other common print formats and web formats are in the marketplace, available for you to trial today. If you were to take on the task of writing a transform on your own (and many have done this) there is the question of how long it will take to design, code, test, and implement. How long does it take to design and code a program that parses a print file and recognizes all of the variation, reads external resources and interprets them into a new file format that produces an identical view of the file? The answer will be different for every organization that takes on the challenge, but from personal experience I can tell you that it is not a trivial process.
Let me clarify that a bit. Three times in the last 20 years I have been on the periphery of the development process for program products that manipulate or transform print datastreams. While I was not the designer or programmer, I did have documentation responsibilities that caused me to play the role of quality assurance and testing associate as well as technical writer. Let me tell you what I learned next time.
If this is valuable, drop us a line at pm@outputlinks.com!