Technology Choice: Sketching A Digital Factory

In the last post I wrote about investigating issues in software projects, or in other words, determining the cause between a specified (or planned) behaviour and an observed (or actual) behaviour when interacting with digital products. I was primarily speaking about how this process of investigation plays out after features have been developed and handed off to quality assurance staff, but can (and does) also happen at other stages in a project lifecycle. In practice, this process of investigation is also a natural part of feature development. Sometimes these investigations result in new technology choices.

The process of creating a digital factory begins much earlier than the development of individual features, with a forecast of requirements. After this forecast, and a sketch of an anticipated division of labour, there is a "chicken and egg" dynamic (i.e. which came first?) with technology choice, where some of the tools that will be used to meet these requirements may have been pre-selected. This happens for various pragmatic reasons, for instance when organisations start new projects they generally leverage their existing capabilities, mirroring the behaviour of individual people.

We've explored in previous posts how the digital world is dynamic, unstable, and effectively invisible. The natural size of the field of truth and the fog of war is already very large, and we are strongly incentivised to minimise both in order to reliably deliver software. So as technologists we generally try to avoid increasing the overall pool of technologies we deal with, to the fullest extent possible. To relate this back to some of the concepts I've previously covered: increasing the pool of technologies can dramatically increase the size of both the field of truth and the fog of war by introducing a flood of new primitives, which have their own versions, handshake agreements, divisions of labour, and so on.

Some examples of technological choices that happen early in a project lifecycle:

• Cloud providers, such as Amazon Web Services, Google Cloud and Microsoft Azure
• Frameworks, such as Flutter, Node.js, Unreal Engine
  • With some technologies the choice of framework may effectively also choose the language of our application code.
• Platforms, such as Facebook, Google Maps, OpenAI, Stripe, Wordpress

Ultimately, there are various objective measurements and a field of conjecture. Available information is weighted in a subjective manner inside a particular social context, which itself can be very influential - for as long as there has been computer technology there have also hype cycles about particular solutions.

The cost of switching solutions can be extremely high for some domains, and that generally boils down to substantially different sets of handshake agreements between alternatives. There are various contributing forces for this that are interconnected. Some are ownership, differentiation, the supply chain, code metrics, norms around interoperability and other concerns like the strategies of large technology companies that form part of the social context.

Once these decisions are settled, technologists are in a much better position to understand the primitives they will be working with in order to solve real-world problems and meet the requirements of a project. Let's ground some of this with a scenario inspired by the real world.

If we know that the requirements for a project is simply to be a repository for information to be shared between many people (e.g. customers for a business), our technology solution could be a Facebook page, a link to a shared Microsoft Word Document, a static website, or a number of other alternatives. If new requirements arise, such as a need to process transactions, we might consider using a digital platform like Shopify or Stripe as a complement to our previous solution for sharing information. Depending on the decision we made for the first step, we may have a disconnected experience for customers who have to access the information repository (potentially a Word document) about our business before making transactions (potentially a Stripe checkout flow) with the business. Beyond an interest in providing a fully integrated solution for customers, we might also find that the technology choices that were made previously don't allow for sufficient differentiation in the market. We haven't necessarily reached the end of our requirements gathering process either, and new requirements may impose additional constraints and push our decision-making in new directions.

From the previous example we can see that emerging requirements forced a re-evaluation of technological solutions, potentially resulting in throwing out what had previously been built. In that scenario relatively high-level primitives (e.g. entire software platforms) were under consideration, but a similar dynamic can play out at a much more granular level when producing software with code, as per navigating extreme memory pressure. Changes to the supply chain, changes to machinery, changes to production processes, perhaps a whole new factory, depending on the context.

Until next time.