10 old-school IT principles that still rule

The more things stay the same, the more they change.

That’s not exactly how the saying goes, but it is the phrase that should be engraved over every door leading to IT. It’s certainly better than “Abandon all hope, ye who enter here.”

Not a lot has changed since our early days, when IT was EDP and programmers were the high priests of the glass house.

Except for everything.

Luckily, much of the fundamental wisdom of the early days of IT still applies, just in a different, modernized guise. Here are 10 old-school principles that will guide you through next-generation IT, and the fundamental differences in the ways you should apply them.

It’s never just about how good the technology is

Old version: “Nobody ever got fired for buying IBM”

New version: Open source can provide the same advantages

The technology you buy is a long-term commitment on your part. You need it to be a long-term commitment on the supplier’s part, too.

To play it safe, IT used to buy from big vendors. Now? Not only can open source be just as safe, sometimes you can get it from IBM or other big vendors.

Not every open source technology has a broad enough base of support, but many do. If PHP, for example, will do the job, would you look at Java twice given its awful security track record? And yet Java is supported (perhaps “provided” would be more accurate) by Oracle, one of the biggest software companies in the world.

This isn’t entirely new, either. The open-source-like SHARE library dates to the 1970s, after all.

Good information security starts with good physical security

Old version: Keep the hardware locked away

New version: It doesn’t have to be your locked room

We’ve always kept the hardware locked away, limiting data center access to a small number of employee badges and keeping automated logs of who enters and when. It’s just that now, not every locked room is our own.

For SMBs especially, there are alternatives, ranging from co-lo facilities to full cloud.

But don’t pocket all of the savings from not building out your own data center. Invest some of it in a low-latency, high-bandwidth network connection to your offsite provider. Even better: Apply another old-time principle — never have just one of anything. Make that two connections, with points of presence on opposite sides of your building, so a back hoe can’t take your business down by digging a hole in an inopportune spot.

Know the threats

Old version: Inventory security threats and implement countermeasures

Middle-age version: Lock down the desktops and guard the perimeter

New version: Harden the assets. Guard the perimeter, too

Back in the day, thwarting security threats mostly meant timing out CICS sessions so hackers couldn’t dial in and inherit them. Then came PCs, distributed systems, the Internet, and lots more threats. We responded by locking down desktops and guarding the perimeter with increasingly sophisticated firewalls.

Many still think the best countermeasure is to lock everything down and not let anyone be creative. But businesses live and die on innovation, and innovation means more than new products to sell. It means creative thinking, and the implementation of that thinking, everywhere in the business.

These days we should spend more time hardening the assets than the perimeter, and even more time actively supporting users, because the biggest threat is a workforce that isn’t allowed to innovate.

Testing software means more than just putting code into production and seeing what happens

Old version: Maintain three environments — dev, test, prod

New version: Move a lot of testing to the cloud

Regression and stress testing separate the pros from the amateurs. They always have, and they still do. Regression testing makes sure new stuff doesn’t break old stuff. Stress testing makes sure everything will perform well enough when everyone starts banging away at it.

IT, being professional, maintained at least three environments — development, test, and production. That meant buying three of everything. And maintaining them, too. Ouch!

Now, even when you maintain your own data center, spinning up a test environment in the cloud often makes more sense because you only have to pay for it while you need it. Depending on your production environment it can work quite well for regression testing, too.

Stress testing? Not yet. Too many variables, at least for the time being.

Control changes to the production environment

Old version: A formal change control process

New version: A formal change control process

We’re long past the days when developers could just slam their new code into production. There’s a process to go through. Nobody actually likes the process, but it isn’t about liking the process. It’s about making sure the change doesn’t disrupt production, and if it does disrupt production, it’s about making sure there’s a back-out plan.

Think the cloud changes things? It does. It makes change control harder because now, if you aren’t careful about how you manage your cloud providers, they just might slam their changes into production without going through your process.

It is, after all, their infrastructure.

Waterfall ought to work, but agile actually does

Old version: Informal back-and-forth between biz managers and programmers

New version: Scrum: Informal back-and-forth between biz managers and programmers, only with a book of rules to follow

Long before formal development methodologies drained the fun out of IT, business managers used to wander over and ask, “Can you get the computer to do this?” The programmer would try something, show it to the business user, and they’d iterate until it was right.

They didn’t call it agile. They called it “having a conversation about what the computer should do,” but it was agile, nonetheless.

Then waterfall methodologies came along. They’d work, too … if business managers could perfectly envision a complete working system and describe it precisely. But they can’t, so we lost 30 years of productivity.

Enter Scrum, which takes iteration and interaction, and adds enough methodology to drain most of the fun from IT that other versions of agile had put back in.

Relationships precede process, and relationships outlive transactions

Old version: Managing relationships with other top execs is a key part of the CIO’s job

New version: Managing relationships with the rest of the business is a key part of everyone’s job

Before businesses are anything else, they’re collections of relationships. With good relationships, everything can work. Without them, nothing can.

Back when businesses were strict hierarchies, the CIO managed relationships with the other top execs, and that was enough. If the other top execs didn’t trust the CIO, IT couldn’t succeed. It was as simple as that.

But every time any member of the IT department interacts with anyone else in the business, it affects the business/IT relationship. It isn’t just about the CIO and other execs. If the rest of the business doesn’t trust IT, IT can’t succeed. If it does, everything about IT is easier.

Not easy, but easier.

Integrate, because interconnecting ‘islands of automation’ takes a lot of stupid out of business processes

Old version: Gradual accumulation of custom-programmed batch interfaces

New version: Service bus or equivalent with engineered real-time interfaces

Even newer version: Integrating with non-IT-driven SaaS solutions, too

When humans rekeyed information from computer-generated reports into data-entry screens, IT realized one of its most important responsibilities was integrating disparate systems to keep data synchronized.

So it built interfaces. Lots of them. All custom-batch ETL.

Now there are so many it’s a hard-to-maintain mess. So smart IT invests in a service bus, or something similar, and engineers its interfaces too, because just piling one on top of the other means the shiny new tech re-creates the same old tangle.

Today, lots of IT is happening outside the IT department, mostly in the form of SaaS brought in by business managers as islands of automation. Eventually they’ll get tired of having their staff rekey data into it. Be ready for them.

IT exists to support the business

Version so old it’s a cliché: No technology for technology’s sake

New version: Provide technology leadership

Technology for the sake of technology is a bad thing. That doesn’t mean IT should limit its role to processing work orders. It has to go way beyond this and provide technology leadership.

Any IT department that fails to provide technology leadership — to suggest and discuss, not just to accept and deliver — is failing at a fundamental level.

Technology leadership also means supporting managers and users who are ready to buy or build their own technology. It’s time to recognize that “shadow IT” is a good thing, because it increases IT bandwidth.

Sure, there are risks. Anything worth doing has risks.

IT must help everyone in the business succeed with all of their technology, not choke off anything that’s “not invented here.”

It’s about business change, or else what’s the point?

Old version: IT is the major driver of change throughout the business

Middle-age version: IT is the biggest barrier to change in the business

New version: IT is the major driver of change throughout the business

When computers were new and shiny, business executives counted on them to drive change everywhere by making business processes quicker and cheaper while cutting way down on manual errors.

That lasted until IT had to support so many interconnected systems that doing anything new was time-consuming, expensive, and risky. Its reliance on waterfall methodologies didn’t help either.

We’re finally breaking loose again. Between agile, better integration tools, and non-IT IT, information technology is starting to drive change again instead of following along after it.