Business Simulation Data Architecture
An exploration the technical aspects of business simulation data architectures - why they are important, benefits and examples.
Home > Platform > Data Architecture
Having been involved in information system design with both GE and Honeywell and the author of two books on Data Processing I recognise the importance of data centric software architectures and so when I developed my business simulation software architecture and created my platform I ensured that my business simulations were driven by data from a series of databases and data files as this speeded development, improved quality, provided for customisation and multiple versions. Below are the files (data-bases) used by my simulations.
Either scroll down for or click on the diagram above to jump to more information
Right from my very first business simulation-game EXEC Management Game System 1970) I held the data and parameters used by the simulation models in files separate from the models and other software.
EXEC Management Game System Architecture (1970)
My Data and Parameter Database consists of a series of records that stores the variable's text, format, the associated data and, if appropriate, a link to a help record explaining the variable. Besides storing variables, the database also stores market, resource and product names etc.
My standard database consists of six data arrays - three cover parameters (economic, markets and resources/products) and three cover team/period data (financial/operations, markets and resources/products).
Holding data and parameters in files allows the simulation to journalise data. This means that as the simulation progresses a file is created for each period, allowing a past period to be rerun to correct for decision errors or hardware problems.
Placing data and parameters in a separate file rather than spreading them through the model (as magic numbers) prevents data existing in several forms in the model and ensures that when variables are changed during calibration they are all changed!
The iterative-incremental, emergent design process means that variables are added throughout model design and this is speeded by adding the variable to the file and, during customisation, it is much quicker to go to a single entity rather than searching for the datum across the simulation model code.
Holding data and parameters in an editable database means that it easy and quick to customise a simulation when one wishes to have different product/market names and financial terminology. Changing variables is slightly more time consuming but still reasonably quick and easy. Also, one does not need to search for individual variables across a large model and (hopefully) change all!.
Commonly one needs several versions of a simulation to meet differing learning needs, participant capabilities, manner of use and business terminology. For example, most of my simulations have "English" and "American" versions, implemented by having an English Data and Parameter database and an American Data and Parameter database.
Gathering and clearly documenting all the variables together in one place means that the maintenance, extension, revision and modification of a simulation is quick and easy.
Reports and Decision Entry Templates are defined in the Reporting/Decision Database for use by my Reporting Engine create and populate reports and decision forms.
A report definition (record) consists of the report name, a link to a help record for the report, the report type and what data is to be displayed (parameter list). Besides defining reports, the Report File stores information that tells how the Simulation Manager how to control the way the simulation evolves and progresses, how reports and decisions are grouped. Overall there are nearly fifty report types but there is the opportunity to increase the number of report types.
As with the Data and Parameter database defining reports and decision templates in an editable database allows you to have multiple versions so that the simulation meets your exact needs. For example, commonly I provide my business simulations in several versions - "classic" (a basic, simple simulation), "progressive" (where new reports and, often, new decisions are introduced as the simulation progresses), "compleat" (a complex version) and "assessment" (where there are special reports for assessment centre assessors) - versions that have different reports and decisions that are defined in the database.
Speedy Development, Customisation & Maintenance
Adding or modifying reports and decision templates is a major need during development, customisation and maintenance. Defining these in a database means that all that is required is to change or add a record - something that takes a minute or so.
Unlimited Reports and Decisions
The number of records in the Report/Decision database depends on the complexity of the simulation and the number of versions. For my simulations they range between 38 and over 200. Between 1970 and 1995 I had to hard code decision templates and reports in the model the time taken to do this caused an economic limit to the numbers.
Learn More about the Report Database and the Report ;Engine
During the 1970's and to a greater extent during the 1980s I introduced textual comments to provide qualitative feedback about decisions, strengths and weaknesses, highlight issues and provide statements from staff, customers, bankers etc. By having the simulation generate these comments I automated reflection triggers, provided clues to the links between decisions and results, flagged unusual or radical decisions helping both the tutor running the simulation and its participants.
Initially, comments were hard coded in to the simulation model. However, as the number of these comments increased and I had the need to internationalise my simulations (provide different language versions) I moved the comments in to a separate database. Each record in this database stored the comment's text, parameters that controlled when it is displayed and a help record link that provided a detailed explanation. Placing comments in a database meant that I could increase the numbers from a dozen or so to several hundred.
In the early 1990s, larger PC memories coupled with Hypertext meant that I could start to embed in my simulations a context sensitive help system. A system that helped with software use, provided advice about the current task, explained (delineated) variables and reports and, optionally, provide an on-line manual. The help database consists of a series of records (pages) each with a heading and the help text. It is possible to embed in the help texts hyperlinks to other pages, sound and pictures. Part of the Help Database contains standard information about the simulator with the rest specific to the simulation. Typically, the Help Database has several hundred records.
Learn More about the Help Database and the Help Engine
In order to use a business simulation with different groups of learners, with different of learning objectives, in different ways and different languages requires the simulation to exist in several versions. For each of these a separate control file defines which databases are used, what decisions are made and reports produced, printing options etc.
The Version File contains a list of Control Files to allow the tutor to select which version to use. Below is an example of a versions menu showing different versions with different learning needs and for two different languages.
These store standard data that is used by the simulator (rather than the simulation model) - data that is commonly used in several places in the platform and by several platforms. Storing these in a file and using flags (constants) in the code to reference is standard software design practice as it eliminates the need for magic numbers and allows the platform to be localised to a foreign language.
Most recent update: 20/07/15
Hall Marketing, Studio 11, Colman's Wharf, 45 Morris Road, London E14 6PA, ENGLAND
Phone +44 (0)20 7537 2982 E-mail email@example.com