Skip to content
Create an account for full access.

Chains of creation

It is always necessary to understand which system (target, in the environment, or creating) you are talking about at any given moment—because it is about your conscious attention to various objects, at different times, yet. For example, when you just mention an "axe," it is unclear—are you making the axe (axe - target system), are you using the axe to split wood (target system - wood, axe is one of the creators/one of the creating systems, necessary for preparing the target system-wood for operation—burning in the stove), or the axe for you is one of the systems in the environment of the target deck, with which the axe must chop wood and whose properties you are investigating in order to design and make the right deck.

From the very beginning of discussing life cycles in engineering, there was an understanding that they are connected through the stage of operation/use in long creation chains, as the creator's operation stage—this is when the creator participates in the project life cycle works. In the chain, this may spread to several levels.

There is a simple way to show creation chains for a one-time life cycle: the life cycle itself is depicted on them by arrows with notches that separate the stages of the life cycle, and segments of operation of each system, providing a service for creating another system as project work/organizational unit/creation system, are shown as a bracket arrow on the timeline of the life cycle stage of the next system in the creation chain:

On such diagrams (it takes a few seconds to draw!) it is convenient to tell stories about creation chains like "we organize a startup that will create CAD software, with which we will then design an axe, with which we will then chop wood, with which we will then prepare dinner"—and for each system in the creation chain in such a diagram, it is clear that it goes through a fairly long period of its own production before being used/operated. The disadvantage of such a picture—it is actually about physical time, albeit drawn in a very abstract way (one of the early understandings of the life cycle as a “waterfall” of stages:: works, not practices), but the main thing—systems are not just put into operation once, they continue to evolve during operation, meaning that after being put into operation, strategizing new opportunities/features continues, their design, production, engineering justification of the system's success with these features, integration into already functioning systems.

Let's remember the alphas that were introduced in the systems thinking course. Let's switch to the language of practices, not jobs: alphas are objects of tracking in the project because as systems are created, alphas change their states since work on some practices is carried out for changing the states of alphas.

Let's imagine some areas of interest by the names of typical systems that any enterprise/firm deals with:

  • Target system: the system that the company makes
  • Supra system for the target system (clients have needs related to the supra system)
  • Creator of the target system (a team of engineers involved in applied engineering, for example, software engineering, if the target system is software)
  • Creator of the company teams (who will create a team of engineers and a creator team of agents, meaning the team of firm managers responsible for its development)
  • Creator of the creator teams of the company, which will create a venture—group of investors who provide the necessary capital for the company's development (the team of company founders who negotiate with investors, formalize investment deals, and organize/create and develop the team of managers)
  • Creator of the agents, who will create a group of agents (sales team)
  • Creator of the client group (agents, i.e., a group of agents who will recruit clients)
  • Client group (a group of clients who have needs in the system, they create their supra systems and are interested in the target system)

Each area of interest will have several alphas that we will track later: system, its description, its works. For now, we are interested in the works of creation to discuss creation chains that form a graph. We will not show works, practices, alpha states, or system descriptions. But we will show that the company creates an agent network (agents), which brings clients (client group) who have supra systems in which our system will be used. We remember the firm's founders, but we will not document the creators of the venture (investors whom the company founders create from owners of free capital). Task: to model all these attention objects so as not to forget anything. The list from the previous paragraph is just such a model, and it will be sufficient to conduct quite a few discussions of the enterprise, each time clearly understanding which alpha from the area of interest you are discussing for which system.

When we consider systems in pairs: creator::system "creates and develops"::work "its system"::system, if "its system"::creator, this chain can be continued. Moreover, one creator can create several systems, and at that moment the chains turn into graphs.

Exclusively for illustrative purposes, let's provide a diagram of the creation graph as a set of creation chains (in real life, you will create and fill in lists and/or tables, not diagrams, as you will get tired of making constant changes to the diagram, but we will tell you about tables a little later)[1]:

All creation chains in the creation graph somehow lead to the target system, but if desired, it can be shown that the target system also creates something, it can very well not be the last in the chain (it could easily be a lathe that a client buys from you). The colors of the areas of interest are taken from the OMG Essence standard: alphas related to the target system are shown on a yellow background, for the supra system—on a green background (the client as an external project role has a need for the characteristics of the supra system that the target system, as part of the supra system, can provide, so the client also falls under the green background), and the creator teams in their chains are shown on a blue background. By and large, thinking about all these systems shown in their chains is the same, so the color in the discussions is not so important. However, it can be taken into account. So, yellow is the beginning of all beginnings, the target system, and therefore all discussions should somehow lead to its creation and improvement, green—these are the systems and teams (external project roles) outside the company, and blue—this is the company itself, internal project roles. These are alphas, so discussions about orgroles, and orgunits here will be viewed as work products from the perspective of OMG Essence, which we will use to determine the state of alphas. And keep in mind that the ontology in OMG Essence is a bit crooked (this was warned at the systems thinking course), so fans of rigor and formalism have a tough time, but we will not invent anything of our own here, we will use the language/discipline of this standard—OMG Essence is specifically designed to describe development methods/processes/practices, and we will use its concepts for these purposes, except we do not recommend using the notation offered by this standard (both textual and diagrammatic) and the set of areas of interest and alphas proposed in it. Do not copy this diagram, do not even draw your own, adapted one. You will need to describe your versions of creation chains for your project and also describe the states of alphas from these creation chains in tables in some universal modeler. How to do this will be explained later.

We (who are we? A team, a collective team, an enterprise? Owners, managers, investors?) are establishing a software company that will develop data modeling software during bridge construction, a design institute will consider this software when planning construction, and the construction will operate this software when building the bridge. And the target system? Bridge (as a provider of "transport flow," this chain of creation can continue!). And you will need to carefully work out this entire creation chain (it's not even fully specified here yet! Creators in very different chains, and not so much in chains as in creation graphs, there are many more). If you fail to model and document such creation chains, bringing them to the target system every time, you will find yourself in a tangle of endless discussions about what exactly you are doing within a somewhat indistinct “hanging” crowd of various people from various departments of various companies with all important and unimportant details of description. It will be unclear what from all the discussed matters needs to be addressed, and whether it is necessary to address it at all. If you model and document the creation chain, you will quickly explain why and how your project is needed (usually it is somewhere in the middle of one of the creation chains in the creation graph), how it will lead to the success of the target system (or you will understand that the project does not affect the success of the target system, and therefore no one else needs it, and close this unpromising project).

The further along the creation chain you are from the target system, the more attention you need to pay to it: your thinking will require efforts to keep it in focus. Systems thinking requires focus, you need to find the target system, and then design and justify the entire creation chain up to “your” system, not skipping any systems in this chain and keeping in mind the benefit of the entire project for the target system. Without focus, you will lose sight of the target system. The advice here is a common one for enhancing focus: document the description/model of the creation chain! This will help keep the focus on the target system.


  1. High-resolution image --- https://ic.pics.livejournal.com/ailev/696279/215914/215914_original.png ↩︎