In large technology departments, dysfunctional relationships breed like mushrooms in a dank basement. Your dev and ops teams are no longer on speaking terms, while your junior and senior developers can't seem to agree on anything. IT and legal are constantly at each other's throats. Storage wonks are ready to declare war on the database admins, while sys admins seem to be on everyone's bad side.
Why can't they all just get along? In many cases it's the tension between conflicting demands on the same systems -- say, DBAs who complain about network performance but refuse to streamline their storage needs or business users who want to roll out new apps quickly, blissfully unaware of the effect they could have on other critical systems.
[ Also on InfoWorld: Beware the nine circles of IT hell, and learn steer clear of 20 common IT blunders and the 12 "best practices" IT should avoid at all costs. | For more IT management wisdom, sign up for Bob Lewis' Advice Line newsletter. ]
Fortunately there are solutions. We asked our geek relationship adviser, Crabby van Buren, to help find the common ground between these five warring factions. His advice follows.
Dysfunctional IT relationship No. 1: Storage admins vs. DBAsDear Crabby: Our database administrators have an insatiable appetite for storage. They never delete anything, they won't let us archive data or store it off-site, and they're constantly complaining the network is too slow. Meanwhile, the cost of storing all this data is killing our budget and making us storage engineers extremely unpopular with the CFO. What can we do? Underfunded & overcapacity
We feel your pain. Even today's networked and cloud storage options can't always keep up with the data explosion. But to the folks who aren't responsible for providing storage, the supply seems almost infinite.
"To solve the problem, you need to look at the groups that are producing the data," says Jim Damoulakis, CTO of Glasshouse Technologies, an IT infrastructure services provider. "DBAs are some of the biggest examples. They are extremely risk averse, tend to save everything, and want to have total control over all of it. But having to save everything forever can bring your backup systems to a screeching halt. You need to incent them to be more efficient."
In other words, once a department has to foot the bill for its insatiable storage habit, it may begin to appreciate the wisdom of efficiency. The problem is that most people hate chargebacks with a passion, says Damoulakis. The alternative is to set up a system that reports which users are consuming what resources, so when the CFO comes around to beat on the storage people for spending too much money they can say, "Talk to these guys."
Interestingly, says Damoulakis, a lot of this is already happening because of the cloud. Departments that bypass IT to order services directly from a third-party cloud vendor are finding that they're charged on a consumption basis, whether they like it or not.
"In a funny way the cloud is moving this to the forefront," he says. "It's a backdoor into a chargeback mechanism. Organizations that are adopting private clouds are also finding they can use that to make DBAs and other groups accountable for their own IT spend."
Dysfunctional IT relationship No. 2: Senior developers vs. junior developersI'm a new software developer for a large company that desperately wants to be on the cutting edge. I'm trying to help them do that, but I keep getting stymied by the graybeards. The senior developers are always reviewing my code, and it takes forever to get approval for even a simple change. They're slowing down the company and, frankly, hurting my career. How do I tell these old dudes to back off without getting fired? Young & Restless
[ Want to cash in on your IT experiences? InfoWorld is looking for stories of an amazing or amusing IT adventure, lesson learned, or tales from the trenches. Send your story to email@example.com. If we publish it, we'll keep you anonymous and send you a $50 American Express gift cheque. ]
The first thing you need to realize is that maybe, just maybe, your more experienced developers might be right in being a little more cautious about unleashing insufficiently vetted code unto the world, says Joe Masters Emison, VP of research and development for BuildFax, which stores construction records for hundreds of millions of properties across the United States.
"Software is wonderful in that you can do amazing things with it," he says. "So a junior developer looks at Facebook and says, 'Gosh it would be easy to create X because all we'd have to do is change this one thing.' And if Facebook only served five people, that might work. But you may not understand what's required when you've got a large user base and a large body of code with a lot of people working on it."
It's the senior developer's job to contemplate all the terrible things that could happen from one tiny change, he adds. The cost of even one hour of downtime thanks to a small tweak in the code could be enormous.
For their part, senior developers must acknowledge there are scenarios where rules can be safely broken -- like editing code that's already in production -- without causing the sky to fall or the company's share price to plummet.
"There are certain situations where you want to do a live edit of a database -- say, to push out maintenance upgrades," says Emison. "Or sales might come to you and say they have a customer they need to close this quarter, but it requires certain changes to the code. When the risk of anything bad happening is low, you could be better off from a business standpoint to break the quality rules once in a while."
But if you must engage in "cowboy coding," Emison advises you follow the pink sombrero strategy laid out by Joshua Siler, a former VP with marketing firm Babcock & Jenkins who is now CTO at HiringThing, a cloud-based service that helps hiring managers post jobs online and manage applicants. Siler wrote:
Bottom line: As a junior developer, you need to learn more patience, while your bosses need to retain some flexibility. Otherwise, development turns into a fiefdom where hot new talent inevitably leaves and nothing innovative ever gets done.
Dysfunctional IT relationship No. 3: IT vs. legalI'm an IT manager at a midsize enterprise with a lot on my plate. Yet every few days the legal department hounds me about something -- compliance, e-discovery, cloud service-level agreements, yadda yadda. It's keeping me from doing what my employer actually pays me to do. How do I get the lawyers off my back so I can get some real work done? Beleaguered by legal
Shakespeare may have been onto something when he wrote, "The first thing we do, let's kill all the lawyers." But without legal covering your company's back, your employer would probably be in a world of hurt -- and you'd find your job even harder to do. A big part of the problem is that many corporate lawyers don't understand what IT does and have no idea what they're asking for, says Craig Carpenter, VP of marketing and general counsel for Recommind, a maker of e-discovery software tools. For their part, tech pros often see legal requests as a nuisance, even though one liability suit can bring the company to a screeching halt. For example, legal might come to you and say they need all email for these 50 people from 2008 to 2012, and they need it tomorrow, says Carpenter. "IT looks at legal and says, 'You have no idea what it's going to take to comply with that request,'" he says. "Legal looks at IT and says, 'You have no idea of the downside if we don't.'" To bridge the gap, large enterprises need to dedicate a staffer who understands enough about both technology and legal that he or she can act as liaison between the two groups, Carpenter says. "They don't have to experts in both fields, but they do need to understand what it means to extract metadata from both archives and live Exchange sessions," he says. "They need to know what legal really means when it says it needs to collect all emails from these 10 custodians. And they might be able to help legal understand that it's about to make life a living hell for 10 email admins and perhaps they don't really need all of the data they're asking for."
Shakespeare may have been onto something when he wrote, "The first thing we do, let's kill all the lawyers." But without legal covering your company's back, your employer would probably be in a world of hurt -- and you'd find your job even harder to do.
A big part of the problem is that many corporate lawyers don't understand what IT does and have no idea what they're asking for, says Craig Carpenter, VP of marketing and general counsel for Recommind, a maker of e-discovery software tools. For their part, tech pros often see legal requests as a nuisance, even though one liability suit can bring the company to a screeching halt.
For example, legal might come to you and say they need all email for these 50 people from 2008 to 2012, and they need it tomorrow, says Carpenter.
"IT looks at legal and says, 'You have no idea what it's going to take to comply with that request,'" he says. "Legal looks at IT and says, 'You have no idea of the downside if we don't.'"
To bridge the gap, large enterprises need to dedicate a staffer who understands enough about both technology and legal that he or she can act as liaison between the two groups, Carpenter says.
"They don't have to experts in both fields, but they do need to understand what it means to extract metadata from both archives and live Exchange sessions," he says. "They need to know what legal really means when it says it needs to collect all emails from these 10 custodians. And they might be able to help legal understand that it's about to make life a living hell for 10 email admins and perhaps they don't really need all of the data they're asking for."
At the very least, says Carpenter, organizations should host off-sites with both teams so that they can have a regular meeting of the minds. The good news is that relations between tech and legal are improving.
The convergence of legal and tech is creating new job opportunities, he adds. Some day legal could end up offering you a job.
"Organizations are making roles for legal people to be part of IT or pulling people from IT into legal," he says. "But at the end of the day, most of the people who work with me have a technology background. It has created a whole new opportunity for IT professionals."
Dysfunctional IT relationship No. 4: Dev vs. opsThe development team is driving us crazy. It's operations' job to keep the servers humming, fight off hackers, keep our systems secure and our IP from leaking out, and manage third-party services -- all while keeping the lid on costs. But all dev can do is complain we aren't nimble and don't implement changes rapidly enough for their liking. Don't they realize we have a company to run? Operating under pressure
Large organizations need both their development and operations teams working in sync if they want to survive in a rapidly changing business environment. The problem is that their core functions are fundamentally at odds, notes Winston Damarillo, CEO and co-founder of Morphlabs, a provider of converged infrastructure solutions for enterprises.
"The IT operations team's goal is to maintain the status quo, while the development team seeks to disrupt it," he says. "There's intense pressure on dev to deliver innovative products, services, and tools to customers. At the same time, ops has to grapple with maintaining security and protecting intellectual property while keeping all the systems running. That tends to limit the sometimes rapid and ungoverned changes sought by dev."
Sometimes it seems like dev and ops are speaking two different languages, says Todd Olson, VP of products for Rally Software, an agile project management and coaching firm.
"The same words can mean different things to them," he says. "The ops guy is all about reducing risk, the dev team wants to produce as much stuff as possible. They have different interests in mind."
One solution is for your organization to join the devops movement, combining the warring factions into a single team where each member has both development and operations responsibilities, says Olson. That may require significant cultural change throughout the organization, as well as overhauling legacy structures such as separate management teams and budgets for each group.
The mismatch between dev's need for speed and ops' need for control has led a lot of development teams to opt for public clouds, says Brett Adam, CTO at rPath, an enabler of PaaS (platform as a service) for enterprises and service providers. "While this provides the agility dev needs, it often does so as an end run around the ops team."
"All of the velocity gains we've made on the dev side won't translate to business value until the same velocity is achieved on the ops side," says Adam. "Enterprises need both speed and control, enabling developers to rapidly provision what they need while also satisfying IT's need for governance. A private PaaS solution can align both of their interests."
Enterprises operating their own private clouds should consider a converged infrastructure, which could allow the dev team to spin up their own virtual machines as needed for building and testing code, says Damarillo. That would give them the ability to rapidly deploy in real-world conditions while still ensuring the safety and uptime ops demands.
Dysfunctional IT relationship No. 5: Sys admins vs. the worldLet me put this bluntly: The sys admins at our company are impossible. They're constantly nagging us to change our passwords (which are hard enough to remember as it is), haranguing us about software licenses, or insisting we follow some arcane procedure. But when we ask them to do something the business needs, the answer is almost always no. I'm tempted to bypass IT entirely and get what I need from the cloud, only I'm afraid the admins will change the passwords and lock us all out of the network. Frustrated & fearful
When you hold the keys to the kingdom, it's easy to create fiefdoms. For years, the admin's word was absolute. Users had to adhere to strict policies and procedures or get locked out. When admins spend all their time just getting systems to work properly, change is something to avoid at all costs -- in case something breaks and they have to fix it. Every so often, one of them will go rogue and cause real damage.