All Posts in Organizational Design

|In: Leadership|Last Updated:

ATHENS, GREECE — The Parthenon stands on the fields of the Acropolis overlooking this ancient, modern city. Built some 2,500 years ago during the height of Athens’ power and influence, its age and commanding architectural grace and sophistication inspire a sense of awe that requires presence, not mere description. It stood more or less intact until 1687 when a Venetian artillery shell exploded the Turkish ammunition dump stored in its heart, which should give you a healthy dose of respect for its builders.

We can only wonder whether our best structures will last even a fraction of that time to inspire awe among our own successors. The ancient Athenians, lacking our finely tuned understanding of economics, built the Parthenon as well as they could, not merely as well as they could cost-justify.

We in IT work in more ephemeral materials than marble, but even our own modest efforts persist far longer than we expect, or even prefer. Our own legacies … systems … outlast at least the employment of their builders, stubbornly resisting attempts to replace them.

Why are they so hard to replace? They are, after all, just software, aren’t they? Well, no, they aren’t. They, along with such items as factories, warehouses, and the knowledge and experience of non-transient employees, form an organization’s infrastructure — the basic foundational framework on which an organization is built. It’s an overused term these days, but one whose meaning is worth preserving.

Infrastructure, we’re told, is strategic, but it’s deeper than strategy. A company’s infrastructure is its soul if you think in such metaphysical terms. If you’re more hard-nosed, it defines both enablers and constraints — a company can change strategies more easily than infrastructure, but the each company’s infrastructure predisposes it to some strategies while creating severe constraints that inhibit others.

Yeah, yeah, buddy, but how does this affect me today? Deeply and subtly, that’s how. Take stock of your existing infrastructure, what it enables and what it inhibits. It’s part of what a CIO or CTO brings to discussions of company strategy. More, when you’re planning new major systems or system replacements, drive the discussion beyond specific process requirements to explore which future strategies it will enable and inhibit.

It’s fashionable to talk about the compression of business cycles these days, but companies that are in business for the long haul understand that underneath all the nimbleness of rapid change must be an underlying stability.

Let the Parthenon be your inspiration.

Comments

|In: Industry Commentary|Last Updated:

Times change, and few programs warrant eternal life.

Take, for example, the U.S. Patent and Trademark Office. Established to encourage innovation, it now encourages patent holders to use attorneys instead of engineers to protect their marketplace position. Close the Patent Office and companies would have to win by getting to market first and innovating the most.

A program that has even more clearly outlived its purpose is the H-1B visa program. Created to help American companies deal with a shortage of skilled programmers, it lives on in a time of high IT unemployment. Let’s replace it with something better suited to our present circumstances.

What should that look like? Beats me. Keeping foreign programmers out altogether, like banning foreign cars and clothing, is protectionism, which just makes America uncompetitive. CIOs and CTOs, under heavy pressure to cut costs, would simply move more programming work off-shore, whether or not it’s a good idea.

And it probably isn’t, as quite a few readers pointed out in response to my recent column, (see “The IT rust belt,” 7/15/2002). Successful off-shore development requires strong separation of systems analysis — to create perfect, detailed specifications, immune to both misinterpretation and the changing needs of a dynamic business — and coding to those specifications without adding creativity or business insight.

That’s fine for cut-and-dried conversions, upgrades, and minor maintenance work. For anything more interesting, this approach didn’t work even when it did work. Which leaves IT management and American programmers with a shared problem: How to make on-shore development cost-competitive with off-shore development.

There’s no single solution, but there are opportunities. Here are three:

1. Adopt methodologies that merge programming and analysis into a single discipline. This will save both time and labor.

2. Take real advantage of modern development tools, which should cut coding time by easily ten times or more compared to IT’s bronze age of hand coding and batch compilation.

3. If you need inexpensive developers, look to small-town America. While you won’t find wages as low as in Bangalore, India, they’ll be lower than in Manhattan or Silicon Valley. Meanwhile, even the biggest language and cultural barriers — between, say, Californian and Southern, will be relatively minor in comparison.

Comments