Re-inventing Frankenstein or “Engineering an old workflow with new tools”

Our project manager included this in her kick-off meeting invitation a week ago:

If implementation is scheduled to occur on 12/31/09, then we have 163 business days to do “everything” from today, 5/12. <reality check>

I support a Composition department that has a very complex workflow system. It’s a combination of internal web servers for file storage and job-tracking, Macs running third-party applications, lots of custom-developed applications, lots of scripting and lots of managed preferences.

For the next several months, we’ll be re-engineering this Frankenstein system that we developed for about $2 million four years ago and has generated over $100 million since then. The project’s goal is to bring all software up-to-date so that we are poised to be able to transition to a different platform in a few years if management decides that’s the best direction. My goal is to re-engineer what I put together four years ago, applying new technologies and knowledge that I’ve gained during that time.

Roll-out of the re-engineered system for about 90 Macs in two different countries (the U.S. and India) takes place over a weekend.

Frankenstein mine

While I didn’t develop the workflow for this department, I do have to support it.

Working files are stored on an internal web server that acts as a file server for our QuarkXPress documents, graphics files and customer-supplied files. The server also acts as a job tracking system, allowing users to check-in, check-out and version documents.

Jobs are downloaded to the Mac workstations, using some of our custom software, and worked by human beings for tasks that cannot be automated. However, when users are ready to print, proof, upload documents or create PDFs, they have about a dozen custom-developed tools and third-party XTensions/plug-ins that ensure accuracy and speed. Some of these tools have specific settings or preferences that may need to be tweaked a few times each month. That means I have to package these new settings and get them installed on every machine, often with less than a day’s notice.

Most everything we produce for our customers must meet some sort of government filing guidelines, so accuracy has to be 100%. Because this is a high production environment with such stringent requirements, one slight change in procedure or one out-of-date preference can break something else and result in malformed data–translation: unhappy customer. An unhappy customer means an upset departmental manager and that means I have to fix problems fast. Better to do everything right the first time.

Looking back to see forward

Exactly four years ago, we had this exact same scenario.

The Composition engine was using QuarkXPress 4.0 on Mac OS 9 and we were managing Macs using FileWave. At the time FileWave was limited in the number of configurations we could manage and management was clunky. I had to remote control our server and drag updates or changes to different “folders” in FileWave. These updates would be copied in a trickle of bits to the workstations where they’d be installed and force the user to quit his applications or restart his computer to get the new updates.

Under Mac OS 9, fonts and preferences would get corrupted and make the Macs unusable for users on all three shifts. Building or rebuilding a machine literally took 24 hours because of the way the system was designed. I would curse under my breath when I’d sit in front of a workstation because my hands were tied by the FileWave software that was preventing me from doing simple maintenance such as deleting those corrupt preferences.

We moved from Mac OS 9 to Mac OS X 10.3.9, QuarkXPress 4.0 to 6.5, various Adobe products to Creative Suite and, of course, updated all our XTensions, plug-ins and custom software. Six months later, we scheduled to upgrade to Mac OS X 10.4. The goal for that project was to simply recreate the same workflow in an updated environment. Little functionality was added.

Our goal for this new project are similar, however, we’ve heard rumblings from management that they’d like to possibly switch in the future to a Windows-based solution using InDesign. If we were to attempt to do that today, we’d have to develop an entirely new system. None of what we use today–documents, fonts, software–is portable.

My recommendations were to approach this in five steps, never tackling more than one or two at a time:

  1. Upgrade to Mac OS X 10.5 or 10.6 to simply maintain stability with software and hardware. Upgrade to QuarkXpress 8.0 too. This will buy us time for the managers to make their final decision about the direction we should proceed.
  2. Convert our PostScript fonts to OpenType fonts throughout our QuarkXPress and supporting documents. This puts us in a position to use the same fonts on Windows and we’ll clean up any licensing issues.
  3. Use something like Markzware’s QuarkXPress to InDesign converter to transition documents. This puts us in a position to move to InDesign on Windows later if desired.
  4. Replace all remaining PowerPC hardware with Intel hardware during the next few years. This allows us to continue using our expensive Mac hardware to run Windows later.
  5. Run InDesign with OpenType fonts on Windows on our existing Macs. This gives us the most bang for our hardware buck.

Tools assessment

My saving grace is that I get to choose how I support this department and its Frankenstein workflow system.

In January 2006, we transitioned these tools:

I call the move to Mac OS X one of my “tools” because I can do things such as SSH into a machine while a user is working and I can lock down permissions on applications and fonts to prevent corruption issues.

In this next upgrade, I’ll continue with using Casper 7.0 and Apple Remote Desktop 3.2. These are very scalable solutions that have well met our growth from just 50 Macs in the one department to nearly 90 Macs in two countries. I’m really looking forward to using Casper 7.0 because it will have new features that will let me replace many of my imaging scripts and preference files with MCX settings–all without having to have a Mac OS X Server machine.

For now, we’ll stick with Mac OS X 10.5 even if the announcement for 10.6 unexpectedly includes support for PowerPC Macs. If it does then our hardware needs are already met and we’ll be able to upgrade six months later, but if it doesn’t then we need to replace lots of G5 Macs in the near- to long-term future. Our development efforts are now standardized on this OS version.

I’m anxious to begin posting how I’m able to use my new tools to do the same job more easily and much more efficiently. A simple one for starters: using launchd for Extensis Suitcase… next.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s