All Posts in Organizational Effectiveness

|In: Organizational Effectiveness|Last Updated:

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.

Comments

|In: Industry Commentary|Last Updated:

Definitions get me into a lot of trouble.

Early in my career, I was asked to perform a “feasibility study.”

“What’s the subject?” I asked.

“An inventory system,” my boss answered.

“OK, it’s feasible,” I told him. “I guarantee it. Lots of other companies keep track of their inventories on computers, so it must be.”

More patient than most of the managers I’ve reported to in my career, he explained to me that in IS, a feasibility study doesn’t determine whether something is feasible. It determines whether it’s a good idea or not.

It turned out to be a good idea (a tremendous surprise), so next we analyzed requirements. You know what’s coming: A senior analyst asked me if the requirements were before or after the negotiation.

“What negotiation?” I asked. “These are requirements. They’re required.”

This is how I learned that we do feasibility studies and requirements analyses in part to test the validity of the requests we receive. The process would be unnecessary if we believed end-users were our customers.

At the supermarket, nobody says to a customer, “Those fried pork rinds aren’t an acceptable part of your diet!” or, “Prove you need that ice cream!” At the supermarket, wanting something and being able to pay for it are all that matter.

In IS we used to view end-users as our (internal) customers, and we figured the relationship followed from the role: If they’re our customers, our job is (as Tom Peters would say) to delight them.

End-users aren’t our customers, though. They’re our consumers – they consume our products and services but don’t make buying decisions about them. But does that really change anything, or is it just a useless distinction?

It does change things. “Customer” defines both a role and a relationship. What does “consumer” say about a relationship? Nothing. Or at best, very little.

“Consumer” defines only a role, and in the context of organizational design, role is a process concept, whereas relationship is a cultural one. (Definitions: Processes describe the steps employees follow to accomplish a result. Culture describes their attitudes and the behavior they exhibit in response to their environment.)

What should the relationship between IS and the rest of the business look like? This is one of the most continuously controversial issues in our industry. When you view it as a clash between process design and cultural cues, the reason our discussions are jumbled is more clear.

Defining the rest of the business as our consumers frees us to define whatever relationship works the best. As with my inventory system, every highly successful result I’ve ever seen in IS has been the result of an open collaboration between IS and end-users, with authority shared and the dividing line between the two groups obliterated.

Yet many of my colleagues and much of the correspondence I receive on the subject still advocate a hard dividing line between the two groups, with formally documented “requirements” defined by a small group of end-users and the authority for “technical” decisions reserved for IS.

Of course, purely technical decisions are few and far between these days. What brand of NIC should you buy? OK, that’s a technical decision, but even something as seemingly technical as choosing a server OS places constraints on business choice. Or, looking at the opposite end of the process, selecting a business application limits IS’s choice of operating system, sometimes to a single one.

Trying to partition responsibilities to preserve the prerogatives of one group or the other leads to nothing but bad results. “You have to do this for me because I’m your customer,” and “You can’t do that because it violates our standards,” are two sides of the same counterfeit coin.

There are few purely technical or purely business decisions anymore. Since form follows function, you should strive for a relationship that recognizes this fact. What kind of relationship should you have with your consumers? One that emphasizes joint problem-solving and decision-making, and working together in a collaborative environment.

Or, in a word, “partnership.”

Comments