Platforms and tool stacks ​

If we consider the multi-level product/constructive/module breakdown (PBS, product breakdown structure, as opposed to the functional breakdown SBS, system breakdown structure), we can see sets of small constructive "bricks" at each level, representing through their interfaces services for assembling higher-level "bricks". Such a coordinated set of modules with their predetermined interfaces is called a platform.

A platform is always a product/constructive/module consideration of a system with an emphasis on the standard way of obtaining the required service from a module through a published interface. The discussion of a platform is always related to its services, i.e. external behavior provided on the interface to higher-level products/modules in the product/constructive/module breakdown. For software modules, this interface is usually called an API (application program interface), an application program interface. An application is a higher level than a platform.

If we are not talking about a software system, we can simply talk about an application interface (application interface, not application program interface). An application interface is a defined module interface to modules of the suprasystem.

If the platform is implemented by software libraries or "hardware" modules, then it literally becomes part of the application during its operation and becomes its subsystem. But if we are talking about a provider platform whose service changes something in the offered part of the working target system, then only interface modules (often called adapters/converters/connectors) are included in the application or "hardware" system, while the platform itself is considered to be in the external environment (run-time, operation time for the platform).

In the already mentioned social dances (tango, kizomba, forro, salsa, etc.), there are also interfaces, which are usually standardized at the "base" level: there are conditional signals that are sent from the leader to the follower (this is a non-gender terminology for "partner," a concept now adopted worldwide). For example, if the follower's hand is on your (leader's) shoulder, and you try to turn the follower without moving this hand, the hand will get in the way. You give a little push to the hand (this is the "leading signal") — and the follower's hand rises vertically upwards. Now turns are possible, and this hand will not interfere. This is one of the interfaces in social dances (there are others as well): between the shoulder and the hand, as well as a description of the standard, what interactions are possible in this area, what signals are transmitted, and what happens in response to these signals.

In thinking, this is not much different from accessing a program service (remember that "service" is often also called provider behavior and the provider of the service itself, a "service", a "server"), or requesting a service from some equipment. In this sense, the follower, following the "base" standard with its signals, represents the platform of this "base". And an important feature of social dances: standardization of the interface, "platformness" leads to the fact that the leader and the follower, coming to a certain festival party from different countries and dancing together for the first time, can interact predictably and reliably with each other. This interaction in systems thinking is described in more or less the same set of concepts as the interaction of a smartphone and its cellular station, a tram with its tracks, a web browser with a web server. When you think about the interaction of two products/modules, think about the interface.

The main question in discussing platforms is the so-called visibility of interfaces. Interfaces of a lower system level should not be visible outside the module, i.e., modules can only be connected through interfaces provided inside the module. Roughly speaking, if you have a box with a certain connector, you cannot plug an external device into this connector somewhere inside the box, bypassing this connector, even if you really want to. In systems, everything is connected to everything else, and a parasitic connection may pass through an unnoticed connection (which will also be an interface, just an "unaccounted" one), unforeseen errors may occur.

For example, if in your department, where you plan the work of employees carefully, receiving orders for these tasks through some tracker (this tracker is only an interface module, providing the interface for ordering work, it doesn't matter that it is a fairly large software system, at the system level under consideration, it is simply an interface module for ordering work, a means of communication of the department with the outside world), people from other departments may come and ask for work to be done for them "out of turn" — and they will not be refused, the consequences for the organization will be fatal: some unexpected work will be done, some seemingly free employees will be busy, some important (but importance is determined by the suprasystem! Inside the customer module, both the customer and the executor may not know the importance) work will not be done due to delays associated with this suddenly appeared "out of nowhere" work (bypassing the planned interface supported by the tracker).

In electrical engineering, there are three types of faults: a contact where it should not be, no contact where it should be, and a bad contact. This joke is about interfaces — which should be where they are provided by the design!

A module breakdown/productive/constructive/platform stack diagram is used to discuss the visibility of interfaces. Each platform level is separated from another level by a standardized (i.e., described and documented!) interface. Implementations of lower levels can thus be changed in such a way that the suprasystems will not notice if the modules adhere to interface agreements. The resulting multi-level module/productive breakdown is called a platform stack or an instrumental stack (stack looks like a stack of trays in a dining room or a stack of sheets of paper in a pack). Here is an example of various instrumental stacks for inter-computer communication in the Internet of Things (IoT): . [SlideShare link]

The diagram shows that in different compared communication standards, five platform levels (part-whole relationship) of modules/constructive parts are described/defined, which can be divided into those that implement the transmission of a physical signal (physical), data transmission (Data Link), etc. Meanwhile, data transmission modules interact with physical signal transmission modules using the protocols specified in the diagram. And so on at levels above, down to the application level: each level of the instrumental stack (the level implementing this stack of modules) provides a service interface up and uses the services of lower-level modules.

It doesn't matter what these levels of the platform stack do/how they work. For "how they work," you need to discuss operation in run-time, while the discussion of platforms is design-time, "what is it made of and how it is connected," the time of creating the system. The main thing in representing this instrumental stack is that no module/product of a higher level "sees" the modules of a lower level, does not have access to them, cannot "plug in" there, only those that are directly below it, and the interfaces implementing the services of the platform levels are standardized—just like the set of these levels themselves. In dances, you pass the signal from shoulder to shoulder, not from muscle to muscle, or even from shoulder muscle through the skin, and then through receptors and nerves further to the follower's arm muscles. Muscles are constructive objects of a lower level, and if nothing is broken at the "shoulder" and "arm," and there is no need to fix it at a lower level, it is necessary to use the prescribed interfaces.

There are two ways to represent such diagrams of module/platform/instrumental stacks:

• In some diagrams, the platform "panel" is named after the standard describing its application interface. An application is at the top of system levels, applicability goes from top to bottom in the stack. The implementation of this interface module is located "between levels" (exactly this way is shown on the diagram of IoT instrumental stacks, which is the most common)
• The modules themselves (naming platforms) are shown on the panels, and the interface of these modules is either considered named by the module itself (for example, a software module/package of deep learning TensorFlow has a TensorFlow API, and therefore it does not need to be separately described, the module name is sufficient), or it is specified separately.

But if a platform level implements a standard with a different name, then it is specified somewhere within the boundaries of the module implementing it with an individual line closer to the upper module's boundary, or even extracted and explicitly prescribed "between platforms", as done in the application security stack diagram. Standards are specified on the side of the platform diagram, and each panel represents a layer of modules:

The top bracket for the interface standard into the suprasystem from custom code somewhat "disappears" in this way of representation. Therefore, the method from the previous picture, where the platform is indicated by the names of its modules/layers, and the appellation is shown on the side, is more commonly used.

Both of these methods are often mixed, creating a hybrid module-level diagram. For example, the modular diagram of an artificial neural network compiler, where the top rows are the names of software modules/packages of neural network implementations (MXNet, PyTorch, etc.), and the lower rows are interface standards for some hardware (OpenCL, CUDA, etc.):

It does not matter if you do not understand the subject area described by these architectures (sets of solutions for dividing the system into modules and organizing connections between modules). It is important that you can assess the similarity of these diagrams to each other (at least visually), understand the thinking principle behind them — and then it is better to deal with the types of diagrams that a particular project role suggests you to look at or the diagrams you draw yourself.

Platformness allows for the efficient division of labor: each platform level implementation can be handled by a separate team that is well-versed in working at their system level (systemic approach!), and since we are talking about functional parts playing roles, such teams can compete for the efficiency of implementing the required functions with their module services for each system level.

Engineers who use certain platforms to create their target systems may not think about how these platforms work — as long as these platforms provide the service through the described interface. This significantly simplifies the task of creating complex systems, accelerates it, and makes it cheaper. You need to understand the options of modules and the services on their interfaces but you do not necessarily need to understand how they work internally, and how exactly they work internally. And if this application interface is standardized, and there is competition among module/product/component suppliers, they can select a suitable implementation variant based on price and characteristics. And this happens on many levels up and many levels down the instrumental stack, systemic thinking is recursive.

Money usually comes from successful and mass use of the top, most application level (of course, for each level of the instrumental stack, the higher level is "application", systemic thinking is applied recursively — that is, it is the same for each system level, the same for each system in it). Look at the examples of the explicit use of platform reasoning in NVIDIA's strategy — when describing the structure of the intelligence stack, the robotaxi stack, the computational infrastructure stack, and pay attention to the type of diagrams used there.

"Shake-up" of the entire instrumental/platform stack, rebuilding of all markets usually occurs when the physical implementation principle of the lowest level of modules changes, when the implementation of the platform at the lowest level changes.

For example, when mechanical or pneumatic elements were replaced with vacuum electronic tubes in computers, the computers became scalable, and they started to resemble functionally modern computers rather than calculators of the past. Replacing tubes with discrete semiconductor technology enabled mass production of computers and dramatically changed computer technology. Substituting discrete electronics with large-scale integrated circuits again turned the entire computer market upside down, with all the software overlays. Replacing a CPU with a GPU overturned the AI market. Replacing human performers with robot performers revolutionizes the entire production. This feature makes instrumental/platform/module/product/hardware/software stacks convenient for discussing a company's strategy. When strategizing, the discussion revolves around which of the modules at these platform levels the company will produce itself and which it will procure externally, what interface standards it will set for these modules, and which it will take from ready-made standards. A good example of such strategizing at the system levels of the AI stack is provided by NVIDIA.