These graybeard IT tenets still reign -- when applied in their modernized guise
Stories by Bob Lewis
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 or NetSuite.
You might have read that 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?
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 synchronised.
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 colour 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 synchronised.
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. 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.
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.
It's all to do with the rise of single-actor practices — situatios where one employee, supported by technology, can do whatever needs to get done (don't bother Googling it — it's my term and isn't in wide use yet). Organising a practice with just a single actor maximises consistency and minimises the amount of coordination needed. When the practice involves direct contact with customers, it's also more personal.
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.
Lewis is InfoWorld's advice line columnist
"Our financial situation is strained and that is putting it kindly. You're going to have to find ways to do more with less. It is time for that can-do attitude. Time to put your backs into it and show your mettle." There is no doubt you and your IT colleagues are hearing such talk from company management.
It is time to respond. "What are you, nuts?" is one possible way.
Well, maybe that would be a bit intemperate. The right answer is, "Let me huddle with my team and put a plan together".
Of all the instructions given by a business leader to IT, none is fraught with more peril than "do more with less". The naive among us might think the opposite – that it is a chance to shine, to show how you can rise to a difficult occasion.
But nothing could be further from the truth. That is because anything you achieve beyond standard "continuous improvement" (incremental increases in effectiveness, usually in the 3 to 5 percent range) will be an admission of past incompetence.
Did I say "admission"? Let's make that "broadcast".
Let's say you agree to do more with less and succeed in a spectacular fashion. It might make you a lot of friends. More likely, it will raise the question of why you didn't start doing all the things that let you do more with less years ago.
It is a problem that is always going to be with any employee. In times of stress it is accentuated, because in times of stress, people are more likely to be grumpy than grateful.
All things considered, you will find it a lot safer to do less with less than to do more with less. The challenge is making your case in a way that leads to your stakeholders nodding their heads, instead of grabbing their pitchforks.
The economy is in tough shape – no news there. The most optimistic projections have it remaining in tough shape for some time to come. This isn't a blip and it is going to personally affect us all, including IT leaders and practitioners, for years. Everyone in IT, from service desk analysts right up to the CIO, deals with requests that have political consequences every day.
In the hangover economy we're in, politically charged requests will be more frequent and more strategic than they were when the "kegger" economy was in full swing, and the requesters – sober and headachy instead of ... well, you know – are less likely to throw their arm over your shoulder to slur, "Hey, that'sh OK. I unnuhstan. We're shtill friendsh, aren't we"?
There is no request that is more political than whatever variation of "do more with less" hits your desk. If you are a developer, it will take the form of "Can't you just squeeze this in"? If you're the CIO, it will be, "We're cutting your budget by 10 percent and adding three new projects to this year's mandatory list".
Our goal for the Less with Less blog and the Slow IT movement is to give you some tools, tips, and techniques to get you through the day and the next budget cycle, and to spur some discussion. In other words, don't be coy – post your own thoughts. Join the discussion group, add comments to the blog post or write on our "wailing wall". Just go to www.slowit.net.
If you have ideas to share, please do so. And if you have any specific topics you would like us to cover, please don't be shy about it. Let us know and we'll be sure to add them to the list.
In the meantime, here is your first tip. Faced with a request to do more with less, always remember the single most important rule for handling any request. There are two answers that are almost always the wrong ones to give and one that is always safe. The two wrong answers are "yes" and "no." The safe bet is, "here is what it will take."
ManagementSpeak: What a novel concept. We should review this at corporate.
ManagementSpeak: We are not having any layoffs.
ManagementSpeak: I will accept no excuses!
ManagementSpeak: Times are tough and we all have to pitch in.
ManagementSpeak: I'm looking for people who can think in unconventional terms.
ManagementSpeak: Are there other options?
ManagementSpeak: You’ve blown it out of proportion.
ManagementSpeak: As part of the ongoing drive to improve our customer response, we have decided to streamline the process for users requesting services from IS.
“Imagination is the only weapon in the war against reality.”
ManagementSpeak: We need to establish uniform practices across the enterprise.
ManagementSpeak: This isn't a cost-effective solution.
ManagementSpeak: To be honest with you ...