System changes are like Mexican butterflies.

For decades, we’ve been migrating functionality from applications to infrastructure. We used to choose the best application and bought whatever platform it ran on, congesting our data centers with a hodgepodge of incompatible systems. We’re smarter now … we understand that eliminating redundancy is as important in the platform layer of our technical architectures as in our data designs, so we establish technology standards and require new business applications to be compatible with them. In doing so, we’ve moved the physical interfaces, especially network and DBMS compatibility, into the technical architecture — we’ve moved functionality into the infrastructure.

With OO we create a library of reusable objects. Before OO we created subroutine libraries and COPYLIBs. These libraries are part of the infrastructure, too.

Have you installed an ERP suite? If you do, it has an API that turns it into a platform. By acting as a platform and not just an application, ERP has also moved functionality into the infrastructure.

Enterprise application integration (EAI) has the same result. It turns data and logic interfaces, which used to be part of your applications, into yet another part of the infrastructure.

Every time you move something into the infrastructure you improve maintainability, integration, consistency … all good things. Unfortunately, you also lose flexibility, because with all of these benefits comes interconnectedness. Like the butterfly of chaos theory, which supposedly messes up the weather in New England by flapping its wings in Mexico, even tiny application changes can have unexpected and significant consequences.

That’s a problem, because while we’re busily moving everything in sight into the infrastructure, increasingly sophisticated business leaders, workgroup supervisors and individual end-users spot endless opportunities for improving the business through information technology. Maybe it’s a Macintosh in marketing. Maybe it’s a tracking system for the trade-show team, a contacts database for public relations, or thought-mapping software for strategic planning.

Whatever it is, it represents a business improvement opportunity for some small community of interest in the company and another headache for you. They get the benefit, you have to maintain it, make sure it continues to operate when you upgrade hardware and operating systems, integrate it … and then it becomes part of the infrastructure, too.

It’s easier to just turn down these requests, because approving them all feels like being smothered by a swarm of Mexican Chaos Butterflies.

There is a third alternative to rejection and asphyxiation: Recognize that moving everything into the infrastructure is the equivalent of creating a centrally planned economy — in this case, an information economy. As we learned by watching the eastern bloc fall apart, when it comes to economies, central planning has its limits.

Not everything belongs in the infrastructure. Create a space outside the infrastructure for beneficial uses of information technology that just don’t fit, and don’t have to fit.

Create a multilevel support framework that establishes the ground-rules. A standalone system can be pretty much anything. If it needs to run on the network you need a traffic analysis; if it needs read-only access to existing databases you need volume estimates and adherence to security standards. If it needs to update core data … sorry, that’s a Mexican Butterfly.

For projects fitting the framework, the requestor is free to contract with an outside company — you’ll recommend one — and you’ll work with the contractor to make sure the results fit into this framework.

Don’t create the framework on your own. Develop it with key business users and ask your Systems Steering Committee to endorse it — it can’t succeed unless the rest of the business accepts responsibility and accountability for the information systems they ask for. Not everyone does. Sometimes, people asking for your help want you to turn them down. That way, they get credit for trying without the pain of change; you get the blame for being an obstacle to progress.

Turn the tables. Give them the worst thing anyone can get: Exactly what they’ve asked for.

When Wess Roberts wrote The Leadership Secrets of Attila the Hun, I hope he got a lot of angry mail.

Last month I made some suggestions about what IS leaders could learn from McDonald’s and the roof fell in. While a lot of my mail was complimentary, many correspondents took issue with some of my advice, all of my advice, the notion that there are any parallels between McDonald’s and IS, some or all of McDonald’s business practices, and the quality of the McDonald’s dining experience.

You would think I had said you have something to learn from Attila the Hun. Hey, that was Wess Roberts, not Robert Lewis.

It’s easy to find reasons not to learn from others. The Germans, for example, discounted relativity because Einstein was Jewish. The result: No atom bomb, they lost World War II, and we watch reruns of Hogan’s Heroes.

Because McDonald’s experiences high turnover in counter help and pays low wages for these positions, some of my correspondents said you have nothing to learn from it when you look at your own hiring practices.

Wrong answer. You have a lot to learn, not by blindly imitating but by paying attention. McDonald’s structures its work to require as little expertise as possible. It hires anyone who can do it. And it pays its employees what the market will bear. Neither McDonald’s nor its counter and kitchen workers think of these jobs as careers – it’s just basic employment. It’s better than welfare, and McDonald’s can sell burgers at a competitive price.

McDonald’s recognizes the need for jobs as well as careers. Do you? If you’ve structured every position in IS as a career, you’re probably making a mistake. Jobs in IS require more expertise than working the counter at McDonald’s, but in some situations you can still move expertise from individuals to systems and processes. Figure out when it makes sense to do so. Have you looked for the opportunities, or have you assumed they don’t exist?

In IS, you often structure the work around the unique abilities of the employees you have instead of first defining the position. McDonald’s doesn’t have much to teach you here, but a local entrepreneur, who gets more from 10 employees than competitors get from 20, may. Since he’s in the garment trade, though, not IS, you have nothing to learn from him, do you? Sure you do.

Some letters indicted the whole fast-food industry, not just McDonald’s, saying it exploits workers. Yes, and many employees in IS wear pagers and are on-call 24 hours a day. Is that exploitation, or is it the nature of the work, and so long as there’s no misrepresentation as to what’s expected, there’s no harm and no foul?

Whether it’s Attila, McDonald’s or (worst of all, according to some participants in my Infoworld.com forum) Microsoft, you have something to learn from any individual or organization that has proven itself highly effective. And with all due respect to Stephen Covey, not all of the lessons are obvious, they won’t all feel good, and they don’t all come from people and companies that are admirable in every respect.

In fact, you won’t find any company or individual you can admire in every respect. Not one. Not even you. Or me. Although it’s easy to be self-righteous, it’s hypocritical because no matter how much the other guy looks like Bill Clinton with Zippergate, somewhere in your own life you know you’re Newt Gingrich, just as guilty only nobody knows about it.

Self-righteousness is just another form of arrogance. If you’re unwilling to learn from McDonald’s, are you willing to listen to an employee you find personally irritating? Probably not, but you’re doing both yourself and that employee a disservice.

Learning from others is like learning from history. Sure, there are lots of wrong conclusions you can draw, and if you do learn you’ll find a whole new set of mistakes to make. But if you fail to learn, from history or from contemporaries, you’ll just make the same old mistakes, and that isn’t just dumb … it’s boring.