Your aging mom needs a new car. You are picking it out for her because she quit paying attention to cars long ago. All you ever buy is Fords. You also always buy trucks. Do you pop off and buy your Mom an F350? Not unless she actually needs an F350 (highly unlikely, but aging moms are as varied as any other group of people, so maybe). Why? Simply because you are buying a vehicle to solve a problem: Your mother’s need for a new car.
Setting the parameters of decision-making is the CIO’s role. Or at least a part of it. IT has struggled with justification since its inception. Far too often we are justifying choices that are made before justification is carried out. Browser wars, OS wars, language fights … all have marred IT practically from the day that an IT staff became necessary.
The fact of the matter is that people have preferences, and organizations do, too. If you have 300 instances of Oracle database running, you have investment in staff, training, licenses, etc. that you can reuse if Oracle is a choice on the next project. Contrast this with “the next project” containing a purchased package that only works with SQL Server. The two are natural tensions that need to be figured out.
In far too many cases we zero in on what an individual thinks is best or “right,” and not on the needs of the organization across projects. On the development side, Agile has made this more of an issue than it has been in a long time, maybe ever. Simply put, the faster the better is the rule for Agile, but long-term ramifications of that approach can be large. If internally developed apps vary from NoSQL to SQL server to Hadoop to Oracle and you’re having to maintain all of the above, both in Ops and in Dev, you may have delivered quickly, but the accrued cost—call it the mortgaged technical debt—can be expensive over the long term.
And the way that we end up with multiple solutions to a given problem is by allowing champions to drive their point home in a vacuum. While it is great when an employee says, “I know a [needed library, tool, app] that will solve this and I can have it running in a day,” there is a larger picture that needs to be considered.
DevOps definitely gives us the opportunity to review these choices and put a stake in the ground. Sometimes the internal champion is right, and that’s the tool to use in this scenario. Sometimes they’re not, and an already implemented tool/library/app should be used. But the conversation needs to happen.
I wrote about some of this back when I worked for F5. It was amazing to me the number of customers who purchased F5’s very expensive gear, then set it up as a load balancer and went looking elsewhere for WAN optimization or security solutions, when the BIG-IP could do the job. That’s a good example of waste, but just the tip of the iceberg.
When implementing DevOps on the Ops side, take a look at what you have. If you’re writing the same script for three different targets, it is probably time to go find out why. The reasons might be perfectly acceptable, but they might not be. If purchased apps really only support one product for AAA, then that product is probably required, even if it means propagating logins across to the corporate standard AAA tool.
But the process to make certain these decisions are being made intelligently, with a focus on standardization but adaptability to handle exception cases, is driven from the top. Stressing that first choice is X, but Y and Z are acceptable alternatives for projects of priority three and above is important. Stressed from the top it says, “We have standards, and we all need to try to adhere to them to keep workloads down as much as possible, but we have a business to support, and will make exceptions where business value is added.”
It’s not always easy. Not politically, and not technologically. Sometimes the solution available internally isn’t a perfect fit for a given problem, but long-term, the work required to make it solve the problem is less than the expense (in duplicated expertise and licensing fees, let alone duplicated DevOps scripts) to drop an easier solution in. IT staff are smart folks and fully capable of making those decisions, but the direction to do so must come from the top. Without it, some will aim for standardization over speed of implementation, some the opposite. Inevitably, many will aim for what is easiest for them.
I have worked in two industries where data went from paper in filing cabinets to microfiche to mainframes to client/server to virtualization and/or cloud. Don’t assume what you’re doing only matters for now. Make the rules, ask the tough questions such as, “What do we have in-house that could fulfill this function?” and expect honest answers.
And if you’re going to do calculations such as TCO or ROI, make sure the team knows you want the numbers to lead to the solution, not the other way around. Because we all have seen the case where the solution changed how the numbers were calculated, and that just wastes everyone’s time.
So step up, Mr. CIO. Get Mom the Focus or a Honda—whatever will suit her needs. Not what you’ve always done, and not what is easiest for you to do. Set the rules so the team knows what decision criteria are, and make them clear so there is no miscommunication. And finally, give your DevOps team the room to make consolidation recommendations. If they’re seeing duplication of effort, let them call attention to it, and have a process to resolve their concerns. In the end, a simple, “No, that duplication is necessary because of X,” or “Yes, we should consolidate,” needs to come out of that process for each recommendation they make.
And if your Mom is that one that drives an F350, send me a picture of her by the truck. I’ll talk to the editors about getting it posted.
