The scale of a business or simulation (continuous or discrete-event) system can be driven by a number of factors. Scale can be measured in terms of CPU cycles, communication bandwidth, disk storage, dynamic memory usage, power consumption, and perhaps other factors. The ones that simulations and business systems have in common include:
- The number of operations: The more different activities that are modeled, and the more examples of each activity there are, the bigger the model will be. While much larger models are possible, I’ve built models that could involve up to 84 different activities, some of which included up to a dozen stations. A business process with twenty different activities but with some involving 100 employees could in some sense be regarded as a larger model.
- The number of arrival events: Many systems process entities that arrive at the beginning of a process, traverse the process over time, and exit the process at the end. In other systems there may be no true entries and exits, but events may be generated according to a schedule, while additional events may be generated through other mechanisms (like equipment failures, repair and supply actions, and so on. I’ve worked on systems that only process 40 items per hour at top speed and others that processed thousands.
- The number of internal entities: The more entities that are or can be represented in a system the larger the scale. I’ve modeled furnaces that held only a dozen slabs of steel at a time but on document imaging systems that processed thousands of pieces of paper.
- The complexity of representation of each entity: Some entities exhibit only simple behaviors and have only a few characteristics requiring data values, while entities and components of other systems might require large numbers of parameters to describe. In theory a system parameter will only exist if it can be changed or if events are affected by its value, so the existence of each additional parameter makes the system larger in scale.
- The number of users: A fire-and-forget system has only one user and no interactions. A training simulator may handle input from multiple trainees simultaneously while a distributed simulation may involve many more. A large scale business system may have users throughout a building or campus, or all around the world. The more communications and interactions with users there are, the larger the system.
- The degree of interactivity supported: An interactive system will incur more overhead than a fire-and-forget system. The more user interactions the system suppports the greater the scale may be.
- The volume of internal communications: A single, desktop system may have little or no communication between processes. I’ve worked with single-threaded, fire-and-forget models and with single-processor systems running up to a dozen concurrent, real-time processes, many of which are in communication with each other as well as external processes. Any system designed to support communication between multiple processors will add complexity. In short, scale increases with more internal communications.
- The amount of checking against external values: Simulations and business systems may both have to check against historical and other values for ongoing validation, compliance, and for other reasons.
- The amount of reporting required: I’ve seen systems put out multi-gigabyte files and others which record very little information. Sometimes the output is highly graphical in nature and at other times consists only in hundreds of thousands of lines of text.
- The amount of internal logging and bookkeeping: If a system needs to record values that are needed not for output as such but for the monitoring of the health of the system, the scale of the system increases.
- The residence time of entities in the system: Entities can pass through some systems in a matter of real or simulated seconds while they may remain in other systems for months or years. The longer entities may reside in the system the greater the scale.
These factors apply to simulations but not business systems:
- The amount of simulated time modeled: A system that models behavior over a longer elapsed time will take longer to run than one that models events over a shorter time. I’ve worked on systems that modeled just a few minutes of time and others that modeled up to a full year.
- The size of time steps: If two systems that simulate the same amount of elapsed time then the one that does so in smaller time steps will, all other things being equal, take longer to run and be of a larger scale. This can apply to discrete-event simulations where many events happen quickly and the same may be true of business systems, but mostly this applies to continuous simulations.
- The size of elements, nodes, volumes, etc.: This applies almost exclusively to continuous simulations. Thermal simulations, computational fluid dynamic simulations, stress analysis simulations, and other types may all model the behavior of different regions of volumes of solid, liquid, or gaseous material (as well as material in other states). The more granular the system is, i.e., the more nodes or sub-volumes it defines, the greater the scale of the model.
It is theoretically possible to consume computing resources approaching infinity by making nodes and time steps smaller and smaller. That is, increasing granularity increases the resources required to complete the simulation, but can also improve the accuracy (to a point, which is a different discussion). One generally tries to use the largest values possible that will yield usable (and accurate) answers. Many factors contribute to that accuracy and usability, including number scaling, number size (say, 32-bit vs. 64-bit or larger), the characteristics of intermediate results, rounding errors, chaos effects, Courant limits, and so on. One also wants to save time and money.
One may ponder the fact that CFD simulations can include large numbers of nodes around an aircraft that may be a few inches on a side or smaller, but one intended to model global weather evolutions, even if it defined a billion nodes, would still have to define nodes that are greater than a mile square and more than a mile high. How accurate is that going to be, particularly when considering that each surface node might have to define parameters for ground cover (buildings, roads, parking lots, vegetation, ice, fresh water, salt water, mud, rock), moisture retention, permeability, reflectivity, habitation, gas and particulate emissions, ability to absorb and emit radiation on different frequencies, elevation, angle to the sun, and so on? And that’s just the ground level. We haven’t even discussed the effects of clouds, oceans, solar radiation, and other things. And that’s also with a billion nodes, which would be a pretty large model. Early models defined nodes so large they ignored features like… England. Such models may also be run over a one hundred year time span. One can imagine that’s a large undertaking under any circumstances.
These factors apply to business systems but not simulations:
- The amount of external regulation: While simulations themselves generally aren’t subject to regulation by governing bodies (though the actions based on their results might be, and evidence may have to be shown of the steps taken to verify, validate, and perhaps accredit them), but business systems may be subject to regulations of many kinds, or may represent processes that are highly regulated. Adding overhead to a system in order to meet regulatory requirements increases the scale of a system (in terms of many of the factors listed in the first section, above).