All Posts in Office Politics

|In: Leadership|Last Updated:

I have a confession to make. I like Microsoft Access. In fact, I like it a lot.

The Microsoft Jet database engine is a disaster, but Access itself lets me snap together simple applications in not much more time than it takes me to think through the design. Sure it lacks some niceties, like decent support for recursive data structures. The lack of a macro recorder is simply baffling. Some features blow up inexplicably. Still, all in all Access generally stays out of the way, letting me do what I want to do without a whole lot of trouble.

Microsoft Access lets end-users design simple systems simply. So why do so many IT professionals complain when end-users do just that? Because many of these end-user-developed systems succeed, that’s why. By becoming too successful they become production applications … fragile production applications that require duplicate data entry, disagree with the system of record, disagree with other independently-developed Access applications that have succeeded, and sometimes just plain blow up. Did I mention that the Jet database engine is a horror?

These problems don’t just cause headaches for IT. They cause headaches for the business as well: A workgroup that used to work inefficiently using pencil-and-paper techniques now can’t work at all until its “production prototype” is up and running again; and a department that gets different answers to the same question depending on which database it queries never knows the right answer. To be fair, these same workgroups gave different answers to the same question when they used pencil and paper, too. It just took them longer to disagree.

Many IT organizations, seeing only the cost of the mess and not the business benefit of the automation these applications provide, simply ban Access. I formed the mythical Value Prevention Society (VPS) earlier this year as a place for them to congregate.

Enlightened IT organizations take a different approach to the problem. I’ve outlined some elements of their operation in earlier columns: Train power users in data-design; expose production data to MS Access and Excel (read only, please); and provide advisory services to end-users engaged in developing applications that use these tools.

By themselves, though, these steps mere ensure each individual application behaves as well as possible. It doesn’t solve the problem of having hundreds, or even thousands of them floating around colliding with each other.

A tangle of Access applications is nothing for IT to sneer at, of course. In many companies, IT has created its own tangles that are still in production as well. All that’s happened is that end-user-developed Access applications reveal the core problem of enterprise architecture at a different stratum of the organization. IT architects know that optimization of the parts doesn’t result in optimization of the whole — often the result is the opposite. A portfolio of individually sound, best-of-breed applications can still yield an icky applications portfolio. Which points to the solution for the Access tangle.

When enterprise architects analyze an applications tangle, they work with business areas to settle on a portfolio of go-forward applications, and create a coherent integration strategy. Then they develop a decommissioning plan for the other applications.

Do something similar for the Access tangle. Get close enough to the business to know which Access applications have reached “tangle” status. But instead of choosing some as go-forward applications, use the tangle to provide the specifications for a new, production-grade application to replace the whole shebang. My guess: IT should be able to replace an Access tangle with half the effort it would have taken to be involved at the beginning.

Last week’s column pointed out that there’s no such thing as an IT project. It’s always about changing the business. That’s still true.

What’s attractive about the Access Tangle Replacement Methodology (ATRM) is that the business change takes place before IT ever gets involved.

Comments

|In: Industry Commentary|Last Updated:

160 years ago we were a nation of farms and small merchants, in which both people and information traveled no faster than when Julius Caesar overthrew the Roman republic.

A mere 45 years later, the trip from the east coast to California, formerly a half-year ordeal, was a routine two week journey; information traveled coast-to-coast in seconds; and giant corporations were considered persons by the law.

And you thought the Internet transformed the world? Compared to the transcontinental railroad, the agent of these transformational changes, the Internet hasn’t come close.

Take time to read Stephen Ambrose’s Nothing Like It in the World, which chronicles the process through which Abraham Lincoln preserved the union from an east/west division just as surely, if less dramatically, as his leadership of the Civil War preserved it from secession by the southern states.

Whenever you read history you learn something useful about the present. Among the many instances here are foreshadowings of both Enron and a current IT controversy.

The Enron foreshadowing? Both the Union Pacific Railroad and Southern Pacific Railroad companies created separate construction companies. The construction companies, owned by the railroad company board members, siphoned off huge amounts of capital from the railroad companies, enriching their owners while leaving both the employees and other railroad shareholders holding the bag. Sound vaguely familiar?

But that doesn’t directly affect you as a working leader of information technology. This does, as a metaphor for problems you deal with every day:

For the Southern Pacific Railroad, hardwood railroad ties were in short supply. To avoid construction delays, it used cottonwood ties in much of its initial construction instead, even though they would last only a few years. Bad engineering? The company desperately needed cash flow. Had it waited until it could acquire enough of the “right” railroad ties, it would have run out of money before finishing construction.

This philosophy explains a lot of what we’ve experienced with Microsoft operating systems over the years. Time-to-market has usually trumped internal engineering, to the despair of many in our profession. Was this decision wise? The question is, for whom? Certainly, the earlier Microsoft is able to ship product the earlier it makes a profit. What — you thought Microsoft was an altruistic enterprise, putting your best interests ahead of its own? That isn’t how business works. From its perspective, generating revenues earlier was worth the impact on its image with respect to quality.

Sometimes bad engineering is the best engineering — a valuable lesson. An example even closer to home:

Quite a few readers griped about my endorsement of Fire Controlman Derrick Thomas’s homegrown database, which reduced the time needed by the U.S.S. Benfold for each Persian Gulf ship inspection by two and a half hours. Thomas should have worked with an IT professional to build it right, I was told … after all, it was probably an undocumented mess, and who supported the system once he left the ship?

Had Thomas had taken this advice, he’d have waited until the Benfold returned to port, then submitted his request. Had it ever emerged from the priority queue the Benfold would have received the system a year or two later.

It’s cottonwood now or hardwood too late: A fleet of destroyers’ worth of capital and wages, times 2.5 hours per ship inspection, times a few hundred inspections, all spent because end-users shouldn’t build systems by themselves?

The quality of Thomas’s code is unknown. But the quality of his business judgment?

Outstanding.

Comments