All Posts in Technology

|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:

I finally watched The Matrix last week. It’s a thought-provoking movie that asks three disturbing questions:

1. Does anyone call what Keanu Reeves does “acting”?

2. Has there ever been a stupider premise than the human body as the ideal source of electrical energy?

3. Does Moore’s Law make the movie’s basic premise inevitable?

We’ll leave the first two questions to Roger Ebert. Before we dig into the third …

Last month I asked what you envisioned as the center of your network, the mainframe or the PC. In other words, is the point of your network to connect terminal devices to the systems that drive them, or is it to connect employees to the resources they need to do their jobs?

The e-mail and forum exchanges on this question surprised me. Most unexpected was that nobody proposed putting processes in the center, even though the process view of the enterprise dominates consulting circles these days. The correspondents who proposed an “acentric” perspective also caught me off-guard, since to me acentrism means no design focus.

What bothered me the most, though, was how many respondents told me the enterprise “never stopped running on the mainframe.” This contingent disputed my assertion that a company’s work is performed by individual human beings, and that companies succeed or fail one person at a time.

On reflection, this isn’t a question of who is right – the question is which perspective is the most useful. With the mainframe in the middle you’d divide work into three categories: Data preparation, where people and feeder systems massage data into processable formats; The Work, which is what host applications do; and exception-handling, which is what people do with system outputs (since the system does The Work, it only reports the exceptions it can’t handle).

With Process in the middle, both humans and information systems fulfill roles in the company’s core processes, performing well-defined tasks that transform inputs into outputs.

Both of these perspectives can be useful. I’ve designed and implemented quite a few successful applications based on the systems-centric view myself, and as mentioned, the process-centric perspective currently dominates business design.

When you put the employee in the middle, though, several good things happen. First, you reduce overhead. Every time one employee hands work to another, entropy happens – work goes into managing the transfer of work rather than getting the work itself done. With a human-centered view you’ll organize resources so work stays on a single desk until it’s done.

Second, customer relationships will improve. When one human being owns each piece of work, the company has a chance of looking less like an impersonal machine that answers all requests with, “We can’t do that – it violates our procedures.”

To understand the third benefit, let’s revisit the basic idea behind The Matrix – that eventually we’ll all be slaves to one or more artificial intelligences. Just thirty years into the future, Moore’s Law will have clicked over twenty times, so computers will be one million times more powerful than they are today. One million.

No matter what the cognitive task, computers will be better at it than you are, so if the mainframe is in the middle, you’ll be working for it. Likewise for process-centered work – computers, being far more capable than humans, will do all the interesting stuff. (In the movie version, we’ll do nothing but cheap manual labor. Fortunately, Microsoft will have written the operating system and our heroes will take back the world when the blue screen of death happens.)

If humans are in the middle, we may have a cable going into our skulls (although I sure hope wireless technology has progressed more by then) but it will be to augment our abilities, not to boss us around.

Okay, this is the stuff of a summer movie, and your choices today will neither save nor destroy the world two decades from now. My point is to illustrate the third benefit of putting humans in the middle of your system designs – you’ll help make your company a better place to work.

Comments