In his 1985 paper entitled “Programming as Theory Building”, renowned computer scientist Peter Naur argued that you cannot truly understand what a computer program does by merely looking at the source code of the program. In Naur’s view the program is merely an implementation of a deeper set of axioms, beliefs, and understandings… a theory… which is more deeply held directly by the programmer. To understand the program, you have to understand the thinking of the programmer, who in turn is informed by externalities which provide the impetus to create the program in the first place.
This section of documentation attempts to capture the axioms, beliefs, and understandings motivating the implementation of the Muse Systems Business Management System. This content should not be viewed as necessarily establishing functional requirements or specific implementation plans, though such project artifacts will express the ideas written in this section as tempered by practical reality. In addition to establishing a “theory” for our system, we also hope to provide learning materials for those that might work with this system who might not have an extensive background in working with this class of business systems.
Most business system documentation is organized along the lines of typical business operations and departmental structures, however our organization of topics in this discussion of theory departs from these conventions. Because we’re dealing with these topics on a conceptual level rather than an operational level we’re organizing our content along these conceptual boundaries. Naturally systems design and documentation dealing with the daily use of these systems is best organized in the traditional, operationally focused way.
Finally ideas presented here should not be considered a formally researched collection of business system implementation practices. These ideas originate in the practical, real world experiences of the author. As such they are anecdotally motivated. This isn’t to say no research was conducted or that practical experience cannot lead to useful knowledge, but that the information in this documentation would not be considered academically rigorous. The focus here is on developing a working, practical model for a system used by real businesses rather than trying to write a paper for academic consumption.
In the course of describing the ideas which drive the design and development of our business management system, there are certain concepts and knowledge needed to establish a baseline understanding and a scope for our project. In this section we explore these ideas to ready the reader for later discussions.
Business transactions are always carried out in a context of the involved parties, the locations and jurisdictions, and the date and time of transaction consummation. By describing in detail the Business Relationships of the parties and places involved in a transaction, we can establish terms, rules, and requirements to which business transactions must adhere.
While our Theory focus is on the business practices and processes which business systems are intended to facilitate, there are nonetheless technical issues at a theoretical level that is proper to address in this documentation. Ideas of information organization, processing states, and similar concerns are all part of our Theory.