Slashdot Mirror
Who Makes the Decision To Go Cloud and Who Should?
Esther Schindler writes: It's a predictable argument in any IT shop: Should the techies — with their hands on their keyboards — be the people who decide which technology or deployment is right for the company? Or should CIOs and senior management — with their strategic perspective — be the ones to make the call? Ellis Luk got input from plenty of people about management vs. techies making cloud/on-premise decisions... with, of course, a lot of varying in opinion.
The first call comes from the technical people, and answers the question "Is the company technically able to move to the cloud, and if not what's required to get it to that point?". Once you've got that covered, then business can decide whether it makes sense to move and whether they want to invest what it'll take to make it happen. If it isn't technically possible it doesn't matter how much business wants it, and business can't make a determination about investing what's needed to make it possible if they don't know how much investment it'll take. You can't make a cost/benefit decision if you don't know the cost.
Honestly both should be involved. Anyone proposing a solution should be prepared to back that solution up when presenting it to others. I have seen Management make some really absolutely stupid decisions relating to software and platforms, but I have seen the Techie side do the same.
It's hard to explain who exactly should be in charge but IT staff should propose several solutions, their costs attached to it and the cost/benefits. There is never one solution and neither is 'cloud' a solution in and by itself. In the end, unless you're a small shop or require very small amounts of something, the 'cloud' is almost never the answer.
If you have 10 e-mail accounts, a hosted provider may look promising, but if you end up paying more for an e-mail solution in a month than you'd do buying your own hardware, you're doing it wrong.
Custom electronics and digital signage for your business: www.evcircuits.com
I've found that whoever has a position of authority in the organization makes the call, usually after having spent far too much time under the influence of a sales rep that lavishes them with meals or outings like to play golf.
Do not look into laser with remaining eye.
There's no hard, fast answer, although it would probably be popular around here to assume that the right place is with the Tech dept. This is certainly supportable; I've seen plenty of clueless administrators blinded by blinking lights and flashy fluff make architecturally very poor choices!
At work, we are a vertical stack cloud-based software vendor. We work with hundreds of clients and deliver a very excellent product that saves our clients $$$. Several times now, I've seen IT departments that have ballooned into inefficient "candy stores" for developers who are mostly intent on increasing their take of the organization's $$. It mostly happens because the managers at our client organizations aren't techies in any sense of the word, so they take whatever techno mumbo jumbo blurted out by the techies as gospel.
When the powers that be at the organization bring us in, and ask the tech department, they are almost universally ice cold to the idea of working with us, as their job is potentially on the line. Change = BAD! And so we see a fight while the corrupt IT department and the management duke it out. We've lost a few, we've won most. In any case, we often come in as little as 1/5 the cost of the bloated, internal IT department's offerings, while offering better service, better security, and strongly worded privacy and availability clauses.
So there isn't a right answer, you know? Some CxOs are clueless or corrupt. Some IT departments are similarly incompetent or corrupt. It all really comes down to "people are people".
I have no problem with your religion until you decide it's reason to deprive others of the truth.
If you can't have a rational discussion between your architects (who are most likely just really senior guys slinging code) and your product managers (who are most likely just sales and account reps without a market vision) you are already screwed.
Shit. I just described my own company.
Technical management evaluates the options based on the requirements, and makes recommendations. BizMGNT shit-cans the recommendation in favor of whatever buzz-word technology is in vogue. Engineers implement the technologies chosen scratching their collective heads as to how this meets any of the initial requirements;. AND they have to engineer supporting infrastructure with no budget, and even less time to make pager-duty tolerable. At least that's how it's worked in my experience. Someone who doesnt have to answer the phone at 2am gets to decide.
Finance. finance declares after 4-6 quarters of overspending on marketing and travel that belts need tightening and austerity is upon us. ragged edge carpeting and burnt out sections of office that havent seen a new coat of paint or replaced bulbs since the Clinton administration are passed over and the finger is pointed squarely at the company to stop renting beamers for golf outings. IT staff with crispy mice and rubbery keyboards are glowered upon and in turn the management steps in, begrudgingly, and does what management does to get the harsh glare of 'why do you have 5 monitors' off the team. Clouds are looked at, RFQ's are drafted, 30 minute powwows with the team are conducted and the reigning PHB compiles a short-shot list of the top 3 potentials to outsource the companies infrastructure to at a greatly inflated cost savings.
then its up to "the business" which in turn will glaze over as 3 choices are paraded out and the one with the most ad-buy in the seatpocket magazines on the flight to shanghai the CEO had to memorize for 17 hours gets chosen. After 3/4ths of the infrastructure is hauled kicking and screaming into the cloud, BIS screams bloody murder and keeps their mainframe while the exchange instance now shits the bed once every week. bitchcraft from the business about slow access, lost data, weird permissions, unplanned outages and lack of any discernable support chain are summarily compiled into a ticket system and ignored as IT staff shuffle together the last mighty years of their work into a functional CV and start shoveling tradeshow trinkets from their desk into boxes 'just to clean up a bit.'
6 months later half the team bails, the last guy who knew how to handle multifactor stuffs a notebook full of scribblings into a managers mailbox, and "the cloud" suspiciously gains 3-4 new employees with an impeccable history of providing excellent service and designing robust systems.
Good people go to bed earlier.
.
I've also worked for companies where such decisions were made by solely by the CIO. The CIO in one of the cases was not a technical person, and got the CIO position because of whom he knew.
The success of the project seemed to be directly related to the amount of discussion and information exchange among the "hands on" technicians and management (including business management).
The more discussion and information exchange, the better the outcome of the project.
Tell people that instead of saying "in the cloud" they say "on somebody else's computer" and see how that goes--
"We store the company's most important information on somebody else's computer"
"We control access to that data by storing it on somebody else's computer"
"We back up all our mission-critical information to somebody else's computer"
"Our data is secure because we store it on somebody else's computer"
Doesn't sound so good, eh?
It's not necessarily that so much as the head honchos usually have grandiose visions that are short sighted.
For that reason, and others, IMO it is best to follow the typical procedures one does in typical successful IT project management, which may sound bureaucratic, but it avoids disasters, thus these are pretty common procedures for a very good reason:
i.e:
1) Problem statement: Why is what we're currently doing insufficient?
2) Do a productivity gap analysis: Where are we now, where do we want to be?
3) Does the proposed solution provide for long term growth (so that we don't have to ask these questions again in only a few years)?
4, 5, 6, etc, etc,
But along the way, never leave out this important step: Consult with all of the stakeholders and make sure this solution works for them early in the design phase to figure out if this solution is even worth pursuing.
The stakeholders often include: Upper management, middle management, lower management, the techies, the rank and file employees, the customers, and sometimes the shareholders.
When you consult with them, what you're looking for are things like this: Does this new system work better than the old one? Does the new system make your job more difficult in any way? Does the system make your job easier in any way? What do you like about it? What don't you like about it? What else do you think you may need? (On that last question, make sure to have well defined scope limits early on to avoid feature creep.)
I remember at one place I worked, somebody higher up decided that they wanted to move all of the sales department to Microsoft Dynamics CRM some time before I first worked there. One day while I was asked to troubleshoot a problem with it, (and believe me, MS CRM has TONS of bugs) and I was totally stumped because this person's account didn't work even though his permissions were the same as everybody else's. After I did some investigation, I found out (and the management wasn't even aware) that every salesperson had this problem, only very few of them even tried to use MS CRM at all, so nobody actually reported it until this one guy happened to try it a few years after we had already supposedly been using it.
That's a classic example of when somebody implemented a new "IT system" but completely failed to consult with the rank and file employees to see if it's something they'd even want to use at all. It's also one of many classic examples of failed IT project management.
TL;DR: Basically, everybody who it applies to should have a say in it.
Having worked my way up through every level, the biggest thing I've learned is "correct" is amassively subjective concept, based on value statements people at other levels don't see.
To take a deliberately simple case:
I would have declared a manager insane for buying Office365 licenses. After all, you can buy copies outright for less.
Except, as that manager, any savings I get are dwarfed by the pain in the ass of keeping licensing info. Some idiot loses the info and you're out far more than the difference when you have to re-buy. Or you don't re-buy and you're vulnerable to huge fines. Or you have someone dot every i and cross every t and you pay more for their salary than you save. Or Office365 keeps everyone licensed and demonstrably so.
Same goes for commenting.
Earlier in my career, commenting was slow. I could understand my code just fine without it. It was clearly readable after all. What idiot manager wants less productive code after I jumped through hoops?
Now I've paid the price of countless devs who write code no one else can follow. If watched countless more declare they have to rewrite everything because the previous guy who swore his code was readable wrote something the next guy swears is not. My perspective is completely different. I'd now rather each person codes a little slower so the company moves faster overall.
Who's right? Everyone has a good perspective but each is colored by the values that they weigh in.
I know my devs often think my calls are "wrong" because they assign different values to those I do... But I also know I've been put in the position exactly because I have the perspective I do. The best I can do is try to explain and help them understand, listening when they genuinely see something I've missed.
At a previous employer, I got to see this whole turn of events unfold [the wrong person deciding to move to "The Cloud"]. It went something like this:
a) CEO (non-techie btw) gets wind of "The Cloud"
b) SalesForce.com reseller somehow gets past the call screeners and directly to the CEO's phone.
c) CEO flies to San Francisco to a "DreamForce" convention to see Sting perform and hear Colin Powell speak and hear Virgin and Coca Cola sing praises to the platform.
d) CEO signs up for 3 years of SalesForce.com and a bunch of addons without consulting anyone
e) CEO flies back and tells everyone (and I quote: "OK everyone, I'm driving this car down the street with no headlights on, hang on, here we go!")
Needless to say I was out of that place not soon after. It was a real shame to see this "Cloud" technology forced down everyone's throats on a whim of the CEO, when he had absolutely _zero_ input from anyone else in the company (IT or otherwise). Especially when we had a really good system in place that just needed a few tweaks to make it perfect.
My friend who still works there now as to run around like crazy coding a bunch of APEX scripts just to hold things together. It's a sad, sad mess unfortunately.
The "techies" should submit a report, in writing, outlining the implications of a decision. No matter how much people hate writing reports, it does have a degree of accountability that casual consultations do not have. The writer is more inclined to provide both the benefits and the drawbacks of the decision as well as providing the rationale for approving or rejecting the decision. Documentation also forces accountability on senior management, since they have information upon which to base their decision. This is information that they have to take to their bosses if called upon.
This is not to say that the techies will agree with the outcome, but it can soften the blow. I have certainly written proposals for things that I did not approve of, but it was better than their alternative. (That original plans would have resulted in my resignation since they were planning to do something illegal. The alternative accepted their goals, but brought them in line with the law.))
Of course it is easy to show how blind management is, However it IT guys are not blame less.
IT has a history of the following bad behavior, that would make management want to find a way to slim its IT Staff.
1. Personal pet projects: This is often a business related project, however there are alternatives that may work better, however it IT worker is too emotionally interested in keeping it going, then giving it up for a better solution. Hanging on to the couple features that has that the others do not.
2. Attempts to make you "Irreplaceable": Sure that program your infrastructure you support is impressive, and perhaps no one else currently will want to touch it with a ten foot pole, and it is your baby, that is keeping the organization running. However in case of accidental death or injury the company is in a bad place, so they will want a better solution. And BTW just because people don't want to touch it, if they have to they can and will be able to maintain it, no matter how hard you make it.
3. Failing to project in the future: If they move to a cloud service, then your job is antiquated. However have you been future proofing yourself. Realizing the role you need to take after that particular feature moves away?
Now I am not trying to blame us IT guys for every stupid business decision... However you need to realize our personal bad behaviors do get noticed up, and influences business decisions.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Thats an easy one. This one happens like all the rest, as usual: Marketeers decide without asking the Techies. Techies have to solve issues in record time with no say.
When all comes crashing down, the techies save the day with the secret auto-backup they've been pulling off the cloud for the last 6 months.
We suffer more in our imagination than in reality. - Seneca
How a plan becomes policy
Ce n'est pas une signature automatique.
One thing that gets me in discussions across organizations is how poorly the "cloud" is defined. IT often has a slightly different definition of the cloud than senior management than end users than tech support (and so on). Are we moving email to the cloud, setting up a collection of virtual servers to run our custom apps on, using Salesforce, creating a hybrid solution for redundancy? Even in those situations, the motivations and concerns are often different.
Then there's the accounting aspect. Is the shift simply to move IT from CapEx to OpEx? Does the IT staff understand the difference? Has management worked out a 3 year forecast to make sure the financials actually work out?
When making these decisions, all major stakeholders need to be involved and represented. You need to look at it from different perspectives and make sure everyone understands those perspectives. Only then can you really make an informed decision. Yes, that's much more difficult than simply believing the sales guy, but for something as important as IT infrastructure, it's what you should do.
I work on the laboratory informatics/gene sequencing side of the world and these conversations are becoming more common. To help give scientists some perspective, I've putting together some blog posts that introduce all the different angles:
https://www.lab7.io/is-your-he...
Yes, it's a bit of shameless self-promotion, but it's also relevant to the discussion (and I don't want to just cut-and-paste it here :) ).
-Chris