Company Logo

SE&D Blog Post #1 – May 23, 2016

Topic: Definition of a “System”

  • “SystemAn integrated set of interoperable elements or entities, each with specified and bounded capabilities, configured in various combinations that enable specific behaviors to emerge for Command and Control (C2) by Users to achieve performance-based mission outcomes in a prescribed operating environment with a probability of success.

Source: Wasson, Charles S. (2016), System Engineering Analysis, Design, and Development: Concepts, Principles, and Practices, p. 2, New York: John Wiley & Sons, Inc.”

Since the beginning of modern day SE in the WWII timeframe, academia, industry, government, and professional organizations have attempted to establish definitions of a “system”. Constructively, the robustness of definitions created in these exercises is often inversely proportional the number of people participating. In general, you would expect more people vetting a definition to result in a more robust definition that is accepted across diverse disciplines, level of experience, and paradigms. However, in today’s world by the time professional organizations obtain worldwide vetting, “buy-in,” and approval of a definition, the resulting definition becomes so diluted that it loses its substantive meaning.

How does this happen? What starts out as a substantive discussion quickly evolves into grammatical and political “word-smithing games.” For example, group discussions exchange “happy” for “glad” to accommodate the wide range of experiences and sensitivities of professional disciplines, business domains, and factions within each discipline. Wasson, 2016, p. 3 provides an informative discussion of what occurs when teams of people attempt to focus on 1) content and 2) grammar simultaneously.

In general, technical definitions occur in two forms: 1) philosophy-based and 2) physics-based observations.

  1. Philosophy-based definitions are opinions formed by those of differing knowledge, skill, and experience levels, which vary from “I learned about the discipline yesterday and now I have a philosophy based on my (limited or no experience) opinion” to professionals with years of in-depth experience who actually know “how to” perform Systems Engineering and development (SE&D).
  2. Physics-based observational definitions are those based on observations of real-world, life cycle operations and characteristics of the entity or concept being defined. Such is the case for the Wasson definition above.

To illustrate this point, consider common definitions of a “system.” Philosophy-based definitions constrained by a minimalist words mindset define a “system” as follows: “a collection of people, processes, equipment and procedures, etc.” This checks the box for: 1) what a system consists of and 2) using the least number of words.

Many years ago a colleague gave everything the “So What?” test. If a system is “a collection of people, processes, equipment, procedures, etc. – so, what?” How does knowing this provide value in developing systems? It says nothing about the interrelationships among these elements or how they holistically produce a performance-based mission outcome.

The problem with philosophy-based definitions is they are typically opinions that fail to characterize a system’s unique characteristics and interactions of a system with its operating environment. Characteristics such as users, boundaries, mission, context, composition, capabilities, performance-based outcomes, context – when/where/how is can be used, probability of success, et al.

Now consider the definition of a “system” presented above (Wasson, 2016, p. 2).  Technically, it characterizes what a system is based on physics-based observations of reality, not some opinion-based philosophy. Is the definition lengthy? Yes, but what phrases of the definition would you eliminate for the sake of reductionism and simplicity without impacting its robustness to characterize what a system really is and accomplishes? Observe how it provides: 1) substantive content, 2) context, and 3) passes the “so what” test in terms of value in developing systems.

one comment:

  1. Scott August 11, 2016 10:28 am

    Nice website! I gave a talk about SysML focusing on the definition of the base elements of a system (in other words… define the parts, components and lowest levels of what is to be defined). The definition above stops at “equipment” which perhaps implies an assembly of parts/components and software.

    I came to the realization that at the elemental level of a system, you know you have reached the bottom when all interfaces are external to your element, part/hardware component or code function/software element. I found that I was pleased immeasurably by describing the lowest atomic level of a system as a “thing”.

    My unfortunate conclusion is that the definition of a system (using Occam’s razor) should be “a group of two or more things that are temporarily or permanently interfaced”.

    The definition with C2 statements and every type of abstract “thing” seem overly byzantine. So the term “thing” is an abstraction for people, processes, equipment, etc. My view is that the opposite of abstraction is specification.

    So systems engineering is the process of providing definition of a system thru specification. Defining a preliminary system using abstractions is not what should be considered a final state. Specification requires defining not only what but also how.

    Any / all comments welcome!





*