But with vendors come different issues. They can go out of business, or get acquihired. If their product is in any way not aligned to your business needs - and it almost never is - then you have to either throw a lot of money at them so they customize their service for you, or you can alter your business to fit the vendor's offerings (and keep altering it as they iterate on their product). Both options are terribly inefficient compared to just asking your engineers to tweak something in your own codebase.
(And then your country's government and the US government decide to unfriend each other, and suddenly 95% of services you depend on and their competitors can't service you anymore. There's that risk too. See e.g. Venezuela.)
I viscerally hate the idea of a business being assembled purely from third-party services, reducing itself into a pile of contracts. I really dislike the way how our economies start turning into NPM. But everyone keeps saying there are good business reasons for that. So maybe they are. I don't have a formed rational opinion on which way is better yet.
- Non-IT companies overall have terrible IT systems because as soon as they have two systems they need some sort of integration which the vendors are likely to botch and the resident "IT person" isn't qualified to build and maintain.
- "Nobody was ever fired for choosing $vendor" actually makes sense when integration is a black hole for time and money. At least a single vendor is likely to have already taken care of integrating with their own products.
- When people start looking at which parts of an IT infrastructure to improve it's usually the oldest and most botched-together piece. But it is nearly impossible to replace because of all the botched-together custom integration code which was cobbled together by half a dozen barely-qualified staff.
More and more, I think such a phrase should read, "resident management requested too many features without sufficient budget".
> code which was cobbled together by half a dozen barely-qualified staff
Idem, "code copy pasted to satisfy excessive requirements of pointy haired boss" is the more informative statement here
I cherish my customers that have company lifers on the other side. Dealing with people that actually know what they are doing and have history and context to draw on is such a luxury.
So long as each part of the system can export and import CSV, or similar, then anyone with Excel and enough time can become a Systems Integration Expert
We won the internal bid for a functionality module that ended up being a standalone service called by system X. Vendor X had lost that bid. They convinced the bank that it is absolutely necessary for us to expose a JDBC driver as an interface.
Their engineers were actually pretty cool and we agreed to implement something which made more sense. Unfortunately this decision was blocked. We ended up exposing a simple RPC API via a JDBC driver. I think it had over a thousand methods, almost all of them empty.
Given that, consider that when a salesperson from some vendor visits you, they're not likely to be accurate in describing their wares either.
One phrase that I've increasingly come to love is "torpedo in the hull" (https://allaboutstevejobs.com/blog/category/steve-jobs-histo...). It's tough seeing senior folks tolerate vendor-outsourcable projects going to weird internal special projects & artisinaly-managed OSS. We know most folks switch jobs every couple of years now, including those behind that fancy internal project, and inheriting unnecessary code & ops is such a drain. Why encourage planting timebombs?
A nice thing about vendor-shaped holes in commodity areas is the holes are clear and plenty of vendors happy to quickly fill in. Comparing that to changing some internal project that gets its tendrils into who knows where with who knows what servers & services is night & day. I much rather figure out a Hubspot-to-Wordpress-and-Marketo migration or Zenefits-to-Gusto migration than some weird internal Elixir, Java, & InfluxDB Zeit blog spread over a bunch of AWS services that were primarily developed by two microservices devs who had both left the company to their next great thing over a year ago.
Our clients do outsource custom development primarily due to cost-saving reasons. Being non-tech companies it is very difficult to justify high IT project costs. Competing for qualified talent is no fun as well which leaves them with internal IT whose primary job is to keep existing things running and that's it.
For them, it is a choice of:
A) Outsource development of the 3 projects and actually have the 3 projects completed and bring business value
B) Hire 3 teams of engineers, managers, UX, whatever, and keep them salaried
C) Do not have the 3 projects at all
The budget often allows for initial development only, making option B non-viable.
(The question, though, is why the three badly-performing services aren't replaced.)
