I asked this question on the Operations Research Beta site, but haven't gotten an answer after 5 days. Hoping that this Stack Exchange site is more suitable than Stack Overflow (though the latter does deal with implementation, which participants might readily discern from modelling).

In my post-graduate research and subsequent career in operational analysis, the difference between following seems to have become clearer with the years: (1) a model of a problem or operations in the real world and (2) implementation of a corresponding analysis tool that applies the model to actual data.

Item (1) can take many forms: A collection of inter-related equations, a schematic, and/or a word description. But one cannot take item (1) and apply it to actual data to get the results.

To apply a model to actual data, the model must be realized via item (2), which can take the form of spreadsheets, coding (preferably in a 4th generation language), software whose execution is specified via a graphical schematic language [1], digital circuit/systems modelling environments [2], discrete event simulators, optimization packages, etc.

Is there an actual paper, book, or some preferably non-contentious source that describes this distinction? Some of what I've found seem not to distinguish between the two items, preferring instead to distinguish their amalgamation from "implementation" of recommendations falling out of the analysis. The latter is not what I mean by "implementation" in the context of this question.

ANNEX: My personal view of modelling layers

As suggested in the comments, I'll refer to a concrete example. It is not in the area that I work in, but rather, from what I recall in a course.

Before any modelling, someone may have a problem. He/she can describe the problem, but at this point, I don't consider it a model. For example, a wholesale distribution centre might want to get more profit from its operations, but isn't sure where or how to sharpen things up.

The salient parameters and relationships of a real world problem need to be identified. This representation of the problem is an abstraction, so it is a model, but it is still in the language of the problem domain. In the above example, say the manager's new hire happened to have taken a operations research course before. He/she recognizes that the operations resemble a linear programming model from class. The parameters were the cost of shipping product different retailers, the demand from the various retailers, etc., and the decision variables represent how much to send to each retailer. The model doesn't represent all aspects of the problem, but using it may improve efficiency over just winging the decisions.

Normally, an algorithmic model then needs to be identified, e.g., evolutionary algorithms, LP/ILP/BLP, etc. In the above, the new hire chooses LP, since it was an LP model that he recognized as roughly representing actual operations. Strictly speaking, however, one could choose (say) genetic algorithms (GAs), simulated annealing (SA), exhaustive search, etc. Normally, a mapping is also needed from the model in the problem domain to the algorithmic model. The LP variables can be found in any textbook, and it is simply a matter of stating what real-world variables correspond to the textbook LP variables. Different search algorithms might provide more flexibility in what the variables can represent, and the relationships that can be specified between variables. Again, since the new hire recognized the similarity between the operations and an academic LP problem, the mapping of variables is straightforward.

This mapping is what I mean by analysis model because it is how one plans to analyze the problem. It encompasses both the abstraction of the problem, the selection of the optimization method, and the mapping of variables from the former to the latter. In so doing, one chooses what aspects of the real world will be represented and what aspects will be ignored.

The executable code then needs to be planned at the design/architectural level, e.g., the object oriented classes to manage the data and bookkeeping. Then someone needs to write the code and test it. Many people in my circles refers to this activity as implementation, but the noun "implementation* also refers to the resulting code (or executable schematic). The implementation still represents the problem, so is technically a model, albeit an "executable" one that can be applied to input data to generate a result. It's design and development, however, is quite different from the previous 2 models, so I try to maintain this distinction by referring to it as [an executable] implementation, leaving out the word "model".


[1] Core Sim, G2 ReThink, LabView, etc.
[2] These may use a combination of schematics and text languages for specifying system behaviour.

  • $\begingroup$ As I understand it, you're interested in the subject that describes some part of the overall process that's given in the annex. Specifically, which part of the process described in the concrete example are you interested in? $\endgroup$
    – Nat
    Aug 31, 2020 at 22:58
  • $\begingroup$ I'm actually interested in a (possibly online) source that draws the distinction between the analysis model above versus the executable implementation, and explains this difference. I and some colleagues took it for granted that everyone would recognize this distinction, but I couldn't actually corroborate this from an online search. $\endgroup$ Sep 1, 2020 at 0:15
  • $\begingroup$ The analysis modelling is book, brain, and paper work while implementation involves planning the organization of code, crafting it, and/or schematic capture. The former may be theoretically challenging, while the latter may require experience leveraging commercial applications, design patterns, and technologies/standards for interfacing enterprise applications. It is a realization of the analysis scheme that can be applied to data. $\endgroup$ Sep 1, 2020 at 0:15
  • $\begingroup$ It sounds like you're asking about what's simply called modeling? Or, the even more abstract aspect of it'd be called binding. $\endgroup$
    – Nat
    Sep 1, 2020 at 0:52
  • $\begingroup$ I'm still fuzzy on exactly what you're trying to point to, in specific, so it's hard to recommend further reading because these are huge topics with tons of available literature. The overall binding/modeling/implementation/solving pattern is common throughout many fields, including most of the sciences, engineerings, medicine, business, constructed maths/logics, etc.; probably lots of reading out there you may enjoy. $\endgroup$
    – Nat
    Sep 1, 2020 at 0:54

1 Answer 1


Effective procedure.

An effective procedure is an executable specification of an abstract model.

Effective procedures can take the form of actual software you run on your computer, or they can be abstract software you run on an abstract computer. Either way, they're more imperative in nature, specifying a procedure that can be performed, rather than merely a constraint-based description of a model.

You might also be interested in:

  • $\begingroup$ Your answer gives a glimpse of the fact that there are layers of modelling, from the problem as described in the real world to something that actually runs on a computer. I've now elaborated on at least one possible layering of models in my question. Your term "effective procedure" seems to straddle: (1) my "algorithmic model" and (2) pseudocoding in planning the design of my "exectuable implementation". $\endgroup$ Aug 30, 2020 at 18:24
  • $\begingroup$ As such, it doesn't quite draw the distinction that I'm looking for. I'm beginning to wonder whether my distinction is particular to operational analysts who map real world problems to known algorithmic models rather than mathmeticians who push the boundaries of those algorithmic models. It would be helpful to find an articulation of this particular distinction between analysis model an executable implementation. $\endgroup$ Aug 30, 2020 at 18:24
  • $\begingroup$ @user2153235: You're asking about pretty simple stuff, so there's probably a common term for what you're trying to refer to. It's just hard to tell what you're trying to say because some of the basic terminology seems missing. $\endgroup$
    – Nat
    Aug 31, 2020 at 19:48
  • $\begingroup$ @user2153235: Since the terminology seems a tad sketchy, I'd recommend keeping it simple. Perhaps describe a hypothetical scenario where Alice starts from a basic problem and finds a solution, going through all of the steps? Then once that basic example's laid out, you could ask what a specific section of it's called. $\endgroup$
    – Nat
    Aug 31, 2020 at 19:50
  • $\begingroup$ Thanks for the suggestion. I added some detail to the Annex of the question to illustrate the stages of the problem modelling. $\endgroup$ Aug 31, 2020 at 22:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.