All Posts in Policies and Procedures

|In: Industry Commentary|Last Updated:

Recently I described some research I bumped into 20 years ago about a parrot that appeared to understand both the meaning of the words it mimicked and at least some elementary rules of grammar. Not having heard anything more about it, I concluded the research didn’t pan out and parrots are mere mimics after all.

My thanks to dozens of IS Survivalists who set me straight on this subject. Dr. Irene Pepperberg and Alex, her African Gray Parrot, are alive and talking to each other. It’s fascinating research. Bop over to http://www.cages.org/research/pepperberg/index.html to learn more about it. My apologies to any parrots I may have offended by likening them to the wrong class of human beings.

Offending human beings is OK, though. It’s your turn if you’re one of those who insist on giving the company what’s convenient rather than what’s important. You probably don’t recognize yourselves. To help you sort it out, you’re the ones most likely to explain that anytime you deliver something that’s inconvenient, it’s really a violation of IS standards that will further increase maintenance costs, cause PCs to require rebooting five times a day, and besides, the company really doesn’t need it anyway, regardless of what the person doing the work says.

The history of the PC is excellent evidence of this attitude, as an IS Survivalist who asks to remain anonymous pointed out in a recent letter: “Since the IS organization ignored us, we bought PCs to do our work, until the IS organization woke up and discovered their mainframes were dinosaurs.

“So the IS organization went to our management and took over our PCs and then demanded money to manage them. They then complained we used them for things other than functions their mainframes used to do, and since they never tried to understand what we do with them, they mismanaged them.

“The costs for PCs skyrocketed because of this mismanagement, so CIOs were invented to keep us from buying anything. Then the CIOs discovered our computers were becoming obsolete (because they wouldn’t let us replace them) and they mandated we replace them, but we had no money because we gave it all to the Information Systems people who squandered it on lousy PC support contracts.

“Instead of finding out what we need to do our work, and providing tools for us to use and standards for us to follow, IS people now dream up misguided, grandiose, expensive projects to do it all for us and leave no money to do the things that need to be done. And we, the user organizations, end up doing all the computer planning ourselves, developing our own standards, and inventing workarounds to the cumbersome system set up by the IS organization and the CIO.”

Overly harsh? Maybe. For example, I don’t think CIOs were invented to keep end-users from buying anything. That’s what corporate controllers are for. CIOs were invented to be comforting to business executives who had trouble relating to technical managers whose sole excuse for holding their jobs was that they got things done.

The first PCs to enter businesses were bought to enhance personal effectiveness. They lacked the really stupid features of the 3270 interface and they made end-users independent of IS (a huge factor in their popularity). If somebody sold software that would be worthwhile to the end-user, that end-user could simply buy the software, install it, and enjoy the benefits.

This is InfoWorld’s 20th anniversary year, and in those two decades IS has gained control of the “personal” computer. In doing so we’ve tried our best to make it as impersonal as possible.

When I attended the University of Minnesota, its management tried to encourage the use of mass transit, not by making mass transit more convenient but by reducing the number of parking spots. Students, faculty and administrators, however, preferred the device they could personally control — the automobile.

We can talk about how PCs are an enterprise resource all we want. We can’t, however, change human nature, and end-users don’t want an enterprise resource on their desks. They want a personal device that provides access to enterprise resources.

Comments

|In: Architecture|Last Updated:

Electric fish are fascinating critters (at least to me — regular readers will remember I spent years studying these suckers). One of their more remarkable features is their electric organ – the gadget they use to generate electricity. It started out as a muscle. Aeons of evolution eliminated its ability to contract while increasing the amount electricity its cells generate.
That’s how evolution works — it grabs whatever is convenient and adapts it for whatever use is called for.

We do a lot of this in IS as well, continually adapting and evolving our legacy systems, databases, and computing platforms to whatever new requirements pop up. And this is a good thing to do.

Eventually, though, we find ourselves in evolutionary dead-ends, where our adaptations, kludges, shortcuts, and patches turn into barriers that prevent further change. Mother Nature handles this situation through extinction. You’d probably prefer a different strategy.

The alternative to evolution is design, and design is what distinguishes architecture from gluing a bunch of stuff together wherever it happens to fit. In this, the final article in our series on technical architecture (hey, don’t cry!), we deal with design.

Architects, whether designing IS infrastructures or office buildings, have to be both technically and artistically inclined. So far we’ve talked about the analytical, technical aspects of architecture.

Good designs, though, are as much a matter of art — aesthetics — as of technical prowess. Aesthetics pays off, because ugly designs turn into unreliable, clunky, nasty implementations. It can’t be logically proven, but it’s so nonetheless.

Defining aesthetics is more or less impossible, though, because aesthetics is mostly a matter of taste. You still need to make consistent design decisions, though. To do so, develop a set of clear, consistent principles designers can use as a starting point. And to develop good design principles, you need to understand the important design issues.

A design issue is any technical problem you need to solve or computing function you need to deliver on a regular basis. For example, physical connectivity is a design issue. You have several design principles to choose from: One connection per end-user device with network gateways to resources as needed; multiple end-user connections (for example network, modem and desktop TAPI); or ad hoc decisions as seem appropriate for each situation.

I’m a big fan of a single connection to the desktop and doing everything through the network, but that may not be the right solution for you.

Take another design issue: How to handle data redundancy. You have several design principles to choose from. You can: modify your systems to eliminate redundancy; define master/slave relationships among your data stores and periodically resynchronize everything; build technology that propagates update transactions to all redundant data, keeping everything synchronized in real time; or live with the mess and not worry about the redundancy. Pick one and don’t lose your guts.

In fact, for each design issue the most important thing is to pick just one design principle and live with it — and also, make sure your design principles are consistent with each other.

Which brings us to standards. Many design principles establish the need for a standard. In fact, every standard you establish should stem from a design principle — otherwise you don’t need it. For example, you may establish a design principle that all data will be stored in a single mainframe RDBMS, accessed through standard ODBC calls. This principle calls for selection of a standard ODBC-compliant RDBMS.

Now the really hard part: Your design principles are important, but they aren’t religion. You’ll sometimes have to make pragmatic decisions that violate a design principle or standard. Figure a way to mitigate the impact, and do what’s right for the business.

Your company’s strategic, tactical, and infrastructural goals drive the applications, information, and ultimately the computing platforms you provide. These define the design issues you need to resolve, which in turn cause you to select a set of consistent design principles.

It’s these design principles that lead you to choose specific technical standards.

Otherwise, your standards are just red-tape.

Comments