Counterpoint: YKK (look at your zipper) relies on absolutely no one else for its supply chain [0]. This could easily be seen as a waste by those who would say YKK should just source its metal from the foundry down the street. It's easy to do a quick thought experiment in your head to think about how feasible it might be for every company to vertically integrate the way YKK has. On the other hand, YKK can't get jerked around by greedy corporations looking to take advantage of their dependencies.
Fascinating link, I had no idea YKK was like that.
Vertical integration stories like this, or Ford's Rouge plant[1], make me reconsider my general predisposition towards "buy" in the software space.
For many years, I've argued against building software you can easily buy or download, but maybe reinventing the wheel is not so terrible if someone wants a company to be long-lived. Primary benefit is the software can be customized for the company's specific needs and not held back by other companies' software, of course. But even if using open source, it can help avoid fad software trends, or the whiplash-speed changing of standard tools/libraries (e.g. the open-source client-side Javascript world).
Software is a bit different, because your copy won't just stop functioning if the supplier disappears. And if the source is available, then what you're really getting is a "factory", not its output. It can still be a problem if you have no expertise on how to operate said "factory" - but it's a very different problem.
> Vertical integration stories like this, or Ford's Rouge plant[1], make me reconsider my general predisposition towards "buy" in the software space.
Schwinn was another great example of this back in it's heyday. The Chicago factory could essentially produce every part of a bicycle from 1010 steel.
The issue with this model for a lot of companies is that a high level of vertical integration can make it very difficult to pivot. In the case of Schwinn, the change in consumer taste towards lighter bicycles/frames was not something they could adjust to in a cost effective manner; the lighter alloys other companies were beginning to use at the time were not usable in their production process. There were many other factors in their downturn but that was a big one.
> For many years, I've argued against building software you can easily buy or download, but maybe reinventing the wheel is not so terrible if someone wants a company to be long-lived. Primary benefit is the software can be customized for the company's specific needs and not held back by other companies' software, of course. But even if using open source, it can help avoid fad software trends, or the whiplash-speed changing of standard tools/libraries (e.g. the open-source client-side Javascript world).
There's two sides to the 'buy/build' camp that seem oft ignored; The first is that 'build' is a huge cost unknown (i.e. risk) to the business. Maybe you'll build the right solution. Or, maybe it becomes a terrifying project that was put together so haphazardly that they wind up taking the developer's machine and put it in the server room, because they've run out of time and the code doesn't work anywhere else.
But the second... is that a lot of the off-the-shelf software has a specific use case. And the more off-the-beaten-path your business is, the higher the likelihood that you'll have to write customizations to actually meet the requirements. Those have their own set of risks, and I've seen projects where teams have wound up tossing the 'tool purchased by the business' and writing their own thing because it wound up being cheaper to do that than integrate with the muddled mess the company signed a fools bargain contract for (incomplete, poorly documented AGPL clone of a very popular Apache licensed product.)
It's like everything else though; companies want to 'externalize' the cost/risk. And sometimes that works. Sometimes, you have a good contract, with the right carrot+stick SLAs with a vendor, and having that peace of mind that they -will- respond within 24 hours and not use up your own internal developers troubleshooting the in house leetcode.
One of my favorite examples of this paradigm in practice is Job scheduling and/or queueing. Every company I've worked at has had their own 'opinionated' way of doing job. At one, where the requirements were very well defined, the in house library was hilariously bare code and ran on windows scheduled tasks, directories-as-output and at-first-glance terrifying oracle sprocs. But... when you looked at the actual requirements? it did exactly what it had to and no more. The output had to go to FTP, so who cared if it used directories for output as the default? And quite frankly it worked and was simple enough any developer worth their salt could maintain the structure/paradigm.
At another org, that loved to buy/use things off the shelf, I lost many a Sunday to bizarre problems where the combination of Quartz.NET wrappers, MassTransit wrappers, RabbitMQ wrappers.... secondary database queue tables.... just didn't play nice together and would deadlock on the server.
Never heard of them. Their company setup is pretty impressive. However to say 'relies on absolutely no one else for its supply chain' is an extreme exaggeration and frankly impossible.
They don't make the computers, fiber optics, switches, exchanges, or software that their web site requires to run. They don't own the fleet of trucks, boats, and planes required to get their product to their customers - or their raw materials from plant to plant. They likely use rubber mats in their plants but I don't think they have a rubber plant. Unless they use outhouses I'm pretty sure they don't make toilets and sinks and plumbing. I don't know if they produce their own electricity but I'm sure they didn't build a generating plant from scratch....and on and on it can go.
If you haven't read it, search for the essay - I, Pencil - I'm sure YKK uses pencils as well.
The point is noone is even remotely close to being their own supply chain every one is deeply dependent.
We had an argument in a CS class once about what the most "pervasive technology" in the room was. We were examining claims that "computing would become so pervasive and ubiquitous that it would become invisible" like electricity and that zipper.
The reason it won was because we could count more of them than any other piece of tech in the room. Every person had more than they thought -- often as many as half a dozen between their pants and schoolbag.
The thing about zippers is, YKK is hands down the best and most reliable zipper. Yes I know there are types of zippers, metal coil, molded plastic etc- YKK makes the best of each.
Plenty of companies try to source their own (Levi's is the first to come to mind), but the best companies all use YKK zippers because they know. If it doesn't say YKK on it, it's not a YKK zipper.
The companies also use it because their customers know. Not only YKK succeeded in making itself the most trusted brand, but they also succeeded in informing the end users of complete products that there is an important practical difference they must to pay attention to.
and it may only be the beginning.. application class SoC can fit in a microusb plug.. I think some people hacked some arduino like chip in the wire itself (granted it was not as thin as a normal cable)
> They don't make the computers, fiber optics, switches, exchanges, or software that their web site requires to run. They don't own the fleet of trucks, boats, and planes required to get their product to their customers - or their raw materials from plant to plant.
You aren't describing a supply-chain. They don't lose a computer for each item sold. The difference is that they can have a disruption in their infrastructure suppliers but continue to sell products at a degraded pace. If they lose all access to a raw material (supply chain), they can't sell any more product once they are out of supplies.
> They don't make the computers, fiber optics, switches, exchanges, or software that their web site requires to run.
Because they don't need to. The quality of their network setup has no, utterly no, relationship to the quality of the final product - the machines and materials however do have such a relationship and therefore it's done in-house.
Additionally this vertical integration removes the incentive for a supplier to cut corners somewhere for more profit - which is something that Tesla and SpaceX also have discovered and apply it wherever they can.
Vertical integration can certainly be a great approach and can have many advantages. It can also limit your risk of exposure to outside events.
However, my point is and was that controlling your whole supply chain is impossible.
Computers are critical to everyone's supply chain, including YKKs. If they aren't and YKK can fall back to pen, pencil, and paper then they are dependent on those manufacturers and industries.
Again every business and every one is DEEPLY dependent on hundreds if not thousands of others.
The difference is that they can ride out a supply chain interuption for months for non consumables that aren't a direct part of the manufacturing process.
Giving them time to find alternative suppliers for things like computers and pencils.
If they instead depended on consumables like say zipper teeth, they would have to shut down almost immediately in the case of a supply chain interuption.
Interesting. YKK is the highest-quality large manufacturer of zippers in the world. There is a correlation between the quality of a garment or zippered good and the presence of a YKK zipper.
That’s an interesting insight. Companies as they grew and supporting companies who could specialize and take advantage of economies of scale would provide attractive alternatives to vertical integration. Most of the auto industry is like that. Not sure how feasible integration would be in a modern economy these days.
The claim about relying on absolutely nobody else sounds like an exaggeration though. Even if we limit the scope to consumables, I don't think they produce their machines' lubricants.
[0] https://ykknorthamerica.com/the-ykk-difference/vertical-inte...