Components of a Solution

I wanted to define some terms and provide some context in preparation for the next few posts. Specifically, I’m describing the components of a solution. A process model is a model of a system that either does exist or will exist, either after it is implemented or after it is modified from an existing system. I’m going to be referring to the work needed to affect the solution itself as the solution or the solution effort over the next few days.

As called out in the diagram directly below, a model is made up of many standard components. I’ll refer to these repeatedly in the descriptions that follow, so I want to start by describing the components here.

  • System (or Model): A system is the entire system or process being investigated. A model is a representation of that system or process.
  • Entity: Entities are items that move around in the system. They can represent information or physical objects, including people. Entities will sometimes pass through a system (like cars going through a car wash) and sometimes move only within a system (like aircraft in a maintenance simulation or employees serving customers in a barber shop). Entities may split or spawn new entities at various points within the system, and can also be merged or joined together.
  • Entry: Entities of go into a system at entry points. Note that the entry can represent an exit point from an external system, and thus a connection with that system.
  • Station (or Process Block or Activity): These blocks are where the important activities and transformations happen. The important concepts associated with stations are processing time, diversion percentage (percentage of time entities being processed go to different destinations when they leave the station), and the nature of the transformations carried out on the entities being processed (if any). A wide variety of other characteristics and behaviors can be defined for these components, and those characteristics (like being open or closed, for example) can change as defined by a schedule.
  • Group (or Facility): A group of stations performing related operations is referred to as a facility. A toll plaza includes multiple stations that all do the same or very similar things. A loading dock that serves multiple trucks works the same way, where each space is a separate station. In a more information-driven setting, a roomful of customer service workers could be represented as individual stations, and collectively would be referred to as a group or facility.
  • Queue: A queue is where entities wait to be processed. FIFO, LIFO, and other types of queues can be defined. A queue can have a defined, finite capacity or an infinite capacity. If the queue has a physical component it might be given physical dimensions for length, area, or volume. A minimum traversal time may also be defined in such a case.
  • Path: A path defines how entities move from one non-path component to another. In logical or informational systems the time needed to traverse a path may be zero (or effectively zero), while length and speed may have to be defined for physical paths. The direction of movement along each path must also be specified. Paths are often one-way only, but can allow flow in both directions (although it’s often easier to include separate paths for items traveling in each direction).
  • Exit: Entities leave a system through exit components. Note that the exit can represent an entry point of an external system, and thus a connection with that system.
  • Bag (or Parking Lot): A bag is a special kind of queue where entities may be stored but may be processed at arbitrary times according to arbitrary criteria. They are used when their operations are not FIFO, LIFO, or some other obvious behavior. You can think of them like parking lots, where the residence time is determined by the amount of time it takes passengers to get out of the car, walk somewhere, conduct their business in some establishment, walk back to the car, get back in and buckled up, get their phone mounted and plugged in, take a swing of their coffee, set the GPS for their next destination, get their audiobook playing, readjust their mirrors, and finally start pulling out. In such a case the car will be represented by an entity that continues to take up space in the parking lot (or bag), while the passenger is a new entity that is spawned or split from the car entity, and then later merged or rejoined back with it.
  • Combined (Queue and Process): It is possible to define components that embody the characteristics of both a station and a queue. This is typically done for representational simplicity.
  • Resource (not shown): A resource is something that must be available to carry out an operation. Resources can be logical (like electricity or water, though they can be turned off or otherwise fail to be available) or they can be discrete, like mechanics in a repair shop. When a car pulls into a station or process block (representing a space in a garage) a mechanic has to go to perform the service. Sometimes multiple mechanics are needed to carry out an operation. Sometimes different specialists are needed to perform certain actions. Discrete resources can be represented by entities in a system. If no, or not enough, resources are available, the the process waits for them to become available, and only starts its clock when they do.
  • Resource Pool (not shown): Resources can be drawn from a collection, which itself is referred to as a pool. There can be one or multiple pools of resources for different purposes and the resources can have different characteristics. There may be different numbers and types of resources available at different times, and this can be defined according to a schedule.
  • Component: All of the items listed above — except the system itself — are referred to as system (or model) components.

That just describes some of the major items I tend to include in process models. Here are some of the others that are possible.

  • Event: Events are occurrences or changes of state that trigger a change to some other component in a system.
  • Decision Point: These control elements govern the movement of entities through the system, either logically or physically. The diversion percentage characteristic described for stations, above, is an example of embedding a decision point into another component. However, decision points can be included in models as standalone components. In my experience they are usually connected by paths and not other components, but that is an implementation detail.
  • Role: This represents a person or group involved in the process. Roles can be modeled as stations or resources, as described above, but they can also be included as other kinds of components, depending on the implementation.

If the process model is itself a simulation there is yet another layer of components can be added. These are meta-elements that control the simulation and its components. Simulations are often called models, although the BABOK reserves the word model for the graphical representation of a system and associates simulation with the concept of process analysis.

  • Editing interface for the system: This allows a user to add, remove or reconfigure components within the system.
  • Editing interface for components: This allows a user to define or modify the operational characteristics of the components. This can include schedules, events, arrivals, and other items, as well as traditional elements like durations, dimensions, and capacities.
  • Operational interface: This allows a user to start, pause, and stop the simulation.
  • Data analysis capability: Simulations are generally implemented to generate a lot of output data. They can also require a lot of complex input data. Integrated analysis capabilities are sometimes included in simulation tools.
This entry was posted in Tools and methods and tagged , , , . Bookmark the permalink.

Leave a Reply