Modeling 101: What, Who, How, When, Where


Taking a leaf from Wittgenstein who once defined philosophy as a synopsis of trivialities, it may be interesting to supplement the Book of Fallacies and the Reflections for the Perplexed with some trivial distinctions that could be more easily agreed across the system engineering community.

What’s in a Model (Norman Rockwell)

As far as systems engineering is concerned, basic trivialities should focus on systems, architectures, and engineering processes. And as a mother of all, yet all too often ignored, a clear understanding of problems and solutions.

It must be noted that trivialities are not be taken for definitions; their only objective is to provide a sound and undisputed basis for robust definitions that could then be used to build clear and useful principles. As a corollary, one should not try to extend the suggested trivialities but to trim and distill their meaning to an undisputed core.

Systems & Components

  1. To begin with the scope under consideration, systems can be first understood as a collection of interacting agents, devices, and computers.
  2. Within that scope, a computer system is a container of software components, some of them with the capability to interact with the environment: users, other computer systems, or devices.
  3. Finally, software components are symbolic objects representing agents, objects, or activities identified in the business environment.

Enterprise Architectures & Business Processes

  1. Enterprises are social constructs with continuous identity.
  2. Enterprise architectures describe enterprise’s assets and organization.
  3. Business processes describe how enterprises interact with their environment.

Enterprise Architectures & Information Systems

  1. Information systems are meant to manage the symbolic representations of enterprise environments, assets, processes, and commitments.
  2. The relationship between enterprise and systems architects is one of customers and providers.
  3. Enterprise architecture should provide the basis of requirements for systems architectures.

Engineering Processes & Models

  1. Engineering processes describe how to design and build computer systems.
  2. Engineering processes begin with requirements capture and wind up with the deployment of software components.
  3. Models are intermediate artifacts used along engineering processes.

Problems & Solutions

  1. Business problems are set by enterprise environments and their solutions are not to be found in systems functionalities.
  2. Functional problems are defined by business solutions and are meant to be met by software architecture.
  3. Technical problems are defined by functional solutions and are meant to be met by technology and programming solutions.

Further Readings






4 thoughts on “Modeling 101: What, Who, How, When, Where”

  1. Absolutely not. That’s why I’ve mentioned Wittgenstein who defines his own work as a synopsis of trivialities.

  2. Isn’t trivial ? e.g, business stakeholders want to get to a specific set of customers (business problem), business analysts define a new channel (business solution), and ask functional analysts how the system can support it (functional problem).

    1. Remy: Are you saying “trivial and absurd” are of the same kind but only differ in degree? That is too broad a classification.

      My comment did not appear on the LinkedIn discussion.

      Is there a brief description of Wittgenstein 1 and 2. I only know one good statement from him: Whatever needs to be expressed can be expressed with sufficient clarity.

      I am into “The Meaning of Meaning”. I invite you to see

      and give your comments.


  3. Most of the trivialities are useful. Problems and Solutions needs major revision.

    I find “….problems are defined by ….solutions …” absurd (sorry I cant find a more polite word).

Leave a Reply

%d bloggers like this: