How many times has it happened? You do your homework, find the right gear for the right job, and make a recommendation to go with the new guy, Vendor 1, instead of the established firm, Vendor 2. Vendor 1's gear clearly can be shown to outperform 2 in the ways that matter for your enterprise.
And yet, there's still discussion... why?
"Well, we've always been a Vendor 2 shop."
"We get deep discounts on Vendor 2 gear, and this would disrupt the relationship."
"Vendor 2 has offered some very attractive pricing arrangements."
"Vendor 1's licensing actually puts us at a cost disadvantage. Going with Vendor 2, we're covered by their enterprise agreement."
While the first one is just intellectual laziness on the surface, it can have its roots in the other three. Price, along with bandwidth, latency, inspections per second, and all the other technical factors, is a *huge* concern and can't be disregarded.
In fact, your recommendation to go with Vendor 1 may actually be just a bargaining chip to get Vendor 2 to come way down in price. I've seen this happen many a time in negotiations. It may not cause Vendor 2 to change its product to make it where it is equal to or better than Vendor 1's gear, but it will cause them to drop prices so that they don't lose the business.
I've also seen price negotiations that go in Vendor 1's favor to result in a dramatically different set of gear ordered than what was recommended, just to finagle the price to where their gear comes in at a price point lower than Vendor 2.
"If we virtualize these components of the solution, then we can purchase under the software budget."
"These models, which do have lower performance specs, we can get at a steal."
"We'll buy this gear up front, but we won't activate maintenance and support until we actually install it in the next fiscal year, so don't connect any cables until October 1st next year."
"We got what you wanted, except for that additional expense for the value-added additional feature that required a higher licensing level to activate. We can visit that issue again in next year's budget."
These are things that have to be kept in the back of your mind as you make technical recommendations. Even if you get what you want, you may not get what you want.
(https://robonthemoon.files.wordpress.com/2011/06/what-customers-want1.png)
Everyone knows that one guy way up in the company to either gets free hand outs ie tickets to sporting events, dinners etc. Or the one guy who pushes a particular vendor to keep himself employed.
True... I've heard the tales of vendors shooting down careers of engineers that didn't drink enough kool-aid. They want to send a message so that others there live in fear.
In such cases, the vendor has way too much connected to the firm for the relationship to be healthy. Don't live in fear, move on.
you missed out support and ease/cost of acquiring skillset (whether permanently in-house or temporarily/contracting or outsourced/consulting).
No use going with vendor X for 20% performance gain if nobody on your staff has the skills, you have to fly them somewhere else for a week @ 5k per head to do the basic course and their TAC is useless, etc. It usually has to be a pretty big gap to go to a completely unknown/niche vendor. Its obviously less of an issue for the big boys e.g. Cisco to Juniper.
Of course it depends - eg. deploying brocade switches on your access layer instead of cisco for example, no big deal. Core / MPLS switches, another issue altogether. (In Brocade's defence I've seen cost/performance figures up to 50% better than comparable ASRs so yes it can make sense LOL). Ditto for changing firewall vendors.
Yeah... firewalls... everyone wants Checkpoint/Palo, but they also trained up on an ASA 5505... Looks like we get another Cisco!
Yech.... seen that scenario way too many times. but yes, that lab 5505 I bought (then sold as soon as I got that CCNP Sec pass email) turned out to be great value, considering the number of times I've had to jump onto an ASA CLI.
Firepower you say? Why, its basically a second device bolted onto the ASA that you have to separately mess with? great, two for the price of one!!!
We are told we have to maintain two vendors not just for price wars but also so that each site can determine what equipment they want to use. We are a globablized/un-globalized mess. That's one item on my list of why I'm leaving.
If you can go single vendor like Cisco it really does help some-times, so when there is a routing issue between your FW and router they can't point fingers at one-another, there have just been so many times when devices didn't work right between echother that all worked out cause all items involved were Cisco that I fear what would happen getting different vendors working together.
Not saying that's a final "you should always buy Cisco", but it's defiantly something to keep in mind.
the only time I've ever seen that happen is routing to a Nexus :p
either
- broke the Nexus design rules re: peering over a vPC or related topic
- plain old NX-OS bug (7ks.... 5k L3 modules... kill me now)
Never seen a normal vendor FW to a normal router/L3 switch running normal OSPF or BGP develop any issues outside of incorrect design/config.
Of course, active/active FWs and each vendor's special sauce MAC spoofing ghetto load balancing and all bets go out the window
I have had several issues with EIGRP.
Had one where the ASA kept getting stuck in active with an ASR 1002 (IOS bug on the 1002).
One where the ASA wouldn't get the route update the 2921 sent it (IOS issue with the 2921).
One where we had connections flapping between routers alot (IOS bug where you couldn't have QoS on different types of interfaces).
Port channels won't form between different switch modal types.
Lol technical issues... too bad, accounting says that it's cheaper to run our routing off the ASA instead of using a dedicated L3 device, so you get that EIGRP to work, or you're over budget. And that won't look good on your annual review.
Accounting is architecture, remember that!
Quote from: deanwebb on October 20, 2015, 08:09:44 AM
Accounting is architecture, remember that!
This awful, true statement belongs in your signature line so as to be never forgotten :wall:
Quote from: routerdork on October 20, 2015, 09:06:36 AM
Quote from: deanwebb on October 20, 2015, 08:09:44 AM
Accounting is architecture, remember that!
This awful, true statement belongs in your signature line so as to be never forgotten :wall:
Done. And bolded. Commence the wailing and gnashing of teeth.
Quote from: wintermute000 on October 19, 2015, 12:02:15 AM
you missed out support and ease/cost of acquiring skillset (whether permanently in-house or temporarily/contracting or outsourced/consulting).
No use going with vendor X for 20% performance gain if nobody on your staff has the skills, you have to fly them somewhere else for a week @ 5k per head to do the basic course and their TAC is useless, etc. It usually has to be a pretty big gap to go to a completely unknown/niche vendor. Its obviously less of an issue for the big boys e.g. Cisco to Juniper.
Of course it depends - eg. deploying brocade switches on your access layer instead of cisco for example, no big deal. Core / MPLS switches, another issue altogether. (In Brocade's defence I've seen cost/performance figures up to 50% better than comparable ASRs so yes it can make sense LOL). Ditto for changing firewall vendors.
You know... reading this... I gotta say this sounds a little lazy (Minus the support part - that's spot-on).
So you're saying you wouldn't go for an overall 20% improvement in performance simply because you'd have to learn something new? Isn't that part of working in IT? I mean I get the reality and all... but in my mind I'd say a little growing pain (which should be minimal if you have the right people with the right mindset) is well worth a 20% permanent improvement to the network. You should always welcome a new challenge and improve your skill set! But I guess that's why I would never be a CTO...
Quote from: burnyd on October 18, 2015, 08:09:43 PM
Everyone knows that one guy way up in the company to either gets free hand outs ie tickets to sporting events, dinners etc. Or the one guy who pushes a particular vendor to keep himself employed.
Truth... truth... truth....
Vendor X had a bake-off against Vendor Y at a to-be-unnamed company. Same BGP/OSPF network side-by-side, same convergence tests using IXIA to get exact numbers, and Vendor X smoked Vendor Y in almost every category. Talking to the engineers, the feedback I got was they loved Vendor X, and weren't interested in "beta-testing" Vendor Y technology. A former distinguished engineer from Vendor Y becomes their new senior lead architect - guess what they're beta-testing..... hooray for politics.
Quote from: deanwebb on October 20, 2015, 08:09:44 AM
Lol technical issues... too bad, accounting says that it's cheaper to run our routing off the ASA instead of using a dedicated L3 device, so you get that EIGRP to work, or you're over budget. And that won't look good on your annual review.
Accounting is architecture, remember that!
Wow... classic. That's where you need to put a $$ behind what the outages cost you because of the technical issues. Or maybe have them sit on troubleshooting calls with your end users to explain to them that they shouldn't be complaining because it their decision that saved the company money!
Quote from: AspiringNetworker on October 20, 2015, 12:21:37 PM
Quote from: wintermute000 on October 19, 2015, 12:02:15 AM
you missed out support and ease/cost of acquiring skillset (whether permanently in-house or temporarily/contracting or outsourced/consulting).
<snip>
You know... reading this... I gotta say this sounds a little lazy (Minus the support part - that's spot-on).
So you're saying you wouldn't go for an overall 20% improvement in performance simply because you'd have to learn something new? Isn't that part of working in IT? I mean I get the reality and all... but in my mind I'd say a little growing pain (which should be minimal if you have the right people with the right mindset) is well worth a 20% permanent improvement to the network. You should always welcome a new challenge and improve your skill set! But I guess that's why I would never be a CTO...
*I* sure love training and learning about other vendors, but I'm not paying the training cost. In an environment with any amount of turnover, the risk is that as soon as you train up a guy, he walks to a different place, leaving you with zero ROI on the training.
And if you have to train up the next guy because the market isn't very forthcoming with Vendor X experience, then it's that risk, all over again.
Quote from: AspiringNetworker on October 20, 2015, 12:37:17 PM
Quote from: deanwebb on October 20, 2015, 08:09:44 AM
Lol technical issues... too bad, accounting says that it's cheaper to run our routing off the ASA instead of using a dedicated L3 device, so you get that EIGRP to work, or you're over budget. And that won't look good on your annual review.
Accounting is architecture, remember that!
Wow... classic. That's where you need to put a $$ behind what the outages cost you because of the technical issues. Or maybe have them sit on troubleshooting calls with your end users to explain to them that they shouldn't be complaining because it their decision that saved the company money!
CTO Counter-Argument: Do you know in advance what the outages will cost? No? Then we can't count them. Besides, our customer-focused, next-gen, transparent, strategically synergized and orchestrated IT staff will be able to deal with outages and prevent them from costing us any actual money. :mrgreen:
Quote from: deanwebb on October 20, 2015, 01:14:56 PM
Quote from: AspiringNetworker on October 20, 2015, 12:37:17 PM
Quote from: deanwebb on October 20, 2015, 08:09:44 AM
Lol technical issues... too bad, accounting says that it's cheaper to run our routing off the ASA instead of using a dedicated L3 device, so you get that EIGRP to work, or you're over budget. And that won't look good on your annual review.
Accounting is architecture, remember that!
Wow... classic. That's where you need to put a $$ behind what the outages cost you because of the technical issues. Or maybe have them sit on troubleshooting calls with your end users to explain to them that they shouldn't be complaining because it their decision that saved the company money!
CTO Counter-Argument: Do you know in advance what the outages will cost? No? Then we can't count them. Besides, our customer-focused, next-gen, transparent, strategically synergized and orchestrated IT staff will be able to deal with outages and prevent them from costing us any actual money. :mrgreen:
I'd counter with it's more foolish to bet against what history has shown time and time again, and specifically choosing to not learn from previous CTO's mistakes... then I'd probably be boxing my stuff up...
Quote from: deanwebb on October 20, 2015, 12:55:51 PM
Quote from: AspiringNetworker on October 20, 2015, 12:21:37 PM
Quote from: wintermute000 on October 19, 2015, 12:02:15 AM
you missed out support and ease/cost of acquiring skillset (whether permanently in-house or temporarily/contracting or outsourced/consulting).
<snip>
You know... reading this... I gotta say this sounds a little lazy (Minus the support part - that's spot-on).
So you're saying you wouldn't go for an overall 20% improvement in performance simply because you'd have to learn something new? Isn't that part of working in IT? I mean I get the reality and all... but in my mind I'd say a little growing pain (which should be minimal if you have the right people with the right mindset) is well worth a 20% permanent improvement to the network. You should always welcome a new challenge and improve your skill set! But I guess that's why I would never be a CTO...
*I* sure love training and learning about other vendors, but I'm not paying the training cost. In an environment with any amount of turnover, the risk is that as soon as you train up a guy, he walks to a different place, leaving you with zero ROI on the training.
And if you have to train up the next guy because the market isn't very forthcoming with Vendor X experience, then it's that risk, all over again.
Fair, but if a 20% increase in performance is PROVEN (not just claimed by a vendor with no supporting data), that's a definite - not a risk. Then you're only risk is investing in people, which I frankly believe will always be a risk, and a risk you should take. To me it's fairly obvious who to invest in - they're just a certain "type" of person. Burnyd, yourself, and that1guy15 being a few perfect examples. But, again, it's easy for me to say as an armchair quarterback.
Putting a management hat back on... also combining responses...
Your first response counters the argument in the second. We get the ROI on the hardware *if* we go with training, but the training is going to reduce our ROI. As for outages, even with all the training in the world, we're still going to have outages. Why not take a few more hits without a big training budget? If the hits are small, then they're less than the training cost and, therefore, justified. As for the major hits, we call TAC anyway for an RMI. Who needs expert training to dial a phone and say, "Please send the replacement to this address"?
(Management hat still on) We view training here as part of each employee's personal growth, not as a requirement for going with a particular vendor's gear. Granted, if we put in something brand new, we need to get that vendor training lined up. But for our core business functions, we should be able to rely upon normal personal growth for our source of expertise.
We also strive to maintain a structure in which, if we had to ramp up staff quickly, we wouldn't be hampered by obscure or exotic technology. If we have something off the beaten track that's easy to pick up on, not an issue. If we have a core function handled by some bespoke solution that has a high learning curve, well... how familiar are you with the fall of the Roman Empire? Once they lost the ability to support and maintain their technology, it went into decay, disuse, and then disappeared. I want to make sure our IT dollars are spent effectively.
***
(Management hat OFF) There are some niche players - firewall management, for example - that don't compete with Cisco. Those guys can actually be selected on the basis of their merits and then procurement goes to it at grinding down the prices. Some of the niche players, however, ride on the coattails of a major player and then the above stuff comes into play. I see this in the netflow analysis market. There are two major vendors there and *one* of them is in the Cisco order book. That's the one that we looked at the most, even though I liked the other vendor more.
Where majors collide, IE Cisco v. Microsoft in the voice market, it gets really brutal. The network runs on Cisco; the servers run on Microsoft. Two men enter, one man leaves. Heaven help the engineer that champions the wrong vendor.
I mentioned "How about Arista?" when we were talking about needing much higher 10gig port density in the datacenter. That led to an interesting discussion... basically, it would be better to take the hit on the datacenter 10gig stuff than it would be to take the bigger hit for Cisco to get mad and give us less of a discount. Even a single percent move on the discount would be a much bigger cost for us, globally, than what it would cost for us to stay with Cisco in the DC.
Quote from: deanwebb on October 20, 2015, 02:10:37 PM
Putting a management hat back on... also combining responses...
Your first response counters the argument in the second. We get the ROI on the hardware *if* we go with training, but the training is going to reduce our ROI. As for outages, even with all the training in the world, we're still going to have outages. Why not take a few more hits without a big training budget? If the hits are small, then they're less than the training cost and, therefore, justified. As for the major hits, we call TAC anyway for an RMI. Who needs expert training to dial a phone and say, "Please send the replacement to this address"?
(Management hat still on) We view training here as part of each employee's personal growth, not as a requirement for going with a particular vendor's gear. Granted, if we put in something brand new, we need to get that vendor training lined up. But for our core business functions, we should be able to rely upon normal personal growth for our source of expertise.
We also strive to maintain a structure in which, if we had to ramp up staff quickly, we wouldn't be hampered by obscure or exotic technology. If we have something off the beaten track that's easy to pick up on, not an issue. If we have a core function handled by some bespoke solution that has a high learning curve, well... how familiar are you with the fall of the Roman Empire? Once they lost the ability to support and maintain their technology, it went into decay, disuse, and then disappeared. I want to make sure our IT dollars are spent effectively.
***
(Management hat OFF) There are some niche players - firewall management, for example - that don't compete with Cisco. Those guys can actually be selected on the basis of their merits and then procurement goes to it at grinding down the prices. Some of the niche players, however, ride on the coattails of a major player and then the above stuff comes into play. I see this in the netflow analysis market. There are two major vendors there and *one* of them is in the Cisco order book. That's the one that we looked at the most, even though I liked the other vendor more.
Where majors collide, IE Cisco v. Microsoft in the voice market, it gets really brutal. The network runs on Cisco; the servers run on Microsoft. Two men enter, one man leaves. Heaven help the engineer that champions the wrong vendor.
I mentioned "How about Arista?" when we were talking about needing much higher 10gig port density in the datacenter. That led to an interesting discussion... basically, it would be better to take the hit on the datacenter 10gig stuff than it would be to take the bigger hit for Cisco to get mad and give us less of a discount. Even a single percent move on the discount would be a much bigger cost for us, globally, than what it would cost for us to stay with Cisco in the DC.
You sound like management material - and I don't say that as an insult. Wouldn't mind working for someone with that mindset even if we don't see eye-to-eye because you at least have some merit behind your statements.
Haha... as for the Cisco discount.. just tell Cisco that you're considering Arista, and enjoy the temporary almost free gear. :P
EDIT - And wow, being held hostage via discount? Classy.
Quote from: deanwebb on October 20, 2015, 12:55:51 PM
Quote from: AspiringNetworker on October 20, 2015, 12:21:37 PM
Quote from: wintermute000 on October 19, 2015, 12:02:15 AM
you missed out support and ease/cost of acquiring skillset (whether permanently in-house or temporarily/contracting or outsourced/consulting).
<snip>
You know... reading this... I gotta say this sounds a little lazy (Minus the support part - that's spot-on).
So you're saying you wouldn't go for an overall 20% improvement in performance simply because you'd have to learn something new? Isn't that part of working in IT? I mean I get the reality and all... but in my mind I'd say a little growing pain (which should be minimal if you have the right people with the right mindset) is well worth a 20% permanent improvement to the network. You should always welcome a new challenge and improve your skill set! But I guess that's why I would never be a CTO...
*I* sure love training and learning about other vendors, but I'm not paying the training cost. In an environment with any amount of turnover, the risk is that as soon as you train up a guy, he walks to a different place, leaving you with zero ROI on the training.
And if you have to train up the next guy because the market isn't very forthcoming with Vendor X experience, then it's that risk, all over again.
I'll say to this, though I know it's an impossibility, that the company should take a good hard look at itself and accept the fact that it may be at fault for people leaving. Why are those people turning over? Are they unhappy about pay? If other companies are willing to pay them more, that's not a fault of the person, or the other company - your company has decided that it's only willing to go so high. You shouldn't hurt/hinder your infrastructure or team because of a fear of something happening that you're empowering to happen - if that makes any sense. That goes for things other than pay as well.
"Training" can be cheap. It doesn't have to be a 5k/per person class with an instructor who hasn't spent a day in the field. You can hold weekly morning breakout sessions where a topic is chosen and presented by a member of the team. Not only does it force the member to sharpen their skills around that topic, it teaches/reinforces their ability to speak in front of a group of people - particularly their peers, which of course is great for a multitude of reasons. Maintain a knowledge base - an internal team blog of how-to's and what-not.
There are options out there....
When I was at MSFT, we actually did brown-bag sessions and got lots of magical manager review points for doing them. That is a good idea.
Where I am now, we do periodic briefings on tech that we're implementing, just so that everyone else knows what's going on. We document level 1&2 work instructions for the helpdesk people that will also be in charge of repetitive tasks.
We actually get one conference and one week-long class per year for our personal development. It's seen as a part of the overall benefits package, right up there with PTO and a very good health plan. With that mentality, sure, I could take a class and then skate away, but that training wasn't part of an ROI calculation. It was an employee benefit. That being said, there's encouragement for me to maintain my CCNP, get entry-level vendor certs (especially if the test is for free), and work towards a CISSP. Advanced vendor certs? Naaah, not so much. I'm not working for a VAR, so I don't need to gather those up. Experience with a product, absolutely, get as much of that as I can. General certs, like GIAC? I got the green light for those.
Quote from: AspiringNetworker on October 20, 2015, 12:21:37 PM
Quote from: wintermute000 on October 19, 2015, 12:02:15 AM
you missed out support and ease/cost of acquiring skillset (whether permanently in-house or temporarily/contracting or outsourced/consulting).
No use going with vendor X for 20% performance gain if nobody on your staff has the skills, you have to fly them somewhere else for a week @ 5k per head to do the basic course and their TAC is useless, etc. It usually has to be a pretty big gap to go to a completely unknown/niche vendor. Its obviously less of an issue for the big boys e.g. Cisco to Juniper.
Of course it depends - eg. deploying brocade switches on your access layer instead of cisco for example, no big deal. Core / MPLS switches, another issue altogether. (In Brocade's defence I've seen cost/performance figures up to 50% better than comparable ASRs so yes it can make sense LOL). Ditto for changing firewall vendors.
You know... reading this... I gotta say this sounds a little lazy (Minus the support part - that's spot-on).
So you're saying you wouldn't go for an overall 20% improvement in performance simply because you'd have to learn something new? Isn't that part of working in IT? I mean I get the reality and all... but in my mind I'd say a little growing pain (which should be minimal if you have the right people with the right mindset) is well worth a 20% permanent improvement to the network. You should always welcome a new challenge and improve your skill set! But I guess that's why I would never be a CTO...
I'll take that comment in the nicest possible manner (but it would be nice if you bear in mind the non-cisco alphabet soups next to my handle and my constant skepticism of any Cisco non-R&S product).
You're missing the point entirely - I'm speaking from the POV of management which deanwebb has covered off nicely.You need to take off your vendor SE / telco / military hat and look at it with an enterprise POV with their harried in-house team of what, typically 2-3 guys (1 if mid market) who already have a major skills gap compared to consultants/SE/PS engineers. How much is it going to take to upskill them? And critically how much use are you going to get out of those skills? And how much extra are you paying for PS every time something remotely major needs to happen? What's taking that engineer out of the firing line for a week worth? then say add an extra week of man hours lost a year due to unfamiliarity. See it all adding up. And again, can you quantify how many dollars this '20% better' is going to make for the enterprise?
The 20% figure is plucked out of the air but lets go with that. Typically I'm referring to replacing one component (or set of components) - how does a 20% more throughput edge firewall improve the network performance by 20%? And a lot of the time, esp. in enterprise, they are not using anywhere near the capacity of their products. What's 20% more throughput going to help the business in everyday terms on their access switching or a nowhere near loaded firewall? (of course if there's a must-have feature then that's an auto deal-maker or breaker but that's a different question). Let me spin this around: buying existing vendor C (lol) will give you capacity of 100, buying vendor X will give you capacity 120 - but guess what, your maximum anticipated usage is 80. What's the extra 20 doing for your bottom line? nothing.
Finally remember that the network is an afterthought to most enterprises. They want the least disruption, the least change, the lowest opex and lowest capex. Nobody blinks an eyelid when replacing like for like so politically there is zero risk. New vendor? Its on your head..... so how many conservative managers want to make that risk? What plaudits do they gain by putting in something that's got 20% better throughput? Harsh but that's the reality. Then of course to put in the new vendor product, its new change (at least) or project (normal) or program of works (eek!). Who's paying for all this disruption? There is a ton of political conservatism and inertia. These aren't necessarily good reasons- but they're there nonetheless, and is it worth your political capital/time to push this particular wheelbarrow uphill? For a minor performance gain I would probably lean on the side of no. Again, I'm not talking about a killer or required feature, I'm talking about marginal gains.
I've been through this discussion many a time when I was in-house and pushing for something different. Why are we still deploying 8XXs instead of SRXs? Why are we paying for ACS when I could just spin up FreeRadius? Why don't we replace all those expensive 3750Xs with Brocades, then I can stop begging you for IP Services licenses? etc. and I lost that plenty of times due to the management reasons deanwebb sprouted off quite readily. I don't always agree with it but I've heard those arguments enough times from managers who weren't all stupid (and including one or two pretty damned good managers actually) to realise that there is a kernel of truth in there.
And don't discount the hiring question. Maybe you have it easier in the US but here in Oz its difficult enough to get good normal network engineers (and by that you basically assume at least a CCNP level of knowledge on Cisco products). Have you ever tried to hire a good Juniper guy? Now drill down to a more obscure vendor. See where I'm going with this.... this applies also to getting contractors and/or adhoc resources.
Anyhow just pointing out there are a myriad of (possibly good) reasons from a management POV why you wouldn't just buy a competitor's product that is better on paper and cheaper. In my line of work, I see this ALL the time and believe me its in my company's interests to push for a change (since then win the professional services gig designing and implementing, and basically every vendor has a better margin in it for us than Cisco... as our director says, there are 19 Cisco gold partners in our city alone, why chase the same dollar bill as them)
Quote from: wintermute000 on October 21, 2015, 12:14:03 AM
Quote from: AspiringNetworker on October 20, 2015, 12:21:37 PM
Quote from: wintermute000 on October 19, 2015, 12:02:15 AM
you missed out support and ease/cost of acquiring skillset (whether permanently in-house or temporarily/contracting or outsourced/consulting).
No use going with vendor X for 20% performance gain if nobody on your staff has the skills, you have to fly them somewhere else for a week @ 5k per head to do the basic course and their TAC is useless, etc. It usually has to be a pretty big gap to go to a completely unknown/niche vendor. Its obviously less of an issue for the big boys e.g. Cisco to Juniper.
Of course it depends - eg. deploying brocade switches on your access layer instead of cisco for example, no big deal. Core / MPLS switches, another issue altogether. (In Brocade's defence I've seen cost/performance figures up to 50% better than comparable ASRs so yes it can make sense LOL). Ditto for changing firewall vendors.
You know... reading this... I gotta say this sounds a little lazy (Minus the support part - that's spot-on).
So you're saying you wouldn't go for an overall 20% improvement in performance simply because you'd have to learn something new? Isn't that part of working in IT? I mean I get the reality and all... but in my mind I'd say a little growing pain (which should be minimal if you have the right people with the right mindset) is well worth a 20% permanent improvement to the network. You should always welcome a new challenge and improve your skill set! But I guess that's why I would never be a CTO...
I'll take that comment in the nicest possible manner (but it would be nice if you bear in mind the non-cisco alphabet soups next to my handle and my constant skepticism of any Cisco non-R&S product). You're missing the point entirely - I'm speaking from the POV of management which deanwebb has covered off nicely.
You need to take off your vendor SE / telco / military hat and look at it with an enterprise POV with their harried in-house team of what, typically 2-3 guys (1 if mid market) who already have a major skills gap compared to consultants/SE/PS engineers. How much is it going to take to upskill them? And critically how much use are you going to get out of those skills? And how much extra are you paying for PS every time something remotely major needs to happen? What's taking that engineer out of the firing line for a week worth? then say add an extra week of man hours lost a year due to unfamiliarity. See it all adding up. And again, can you quantify how many dollars this '20% better' is going to make for the enterprise?
The 20% figure is plucked out of the air but lets go with that. Typically I'm referring to replacing one component (or set of components) - how does a 20% more throughput edge firewall improve the network performance by 20%? And a lot of the time, esp. in enterprise, they are not using anywhere near the capacity of their products. What's 20% more throughput going to help the business in everyday terms on their access switching or a nowhere near loaded firewall? (of course if there's a must-have feature then that's an auto deal-maker or breaker but that's a different question). Let me spin this around: buying existing vendor C (lol) will give you capacity of 100, buying vendor X will give you capacity 120 - but guess what, your maximum anticipated usage is 80. What's the extra 20 doing for your bottom line? nothing.
Finally remember that the network is an afterthought to most enterprises. They want the least disruption, the least change, the lowest opex and lowest capex. Nobody blinks an eyelid when replacing like for like so politically there is zero risk. New vendor? Its on your head..... so how many conservative managers want to make that risk? What plaudits do they gain by putting in something that's got 20% better throughput? Harsh but that's the reality. Then of course to put in the new vendor product, its new change (at least) or project (normal) or program of works (eek!). Who's paying for all this disruption? There is a ton of political conservatism and inertia. These aren't necessarily good reasons- but they're there nonetheless, and is it worth your political capital/time to push this particular wheelbarrow uphill? For a minor performance gain I would probably lean on the side of no. Again, I'm not talking about a killer or required feature, I'm talking about marginal gains.
I've been through this discussion many a time when I was in-house and pushing for something different. Why are we still deploying 8XXs instead of SRXs? Why are we paying for ACS when I could just spin up FreeRadius? Why don't we replace all those expensive 3750Xs with Brocades, then I can stop begging you for IP Services licenses? etc. and I lost that plenty of times due to the management reasons deanwebb sprouted off quite readily. I don't always agree with it but I've heard those arguments enough times from managers who weren't all stupid (and including one or two pretty damned good managers actually) to realise that there is a kernel of truth in there.
And don't discount the hiring question. Maybe you have it easier in the US but here in Oz its difficult enough to get good normal network engineers (and by that you basically assume at least a CCNP level of knowledge on Cisco products). Have you ever tried to hire a good Juniper guy? Now drill down to a more obscure vendor. See where I'm going with this.... this applies also to getting contractors and/or adhoc resources.
Anyhow just pointing out there are a myriad of (possibly good) reasons from a management POV why you wouldn't just buy a competitor's product that is better on paper and cheaper. In my line of work, I see this ALL the time and believe me its in my company's interests to push for a change (since then win the professional services gig designing and implementing, and basically every vendor has a better margin in it for us than Cisco... as our director says, there are 19 Cisco gold partners in our city alone, why chase the same dollar bill as them)
Wow. So.... I wrote a post to apologize, and then realized I was still missing the point so I deleted it. Suffice to say, I apologize for getting snarky there and for my failure of reading comprehension. Also, as I stated in other posts, it's very easy for me to say and think how I feel as an armchair quarterback when I'm not in your real-world shoes. /respect
On the other side, corporate horror stories carry a lot of weight. Nobody wants to be the guy that signed off on something that later resulted in a massive outage. If the outage *could* happen, meh, that's why we hire engineers. But...
"My buddy over at Big Company put this product in as their solution and it shut down an entire production line for a week."
You better believe that calls will be made to corroborate that info and the vendor will have a very rough meeting with the higher-ups at Your Company.
"I know a guy that used to work at Major Firm and he said they put this in and ripped it all out after a two years and millions in professional services when not even the vendor could get it to work as advertised."
Again, that's a huge, career-limiting risk. It's one thing if I have to hire people with moar skillz, it's quite another when the vendor and his gold partners can't get it up and running. Calls will be made, meetings will be booked.
Part of what I have to do in making a product recommendation is to put out feelers and find out who else is using it and what they think of it or what their experiences have been with it. Stuff like, "Works fine on 100 meg or 1 gig, but forget about 10 gig and this product," make for good information on how this stuff flies outside of a proof of concept demo.
To that end, we have a policy of doing a live PoC, with our engineers flipping all the toggle switches and stuff. Don't show me what this does on a pre-fab lab setup. We want to hook it up to our own ugly gear and see what kind of trouble we can get into. Phrases like, "Oh, you need a license upgrade on your switch" or "that sup card's not supported" or "we need to stand up another VM for that function" from the vendor can give us a better idea of the slog ahead and which product *really will* be the one to go with.
Ease of implementation is a huge factor. If a strategically-shaved monkey can get basic functionality out of the product because the GUI is intuitive, we got us a winner, here. If it's got a CLI-only interface that requires a Mandarin Chinese keyboard layout to work with... well, see ya! As a manager, I would feel tons better about a product that may require that week-long course for deeper knowledge, but that could be worked on by people with no experience after a short ramp-up.
Ease of implementation also appeals to the project manager. That dude wants zero overruns in budget or timetable. Comments like, "slick GUI", "fun to work with", "hopped right on the network and got to working right away," really help them to feel good about a product. Maybe the budget could be massaged with fewer man-hours of implementation assigned, with that money shifted over to capex for the higher-quality vendor?
As for the engineers that disparage the GUI... you're forgetting the Level 1 helpdesk dudes that don't know their DOS from a DoS. They *need* graphical utilities in order to be functional. You're also forgetting that managers like pie charts with colors on them. Those colored pies need to be easy to find and generate, or those managers' eyes are going to glaze over as you show them debug outputs.
Quote from: deanwebb on October 21, 2015, 02:10:46 PM
On the other side, corporate horror stories carry a lot of weight. Nobody wants to be the guy that signed off on something that later resulted in a massive outage. If the outage *could* happen, meh, that's why we hire engineers. But...
"My buddy over at Big Company put this product in as their solution and it shut down an entire production line for a week."
You better believe that calls will be made to corroborate that info and the vendor will have a very rough meeting with the higher-ups at Your Company.
"I know a guy that used to work at Major Firm and he said they put this in and ripped it all out after a two years and millions in professional services when not even the vendor could get it to work as advertised."
Again, that's a huge, career-limiting risk. It's one thing if I have to hire people with moar skillz, it's quite another when the vendor and his gold partners can't get it up and running. Calls will be made, meetings will be booked.
Part of what I have to do in making a product recommendation is to put out feelers and find out who else is using it and what they think of it or what their experiences have been with it. Stuff like, "Works fine on 100 meg or 1 gig, but forget about 10 gig and this product," make for good information on how this stuff flies outside of a proof of concept demo.
To that end, we have a policy of doing a live PoC, with our engineers flipping all the toggle switches and stuff. Don't show me what this does on a pre-fab lab setup. We want to hook it up to our own ugly gear and see what kind of trouble we can get into. Phrases like, "Oh, you need a license upgrade on your switch" or "that sup card's not supported" or "we need to stand up another VM for that function" from the vendor can give us a better idea of the slog ahead and which product *really will* be the one to go with.
Ease of implementation is a huge factor. If a strategically-shaved monkey can get basic functionality out of the product because the GUI is intuitive, we got us a winner, here. If it's got a CLI-only interface that requires a Mandarin Chinese keyboard layout to work with... well, see ya! As a manager, I would feel tons better about a product that may require that week-long course for deeper knowledge, but that could be worked on by people with no experience after a short ramp-up.
Ease of implementation also appeals to the project manager. That dude wants zero overruns in budget or timetable. Comments like, "slick GUI", "fun to work with", "hopped right on the network and got to working right away," really help them to feel good about a product. Maybe the budget could be massaged with fewer man-hours of implementation assigned, with that money shifted over to capex for the higher-quality vendor?
As for the engineers that disparage the GUI... you're forgetting the Level 1 helpdesk dudes that don't know their DOS from a DoS. They *need* graphical utilities in order to be functional. You're also forgetting that managers like pie charts with colors on them. Those colored pies need to be easy to find and generate, or those managers' eyes are going to glaze over as you show them debug outputs.
Haha some very good points here.
About doing a live PoC... yes.. yes.. yes.. yes!!! I LOATHE when a product evaluation is only, "Do you support X, Y, and Z feature?". Sure it's important, but you also need to performance test, and keep the vendors honest. Ixia/Spirent has a way of doing that. I'll never forget slapping 10Gb transceivers into a Juniper Netscreen and watching the SCREAMING 1.xGb performance we were getting according to Ixia. That was my first lesson in ASIC channel polarization (A single point-to-point VPN only uses a single channel in the ASIC, and it's limited to 1.xGb, at least that's what the Resident SE told me) - something you never read about (that I've noticed) in traditional studies. Everyone's perfect according to their data sheets - put em to the test! You also get a real eye-opener on just how "easy" to implement a solution actually is, as you stated.
I remember when I used to knock on GUIs.... then I remember using Arista's TapAgg Manager GUI to configure a traffic steering policy with 10% of the effort it takes to type it all out in the CLI. That and c'mon... when you start managing tens and hundreds of devices... the more time you can save the better, I'm sure. The CLI is still king for troubleshooting though - no doubt.