All Posts in Strategy and Tactics

|In: Leadership|Last Updated:

A month ago I mentioned how the transformation of muscle tissue into an electric organ in some fish exemplifies how evolution works — it morphs existing structures into needed ones.

Several readers challenged the validity of evolutionary theory, describing my acceptance of it as naive. I’m perennially astonished that people who would never dream of challenging the theory of quantum chromodynamics or Einstein’s resolution of the wave/particle duality of electromagnetic radiation are so highly opinionated about evolution — a subject just as complex, even if it’s more accessible.

To be fair, I don’t think there’s a subject taught worse. Every time you hear the phrase “survival of the fittest” you can tally up someone else who learned it wrong. It’s a shame, too, because once you understand how evolution works in nature you understand a lot about how change happens everywhere else. And if you haven’t been keeping track, change has become the one constant in everyone’s lives, so understanding how it works can come in handy.

Once upon a time we designed computer systems to mimic their manual predecessors. Our early systems didn’t change the jobs people did very much, only how they did those jobs. Although we encountered resistance, it was nothing compared to what we experience now, when the systems we deliver are embedded in fundamental transformations of our businesses.

You have three choices when you take on a massive change effort. First, you can think of your task as delivering software that adheres to the specifications. The technical term for this is “dismal failure.” It’s a popular methodology because you get to claim success while everyone else gets to go back to their farms and villages, avoiding the discomfort that goes along with abandoning old ways and learning new ones. If people actually used your new system, you’d risk finding out if it wasn’t such a good idea after all.

Another option is to “manage the change.” This is basically an exercise in successful corporate politics, because the discipline of change management involves analyzing the victims and participants of the coming change and figuring out how to navigate through their sensitivities.

You need to manage change or change won’t happen, because people generally don’t like it. People don’t like it because they’re smart and understand evolution on a personal level. In nature, changes to the environment drive evolutionary change by changing what constitutes “fitness” — traits that used to be adaptive in the old environment become irrelevant or harmful in the new one. Business change is environmental change carried to our day-to-day experience, and as in nature, it makes traits that used to be adaptive irrelevant or harmful to our own future success.

If all you do is to manage change, however, your project will succeed but you’ll make the next change harder. In the long run, you either create a corporate culture that embraces change or you’ll create a corporation of listless and dispirited cynics.

IS leadership can’t single-handedly drive corporate culture, except within IS itself. (A hint: How good have your mainframe Cobol programmers been at adopting object-oriented technology? IS isn’t all that good at change, either.) As part of your company’s executive team, though, you can help shape leadership attitudes on the subject.

What’s needed to create a culture that thrives on change? It isn’t complicated. First, define the behavioral and attitudinal traits you’re looking for — dissatisfaction with the status quo, active interest in making things different and better, an entrepreneurial spirit, and so on. Then make sure you hire and promote people who exhibit those traits. Even more important, find new roles for them when you’ve eliminated their jobs through process redesigns or reorganizations. Employees will adopt the characteristics that help them survive and succeed. The company leadership gets to define what survives and succeeds — that’s how to make the culture evolve.

This, of course, means filling the company with mavericks, trouble-makers, and general pains in the neck. That’s why lots of corporate leaders say they want companies that embrace change but few actually have them.

Comments

|In: Architecture|Last Updated:

Years ago, I used to tell a joke with no punch line. It went, “How many vendors does it take to print a memo?”

For us, at the time, the answer was 10: (1) IBM – PC; (2) Microsoft – DOS; (3) Automenu – DOS menuing front end; (4) WordPerfect – word processor; (5) Synoptics – Ethernet hubs; (6) Anixter – Ethernet cable; (7) Novell – NOS; (8) Compaq – file server hardware; (9) Hewlett-Packard – laser printer; and (10) Pacific Data – font cartridge.

“Imagine,” I was fond of saying, “how many vendors we’d need to do something complicated.”

Understanding what computing functions are involved in addressing common end-user tasks, and what products deliver those functions, is an important goal in managing technical architecture.

This is our 10th article on creating an integrated IS plan and the sixth on technical architecture. We’ll be done soon. I promise. We do have a few more topics to cover, though, and managing your technical architecture well is awfully important.

As last we left our heroes, they had just finished mapping platform-layer products to computing functions, scoring each product in terms of how well it serves its purpose and also looking for redundancies and incompatibilities. Let’s see what they’re up to now … .

Our product/function grid doesn’t address integration and design; that is, it doesn’t ensure that anything actually works.

To do that, some drawings will help.

The first drawing is a physical connectivity map of your enterprise. It shows, not every device on your network, but every class of device that connects through your network.

Your goal in creating this drawing is ensuring that electrons can flow between any two devices that need to communicate, so next to each connection, list the types of service or session available through it. For example, you may have a mainframe connection that only supports 3278 terminal sessions (LU6.2 sessions, to be precise) through the network.

That’s important to know, because that means your connectivity will have to change when you start using the mainframe as an application server. If your mainframe connection supported TCP/IP communication and T3270 sessions, on the other hand, it would work just fine for the new requirement while still supporting the old one.

The second drawing, really a set of drawings, is a client-centric view of your platform environment. Create a drawing for every device that hosts at least one client process or acts as an end-user workstation. Put that device in the center of the drawing and around the periphery depict the resources – server processes – that device must access.

Then, for each resource, list the client process needed to reach it, where that client process runs, and what protocols and connectivity are required to achieve the connection.

(Remember that “clients” are software processes. Although many clients run on desktop computers, that doesn’t make desktop computers clients, and client processes often run on server hardware. A commonplace example: When you fill out an HTML-based form on your browser, the browser isn’t the client. The client process runs on the Web server, perhaps in the form of a Perl script. That client process interacts with a host computer in the background, formats the results, and sends them back to your browser.)

Your goal in creating this second set of drawings is to look for opportunities to simplify. The more commonality between different connections, the simpler and easier it is to manage your architecture.

Don’t, however, fall into the trap of equating “simpler architecture” with “that’s what we need to do.” When simplifying your architecture reduces the level of functionality you provide, be careful.

It may, for example, seem attractive to use a browser as a universal terminal and Web servers as universal clients. It may to you, but browsers make for second-rate interfaces when compared to a full-featured GUI.

As with the rest of the process of managing architecture, keep the purpose in mind at all times, and that’s making sure you know how to connect resources to the processes that need them. Don’t get lost in the technique, because if you do, you’re just painting by numbers.

Comments