Orthogonal Model Components

There are four main perspectives that Orthogonality applies when describing an application:

  • Event – Events occur from inside or outside an application and typically require a Process to respond to each of them. In some cases, the Event initiating its process receives transactions from other applications, or data entry activities occur by humans through a terminal or data collection screen, or when some data record is placed in a State that requires other data to make its own changes.
  • Process – Processes are invoked in response to events as they occur. In some cases, the Event initiating its process receives transactions from other applications, or data entry activities occur by humans through a terminal or data collection screen, or when some data record is placed in a State that requires other data to make its own changes. Each invoked Process SHOULD evaluate or assess the State that its Data and the Application are in before beginning to perform its process steps.

    Constantly running processes are often used in applications to respond to State Changes in either the Data or the Application or respond to periodic changes that occur as time passes: End of Day/week/month/reporting period/ year/decade, etc.
  • Data – Data is a collection of data items that are either initially introduced into an application or are being changed as the result of a Process invoked by an Event.
  • State – State is a condition that each Data Row can be left in once a Process has concluded its prescribed changes or actions; Individual Data Rows and the Application itself can be left in a State. Each invoked Process SHOULD evaluate or assess the State that its Data and the Application are in before beginning to perform its process steps.

The most important perspective to apply to this collection of components is to constantly confirm that each of these models stays in sync with each of the other models. If they are out of sync, then the application should be considered flawed (which could be another State of the Application). And, of course, this “flawed” state could be an Event that triggers a Process built to deliver Warning Messages to critical users about this discovery.