The post makes a very weak case for why “vertical integration” matters (much less a case for why it is the only thing that matters.)
It offers an example of a precomposed automation that is meant to illustrate how advantageous a “vertically integrated” working environment might be, but, personally, I don't think the proposed automation is all that exciting. Since it's just a representative example, it's not worth litigating the details of the example, but I'll just say that the automation posits a very rigid view of a work-flow (“work-flow”—in the very literal sense of the structure of how one goes about doing their work.) I dare suggest that work-flows are discovered rather than dictated.
We can see this in some of the details of the example, like the multimedia nature of the automation (e.g., some notifications happening through direct response, other through delayed, indirect platform interactions, like a chat system or ticket tracker.)
Well, this presupposes that, like, some data scientist who makes a one-line config in some tiny system as a favour to their colleagues want to be spammed by Slack messages about JIRA tickets about failing tests (“don't worry, those tests always fail; we're waiting to replace that system next half anyway.”) There are, presumably, multiple distinct modalities with which various employees will interact with a given system. Not every employee will interact with a system with the same level of importance. There is likely not a singular work-flow that fits all of these users, and I have witnessed many examples where this rigidity becomes a huge drag on actual users' work. (This is exacerbated when components of the automation require internal-only tooling—the poor data scientist now needs to go read through a bunch of half-written, out-of-date documentation about tools they simply don't care about to do a task that is not a core responsibility for them.)
In fact, every time I have started a new project in an environment with “vertically integrated” precomposed automations like this, I have invested some number of weekends of my personal time to figure out how to disaggregate the automation so that I can recompose them into a better work-flow. As a consequence, I end up working much more effectively than my peers. In one such situation, the “vertically integrated” system was designed for a very specific kind of software development and so wholly inapplicable to the analytical development work we were doing that by disaggregating the automation, I ended up moving 5×times faster than peers at the same skill level. (In other words, by the end of day on Monday, I accomplished as much as they would the entire week!)
It's actually incredibly shocking how bad this kind of vertical integration plays out in practice (at least in the large corporate environments I've seen…)
Furthermore, the post fails to acknowledge how poorly these kinds of precomposed automations behave when something goes wrong. In general, I have come to believe that the mark of a good automation is the degree to which it can be decomposed and recomposed. (This is not wholly a consequence of the design of the automation, but is also a result of the culture and habits around how the automation is used.)
Again, while it's not particularly interesting to litigate the representative example, the suggested automation is very “deep,” and I do not believe that is wholly a coïncidence. How does this “vertical integration” behave if just one component of it breaks? Since the automation is reliant on external platforms, it is likely that the integration will break (or require frequent revisiting) as those platforms change. I think it is wholly unreasonable to suggest that we should internalise every component in the automation. This is simply neither feasible nor economical (and really may not even push the boundary out that far—after all, a business system must inevitably come into contact with the outside world.)
So these automations tend to work only with very tight loops that are distant from the boundaries of the organisation, where the components of the automation will never break, and where the automation enscribes some task with no loss of operational fidelity. Otherwise, you end up having to decompose or recompose the automation anyway, in which case wouldn't you have been better off with a collection of loosely connected, independent components?
There's a weird amount of hate on open source in this post. Ironically, it's precisely closed ecosystems that try to be "vertically integrated", like slack or github, that make these vertical integrations gruesomely complicated and brittle.
Malleable systems like emacs, plan9, unix or smalltalk are precisely what allow for these vertical integrations, and they make it so simple that you wouldn't need to buy a product. But, they're not really leveraged today.
One reason we don't is partly because we have to work with other developers and colleagues that are used to tools that don't compose. For example, the author seems to think that CI "isn't used to cooperating", maybe because they're used to CIs like github actions.
Another reason we don't is because vertical integrations just tend to be very brittle, as noted in the other comment. :)
The post makes a very weak case for why “vertical integration” matters (much less a case for why it is the only thing that matters.)
It offers an example of a precomposed automation that is meant to illustrate how advantageous a “vertically integrated” working environment might be, but, personally, I don't think the proposed automation is all that exciting. Since it's just a representative example, it's not worth litigating the details of the example, but I'll just say that the automation posits a very rigid view of a work-flow (“work-flow”—in the very literal sense of the structure of how one goes about doing their work.) I dare suggest that work-flows are discovered rather than dictated.
We can see this in some of the details of the example, like the multimedia nature of the automation (e.g., some notifications happening through direct response, other through delayed, indirect platform interactions, like a chat system or ticket tracker.)
Well, this presupposes that, like, some data scientist who makes a one-line config in some tiny system as a favour to their colleagues want to be spammed by Slack messages about JIRA tickets about failing tests (“don't worry, those tests always fail; we're waiting to replace that system next half anyway.”) There are, presumably, multiple distinct modalities with which various employees will interact with a given system. Not every employee will interact with a system with the same level of importance. There is likely not a singular work-flow that fits all of these users, and I have witnessed many examples where this rigidity becomes a huge drag on actual users' work. (This is exacerbated when components of the automation require internal-only tooling—the poor data scientist now needs to go read through a bunch of half-written, out-of-date documentation about tools they simply don't care about to do a task that is not a core responsibility for them.)
In fact, every time I have started a new project in an environment with “vertically integrated” precomposed automations like this, I have invested some number of weekends of my personal time to figure out how to disaggregate the automation so that I can recompose them into a better work-flow. As a consequence, I end up working much more effectively than my peers. In one such situation, the “vertically integrated” system was designed for a very specific kind of software development and so wholly inapplicable to the analytical development work we were doing that by disaggregating the automation, I ended up moving 5×times faster than peers at the same skill level. (In other words, by the end of day on Monday, I accomplished as much as they would the entire week!)
It's actually incredibly shocking how bad this kind of vertical integration plays out in practice (at least in the large corporate environments I've seen…)
Furthermore, the post fails to acknowledge how poorly these kinds of precomposed automations behave when something goes wrong. In general, I have come to believe that the mark of a good automation is the degree to which it can be decomposed and recomposed. (This is not wholly a consequence of the design of the automation, but is also a result of the culture and habits around how the automation is used.)
Again, while it's not particularly interesting to litigate the representative example, the suggested automation is very “deep,” and I do not believe that is wholly a coïncidence. How does this “vertical integration” behave if just one component of it breaks? Since the automation is reliant on external platforms, it is likely that the integration will break (or require frequent revisiting) as those platforms change. I think it is wholly unreasonable to suggest that we should internalise every component in the automation. This is simply neither feasible nor economical (and really may not even push the boundary out that far—after all, a business system must inevitably come into contact with the outside world.)
So these automations tend to work only with very tight loops that are distant from the boundaries of the organisation, where the components of the automation will never break, and where the automation enscribes some task with no loss of operational fidelity. Otherwise, you end up having to decompose or recompose the automation anyway, in which case wouldn't you have been better off with a collection of loosely connected, independent components?
There's a weird amount of hate on open source in this post. Ironically, it's precisely closed ecosystems that try to be "vertically integrated", like slack or github, that make these vertical integrations gruesomely complicated and brittle.
Malleable systems like emacs, plan9, unix or smalltalk are precisely what allow for these vertical integrations, and they make it so simple that you wouldn't need to buy a product. But, they're not really leveraged today.
One reason we don't is partly because we have to work with other developers and colleagues that are used to tools that don't compose. For example, the author seems to think that CI "isn't used to cooperating", maybe because they're used to CIs like github actions.
Another reason we don't is because vertical integrations just tend to be very brittle, as noted in the other comment. :)