15 February 2001

Computerheads romp past geeks?

by Bob Felton

Translators needed.

A reputation for being very smart but extremely boring and overly fussy isn't necessarily a bad thing. You can usually convert doubters to head-nodding agreement by jotting down equations they don't understand, you're generally left alone to go about your business as you see fit, and nobody wants you to chair the Company Picnic committee. An engineer's life, all things considered, is pretty good: respectable pay, interesting work, and a free hand.

A free hand, that is, until that bunch in information technology (IT)-appliance repair kids cum information technologists, if you please-took over. Now, like Tribbles, they're everywhere. Home brew some code to do some little thing that needs doing and poof! -on the next day, it and the compiler have been squeegeed right off the hard drive. All that's left is a testy e-mail about company policy regarding unauthorized software. Rip open the CPU to install a cool new board and, sheesh! -you'd think somebody had put a goldfish in the water cooler.

And a simple, authorized system upgrade such as a CD-ROM drive can take months-even though once upon a time, a guy could just go out and buy the thing, then crawl under his desk and install it himself.

IT role expanding

Making matters worse, the IT group is insinuating itself into areas once exclusively the province of engineers. IT staffers often pick the software engineers will use and, on the plant floor, sometimes presume to say what remote devices will be selected, how they'll be installed, and how the data they generate will be processed. Occasionally, engineers learn of software and hardware decisions affecting their work without so much as a word of consultation or warning, quite as if the choice of tools engineers use is not any of their business.

Broadly, the matter is that neither department wants "outsiders" messing with its equipment: Engineers don't want computer folk tinkering with their production lines, and IT doesn't want rogue systems snagging at the electronic doily that modern facilities rely on. Further, because responsibility for computer systems has historically been vested in most companies' financial operations departments, engineers have always been obliged to go, hat in hand, to colleagues who don't understand manufacturing in order to get what they need.

That was all right when the two departments otherwise crossed paths only in the lunchroom, but networking, IBM's introduction of the PC, and the migration of both departments to a common platform brought overlapping interests that changed everything. "It's an ownership and budgetary problem," said Jim Pinto, a widely read industry observer. "Each person," he said, "felt that the other was meddling."

Small wonder, then, that engineers and the IT department are so often at odds. At least part of that difficulty is a misapprehension about the nature of engineering work; most nonengineers assume a blueprint tells the whole story, failing to understand the large role that experience and judgment play in good design and smooth operation. But if IT is biting off more than it can chew when it tries to say how engineers should use computers to drive production lines, engineers have been more reluctant than they ought about acknowledging that maintaining modern PCs and operating systems (OSs) is a full-time specialty.

Engineers should abandon, too, the fantasy that they're terrific computer programmers. Engineers could and did teach themselves to write code and develop serviceable, single-purpose programs when the world was 8 or 16 bit and relatively simple OSs reigned supreme, but networked, multithreaded Windows applications require more development skill and programming know-how than most engineers possess or are interested in acquiring. When you consider the Internet, the pell-mell growth of communications options, and management expectations of instant answers to any question, matters grow even more complicated: Seamless data sharing is of the essence-and that requires true top-to-bottom systems integration.

What next?

Where's it all leading? Glenn Harvey, a past executive director of ISA, minced no words following visits to approximately 100 vendor and user companies during the past year: "Computing hardware and software, Internet, and wireless technologies," he said, "are playing more dominant roles in control these days. This, along with corporate shedding of engineering departments and the integration of plant data with MIS, is moving the responsibility for control technologies into the IT groups."

But Pinto, likening the chronic differences between the groups to a large-scale control process, sees a correction under way. In his view, tensions are diminishing because the departments have finally grasped that they need each other. "The IT people," he said, "are beginning to recognize the importance of cross-fertilization." Among engineers, "the old 'till hell freezes over' generation is disappearing."

Roddy Martin of AMR Research agrees that the two camps are coming together, but he offered different reasons. The problem, in his view, is that, "for a long time, business abdicated its role in IT." Management, he said, was intimidated by a technology it didn't understand and allowed IT departments to run amok. Now "business has taken ownership of IT," he said, and restored it to its proper place as a tool. "You can't have IT setting business strategy."

The computer expert of 10 or 15 years ago is now legions of experts: a specialist in using specific applications, a network administrator, a database administrator, repair technicians, and more. A decade ago, Overland Park, Kan.-based consulting engineering firm Black and Veatch created an internal, project-based position called process architect, an engineer who would represent the engineering group's interests to the IT department. To make certain that IT listened, the process architect held the checkbook. "That was key," said Ed Edmondson, a vice president at Intergraph who once headed Black and Veatch's IT group. "They had to listen."

In a variation on that theme, aggressive young engineers chasing the money are joining company IT departments and, one foot in each camp, working as translators of a sort. The result is that yet another computer-based specialty is emerging: liaison to the client departments.

Relief is coming in another form: Thanks to the widespread adoption of open, well-documented, Internet-based communications protocols by instrument manufacturers, selecting, installing, and communicating with remote devices isn't nearly the delicate task it once was. Plug-and-play interchangeability has simplified matters.

"Instrumentation," Harvey said, "will become commodities-e.g., sensors, control valves, transmitters, PLCs will be part of the hardware design, along with piping components [pipe, elbows, tees], other fittings, HVAC components and other hardware. The common requirement will be that all electronic components must be compatible with data transmission protocols. The software and hardware guys, like the Democrats and Republicans, are just going to have to reach across the aisles and find common ground to, together, keep the world running."

Academics have taken note of the problem. Universities are sponsoring symposia to discuss it, and graduate schools are starting to turn out engineers trained in IT issues and usage. Those measures will help eliminate some differences, but getting system upgrades installed will probably remain a problem for a long while to come. IT