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.

10 comments:

  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!


  2. C. Wasson July 28, 2017 10:24 am

    Scott brings up some great discussion points. Rather than answer all of his comments at once resulting in a lengthy response, let’s address each separately as a series of responses.


  3. C. Wasson July 28, 2017 10:36 am

    Point #1: Equipment Inference in System Definition

    Scott’s comments noted “…The definition above stops at “equipment” which perhaps implies an assembly of parts/components and software.

    The definition of a “system” listed at the beginning of Blog #1 does not mention “equipment”; only “elements” or “entities.” Usage of the term “equipment” was made in reference to casual definitions in industry, government, professional, and standards organizations that perceive Systems Engineering as applying to Engineered Systems. As a problem-solving and solution development methodology, SE applies to any type of system.

    An “entity” can represent a person, place, thing, role, etc. and is not restricted to Engineered Systems such as aircraft, smart phones, engines, et al. It applies to Environmental, Geophysical, Biological, Chemical, Celestial, Atomic, Social, and many other types of systems at any Level of Abstraction. For Engineered Systems an “entity” can represent components (generic) such as Parts, Subassemblies, Assemblies, Subsystems, Products, or the System of Interest (SOI).


  4. C. Wasson July 28, 2017 10:42 am

    Point #2: “Entity” versus “Thing” Semantics

    Scotts comments noted “…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 term, “entity,” is generally accepted throughout Engineering, Science, Business, Law, et al as a universal term. From an SE perspective, an “entity” can be logical or physical. In contrast, the term “thing” has a colloquial, non-technical, connotation.

    More importantly to ensure clear communications and standard semantics, Engineering disciplines at all levels – team, project Enterprise, professional and standards organizations levels – must establish agreement concerning the standard terms and their meanings.

    In the 1980’s Object-Oriented Analysis (OOA) and Design (OOD) used “object” as the operative term representing organizations, persons, places, roles, etc. Unfortunately, with the evolution of the Internet and recognition of the need for systems to communicate status, performance, health, et al, the Internet of Things (IoT) – oddly – is now the trend.


  5. C. Wasson July 28, 2017 11:01 am

    Point #3: System Definition

    Scott’s comments defined a “system” as “a group of two or more things that are temporarily or permanently interfaced.” A word of caution concerning context and the meaning of “interfaced.”

    Integrated entities within human-developed Engineered Systems are required to: (1) be “interoperable” – i.e., they can: encode/decode information parameters and data formats, transfer energy, etc., (2) be “compatible” mechanically, and (3) produce performance-based outcomes for a given set of inputs, constraints, and environmental conditions.

    A simple lever and fulcrum can be configured – i.e., “temporarily or permanently” interfaced as you note, remain stationary, and produce no outcome. Interfacing a lever and a fulcrum is necessary but insufficient to produce the desired performance-based outcome. However, when a human operator transfers directed motion and energy to the lever and fulcrum – placed at some position along the lever, a performance-based outcome is accomplished. As a result, the Operator-Lever-Fulcrum System accomplishes more than any one of these entities by itself – e.g., the concept of emergence.


  6. C. Wasson July 28, 2017 11:05 am

    Point #4: Command, Control, and “Things”

    Scott’s comments noted “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.

    Again as discussed in Point #2, the term “entity” is not restricted to human developed Engineered Systems. For example, Natural, Social, Governmental, et al non-Engineered Systems are governed by laws of physics or societal entities that exercise Command and Control (C2) over other entities internal and external to their domain of influence.


  7. C. Wasson July 28, 2017 11:08 am

    Point #5: Abstractions versus Specifications

    Scott’s comments noted “My view is that the opposite of abstraction is specification.” These are two distinctly different but associated concepts.

    An “abstraction” refers to a position within a hierarchical structure such as a multi-level System Architecture within a specific System of Interest (SOI). In the case of Engineered Systems, Levels of Abstraction might be System, Product, Subsystem, Assembly, Subsystem, or Part. Each Level of Abstraction suppresses lower level information. For example, the “Subsystem” Level of Abstraction suppresses information concerning the quantity and names of “Subassemblies” and so forth.

    Expanding this point further … a vendor producing a Flight Computer as a SOI views the deliverable end product as the System Level of Abstraction. However, an aircraft manufacturer that acquires the Flight Computer might integrates it as an entity within the aircraft’s Subassembly Level of Abstraction. Wasson’s 2nd Edition (2016) Chapter 8 “System Levels of Abstraction, Semantics, and Elements” provides an excellent discussion on this topic.

    In contrast, a “specification” specifies and bounds the capabilities, interfaces, performance-based outcomes, constraints, and verification methods for a specific “entity” at any Level of Abstraction within a System of Interest (SOI).


  8. C. Wasson July 28, 2017 12:25 pm

    Point #6: Defining a System Using Abstractions

    Scott’s comments noted “…Defining a preliminary system using abstractions is not what should be considered a final state.” True. Wasson’s 2nd Edition (2016, Figure 4.7, pp. 94 – 97) provides an excellent description of this process.

    Analytically, we begin applying the SE Process as a problem-solving and solution-development methodology top-down to identify Levels of Abstraction and their respective entities. Contextually, each analytical “entity” begins as an “unknown” Problem Space. By recursively applying the SE Process downward to each Level of Abstraction, potential solutions are explored and selected.

    Once architectural Solution Spaces to a higher-level Problem Space are identified, an entity’s Problem Space context analytically transitions to a Solution Space context. For example, analytically a System begins as a Problem Space box. As candidate Subsystems – potential Solution Spaces – are identified, the System is no longer considered a Problem Space but a Solution Space. Then, each Subsystem designated a Solution Space to the System becomes a Problem Space ‘unknown” in terms of its internal architecture. The processes continues until the lowest Levels of Abstraction and entities of the System are identified, specified, and bounded.

    Recognize that the term “Solution Space” at any Level of Abstraction is: (1) subject to change as lower level technical issues require reconsideration and (2) only becomes “final” when the System has been verified, validated, and delivered in accordance with the terms of the Acquirer’s contract.

    Additionally, analytical decomposition and analysis are methods for problem-solving and solution development to reduce system complexity and risk … one step at a time. Wasson’s 2nd Edition (2016, Principle 4.17, p. 93) states “Partition-decompose-problem or issue spaces into one or more manageable solution spaces as a means of reducing complexity and managing risk.”


  9. C. Wasson July 28, 2017 12:40 pm

    Point #7: Issue – Specifications specifying WHAT and HOW.

    Scott’s comments noted “… Specification requires defining not only what but also how.

    This violates a key principle of Systems Engineering (Wasson, 2016, Principle 19.6, p. 401) “A specification specifies WHAT is to be accomplished and HOW WELL, NOT how to design the system, product, or service.” If you specified HOW a system is to be designed, contracted with a System Developer to develop it, and it failed to perform as intended, guess who specified HOW. You can choose to specify how a system is to be developed; however, recognize that if there are better solutions, you unnecessarily constrain consideration those solutions.

    Let the marketplace offerors do what they do best – propose innovative, acceptable risk, least cost and schedule solutions that will satisfy the User’s operational needs. Then, select the best proposal and source, assuming both have acceptable risk and compatible with the Acquirer’s budget and schedule.


  10. C. Wasson July 28, 2017 12:41 pm

    Thanks Scott for the comments. These are thought-provoking topics that abstract Systems Engineering – e.g., “Plug & Chug” Specify-Design-Build-Test-Fix – methods perceived to be the SE Process are seldom addressed and corrected by industry, government, professional, and standards organizations.





*