Is Documentation a System? Is a Work Artifact a System?
Students often ask the following question: “Documentation exists in the physical world, so is it a system? After all, menus, books, and passports all have to be produced.” This is a good question, and those who ask it are digging deeper.
Strangely enough, the answer to this question is connected to attention. Systems thinking relies on techniques for managing attention. People studying systems thinking often jump quickly from one project to another and lose sight of the fact that they start talking about one context and end up in a third. That’s why it’s recommended to use your own not-too-complex activity as a foundation—something that won’t let you lose touch with reality in your reasoning.
If we are discussing the “person” system, then the concepts of “implementation, description, and documentation of the system” are tied to it. In this context, a passport, driver’s license, and everything else in this project will be considered system documentation for the “person-citizen” system. But if you now want to discuss the passport as a system, that’s a different perspective and a different project. For example, a project focused on producing the information carrier “passport.” Notice how our focus of attention has shifted.
Not everyone immediately understands how the context changes during a conversation. In the project of creating a passport, its content—that is, the description of the “person-citizen” system—is not as important. The information in the passport will be discussed in the first project; that’s where the description of the “person-citizen” system is addressed. Accordingly, how to describe the citizen is decided in the first project.
In the second project, the main focus is the carrier itself, not the information it contains. In the previous section, we already pointed out: “But when talking about information carriers, we haven’t said anything about the content of the description itself.” The content of the passport is determined in the project about the person as a citizen, while the characteristics of the “passport” system are primarily related to its protection against forgery or the number of pages.
Here’s another example. The system engineer John Doe is responsible for describing the automobile system. But ensuring that this content appears on an information carrier is the responsibility of the secretary, Dasha. Dasha carefully writes down John’s words and then prints them on A4 paper, or John himself shows the automobile description to colleagues on a computer. Notice that the secretary is not at all concerned with the content—that is, the description of the “automobile” system.
Dasha (or John, but now in the role of presenter) is interested in the information carrier. There are other projects where, for example, Dasha will also play the role of engineer, creating the system—the information carrier. This could be an A4 sheet or several bound pages containing the system description. Instead of an A4 sheet or a presentation, it could be a passport, a book, a website, a digital twin (an IT system), and so on. All these carriers need to be produced, and specific engineering roles will be involved in this work. For example, a book is published by a printer and other roles in the publishing field.
That’s why one of the thinking techniques is consciously shifting your attention between different projects[1]. There is content, and there is the information carrier that holds this content. These concepts should not be confused. In one project, we discuss the automobile as the implementation of the system, its descriptions in the form of various characteristics (subjects of interest), and documentation—on paper, in presentations, on computers, and so on. In another project, different people (or the same people in different roles) discuss how to design a beautiful brochure, website, or digital model. Of course, there is a connection between the projects, and a systems-oriented person understands it well thanks to established systems thinking techniques. This means that, when necessary, they can manage their attention.
Therefore, you also need to recognize the implementation, description, and documentation of the system in any of your projects. But there may always be another project or activity in which system documentation is created from the perspective of its implementation in the physical world. The content or description of the system that will appear on this carrier is determined in your project. Don’t get confused between different projects.
So, what is a “work artifact”? A work artifact always exists in the physical world (4D). A system is also a work artifact created by a team. But not every work artifact is a system. In addition to being a system, a work artifact can also be system documentation. For example, an automobile is a work artifact of an automotive corporation, but in the design bureau of the automotive corporation, the team creates a work artifact—a 3D model of the automobile. This three-dimensional model is system documentation for the automobile system. In the automobile creation project, the 3D model (in the computer) is not considered on its own, but as system documentation for the automobile. This documentation, as a carrier, contains important descriptions of the automobile system.
Let’s finish by connecting another trio of concepts in the following sentence: “A work artifact in the form of system documentation is created using some method of description.” Try to reflect on this sentence and discuss it in a group or write a draft in the AISYSTANT club, providing examples from your work project.
We’ll discuss concepts like system levels and creation chains in Section 5. These concepts will help you work with multiple projects. ↩︎