A surefire bet for IT job security

Become your company's ERP guru and you will find yourself in demand -- really

Want the hottest IT job in town? I sure wish I knew what it is or, even better, what it's going to be.

Here's what it won't be, if that's of any use to you: heads-down coding. If what you like to do is write code without having to deal with anyone or anything other than the system specifications, you'll either find work with a software developer or you probably won't find work at all.

[ Also on InfoWorld.com: Get Bob Lewis's continuing IT management wisdom in his Advice Line blog and newsletter. | Find out why running IT as a business is a train wreck waiting to happen. ]

Meanwhile, here's an opportunity that might not be a hot job but is a safe bet: Become a guru in one of the remaining ERP suites: SAP, Oracle, PeopleSoft (who would have expected it to survive Oracle?), or NetSuite. Yes, guru -- you can either make one of these packages sing, dance, and play the tuba, or you're just another schlemiel.

You might have read ERP suites have become discredited due to their sheer bulk, expense, and cost of implementation. Maybe they have among self-appointed pundits. That's not the case in mainstream IT, though, which has to deal with a straightforward question: What's the better alternative?

(Visualize your screen image waving and shimmering, with a harp riff on the music track, because it's time for a flashback. The image stabilizes in grainy black-and-white, and ...)

A few years back, the phrase "federated architecture" was making the rounds. The concept was pretty simple: Assemble enterprise ERP from a bunch of best-of-breed systems connected by a magic pipe that handles all the translations throughout the IT stack -- from data transport to data translation to business logic -- to keep the application and information portfolios synchronized.

"Magic pipe" turned out to be a good description -- of what the theorists who explained How Great It All Would Be had been smoking. Oh, the moving updates around parts worked just fine, and data conversions weren't a problem, so long as they were at the bits-and-bytes level.

Federated architectures failed to live up to their promise because software is an opinion. The consequence: No matter how often vendors bandied about terms like "metadata," it was of no help when the corresponding data fields in different best-of-breed systems were semantically different -- when they meant something similar but not exactly the same.

When that happened -- for example, let's say one system stores color as RGB values, another as Pantone codes, a third with plain-language words like "red" -- metadata mappings didn't help because the source system data was a round peg, and only some fairly nasty code could hammer it into the square hole that was the target system. 

Then there's the matter of redundant business logic. Because best-of-breed systems weren't designed to respect each other's boundaries, they have overlapping functionality. Magic pipe or no magic pipe, IT either ripped the logic out of one system, replacing it with a call to the other system -- an ugly process that meant tinkering with core code -- or used brute-force techniques to keep the redundant logic synchronized.

(Time for the screen image shimmer and harp again, as we return to the present.)

You don't hear the phrase "federated systems" very much anymore because in most situations they're a good bit harder to make work than the alternative, which is to use an ERP suite as the heart of the enterprise technical architecture. It's in the middle -- the master repository.

IT will implement satellite systems when the ERP suite's module just doesn't do what the business needs. The satellite systems don't communicate directly through a magic pipe, though. They all feed the ERP suite -- the single source of truth that then updates any other satellite systems as necessary. This by itself makes ERP guru-hood valuable. Now let's add two new trends to the mix.

The first is that there are no IT projects anymore -- none. Every project is about changing how the company operates, not delivering software that meets the specs. Business change usually involves software change, but as an enabler for the new way of working, not as the endpoint of the effort.

The end of IT projects will drive dawning awareness of the best Agile variant nobody ever heard of: Conference Room Pilot (CRP), the only application methodology that easily supports business change as well as software delivery. Here's how it works: The project manager reserves a conference room for a month or so, locking the ERP gurus in it with the company's smartest and most knowledgeable business managers and users. Everyone has access to the ERP system in its current configuration (or, if this is a new installation, in plain vanilla).

Also in the room is a big stack of test cases -- real-world situations the system will have to handle.

The business managers and users do real work, just as they would in their offices and cubicles. When they hit a snag, they call a developer over to explain what isn't working as well as it could and describe what they'd like the system to do instead.

Being gurus, the IT developers either make the system do it, or they explain that making the system do what the users described would be very expensive, complicated, and fragile. But here's something that would be much easier that's close, and would that work well enough?

They get to an agreed-upon solution and the developers, being gurus, implement the change quickly. (You might recall the statistic, reported in Frederick Brooks' classic "The Mythical Man Month," that the best programmers are 10 times more productive than average ones.) Rinse and repeat.

Modern IT departments understand their role is to collaborate with everyone else in the business to make designed and planned change happen. CRP is an excellent methodology for succeeding in that role. If you're an ERP guru, you're just who they need.

But wait! There's more! Remember the single-actor practices we've been talking about for the last couple of weeks? In future columns we'll talk in depth about what sorts of technology single-actor practitioners will need. For now, we'll leave it at this:

The nature of a single-actor practice is that no two situations are exactly the same, and success will never look exactly the same, either. As a result, single-actor practitioners will constantly ask IT to get its systems to do just one more thing (fare thee well, Peter Falk). By the way, there's serious revenue on the line, but to get it, we have to act quickly.

Traditional IT hurls all over this sort of request, often offering the popular phrase, "A lack of planning on your part doesn't constitute a crisis on my part," in response.

Future IT understands that even in businesses that aren't entrepreneurships anymore, when it comes to taking care of high-margin customers, the business had better be more entrepreneurial than before.

Which means, that's right, IT doesn't say no anymore and doesn't look down its nose at the requester, either. Instead, it connects the company's single-actor practitioners with its ERP gurus. They saddle up. They do the job. Then they ride off into the sunset until they're needed again.

This story, "A surefire bet for IT job security," was originally published at InfoWorld.com. Read more of Bob Lewis's Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies