What is a system? – Understanding the fundamentals of "systems thinking" through abstraction and MECE (Mutually Exclusive, Collectively Exhaustive)

Last time, in an article titled "Explanation of the Scope and Implementation Conditions of Systems Engineering: SE is a Methodology, Not an Answer," I explained the preface and introduction of the NASA SE Handbook.

To review the key points of the preface and introduction, there are three main points:

This article outlines important prerequisites for utilizing systems engineering, so please take a look if you're interested.

This time, before explaining the main chapter of the NASA SE Handbook, we will explain in detail "What is a system?".

The word "system" is frequently used in our daily lives, but I think it's a word that's surprisingly not understood in a unified way. Especially in the Japanese media, it seems to be used almost exclusively in the context of IT.

In this article, we will thoroughly explain this system, which is described using such vague terminology.

Once you grasp the meaning and concept of this word "system," it will not only form the foundation of what you will learn as a systems engineer, but it will also be a very useful concept in your daily life, so please look forward to it.

In the first installment of this series, "An Introduction to Systems Engineering," I briefly explained the basic concepts of systems. Some of the content will overlap here, but I will proceed carefully to ensure that you understand it thoroughly.

Now, let's begin by explaining "systems," which are the core of SE work.

What is a system?

Let's start with the dictionary definition.

I'll borrow some terminology from INCOSE, an academic organization within the field of systems engineering.
(INCOSE is an abbreviation for the International Council on Systems Engineering.)

It's so abstract that it leaves me with a vague feeling of not quite understanding it, but also not really.

Next, I'll borrow some words from the NASA Systems Engineering Handbook, which forms the basis of this series.

This, like INCOSE, sounds like a story about aerial combat that's both understandable and incomprehensible at the same time.

From these two definitions, we can understand the following three points regarding the term "system":

It seems safe to assume that a system is defined as something that incorporates these three points.

Let's look at the system definition in JCOSE, keeping these points in mind.
*JCOSE is the Japanese branch of INCOSE.

The definition used by JCOSE has become considerably more specific.

To summarize what has been discussed so far in my own words, it would be as follows:

To facilitate understanding, let's illustrate the system based on the definitions.

So, what do you think? Did this help you understand the system a little better?

As you can see from what we've covered so far, the original meaning of the word "system" is not an IT-specific term often used by the Japanese media, but rather a more general term (this is a very important mindset to keep in mind).

It seems that anything with at least multiple elements can be considered a system.

If we only focus on definitions, the discussion will remain abstract. So, next, let's consider concrete examples as systems to help implant the concepts in our minds.

Consider tangible, concrete examples as systems.

Let's consider a concrete example that is familiar to me and falls within my area of ​​expertise: automobiles.

I believe the fundamental purpose of an automobile is as follows:

While there are undoubtedly other purposes such as safety (collision performance and prevention through IT devices), comfort (air conditioning, lighting, etc.), and convenience (driving assistance such as car navigation), here we will consider the fundamental principles in order to understand the system.

We will use diagrams to facilitate understanding.

Let's actually consider the components of a car. Thinking about specific parts like the engine and suspension right away might be confusing, so let's start with a broad overview.

*The diagram is simplified for clarity.

Each of the three systems cannot function as a car on its own. The elements interact with each other to form a car. Even in a physical car, the elements do not exist independently; they are physically connected in various ways through their interactions.

This now matches the diagram illustrating the system concept.

Next, let's compare it with the system definition.

In other words, an automobile can be thought of as a system.

So, what do you think? Have you started to get a sense or feeling of thinking about automobiles as a system?

Let's further explore my area of ​​expertise: powertrains.

*The actual system is much more complex, with intricate interactions and other elements such as the electrical system.

By viewing it as a system, I think it became easier to understand the role that each element, such as the engine, plays in the overall system of the automobile.

Don't you think that by further breaking down the elements of an automobile system, specifically the powertrain, it's become a little easier to understand cars?

This is one of the major advantages of viewing things as a system: by breaking down complex things into understandable elements and then integrating those elements, it becomes easier to accurately understand complex things.

Next, let's change our perspective slightly and isolate just the powertrain of the car system.

As can be seen from the diagram, the powertrain itself, like a car system, is composed of multiple interacting elements that each have a specific purpose.

In other words, the powertrain, which is an element of the automotive system, can also be considered as a system. In this case, the powertrain is part of the automotive system.subsystemI call it

Although I won't illustrate it here, if we break down an engine into its components, the engine itself can be considered a system, and in this case, the engine is part of the automotive system.SubsystemIt is called.
*If you break down an engine, there are various components such as the valve train system, the piston-crank reciprocating motion system, and the cooling system.

In other words, the more you break down the elements, the more systems emerge, which are then called sub-sub-systems.

Here, we will rewrite the automotive system using the concept of subsystems.

As can be seen from the diagram, a system can be thought of as a collection of smaller systems.System of systemsIt's sometimes called that. In Japanese, it might be easier to understand if you think of it as a nested state of elements.

This is also the reason why SE is referred to as systems engineering in the plural form.

What is a system? Have you grasped the concept of viewing things as a system?

In actual business operations, system deployment is broken down to indivisible units, down to the component level (bolts, springs, etc.), but for the sake of this diagram for understanding, we'll stop here.

Next, to deepen our understanding, let's look at examples of organizations and services that do not have a physical form, rather than tangible objects.

Thinking about a system using concrete examples that don't have a physical form.

Here, we will take a broad view and consider the Japanese government as a system.

The Japanese government has many objectives, but let's start by looking at the Constitution.

Some of you may have other opinions, but the Constitution stipulates the above.

First, we'll break it down into legislative, judicial, and executive branches, following the textbook-style approach to political economy.

There may be disagreements on the specific wording, but I believe we can all agree on the basic concepts.

It already meets the definition of a system at this point.

Since we're at it, let's develop an administrative system.

Although there may be differences in actual implementation and interpretation, the basic content should be something we can all agree on. Even just listing a part of it reveals that it's a considerably complex system (the actual government has 1 cabinet office and 12 ministries, but the diagram only shows 1 cabinet office and 3 ministries).

When we view the Japanese government's administration as a system, it becomes clear that the Cabinet and the Ministry of Finance wield immense power. Only the Cabinet system and the Finance system have a nearly one-way interaction with other administrative systems, such as issuing instructions and allocating budgets.

Therefore, if the Prime Minister, who is in charge of the cabinet system, and the Minister of Finance, who is in charge of the finance system, deviate significantly from the objectives of the Japanese government, the Japanese government system will not be able to achieve its objectives at all. So, everyone, please go and vote.
*Incidentally, the date of writing, early February 2025, coincides with the dissolution of the House of Representatives and the general election.

I got off topic.

The examples so far demonstrate that even tangible objects like automobiles, and large organizations like the Japanese government, can be viewed as systems.

Finally, let's consider intangible services.

Since I like pizza, I'm going to think about pizza delivery service as a system.

While there may be disagreements about this objective, it should be agreeable in principle.

We will deploy this as a system.

Next, let's consider the interactions. This time, we'll also consider the nature of the interactions.

Can you picture it? It's already a well-developed system. Clarifying the details of the interactions will make it even clearer.

We will be developing a delivery system.

By considering the nature of the interactions, I believe the relationships between each system have become clearer. Ideally, the order system, production system, and delivery system should be expanded in the same way as the delivery system, and if their interactions were described, they would essentially be horizontal systems interacting, making them even easier to understand. However, the diagram has been simplified (balancing readability and space).

In particular, by changing the colors of the pizza representing information and physical objects, the flow of information and objects has become easier to grasp.

This refers to the information and objects themselves (such as order information or pizza) that flow through interactions.フ ロ ーIt is called and refers to the form of information, objects, etc.Interfacecalled.
*The Japanese translation of "flow" is "nagane" (flow), and the Japanese translation of "interface" is "seime" (meeting point), "shimon" (interface), "joining surface," etc.

This is a very important concept, so please remember it. If the content of this flow and the interface do not match, the systems will not be able to interact correctly with each other.

Furthermore, the key point here is that, unlike the automotive system and the Japanese government system introduced earlier, the contents of this system are not limited to objects or organizations.

Let's reconfirm the author's definition of the system, which was derived from INCOSE, NASA, and JCOSE.

Indeed, every element of a pizza delivery service encompassed not only the goods and organization, but everything necessary to achieve its objectives.

Up to this point, we have considered automobiles, the Japanese government, and the delivery service of pizza as concrete examples of things, organizations, and services, thinking about them as systems.

In other words, you can understand that the term "system" is not something specifically related to IT, as the media often portrays it, but rather a highly general term.

Basically, anything composed of multiple elements can be considered a system.

As explained with further specific examplesWhen viewed as a system, even complex things and concepts can be made much easier to understand and organize.I think you'll understand why I recommend this approach.

Tips for thinking of it as a system

Up to this point, we have explained what a system is and the usefulness of thinking in terms of systems.

Since we're on the subject, I'll share some tips on how to think about things as a system.

The level of abstraction is important in the hierarchy of the system.

The headings might be difficult to understand, so let's explain them step by step.
*The definition of abstraction is difficult to understand, so it will be omitted.

First, let's recall the diagram of the Japanese government that we explained using a concrete example. To focus solely on understanding the system's deployment, we will remove the purpose and interactions of each system.
*The Japanese government is probably the most commonly understood entity among Japanese people, so I've sealed away my expertise in automobiles.

Here, we will focus only on the vertical direction, so we will exclude the legislative and judicial systems.

That makes it appear as if it's specialized in the vertical direction.The vertical direction is called a hierarchy.Is called.

At this stage, we consider the meaning of words at different levels, thinking about abstraction and concreteness.
*The Cabinet System is difficult to understand, so we will ask you to leave for now.

At the top of the hierarchy, the Japanese government is included in so many things that interpretations and images vary from person to person, but at the lowest level of the diagram, it's understandable "what kind of practical work they do," and I think it's at a level where most people wouldn't differ in interpretation.
*The specific tasks involved are still unknown.

This should help you understand how the sense of abstraction and concreteness of words changes depending on the hierarchy.

このThe level of abstraction or concreteness of the meaning of a word.This is what we call it. It's a definition that might offend academics, but here we'll stick with it because we're focusing on its use in thinking about systems (I might explain it further in another article).

Since we're on the subject, let's delve a little deeper into the specifics. As a military enthusiast, I'll explore the defense system, specifically a part of the Ministry of Defense.
*The defense organization structure in every country is very easy to understand in terms of its hierarchy, so this approach was adopted.

As the diagram gradually becomes more concrete, the individual Self-Defense Forces, which most of you are probably familiar with, appear at the lowest level of the diagram. There should be little disagreement that the individual Self-Defense Forces are organizations responsible for defending Japan's land, sea, and air.
*The term "Joint Staff Office" is a uniquely Japanese expression and can be confusing, but it is responsible for operations, maintenance, management, strategy, and major operations. It might be a misunderstanding, but it's something like a combination of military administration, headquarters, and staff.

Let's dig a little deeper.

You'll notice that the details become more specific as you go down to the lower levels. You might encounter some unfamiliar terms, but they all become increasingly specific in terms of defense areas, assigned duties, and scope.
*Up to the division level, a wide range of duties can be performed, including logistics, public relations, personnel, and other support operations. Below the division level, duties are specialized solely in defense operations.

So, what do you think? Did you understand the concepts of abstraction and hierarchical structure?

When thinking about things as a system, ignoring the hierarchical structure and proceeding with the following steps will make it incomprehensible.

If you make a big mistake in the vertical hierarchical structure, it would mean that the Ground Self-Defense Force personnel are directly below the Ministry of Defense, which makes no sense. If you also ignore the horizontal hierarchical structure, personnel, destroyers, and air defense forces would be listed side by side, which also makes no sense.
*In a broad sense, Self-Defense Forces personnel are special public servants belonging to the Ministry of Defense and are therefore members of the Ministry of Defense, but they are not directly under the Ministry of Defense.

In other words, when thinking about things as a system, it is important to control the hierarchical structure, or level of abstraction, and to align the level of abstraction in the horizontal direction.

This example uses the Ministry of Defense and Self-Defense Forces organization, resulting in a very detailed, multi-layered hierarchy. However, when actually considering hierarchies, it's fine to use only the necessary levels.

Tips for controlling the level of abstraction

While controlling the level of abstraction largely depends on practice and repetition, I have some tips that I'd like to share.

First, it's important to decide on the axis for changing the level of abstraction. In the concrete examples given, the Ministry of Defense and the Self-Defense Forces are concretized based on their scope of work and defense area.

However, while the Ministry of Defense and the Self-Defense Forces use two axes—scope of work and defense area—we recommend narrowing it down to one. This is because defense organizations like the Self-Defense Forces are logically structured, allowing for a clean hierarchical structure even with just two axes, whereas it is often difficult to create a hierarchical structure with multiple axes in general matters.

Since we're on the subject, let's also look at the specific examples we used: automobiles and pizza delivery services. In these cases, they are concretized along the axis of role and function.

The second tip is to actually write things down and compare them horizontally and vertically, as in the example. I don't fully understand the mechanics of the brain, but the human brain is good at comparative thinking, so we'll utilize that.

For example, in the case of the Self-Defense Forces, we deliberately shift the level of abstraction between the left and right sides.

Don't you feel something is off? We'll use this feeling of unease to make corrections. If possible, having someone else check it is also an effective method.

This visualization is used to improve the accuracy of the level of abstraction (which is also an advantage of MBSE).

The third tip is to utilize existing organizational charts, bills of materials, and service brochures.

Organizational charts and bills of materials are inherently logical and often have a hierarchical structure, so they can be used as a source of clues.

In the case of defense organizations, especially the Self-Defense Forces, the hierarchical structure is often well-structured.

Furthermore, one of the difficulties when creating a hierarchical structure according to the level of abstraction is that while the hierarchical structure itself comes to mind, it's often difficult to come up with names for each level.

Using organizational charts, parts lists, and service brochures at this stage is very helpful because many terms are organized hierarchically.

In summary, the key to understanding abstraction levels is as follows:

Please feel free to use this as a reference if you find it helpful.

MECE is important for horizontal deployment of systems.

Here, we will explain the key points of horizontal expansion when considering it as a system.

As the heading suggests, the key point is to make it MECE (Mutually Exclusive, Collectively Exhaustive). I think many people won't understand what MECE means if it's just mentioned, so I'll explain it step by step.

First, let's define MECE.
*MECE:Mutually Exclusive and Collectively Exhaustive

This definition is a rather vague and ambiguous way of putting it. Let me rephrase it in my own words.

Has it gotten a little better?

Just like with the system explanation, further manipulation of definitions will only lead to empty rhetoric, so let's use concrete examples to help you internalize them.

Let's use the Japanese government as a concrete example. If we divide the Japanese government into MECE (Mutually Exclusive, Collectively Exhaustive) components, it will look like the following, as explained above.
*It's written in the Constitution, so it must be true.

The legislature, as the name suggests, creates laws; the executive branch carries out practical work based on those laws; and the judiciary checks the application of those laws. This ensures there is no overlap and no omissions in the process.

So, what do you think? Have you grasped the concept? MECE (Mutually Exclusive, Collectively Exhaustive) is something that improves with practice and repetition, so the best way to learn it is to practice it a lot.

Let's take a look at the Japan Self-Defense Forces, which we used as a concrete example to help you get used to it.

As expected of the Self-Defense Forces, their domain is perfectly MECE (Mutually Exclusive, Collectively Exhaustive). However, in practical operations, there are problems at the boundaries of land, sea, and air, so the Ground Self-Defense Force and Maritime Self-Defense Force also have air units, and the Air Self-Defense Force has anti-aircraft units and base defense units (logic and reality).

Recently, as human activity has expanded to include land, sea, air, space, and cyberspace, this too is MECE (Mutually Exclusive, Collectively Exhaustive).

When considering this as a system, it's important to be careful not to ignore MECE (Mutually Exclusive, Collectively Exhaustive) when expanding left and right, as this can lead to duplication and omissions, rendering the system largely meaningless.

As mentioned above, the system becomes meaningless due to duplication, omissions, and missing elements, so be sure to keep in mind that the left-right expansion is MECE (Mutually Exclusive, Collectively Exhaustive).

Tips for MECE

Since we're on the subject, let me share a few of my personal tips for achieving MECE (Mutually Exclusive, Collectively Exhaustive) structures, just like with levels of abstraction.

The first tip is to define the prerequisites for MECE (Mutually Exclusive, Collectively Exhaustive).

In fact, MECE is based on logical assumptions. The specific examples introduced above are also MECE based on those assumptions.

The two examples above can be divided into MECE (Mutually Exclusive, Collectively Exhaustive) categories precisely because they have certain preconditions.

Therefore, it is very important to define the preconditions before starting the MECE (Mutually Exclusive, Collectively Exhaustive) process.

Furthermore, the underlying assumptions are extremely problematic for MECE (Mutually Exclusive, Collectively Exhaustive), as the answer changes depending on the assumptions, even for the same subject.

For example, let's consider MECE in the context of a person's gender, specifically male and female.
*This is a sensitive topic, but it's easy to understand, so I guess it can't be helped; there's no particularly deep meaning behind it.

As you can see, the answer can change considerably depending on the assumptions, so be sure to define the assumptions. Personally, I recommend always writing down the assumptions when creating a MECE diagram.

Conversely, if your boss or clients ask you to use the MECE principle at work, always ask them about the prerequisites. Otherwise, it can lead to problems.

The second tip, similar to the level of abstraction, is to actually write things down and check them, like with concrete examples. Writing things down can sometimes reveal new insights, so be proactive in doing so.

Writing things down also allows others to review them, so it's highly recommended.

The third tip, like the one for abstraction, is to actively utilize existing organizational charts, bills of materials, and service brochures. Things written in parallel are often mutually exclusive and collectively exhaustive (MECE), so they can be helpful references.

Even if your organizational chart or bill of materials isn't MECE (Mutually Exclusive, Collectively Exhaustive), it can be very helpful when you try to implement MECE yourself, so make good use of it.

The fourth tip is not to obsess over perfection. This may sound like a matter of mindset, but even if everything is perfectly MECE logically, in reality it is almost never MECE.

Therefore, the number of items that can be perfectly divided into MECE (Mutually Exclusive, Collectively Exhaustive) categories is limited in reality, so I think it's sufficient if you think it's reasonably MECE.
*In reality, only things that are strictly defined by rules, such as age or administrative divisions (national, prefectural, municipal), can be perfectly MECE (Mutually Exclusive, Collectively Exhaustive).

The important thing isn't that it's perfectly MECE, but that it's actually useful when you use it. So, I think it's enough if it's at a level that you yourself are satisfied with and that the person you're showing it to is satisfied with.

In summary, it is as follows:

Please feel free to use this as a reference if you find it helpful.

System deployment is based on the level of abstraction, with horizontal deployment being MECE and vertical deployment being based on the level of abstraction.

We have now explained the concepts of abstraction and MECE.

To reiterate, here's an explanation of the level of abstraction and the use of MECE when thinking about things as a system:

Basically, by adopting the two principles mentioned above, you can understand most things as a system.

Furthermore, controlling the level of abstraction and using MECE (Mutually Exclusive, Collectively Exhaustive) also helps prevent thinking from becoming stuck in hierarchical relationships when considering levels of abstraction, and from becoming stuck in left-right relationships when considering MECE.

For example, even in the case of MECE (Mutually Exclusive, Collectively Exhaustive) in terms of abstraction level, if you can't think of sub-subsystem 1-2, knowing the other systems can be very effective, as it can help you come up with it like a fill-in-the-blank problem (deriving it from surrounding information).

Please feel free to use this as a reference if you find it helpful.

Summary

This time, we'll be explaining the core systems of SE (Systems Engineer), so it's quite lengthy, but we'll cover it all together.

First, the system was defined as follows:

Leaving the details to the main text, the important point is that "system" is not a term specific to IT; anything composed of multiple elements can be considered a system.

The advantages of this system are as follows:

Therefore, I believe this is an essential skill in today's increasingly complex society.

Next, the key to understanding things as a system is to think in terms of abstraction for vertical hierarchies and MECE for horizontal development.

That concludes the summary.

Thinking about things as systems is fundamental to being a systems engineer, so I highly recommend developing this skill. Developing the habit of thinking about things that catch your attention in the news, etc., as systems is excellent training (writing them down makes it even more effective).

Even if you're not interested in becoming a systems engineer, I highly recommend it because developing the skills to think in terms of systems will surprisingly change how you see the world.

Finally, as a service to readers who have read this far, I will introduce a powerful assistant for breaking things down into systems, controlling the level of abstraction, and implementing MECE.

It's simply AI.

AI excels at logical thinking, making it ideally suited for this type of task. Furthermore, AI itself is built within the framework of software engineering, so let's make effective use of it.

However, the prompt is extremely important; simply typing "Please disassemble the system" will not yield the desired response.

The key is to input the perspective from which to break down the system (purpose, function, organization, etc.), the axis of abstraction (domain, role, etc.), and the prerequisites for MECE (biological or social for a person's gender) into the prompts.

Using AI is quite effective, so please try it if you'd like.
*If you're interested in learning more about the process, please ask me directly.

That concludes our explanation of the system.

Next time, we'll return to the NASA Systems Engineering Handbook and discuss the fundamentals of systems engineering, specifically verification and validation.

• NASA Systems Engineering Handbook Rev2
  This book is the basis for this explanation. It is in the public domain, so you can get it for free.

• Systems Engineering Handbook, Keio University Press, supervised by Hidekazu Nishimura
  We'll be working hard to supervise the NASA handbook on this site, but it will take time, so if you want to learn the whole thing right away, I recommend this book. I own a copy myself.