Who Makes the Decision To Go Cloud and Who Should? 154
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 answer is yes (Score:5, Informative)
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.
Re:The answer is yes (Score:4, Informative)
There are too many technical people in IT departments that basically only care about what's cool. "Cool" should probably not be part of a business infrastructure decision.
Re: (Score:2)
Re:The answer is yes (Score:5, Interesting)
I went through this.
Management and I met with the cloud salesperson and technical rep.
The tech rep was full of shit. When asked, he said response time would be FASTER. I objected on the grounds of the restriction of the speed of light.
Our current servers were in the next room via Ethernet.
The cloud was "out there."
I asked, "What fail-overs do you have?" They said that the cloud was in Austin and if it failed, Oklahoma would pick up the slack so fast, we wouldn't feel it.
After the meeting, I called the business number in Austin and asked for support. I got a kid and I asked him if the data center was there in Austin.
He said, "No, but we're thinking of building one."
I said, "How about the one in Oklahoma?" He said, "Cool. We have one in Oklahoma?"
Management loved the word, "cloud." "Cloud." "CLOUD."
It sounded good at cocktail parties and conference rooms and in front of clients.
--
I recommended that we not go with those crooks and I laid it out very plainly, calmly and stuff.
Long story short ... I told management that my recommendation was on the record and that the IT department would certainly support any decision they made.
They took the bait.
6 months later and $60,000 down the road, I got the word to buy servers and switches and stuff to and to quietly duplicate all the stuff in our old computer room.
The cloud had gone down several times and there was no fail-over. It was slower than molasses and exceedingly expensive.
The blow that cracked the nut, though, was the long list of cloud hacks and the business (law) could not risk a breach by placing client data God knows where.
We're supposed to know where God put it, right?
We do now.
The Kazakhstan Problem (Score:2)
The Kazakhstan problem goes like this..
You can't tell where your cloud computing is hosted. Any host can delegate to some other host.
So Vendor A with well paid shiny sales people sells cloud hosting.
Vendor A outsources the physical part of the cloud to Vendor B who is a bit cheaper with slightly less well paid sales people. Vendor A cashes the difference.
Vendor B outsources to vendor C in China who is cheaper still. Vendor B cashes the difference.
C -> D
D -> E
Repeat a few times until all the world's cl
Re: (Score:2)
Is there a backup cupboard?
Re: (Score:2)
I find wording it right helps: "Do we want cloud, or keep our PRIVATE cloud we already have in the next room?"
Re: (Score:2)
That's why you say, "we build our own cloud". If there is somebody with some skill show them a demo with openstack or something like this. Then continue to use your servers.
Re: (Score:2)
Well, #1 and #3 come under technical "Can we do it?", at least the parts where the company has the technical ability to switch providers if one goes out of business and to handle connectivity problems (I classify a provider going out of business as just a particularly severe and long-term connectivity problem, communications with their systems is completely down and won't ever be back up). The rest is all business decisions, the same sort business makes about every external vendor the company does business
Both? (Score:3)
Re: (Score:3)
I agree, it needs to be a joint decision so all factors can be considered.
But it seldom is. Management gets lobbied by sales execs, or reads an article in some airline magazine, or goes to lunch with someone, and there you have it.
Then when it goes wrong it's the fault of that incompetent tech staff who can't carry out a simple mandate.
Cost (Score:1)
It all comes down to cost. Just like any other engineering or design issue.
senior management â" with their strategic perspective
This usually means that there is some financial input not available to engineering for decision making. Like kickbacks or Hookers & Blow.
EVERYTHING IS CLOUD (Score:1)
You mean you have stuff that isn't in the Cloud yet? What rock are you operating under?
Why does it have to be just one team? (Score:1)
Like most things in life, decisions are made in collaboration. CEO wants "cloud", but when the CFO explains the regulatory risk, he finally gets it. IT folks might want to move "to the cloud" to pad their resume, but management doesn't want to spend the money on retooling/retraining/migrating (yes, there are costs beyond cloud costs in migrating).
People should talk, and see what makes sense. Like most decisions a corporation makes.
Senior IT management? (Score:3)
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.
Re: Senior IT management? (Score:2, Interesting)
You clearly haven't run an email server in the past few years.
You are now required to utilize reverse (PTR) records on your IPs, DKIM and SPF records, run inbound and outbound SPAM filters.
Blacklists kill businesses. It is frustratingly time consuming to have to deal with getting an email from an executive with a "Fwd: Message failure, return to sender" in the subject.
Then, as an IT admin, you have to go and hunt down how to get your IP off that blacklist. Some are easier than others, some require faxing in
Re: (Score:2)
It's really not all that hard and MS charges $20/mo/account on the Enterprise side (once you integrate with your LDAP etc). Let's say you need 300 mailboxes, you're suddenly paying $1500-$6000/month + your time investment into setting up these mailboxes remains the same. That pays for a pretty nice system IMHO.
I have run several companies' mail server either on shared hosting or in-office (depending on the resources available) and it ends up costing almost nothing to run a system up to 500-1000 mailboxes, n
Re: (Score:2)
It's pretty tough to get blacklisted if you're aren't actually sending spam. Block port 25 outbound from your office LAN so trojanned laptops can't send spam, and you're probably good to go.
SPF, DKIM and PTR records take maybe an hour to setup right.
And yeah, if it goes down at 3 am, I fix it, just like any other production system. I probably won't have to drive since it's on a VM on redundant hosts like all the office servers, but if necessary, sure.
People being people (Score:4, Interesting)
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".
Re: (Score:2)
What people who are not in IT realize is that we also answer to finance, HR, and legal.
Just the other day HR gave us written warnings and started documenting what I said. WTF. Why? The client came in and demanded all applicants applying MUST HAVE ACCESS TO PERSONAL EMAIL on our network from anyone off the street?!
For the background we are a call center company who has HIPAA and PCI compliance that we use the same switches, routers, and servers. Oh yeah, gee no risk at all of a virus or keylogger coming on s
Re: (Score:2)
HR and management snuck in some Samsung tablets and put in our secret wifi password to get around corporate IT and then were infuriated when we threatened to report them.
This is why I don't allow any PSK wireless networks on the corporate network. It's all based on certificates and domain membership. No unauthorized devices allowed.
It's actually very easy to setup.
Re: (Score:2)
Seriously? (Score:4, Insightful)
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.
Re:Seriously? (Score:4, Insightful)
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.
The decision to go cloud should not be a decision made by any person as the original question implies, it should be a balanced decision made by systems/software/system-architecture people (does it get us anywhere technology wise), business people (does it make financial sense) and marketing types (is this what the customer wants). You might want to throw in a security expert to avoid getting yourself ashleymadisoned.
Business MGNT defines the requirements... (Score:3)
CIO/CTOs are hopefully technical (Score:2)
CIOs/CTOs are hopefully technical in a company that has these needs, and they'll also hopefully consult with their people for these kinds of questions. If they're not capable or willing to do both, the company has more pressing concerns than where to host its stuff.
(Plenty of tech companies have bad CIOs or CTOs).
both (Score:2)
First, "techies" is like calling a manager a "flunky". Insulting.
Second, this has to be a 2 way conversation. The #1 benefit of "Cloud" is cost scope control - you can't customize it so business has a hard line instead of pushing IT for endless enhancements. As for "can or can't", provide managers rough estimates and high level todo's as to what it'll take to get there. There is never "we can't", there's "it'll cost this much" which will make then choke and chose a wiser path.
Re: (Score:2)
can't customize it? what do you think buying instances from amazon is for.
buying the software as a service from some vendor that has servers "somewhere" is not the same thing as moving your shit to the cloud. majority of small tech houses now are doing custom cloud shit.
Re: (Score:2)
First, "techies" is like calling a manager a "flunky". Insulting.
You can choose to be insulted by anything you like, but tech types have been calling themselves techies for decades.
There is never "we can't", there's "it'll cost this much" which will make then choke and chose a wiser path.
No, there's also "we shouldn't". Hosted cloud computing makes sense for some cases, and not for others. If you don't care about security, OK. If you need to scale up and down more rapidly than you can otherwise reasonably provision for, OK. Otherwise, host it yourself.
Comment removed (Score:5, Interesting)
Re: (Score:1)
It depends upon the company (Score:3)
.
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.
Simple experiment-- (Score:5, Insightful)
"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?
Re:Simple experiment-- (Score:4, Insightful)
It sounds fine.
We rely on our server uptime because of someone else's electricity (we should just generate our own)
We rely on other people's hardware. They could have back-doors or bugs. Lets just Make our own servers and software to be sure we have ultimate control over them...
Rhetoric and blah blah.
It comes down to division of labour, and every single day, basically every single human puts their lives in the hands of others. The choice to voluntarily relinqusih control of a piece of your life is a practical one (just as a decision to cloud compute, outsource, hiring contractors, and all the other heebie jeebies that keep insecure employees up at night).
Re: (Score:2)
We rely on our server uptime because of someone else's electricity (we should just generate our own)
I haven't yet seen a datacenter (or even a server closet) that doesn't have at least a small UPS (to allow graceful shutdowns). For mission-critical environments, you actually *do* have back-up generators and the like (Think hospitals). Following that analogy, a hybrid option is actually one that might be worth pursuing, putting services into a cluster and having part of the cluster hosted on-premise.
It all c
Re: (Score:2)
You still do rely on all those things, but you're just pushed them far out of your reach.
Congratulations, you now have far less control than you had before, with the added benefit of your data no longer belonging to you.
Re: (Score:2)
We rely on our server uptime because of someone else's electricity (we should just generate our own)
I'm not even in a tech company, and we rely on business uptime by ensuring that we *can* generate our own electricity if need be. (UPSs to guarantee the critical machines don't die, which includes certain workstations), and then a generator on-site to power the building until the utility company sorts their problems out and switch back over.
The difference you're making is "are you trusting your core business to an outsider who won't suffer as much as you if they fail"?
Re: (Score:2)
> become a serious issue since NSA
That's wrong.
This always was an issue. But now we know.
Re: (Score:2)
You are part of the old guard.
SaaS is simply the way things are heading. Running your own servers will become less and less common as internet connections get faster and faster.
You will simply not be able to compete financially with cloud-based services. Who will want to spend hundreds of thousands of dollars to build a small server room and be responsible for their own DR solution, licensing and upgrade costs and be subject to unexpected expenses for failures and downtime when they can spend around $30,000
Re:Simple experiment-- (Score:4, Insightful)
Sure it does:
We outsource everything to experts who can do things better. For every example against the cloud I can find an example of another company that did it their own way on their own computer and yet were too incompetent to protect it adequately.
The only key requirement is that you are legally covered for fuckups by the other entity and that you're not wholly reliant on a single point of failure. Dismissing the cloud because it's "someone else's computer" is dismissing one possible solution to a variety of IT scenarios due to prejudice and not cost/benefit analysis.
Re: (Score:2)
You are not legally covered for fuck-ups by the other entity.
They are only liable for the cost of the contract and that's it (if that). If they fuck up, they'll say sorry, they may pay you back your last few months to a year worth of fees and then, contractually their obligation is done. YOU as a company remain liable for YOUR data and YOUR clients. Also, if they figure out that it was one of your users that was in any way involved, the liability is pretty much shifted back to YOU.
Read these contracts, they
Re: (Score:1)
Tell people that instead of saying "in the cloud" they say "on somebody else's computer" and see how that goes--
Do your internal staff also clean the toilets? Do you grow all your own food? I mean where does the paranoia end?
On-Premises (Score:2)
In my view, nobody should comment on whether anything should be on-premises or not, if they are unable to distinguish between the word "premises" and "premise." Laziness of the tongue or of the quill is not an excuse.
MGNT might know on-prem site is closing, can't say (Score:1)
Far too often, some exec read a magazine (Score:2)
Yep. Them dang magazines. Or them dang online "executive" websites. Often, "cloud" isn't an intelligent decision arrived at from collaboration between all concerned parties, as well-detailed in the earlier posts, it's "somebody's boss read a magazine article or saw something on the WSJ site," and next thing you know, the commandment comes down: WE MUST GO TO THE CLOUD, even though nobody involved in the issuance of the commandment even knows what the fuck "the cloud" actually IS. Or what it isn't.
Been thr
Re: (Score:2)
Well, just like the other things you listed, "the cloud" makes sense in some applications. SOME. Sadly not ALL.
There are actually good reasons to move your business to "the cloud". Unfortunately management is most of the time not the entity in a company that could gauge whether or not those reasons apply to them. You have identified it pretty well, though the reasons you give area actually a bit less "childish". The reason is more along the lines of why politicians buy into scare crazes. Should for some odd
Re: (Score:2)
I mean, ask your friends. "You guys putting things in the cloud?" "Yeah." "Why?" "Management said we had to." "Why?" "Man, shut up. You already owe me a beer."
They know. You know. "Cloud" is just another fad.
Maybe instead of asking your friends, you should get advice from someone who knows what they're talking about?
Cloud Services offer a value proposition for certain types of applications and services. eg, got a Web App you want to release, but don't want to spend hundreds of thousands on hardware, computer room, resiliency etc? (Yes hundreds of thousands, because that's how much it costs to build a pair of fully fitted out 24/7 resilient computer rooms).
Companies like AWS offer you all that for a few dolla
"Correct" Is Subjective (Score:5, Insightful)
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.
Re:"Correct" Is Subjective (Score:5, Interesting)
Having worked my way up through every level, the biggest thing I've learned is "correct" is a massively subjective concept, based on value statements people at other levels don't see.
This pretty much sums up most Slashdot comments whenever the word management is used. Worker-bees are simply unaware of the complexities and conflicting demands that someone with responsibility faces. Instead of thinking hey that decision doesn't make sense, there most be more to it that I don't understand, the general reaction is, there's a decision I don't understand, that guy is a moron.
The ironic part is that by calling out the decision as stupid they are merely highlighting their own stupidity that they've failed to grasp the full nature of the problem.
TLDR Stupid people are usually too stupid to realise that they're stupid.
Re: (Score:2)
Instead of thinking hey that decision doesn't make sense, there most be more to it that I don't understand, the general reaction is, there's a decision I don't understand, that guy is a moron.
They have the right reaction, they're just aimed in the wrong direction. If your business is based on a technical solution, then your decisions must have a technical basis. If you're making what is technically the wrong decisions for "business reasons", then either your business or your reasoning is suspect. It may not be your direct manager's fault, but at some point, it is someone's fault. If the people at the top reliably choose a direction not supported by technical reasoning, the company will eventuall
Re: (Score:2)
They have the right reaction, they're just aimed in the wrong direction. If your business is based on a technical solution, then your decisions must have a technical basis. If you're making what is technically the wrong decisions for "business reasons", then either your business or your reasoning is suspect.
Yes, but equally, there's a lot of technical people who think they know what's good for the business, but really don't. Cloud services are a prime example, there's so much irrational hate out there, but all the FUD has been debunked. Ultimately it comes down to risk, and both cloud and on-prem come with risk, the cloud option however generally is easier to define and insure against, which is why business is a big fan of it.
Re: (Score:2)
Ha ha ha, that's really funny, and smart, like me. Wait - why have I got the vague feeling like someone's been talking about me, and not in a nice way?
Re: (Score:1)
TLDR Stupid people are usually too stupid to realise that they're stupid.
It's more a question of ignorance than stupidity. You can be extremely intelligent and knowledgeable in certain areas, but clueless about everything else. As is proved by most slashdot comments on non-tech issues.
Re: (Score:2)
The first mistake is licensing something with that restrictive/punitive of a license. If I buy a license from a company, there is a contract and someone (most likely finance) should keep track of that. Additionally, that company should also keep track of it's documents before they sue you (a good lawyer will request discovery on said documents and if they can't be produced, the case pretty much goes away).
If you pay extra just for 'protection', it's extortion. Go with another company that doesn't do this or
Re: (Score:2)
I've had very similar experiences over the years. When you're just responsible for working on one sort of problem, you have a tendency to only recognize what's going on with those problems, and you want to fix those problems in "the best way". Like if you're a programmer, you might want to write very efficient code in the best language using the best tools or framework or whatever, and it makes perfect sense to you. Your manager is simply being stupid and stubborn when they force you to solve those probl
Seen it firsthand (Score:4, Interesting)
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.
Ultimately senior management, with caveat ... (Score:3)
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.))
Simple answer (Score:2)
There's a simple answer:
Get a techie into the position of CIO.
It's the C*Os job to make those strategic descisions and these should be based on experience. So have a techie as CIO and your MBA as CEO. And don't mix them up.
The role of a CSO is simple. And justified. (Score:2)
Who should make the call to take any corporate data to the cloud? That answer is simple. The CSO.
Who usually does end up making the call to take corporate data to the cloud? That answer is unfortunately simple too.
It's usually anyone other than a CSO, with the end result being the justification as to why you need one.
As usual: Marketeers decide without asking (Score:3)
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.
Finance could help... (Score:2)
...if they have the sophistication to model the actual costs of the various options in a comprehensive way that includes deciphering the hazy costs associated with cloud hosting itself (availability options, CPU options, storage costs etc), premise costs (upgraded Internet access with true secondary path), migration costs (can some systems be just P2V'd to a cloud hosting provider or does it involve a platform switch and/or upgrade?), impact on staffing, general in-house implementation from a desktop perspe
Who Makes the Decision To Go Cloud and Who Should? (Score:2)
C-Level Executive of course (Score:2)
Personally, I would be extremely wary of allowing any corporate data to be "housed" in a cloud unless they have deep pockets are can be held liable for damages c
Ashley Madison (Score:1)
Re: (Score:2)
The problem is, the Cloud is correctly named. Clouds tend to leak.
System Analyst (Score:1)
It helps to define the cloud first... (Score:3)
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... [lab7.io]
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
Give the decisions to the decision makers (Score:1)
The tech team should be consulted to make sure any new solution is sufficiently compatible with existing ones. HOWEVER, they are just one of the stakeholders in the process: users will flat out reject anything thrown at them without consultation, business leaders may know about competing projects or business goals, and any major initiative is likely to trip over a handful of shadow IT projects.
The CIO needs to be the ultimate decision maker because they have the perspe
Who should? (Score:2)
Whoever has the guts to stand up to the marketing drones and tell them, "No".
The Roads Must Roll (Score:1)
Did not Heinlein write about techies vs. management in The Roads Must Roll?
Re:Whoever pays the bills (Score:4, Interesting)
Re:Whoever pays the bills (Score:5, Insightful)
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.
Re:Whoever pays the bills (Score:5, Funny)
How a plan becomes policy [stanford.edu]
Re: (Score:2)
Re: (Score:2)
Often the Rouge deployments is due IT not being responsive enough or letting other departments behind while focusing more on others.
Those IT Guys they don't like us Sales folks, the engineering groups gets all the new technology while we get this old stuff. Well we have a budget we will subscribe to this web site that does what we wanted and tried to request for software for year, but was ignored by IT.
Re: (Score:2)
I always rather liked Bleu deployments... Rouge is so.... Moulin!
Re: (Score:1)
I always rather liked Bleu deployments... Rouge is so.... Moulin!
When two different posters used the term "rouge deployment" I assumed it was some new buzzphrase rather than a typo.
Re: (Score:2)
Our organization recently decided to go with Microsoft Dynamics Online. We (IT) didn't really get much of a say in it.
However, what we did was use the initiative as a platform for our own move to expand the cloud deployments from just CRM users to all users.
We are now well on our way to migrating off of on-prem Exchange and a mixed Office 2003 - 2010 environment to an Office 365 solution.
So, in effect, we took an project spearheaded by sales and turned it into a benefit for all users.
Re: (Score:2)
True indeed... painfully true in many cases.
That said, remember that even though the CIO (and/or directors, etc) are easily swooned by vendors, consider this: One expensive fuck-up at the strategic level can destroy a career in less time than it takes for the CFO (or someone similar) to lodge a complaint in the boardroom, the first massive security incident, the first major outage... (and if you think the CIO is taking the heat for it, you're insane... that's why he drags a director or two into the process.
Re: (Score:2)
I've been a consultant for close to 20 years and I'm AMAZED by the decisions made by high level executives based solely on a sales pitch or based on the advice of a family member or friend that 'knows about computers and stuff'.
Re: (Score:1)
I was going to say pretty much the same thing! I've been a consultant for close to 20 years and I'm AMAZED by the decisions made by high level executives based solely on a sales pitch or based on the advice of a family member or friend that 'knows about computers and stuff'.
Unless you're talking about some one-man band operation, "high level executives" do not get to make major unilateral investment decisions based on random hunches.
Re:Whoever pays the bills (Score:5, Insightful)
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.
Re: (Score:2)
I have spent hundreds (if not thousands) of hours cleaning up the carnage of #1
Re: (Score:2)
Re: (Score:2)
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.
Strangely, my experience has been that our devs test-driving "the cloud" has made them appreciate the level of support they get from the in-house IT even more. Almost without fail, every dev team has gone through a phase of "ooh! we can pop up a server without waiting on IT!" Followed by "This isn't *exactly* what we need, and we can't change it from the canned offerings," and "hey, IT support us! Sorry, we can't do anything for you past general advice, you have to work with $CLOUD_VENDOR." And eventually,
Re: (Score:2)
makes the call.
Next silly question?
Sure, the person who pays the bills makes the call but they usually make that call based on cost. If it costs less in hardware/support/security/reliability/etc.. to move to the cloud, then it's usually a safe bet to do it. In most organizations, the person paying the bill would ask the IT department for costs and make the decision based on that. In the company I work for, we only have a few servers and by moving to the cloud we have a fixed bill, a reduced workload, no need to replace hardware, more reli
Re: (Score:2)
Some costs can be hidden from that deciding person. Or greatly understated.
I've seen that time and again.
Re: (Score:2)
FTFY
Re: (Score:2)
FTFY
How do you figure? We now have a monthly fee that is the same each month versus previously we had an initial outlay of several thousand dollars per server, ongoing costs of hardware repairs, and then another outlay a few years later for new servers. Yes, if you don't have a contract then the monthly fee can possibly go up but it usually just tracks inflation and is much more fixed and steady than owning your own servers. You can argue that it's more expensive, it's less secure, or a host of other things
Re: (Score:2)
It could be higher loads, it could be when you need something quickly.
Re: (Score:2)
Somewhere in their billing structure is a gotcha. You haven't hit it yet.
It could be higher loads, it could be when you need something quickly.
Why so pessimistic? Believe it or not, there are plenty of companies out there with straightforward upfront pricing that don't nickle and dime their customers and instead charge a fair price for their services.
Yes, if you need technical support for something that's not under contract, a company might charge you a reasonable hourly rate but believe it or not most companies aren't out to screw their customers. Especially where there is a lot of competition, it's hard to stay in business if you're always try
Re: (Score:2)
If you read the question to the end, you would know. The next question is then "and who should".
Re: (Score:1)
I am lucky to have worked for some darn good companies when it comes to security.
However, the problem is most firms I've encountered have top brass that believe that security has no ROI [1], and going to the cloud has a ton of PR benefit, from the talk about tossing the data center, to not having to have tons of low level admins to yank hard drives, rack/unrack equipment.
Combine that with the fact that a single cloud provider has yet to have been breached, usually makes the CEO/CTO push for a cloud solution
Re: (Score:2)
I am lucky to have worked for some darn good companies when it comes to security.
Ditto. I give thanks regularly that the business principals who run the company I work for get it, generally.
Combine that with the fact that a single cloud provider has yet to have been breached, usually makes the CEO/CTO push for a cloud solution, stat.
[1]: When I ask about the intrusion scenario, the business I was interviewing at said, "we just call Tata or Infosys, and they will fix it."
There may not have been any breaches of a "cloud provider", yet, but that's not really surprising. Honestly, the sec
Re: (Score:2)
I'm just going to leave this here: https://www.google.com/#q=aws+outage+history [google.com]
Re: (Score:2)
So if you were implying its always down, your link doesn't back up your implication.
Yep, you got it. I was implying that AWS is always down. Always. No exceptions. Never running.
Good job.
Re: (Score:2)
>better performing for less
Enterprise-class hardware? Maybe if you're overpaying for it.
If you owned the same hardware that amazon does, it would be cheaper and faster than running it on amazon's VMs. Faster for the obvious reason that you're running on bare metal and not inside a VM, and cheaper because Amazon wouldn't profit if their income from renting VMs was less than what they spent on hardware. Check the price of renting a big VM for 3 years versus buying the equivalent real hardware.
None of this is to suggest that there aren't other benefits to using VMs. Like you said, resilience and monitoring. Someone else's grunts are dealing with the hardware instead of you.
If you do it right, you should be able to guarantee some base load that will keep some computers busy. Buy those and run the system on it. Then use the cloudy servers to scale up as variable load happens. The cloud stuff isn't cheaper unless you are avoiding paying for idle hardware.
Re: (Score:2)
. The cloud stuff isn't cheaper unless you are avoiding paying for idle hardware.
Er, that is the whole point of AWS. It is charged by load, so you scale up and down as required, therefore never paying for idle hardware. The AWS model wins because they extract 100% of every piece of hardware, while most on-prem shops would be lucky to get 10%. AWS is going to take over the world. You heard it here first.