3 ms·
In large enterprises you see the opposite of NIH. There isn't a name for it but it's something to the tune of "You never get fired for choosing IBM." I remembe
by rubiquity 10y ago
In large enterprises you see the opposite of NIH. There isn't a name for it but it's something to the tune of "You never get fired for choosing IBM."
I remember constantly fighting for the right to develop the important software in-house rather than trying to cram them into a Salesforce app or buy some [x]-as-a-Service that does 60% of what you need and gives you 0% competitive advantage or intellectual property.
There's reasons for both approaches but you should never be too far in either direction.
- dasmoth 10y agoFor the organisational form, I've heard "never invent here."
- endophage 10y agoWikipedia says "proudly found elsewhere" or "invented elsewhere" are commonly used. I've heard the latter one before. https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here
- dasmoth 10y agoNeither of those are quite strong enough, I think. Some organisations have a great reluctance to build anything new even when there's a clear need. Hence never invent.
- ismail 10y agoWhat would be the choice/dividing line on what to build vs rent(saas)/buy?
- SimonPStevens 10y agoDon't buy things that are part of your core business. (If your business is creating a word processor, don't buy a rich text box control) Do buy things that are commodities and outside of your domain specific expertise. Accounting software (assuming you aren't an accounting software company). CRM software. Rich text controls. Build things that give you a competitive advantage over other companies in your sector.
- ismail 10y agoThis becomes more complex depending what industry you are in. Take mobile networks no mobile opco has the engineering talent to build their own switches, bsc or ns. One could say this is part of their core business. Yet they buy this.
- gtirloni 10y agoExactly. At a "all hands meeting" of the IT staff of large food manufacturer (top 5 globally), I asked if there was room for developing our own solutions sometimes (since we complained so much about our current tools and the lack of alternatives). I got an angry response from the CTO and later discovered people were laughing about my proposal (either because I must be stupid or because I was certaintly joking, in their view). I wasn't talking about writing our own ERP, my area was server infrastructure and there was tons of automation we could be creating, but instead the general strategy was to buy off-the-shelf tools and pay to be cheated on by IT consultants. The almost complete inability of the IT area to take ownership of its own fate made me leave 6 months later. "Nobody gets fired by choosing IBM" syndrome in full effect.
- dozzie 10y ago> [...] I asked if there was room for developing our own solutions sometimes [...] > [...] my area was server infrastructure You see, a sysadmin in such an environment is not expected to write programs. That's not in his job description. On the other hand, he probably is free to write scripts and configuration. I never bothered with asking if I, as a sysadmin, can write a service that I will use myself, nor I bothered with asking what language should I use. (This way I learned Erlang.) My job was to keep services running as intended, and how -- it was up to me. It would need to be very hostile environment to prevent sysadmins from writing their tools. Though your last paragraph suggests it was hostile.
- Infernal 10y agoThere are essentially four scenarios - you make the "safe" choice and succeed, and you're smart - if you fail, well, you can't be blamed, the safe choice is conventional wisdom. You make the risky/bold/nonconventional choice and succeed, and you're lucky - fail, well, you're an idiot who should've seen it coming.