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 on 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 Responses to “Modeling 101: What, Who, How, When, Where”

  1. putchavn Says:

    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).


  2. caminao Says:

    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).


  3. caminao Says:

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


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: