I’ve talked a fair bit this week about the changes coming in IT work. The rise of information specialisations, the shift away from a relentless focus on technology.

But there’s one thing waiting out there: some of the original IT work is coming back.

Here’s why: we’re moving on from best practices, standard processes and packages alone.

There’s a place for fresh code in our IT portfolios. (If there weren’t, there’d be no point in doing start ups. Seems there’s more of those every day…)

As the enterprises we work for struggle to differentiate themselves in the market, more of that struggle turns into applications.

But the package market doesn’t do differentiation. It does standardization. That’s true whether you install the package, whether your business process outsourcer does it, or whether you buy it in software-as-a-service form.

Yes, they can be customized via parameters. That’s not differentiation.

Differentiation is doing something new and different. It can’t be built on “best practices”, because the practices haven’t solidified yet.

Differentiation requires code. That code could be a stand-alone application, or it could be a component built into one of your standard platforms (e.g. an SAP component). Either way, it’s something that makes you unique.

What will be different, going forward, is that we’ll be constantly looking at the market our enterprise plays in. Have others copied the innovation? Then it’s losing its ability to differentiate. Has the package/service market responded? Then it’s definitely standardizing, and we should be shifting from our code to theirs.

In other words, we’ll be building lots of things, but not necessarily for the ages.

The other big change comes on the architecture, design and analysis side of the equation.

It’s undoing prior decisions, to loosen the enterprise up and make it more flexible.

Sigurd Ringe, who is the founder of Thingamy and blogs frequently on simplifying work, recently posed a question to me on my own management blog: “why are we still doing double-entry book-keeping?”

It’s a good, insightful question that points to “undoing” things.

Double-entry book-keeping was invented, a little over five centuries ago, to reduce errors when everything was done by hand.

Today there’s far less need for that. Checks and balances can be coded, simplifying the process. The user experience and interface can carry more of the load.

Accounting standards probably make that fight not worth fighting. But every organization is littered with similar prior decisions.

Indeed (and this is Ringe’s point) the “best practices” that packages are built on are littered with these, too.

Really rethinking work and how it’s done is a big opportunity area for differentiation.

It’s the same job we did when “automation” was first on the table — but now it’s to fix the user requirements, not discover them.

Enterprise IT doesn’t have to be the care and feeding of decisions made by others with little to no creative opportunities.

In the enterprises that thrive competitively, differentiation in all its forms will rule.