I don’t mean to be a wet blanket, but as much as I keep hearing we’re in an economic recovery, you couldn’t prove it by me. The evidence of said recovery certainly hasn’t trickled down to me or to anyone I know. Perhaps I need to change my newspaper delivery route to a richer neighbourhood.
But in case your company is among those still pinching pennies, I have two counterintuitive suggestions regarding your IT strategy that you can pursue while you continue to wait out the budget drought.
1. Develop a proactive approach to building your IT infrastructure. As odd as this may seem, in times of budgetary crisis, this is precisely what’s called for. The question is, do you understand the difference between a reactive and a proactive strategy? Here’s a tip: A reactive strategy isn’t a strategy at all. It’s how we behave when we can’t wait to get our hands on the latest technology because someone put the “competitive edge” buzz in our ear. It’s not the technology that’s dangerous; it’s the temptation to forge ahead without careful consideration because we’re used to being able to throw money at the problems that inevitably arise.
The solution is simple: If you haven’t already done so, put the kibosh on new projects such as going wireless, especially if it looks like the distraction plunges your department into triage whenever someone’s notebook needs attention. You can always come back to these pet projects later. By then, you’ll be able to step over the bodies of those who did it wrong and approach the technology when it’s less risky. Yes, there are some companies that absolutely need bleeding-edge technologies to thrive. Trust me, yours is not one of them. (If it is, my batting average will still be close to 1.000.)
2. Take calculated risks with the resources you free up. Every Next Big Thing is a risk. Right now, the Next Big Things are XML, wireless, storage-area networks and so on. You have a choice. You can convert your gym socks into XML (in which case, I strongly recommend that you employ Simple Object Access Protocol, or SOAP), and take the chance that this effort will pay off in the long run. Or you can follow up on the Last Big Thing you never finished, such as migrating your company’s information to a directory based on the Lightweight Directory Access Protocol (LDAP).
Don’t get hung up on the example. I chose to focus on LDAP only because of the extravagant promises that surrounded LDAP a few years ago. They sounded a lot like the ones people make about XML and other technologies today. Yet people who jumped on LDAP prematurely didn’t get the competitive edge they expected. If LDAP hasn’t fulfilled its promises yet, why should XML or wireless technology double your profits overnight?
Until LDAP enjoys near-universal adoption, sinking resources into it is still a calculated risk. I was hoping that by now LDAP would have eliminated the difference for me between addressing an e-mail to a colleague and addressing one to the CIO at your company. It’s not even close. But the reason it’s still a risk worth considering is that LDAP may end up marrying public-key infrastructure (PKI), whether or not the chemistry is right between the two. LDAP isn’t the ideal PKI directory solution, from a technical perspective, but you can’t get a more natural combination, from a user’s perspective.
A user should be able to find the person he wants to e-mail, compose the message and then hit Send. The fact that the system grabs the recipient’s public key and encrypts the message should be entirely transparent. That’s precisely what an LDAP/PKI solution would deliver.
What’s the nightmare scenario for taking this risk? You choose to beef up LDAP, and the PKI infrastructure turns out to revolve around an XML-based wireless server. So what? LDAP gateways will abound, and in the meantime you’ll have finally implemented the directory services you promised your employees years ago.
The only other suggestion I can think of is to pay me an outrageous fee to help out with your LDAP project. But I believe that about uses up my allotted number of self-serving remarks for the week, so I’ll leave it at that.
Nicholas Petreley is a computer consultant and author in Hayward, Calif. He can be reached at nicholas@petreley.com.