1. 34
  1.  

  2. 35

    Something weird in the industry, we hold to the highest standard the Toyota model (what pretends to be called Agile, despite not being at all what the Agile manifesto talks about) — yet we ardently refuse to acknowledge that part of the Toyota model was that they owned their entire supply chain.

    I guess, for many people on websites like this one and the Orange Site: you can easily turn a blind eye if your salary depends on it.

    Every time I talk about owning your data or ensuring that you have the means to fix your most critical issues without depending on a specific third party vendor: I am told the same thing, that “[you are] advocating that we create CPUs from scratch?!”.

    Build vs Buy is important, but for love of god: own what you buy. We as an industry keep renting services in the misunderstood notion that renting is somehow owning, and by outsourcing the running of that service you will need to hire fewer people - but then, you have to reconcile that you never really bought anything.

    With that in mind, though, there absolutely is a place for build vs buy vs rent.

    but people aren’t thinking “rent” when they talk about “buy”-ing a service.

    1. 4

      Toyota have never “owned their entire supply chain”.

      It seems fair to say that they (and all car companies?) are all about integrating the services of other parties.

      1. 3

        The relationships are often much more complicated than conventional SaaS relationships. A lot of exclusive relationships with contracts that allow the procurer to monopolize consumption of given parts or lines of business. These often come with implied buy-outs and joint management decisions. The GM and AC Delco relationship is probably the most interesting and unique relationship, representing the far end of the spectrum from a click-thru SaaS terms of service.

      2. 2

        Every time I talk about owning your data or ensuring that you have the means to fix your most critical issues without depending on a specific third party vendor: I am told the same thing, that “[you are] advocating that we create CPUs from scratch?!”.

        What does it mean? Having the capability of deep-diving into a component you’re using to fix the issues? If so, that’s a great argument for using free and open source software.

        1. 4

          I mean, I highly doubt Toyota owned literally every fundamental piece of their supply chain, just the stuff that wasn’t commoditized. CPUs are absolutely a commodity, so you don’t have to build them yourself, you just need people who understand them.

      3. 21

        The reason we want to buy as much as possible is that an organisation has a limited capacity for expertise, so we don’t want to have to become experts on things that don’t make up a competitive advantage.

        “Limited capacity for expertise” is such a good phrase.

        1. 3

          It depends on scale of the business.

          The competitive advantage here could be some green field area where margins are high, then you can afford to not branch out as the market share is still growing and thus, you can afford to focus on a narrow area to be your competitive edge, your product differentiator.

          But as your business sector age, the margin tightens, and the competitive edge could be shifted down the stack thus. At that point, you need to expand your field to get an edge over a smaller margin.

          For example McDonald vs Burger King, both sells burger at a similar price point. As their margin get smaller and smaller, these guys needed to expand to more than just selling burgers: they invested in the supply chain, automation, and even real estate.

          In a previous job, we spent significant engineering effort on low-level optimizations: custom encoding, custom compression, custom storage, etc… as the business is old and expanded over the years to get better margins. Newer leaderships, who lack this knowledge, ordered a cloud transformation blindly, leading to years of stagnant development as it’s difficult to find these margins using public cloud offerings.

        2. 6

          The benefit of dependencies is inversely proportional to the amount of effort spent on a software project.

          https://eli.thegreenplace.net/2017/benefits-of-dependencies-in-software-projects-as-a-function-of-effort/

          1. 4

            This is about manufacturing, but the same principle probably translates to code:

            If a [function] is high cost, tightly integrated with the rest of the system, and difficult to [write], then we need to become experts on that [function] in order to properly evaluate [libraries] and make a good [import] decision. Alternatively, if a [function] is a major part of the value we’re providing, then we also need to become experts to safely [import] it.

            1. 1

              Agreed that leveraging 3rd party components and tools instead of building your own makes a lot of sense. But the ‘model’ of integration with those 3rd party tools and component is critically important.

              Having tens or hundreds of tools with its own configuration files, its own ‘vocabulary’, ‘principles’ and directions – adds a lot of complexity.

              So Ideally, a 100 years from now – we will have standards-guided 3rd party tools that obey similar characteristics, protocols and integration patterns. Then off-the-shelf component vision of the software development and infrastructure will materialize.