Business Systems Theory

• 1: Prerequisite Understanding
• 2: Business Relationships
• 2.1: Entity
• 2.2: Person
• 2.3: Place
• 2.4: Relationships
• 2.5: Entity/Entity Relationships
• 2.6: Entity/Place Relationships
• 2.7: Person Roles
• 3: Technology Design Principles
• 3.1: Information Architecture
• 3.1.1: Data Organization
• 3.1.2: Business Relationships

1 - Prerequisite Understanding

What is a Business System?

The phrase “business system” can refer to any computer system supporting business operations, but here we mean it to be something very specific: a system used to coordinate business activities across different operating units of a company or corporate division and to record the results of those activities.

Historically such systems have been called “Enterprise Resource Planning” (ERP) systems. This term is still used broadly today, but we’ll not use this term in our documentation. ERP systems are widely viewed negatively and with good reason: companies building and implementing ERP systems offer sprawling, labyrinthine applications that are difficult to configure and operate, are sold with expensive professional services implementation engagements, and often times are sold on false promises of seemingly effortless benefit. While some of these realities of ERP system adoption are unavoidable, others are simply the result of low quality offerings designed to maximize software and service profits without incurring the expense of developing higher quality products.

Our position is that there is real value that can be extracted from a business system implementation so long as the offering is built understanding business realities and that the staff tasked with incorporating these systems into their business operations understand the system realities and the related trade-offs of utilizing system functions and features.

The Obvious

Adding detail to our initial definition of “business system”, we can describe what business system software is in terms that will be familiar to those that use it on a daily basis.

Business systems coordinate and record business activities through the entry of “transaction documents” (transactions) into the system. These transactions record the activities of typical business functional areas:

Internally Servicing Departments

Operating Departments

Naturally, the lists above can be constructed differently, at different granularity, or using other organizing principles but the gist is that all these different areas of the business can be operated from a full featured business system. Implicit in running in a common system, and a benefit of so doing, is that cross-functional activities can be coordinated and reported on without having to create ad hoc processes to do so; the business system provides the framework for collaboration and reporting across all of the business’s units.

Three Fundamental Goals

Looking beyond the individual features that are offered by typical business systems, such systems can be reduced to three principle activities or functional areas of concern:

Accounting

The accounting function is geared toward reporting on the financial outcomes of the business’s activities, ensuring that those activities were conducted in accordance with the company’s policies, and are recorded accurately.

The primary product of the accounting function is the corporate financial statements prepared for investors, lending institutions, and regulatory/taxing authorities. To ensure that financial statements are accurate, and to limit risks to the business, controls are established regarding which members of staff may conduct business on behalf of the company and dictate the standards to which business transactions are recorded. Finally, reconciliation and audits of the business records and financial statements are conducted to find errors or unauthorized transactions.

Importantly, this is the domain of financial accounting were the accurate recording and reporting of information is done under the auspices of the professional accounting standards (i.e. the Generally Accepted Accounting Principles or the International Financial Reporting Standards) or according to the rules of the pertinent regulatory or taxing authorities.

Business Operations Support

Supporting business operations involves maintaining records of business relationships and entities (in the general sense), process automation, and facilitating business communication between staff members internally and with business partners externally.

Initially and on an ongoing basis staff will create lists of entities in the system which are pertinent to business operations. Entities may include relationships such as vendors and customers or other kinds of entities such as products or company facilities. These entities will then be used to standardize the recording of business transactions in the system.

Transaction processing from the business operations perspective is principally focused on managing the life-cycle of the transactions. A sales quote may eventually become a sales order which in turn will need to be fulfilled or it may be cancelled or the product eventually returned for some reason. This all has bearing on what actions must be performed by staff. Reviewing transactions in the system can indicate to staff what work must be done or is no longer needed.

As transaction processing moves through the business system, the system can centralize and facilitate communication across operating departments and even with relevant third parties. In our sales example from the previous paragraph, a shipping department may record that a product on the sales order is not available which the sales department will be able to see; the sales demand from the order may cause an automatic purchase order for the product to be placed with the appropriate vendor.

The information consumed by staff performing business operations work will tend to be granular to a specific process, activity, and/or location, will be produced for relatively narrow windows of time, and may consist of representations of financial data which may conflict with similar reports generated for purely accounting purposes. For an example of operational/accounting information disparities we turn to a retail industry scenario. A common operating procedure in physical retail stores is to reconcile the cash receipts and sales processed by each cashier at the end of their shift. During this process, from the operational perspective of the cashier, the regular sale of products and the “sale” of store credit in the form of “gift cards” is often simply considered “sales” for which the cashier is responsible despite the fact that only the sale of products are “sales” from the accounting perspective; from the accounting perspective “gift cards” are to be recorded as liabilities and reported as such. That store staff performing cashier reconciliations will conflate sales and liabilities during the checkout procedure is completely understandable however: the revenue/liability distinction doesn’t change the amount of customer cash taken and for which the cashier is responsible. Worrying about the accounting distinction while closing out the cashier’s shift will only serve to complicate that business operations process without adding any benefit aside from reporting consistency.

Analytics

Information collected in support of business operations or for accounting can be used to gain deeper insights into the functioning of the business relative to the planning of managers, may be used to uncover opportunities, or expose risks. The range of analytics can cover anything from the basic regular reporting of key performance indicators to more advanced trending and statistical analysis of operations.

Analytic reporting is in the domain of management accounting practices. Representations of financial information may depart from those of financial accounting and the financial statements. For example, many manufacturing businesses use the Standard Cost methodology of inventory item costing which uses projected costs for items and inventory analysis rather than costs derived from actual transactions; this is helpful for understanding variances from the planned costs of manufacturing, but is not allowed for valuation purposes by any of the financial accounting standards.

Also unique to the analysis area of concern is the greater importance of long range concerns. Analysis of results and projects may well include multiple years of past results or project performance into the distant future. Accounting and business operation concerns, however, are usually much more immediate and sensitive to current conditions.

User Intent

When a user sits down to use the system, they are typically doing so in service of only one of the three areas of concern described above. This isn’t to say that an individual staff member will only ever be interested in a single area of concern, but rather that any one task to be completed will focus on a single area of concern.

Therefore any given feature of a business system or information product that system produces will typically be designed to support the needs of a specific area of concern so that a user’s task may be completed as efficiently and clearly as possible.

Presentation

Because business system functionality is likely to be facilitating a specific user task within a specific area of concern, the system needs to present its interface and results in way that makes it clear what the scope, applicability, and limits of the function or result are while maintaining clarity. This can be a difficult balance to achieve, but it is essential for success.

2 - Business Relationships

2.1 - Entity

General

An Entity can be any organization, company, government, or individual which can legally enter into a contract and with whom business is transacted.

Ideally, each relevant real world entity only has a single representation as an Entity. Any nuance or multiplicity of roles should be expressible via the Entity’s Relationships.

Individual Person as Entity

An individual, real world person may also be described as an Entity. When this is the case the individual will most often also be a Person with a Relationship to the Entity indicating that the individual acts as their own agent. Other People may be granted Relationships to the Entity so that these others may act as agent on the Entity’s behalf (lawyers, assistants, family, etc.); it is even possible that the individual represented by the Entity does not act as their own agent and therefore isn’t recognized as a Person with a relationship to the Entity, though this would be rare.

Notes on Perspective

Throughout the Business Relationships section we’ll be referring to different Entities from the perspective of one working within a specific company or organization. A “first party Entity” or “primary Entity” therefore would be our company or organization and an “external Entity”, “second party Entity”, or “third party Entity” would be some other Entity from our assumed perspective. When we speak in terms of business systems, the first party Entity will be the one whose staff would be using the system.

2.2 - Person

General

While it might seem obvious what a “Person” is, we’re going to augment that assumable definition a bit here. A Person, for our purposes, is someone who acts as an agent on behalf of an entity; the designated contact for any communications regarding some aspect of business that the Entity may engage in.

Person as Functional Designation

A Person will often times be a named individual in the real world, but there will be times where a Person represents a role that might be fulfilled by any of a group of people; for example, an “Accounts Payable” Person representing a vendor might mean that any one of the vendor’s Accounts Payable staff may act as the accounts payable agent during a discussion of invoicing or payment. In such a case the specific individual doesn’t matter, but still has all the previously discussed traits of a “Person”.

Contact

“Contact”, as we use the term here, refers specifically to how a Person is contacted. This can include designating email addresses, telephone numbers, messaging application IDs, and physical addresses such as mailing addresses as being means by with to contact a Person.

Any one Person may have a variety of different applicable Contact methods, though typically there will be preferred or default methods of contact.

2.3 - Place

General

While it might seem sufficient, from the business systems perspective, to simply identify an address, the idea of Place in business applications go well beyond describing its location. Places designate where business personal property is located (e.g. product inventories & fixed assets), they are associated with coarse grained capacities for work, they establish the dates/times of transactions, and they allow controls for transaction processing and controls for the people working from such Places.

Importantly the designation of a Place of business is also a statement of the legal jurisdictions under which business is conducted, commonly establishing the legal, regulatory, and taxation requirements of that business at that location.

2.4 - Relationships

General

For our purposes, a Relationship describes how any two Entities/People/Places interact with each other during the conduct of business or for which recognition of the Relationship can aid in performing analysis of business data. In addition to the actors involved in a Relationship, we also limit the scope of any single Relationship to some specific area of business concern or purpose.

A well defined Relationship describes the terms, conditions, and understandings of the two parties involved in the Relationship when transacting business in the subject area of the Relationship.

Refined Definition

More specifically, a Relationship as defined in our model is the uni-directional Relationship of a Subject to an Object. A Subject is the first party Entity, Place, or Person. The Object is the second party Entity, Place, or Person. The Relationship between the Subject and Object indicates a Relationship of a specific business nature or “kind”. We can therefore say: the Subject has a Relationship of a certain kind with the Object.

Consider an example Relationship where “Our Co.” sells products to “Their Co.”. In this case “Our Co.” would be the Subject (seller) , the Relationship in question would be a Sales Relationship, and the Object (customer) in the Relationship would be “Their Co.”.

We can see that both Subject and Object have well defined and distinct roles relative to the Relationship. It should also be obvious that even though “Our Co.” sells products to “Their Co.”, it doesn’t necessarily mean the reverse is true and thus the Relationship is uni-directional; if “Their Co.” also sold products to “Our Co.”, we would have to acknowledge that as a different Relationship that was parallel to the Sales Relationship described above.

Subordinate Relationships

Defined Relationships between Entities/People/Places can also act as either the Subject or Object of a secondary or “Subordinate Relationship” in some cases.

To illustrate this let’s consider a different hypothetical scenario where “Our Co.” buys products from “Their Co.” This would constitute a Purchasing Relationship where the Relationship Subject (buyer) is “Our Co.” and “Their Co.” is the Relationship Object (vendor).

For a variety of reasons, some businesses sell their accounts receivable to a kind of third party company known as a “factoring company”. The factoring company will buy the accounts receivable of the vendor at a discount, generally speaking, and then the factoring company receives the full payment from the customer and accepts the risk of non-payment by the customer.

Let’s extend our Purchasing Relationship scenario such that “Their Co.” sells their accounts receivable to “Collect Co.”, a factoring company. In this case, while “Our Co.” will purchase products from “Their Co.” under the terms established by the Purchasing Relationship, when “Our Co.” pays the invoice for the product, they’ll pay it to “Collect Co.”

This is where the Subordinate Relationship exists. The Purchasing Relationship itself now extends to a third party for a narrow, but important aspect of purchasing. We can allow for this in our model by defining a “Payables Relationship” between the Purchasing Relationship (Relationship Subject) and the Entity “Collect Co.” (Object Relationship).

We wouldn’t directly establish a Relationship between “Our Co.” and “Collect Co.” because the Relationship is unique to the Purchasing Relationship between “Our Co.” and “Their Co.” and isn’t generalizable beyond that Purchasing Relationship, even if other “Our Co.” vendors use the same factoring company.

Roles

So far we’ve discussed rich Relationships in which the description of the Relationship itself requires us to specify the nature of the Relationship’s terms, conditions, and understandings in addition to recognizing that the Relationship exists. But not all Relationships need to be thought of in such detail. Some Relationships are simple enough that we can just recognize that the Relationship exists without greater embellishment. In our mental model we’ll use the term Roles to refer to Relationships which are of this simple variety.

Most frequently Roles will relate Subjects made of Entities, Places, or rich Relationships to People acting as Relationship Objects. These Roles can be simple because their full meaning will require contextual inferences from the Subject of the Role. For Example, a Purchasing Relationship may require us to know who our account manager is with our vendor.

Simultaneity

Because we limit the scope of our Relationship and Role definitions to a single purpose, we should expect that between any two Subject/Object actors, that multiple Relationships may exist between them at the same time. Less common, but still feasible for some kinds of Relationships is the possibility for more than one Relationship of the same kind to exist.

• A Subject Entity may simultaneously have a Sales Relationship with an Object Entity in some transactions while having a Purchasing Relationship with the same Object Entity in other transactions.

• An Object Entity representing a large company or organization may have divisional or departmental purchasing organizations which act fully independently. Each of these divisional purchasing organizations may also have their own, independent Sales Relationship with the Subject Entity as the terms, conditions, and people involved in transactions may vary across the Object Entity’s divisions.

2.5 - Entity/Entity Relationships

Entity to Entity Relationships, individually, are directional meaning that the “first party Entity” has a specific, but different role in the Relationship as compared to the role of the “external Entity”. These roles are not reversible and therefore we say the Relationship is directional.

Relationship Kinds

There are many ways to divide Relationships into categories of like kinds, but for our purposes we’ll define the top level of Entity/Entity Relationship kinds as follows:

Sales

A Relationship where the first party Entity is the seller and the external Entity is the customer in sales related transactions.

• Subordinate Relationships

  • Accounts Receivable

• Person Roles

  • Fulfillment Recipient

  • Accounts Receivable

  • Customer Agent

Purchasing

A Relationship where the first party Entity is the buyer and the external Entity is the vendor in purchasing transactions.

• Subordinate Relationships

  • Accounts Payable

• Person Roles

  • Accounts Payable

  • Account Manager/Sales Representative

  • Shipping

Employment

A directional Relationship where the first party Entity is the employer and the external Entity is the employee/contractor/etc. In this case the external Entity is also an individual person.

• Person Roles

  • Emergency Contact

Banking

A directional Relationship where the first party Entity is the consumer of banking services and the external Entity is a bank, lending institution, brokerage, etc. Banking Relationships are usually used to facilitate the creation of banking related ledger accounts rather than to facilitate the processing of specific transactions.

• Person Roles

  • Account Manager

  • Payments

  • Receipts

  • Support

Ledger

A directional Relationship where the first party Entity is a parent company and the “external Entity” is a subsidiary company such that the subsidiary financials are consolidated into the financial reporting of the parent Entity.

Tax Authority

A Relationship where the first party Entity is the tax payer and the external Entity is the government agency to whom taxes are paid.

• Person Roles

  • Remittances

  • Support

2.6 - Entity/Place Relationships

Entity to Place Relationships may be recognized between any Entity and any Place. In fact, any one Place may have Relationships with more than a single Entity. Consider the example of “third party logistics”, where the first party Entity may locate their inventory in an external Entity’s warehouse; in this case the warehouse is under management of the external Entity, but the first party Entity owns, manages, ships/receives, and accounts for inventory at that warehouse. Under our model the warehouse is a single Place and the Relationships with different Entities inform our understanding of the complete picture.

Relationship Kinds

Different kinds of Entity to Place Relationships inform us about which Entities have legal responsibilities in regard to the place, the people we will find at the Place and why they are there, and the tangible personal property that is stored at the place.

More formally we define this as:

Management

This Relationship indicates that the Entity in the Relationship has a management responsibility for the Place. This Relationship may be indicative of the Entity being in an ownership role, as the legal occupant, or merely having a facilities management responsibility for the Place.

• Subordinate Relationships

  • Lessor (to Purchasing Relationship)

  • Tenant (to Sales Relationship)

Staffing

The Entity in the Relationship will employ staff at this Place. This kind of Relationship allows the Entity to manage staffing levels, rules, and legal requirements related to employing staff at the Place.

• Subordinate Relationships

  • Staff Member (to Employment Relationship)

Inventory

The Entity in the Relationship will own units of inventory items at the Place. This kind of Relationship implies a Place related boundary which may delineate financial inventory control, inventory availability for use in manufacturing or directly consumed, or inventory available for fulfillment needs.

It is plausible for Entities to have more than a single Inventory Relationship to any single Place. For example, the Entity may differentiate between units of items that have not been inspected vs. those that have or the Entity may wish to segregate inventories available for distribution, those available for consumer sales, or even rental inventories.

2.7 - Person Roles

Person Relationships are different from the Relationships discussed thus far in that they tend to exist as Simple Relationships or “Roles” where acknowledging that the Relationship exists is sufficient for understanding it.

There are many different kinds of Person Relationships possible and many of the possible Relationships are ad hoc and specific to a given company’s business practices. Given the multiplicity of Roles that can exist, we’ll not try to list the various typical Person Roles, but rather provide some examples to firm the conceptual understanding of Person Roles.

• For Places, Person Roles might include “Facility Manager”, “Maintenance Manager”, or “Shipping Manager”.

• For Entities, Person Roles may include “CEO”, “Reception”.

• For Sales Relationships, Person Roles may include “Purchasing Manager”, “Buyer”, “Support”

Clearly most of these Roles are simply clarifying which Person to contact in specific scenarios which is why these Relationships can be expressed as simple Roles. The Entity/Entity Relationships and the Entity/Place Relationships provide the rich context required for understanding the defined Person Roles.

3 - Technology Design Principles

3.1 - Information Architecture

Data is a first class concern for our overall approach to business management system design. We predicate this elevation of importance on the following assumptions:

• The business management system database will be the system of record for the majority of material business records. This may be on a company, divisional, or departmental basis.

• Third party applications will need to consume data and may produce data which properly is recorded in the system of record database. There may be many such applications.

• We expect that the third party reporting and business intelligence tools will be used to provide specialized presentations and insights into the data.

• The business management system we build may be subordinate to more fundamental business management system which acts as the system of record. This will likely be true if our application is only supporting a division or department of a larger organization.

In all of these cases we’re describing scenarios where our business management system is planned to be part of a larger ecosystem of collaborating applications. This is called the “best-of-breed” approach to business systems architecture and is common feature of enterprise applications deployments.

3.1.1 - Data Organization

Principal Classifications

Most broadly speaking, our basic data breaks down into “business domain objects”: the records defining customers, products, warehouses, etc. which the application users maintain as needed; and “transactions” records: the recorded actions which are taken by the business referencing the business domain objects. We can refine these broad definitions further.

Master Data

Master Data are relations which enumerate business domain objects along with the attributes which configures each object for use by the system. The Master Data establishes the definition of the business domain object in the system. Examples of Master Data include relations defining Entities, Relationships, and Products.

The primary trait of each Master Data record is that it represents information which is true “now”, meaning in the current moment. If the business domain object represented by a Master Record changes, such as a customer changing its mailing address, the Master Data record is changed to reflect the new reality so that at any given moment a Master Data record represents the authoritative definition of the specific business domain object being described. When the Master Record changes, there is no sense of history kept; the record behaves as if the updated data was always the data.

Master Data records have life-cycle stages which determine how they can be used by the system. These stages can be generalized as:

• Preliminary Planning

  In this stage the record exists, may be needed for certain longer range planning usage, but isn’t available for regular transaction processing or reporting. This life-cycle stage indicates future intention.

• Regular Use (Active)

  Records in this stage are actively used in daily business activities and reporting.

• Obsolescence

  Over time, some records will represent specific business domain objects which are planned to go out of use. As that time approaches, certain transaction processing should cease (e.g. purchasing transactions), while others remain available as the Out of Use stage approaches.

• Out of Use (Inactive)

  At the end of the Obsolescence stage, the record is not available for use in regular transaction processing. The record will still be visible to business users as there is expected to be historical/reporting relevance.

• Purge Eligible

  Once the record is no longer referenced by prior transaction histories, the record may become eligible to be deleted from the database outright. It is important to reiterate that any existing transaction history referencing the record should prevent this stage from being reached to keep the data integral.

While all Master Data follows these general stages, any specific Master Data record or relation may only do so informally within the business nor will the business management system always have well defined recognition of these stages. The business management system may provide alternative stage names, subdivide the stages, or allow the definition of the recognized stages to be configured as suits the specific purpose at hand. In all cases however, the stages as listed are the functionally distinct stages which will matter during the course of executing application logic.

Because Master Data records are reused during the course of multiple business activities, Master Data relations will constitute significantly less of the overall application data retained when compared to other kinds of data. Record counts may be low, in the tens of records, but may commonly be in the thousands of records. It is feasible, though rare, for some Master Data relations to grow into the

Supporting Data

Supporting Data relations carry records which exist to support other, more fundamental, kinds of data such Master Data or Transaction Data. Supporting data is Master Data-like in that the records also posses the Master Data primary trait of being a representation of the present state of the Supporting Data.

Supporting Data comes in some basic sub-types:

• Simple Enumerations

  Most (if not all) business management systems use “lists of values” to provide predefined acceptable values used by attributes in our primary data records. Examples of these Simple Enumerations include, lists of available order statuses, approval process states, and product categorization.

  It is not uncommon for business management systems to allow many of these Simple Enumerations to be configured, as needed, by the user as current business requirements dictate. While user management of Simple Enumerations suggests the possibility of life-cycle stages, most often the business management system mandates that all values existing as records of the Simple Enumeration are considered “Active” and the records are simply deleted when no longer of use. Naturally, systems which recognize all existing records as “Active” should only allow for the deletion of Simple Enumeration records when such records are no longer referenced.

• Quantitative Data

  For certain Master Data records, it can be convenient to track summarized Quantitative Data. Consider the simplified example of a Master Data relation defining products sold from a single warehouse. While the Master Data records for a product will define the configuration of the product, there is also Quantitative Data such as how much quantity on hand of the product is currently present, the value of the product on hand, etc.

  Any one Quantitative Data record will always correspond to a single Master Data “parent” record. This data could be stored in the same relation as the corresponding Master Data, and in some business management systems it is. However, there can be technical considerations for storing this quantitative data separately using Quantitative Data relations. Quantitative Data tends to be updated much more frequently than the corresponding Master Data; this can give rise to lock contention in the database due to the competing uses. In addition Quantitative Data usually consists of a small number of numeric fields taking much less space per row than the corresponding Master Data, which can have many more fields including text fields; since updating a row causes the copying of all row data, we can be more efficient by separating our frequently changing data from our infrequently changing data.

  Quantitative Data doesn’t express any sort of life-cycle stages. Any Quantitative Data record will assume the life-cycle stage of its corresponding Master Data parent record.

Supporting Data retention needs are of trivial concern in the broader context of the application as a whole.

Transaction Data

Transaction Data relations describe specific instances of business activity. Examples of Transaction Data include sales orders, order fulfillment and shipping, customer and vendor invoices, and customer support tickets. Transaction Data records depend on Master Data and make use of Supporting Data to describe these business activities.

The primary trait of Transaction Data is that each Transaction Data record represents an instance of a business activity which is finite in time. While the business activity is underway, the Transaction Data records allow for the coordination of the business operations required to execute the business activity. Once the business activity is concluded the Transaction Data acts as a historical reference as to what business operations were performed, to provide data for later analysis, and the support the resolution of any later disputes that might arise related to the performance of the business activity.

Transaction Data has a generalized life-cycle consisting of the following stages:

• Preliminary Planning

  During this stage, a Transaction Data record is being authored, awaiting approvals, or otherwise not yet actionable. During this time the Transaction Data record is not generally visible to business operations or involved third parties.

• In Progress (Open)

  Once all preliminary work is completed the Transaction Data record may be opened and made visible/usable to the various business operations, including third parties if appropriate, that will work the transaction to completion. Arriving in this stage may be given a number of names: “opening”, “releasing”, “posting”, etc. they all indicate that the Transaction Data record is actionable.

• Cancelled

  Certain kinds of opened business activities may be terminated prior to successful completion. When this happens the Transaction Data record is no longer actionable and becomes part of the historical record, but only insofar as unsuccessful activities are concerned.

  Note that this ending stage is only appropriate for business activities which never reached any state of completion. Some business activities may be partially successful, for example a sales order which shipped 5 out of 10 units of an ordered item. All business activities which are partially completed prior to termination are, for our purposes, not considered cancelled.

  At the point of being Cancelled, the Transaction Data record should be considered immutable, except for the possibility of deletion once the record is no longer useful for reporting or analytics.

• Closed

  Upon the successful, or partially successful, completion of a business activity, the associated Transaction Data record will be considered “Closed”. Closed transactions are not eligible for further business operations to be performed and the Transaction Data becomes part of the historical record for analysis and reference purposes.

  Closed Transaction Data records may be referenced by new, related Transactions. For example a closed sales order reference may be required to process a new customer return transaction.

  At the point of being Closed, the Transaction Data record should be considered immutable, except for the possibility of deletion once the record is no longer useful for reporting or analytics.

  Exceptions to Closed Transaction Immutability

  For a variety of reasons, some good and some bad, many business management systems support the idea of re-opening previously Closed transactions for further business activities to be conducted. However, in principle Closed transactions should be considered final and we will adopt this as an axiomatic assumption in this documentation.

• Purge Eligible

  Transaction Data records may be purged when their history is no longer relevant to supporting business reporting or analysis. Such records may be set as eligible to be purged by any process or batch job which runs to delete the records from the database. The conditions which allow Transaction Data records to become Purge Eligible are:

  1. Either already in the Preliminary Planning, Closed, or Cancelled life-cycle stages.

  2. Are not referenced by other Transaction Data records which are not themselves Purge Eligible.

  In practice, Transaction Data in the Preliminary Planning and Cancelled stages have little barrier to being purged from the system, but Closed transactions will usually have time based constraints on Purge Eligibility; detailed Transaction Data must be retained for various periods of time to support financial and tax audits and for reference when communicating with different business partners.

Transaction Data constitutes the majority of the data retained by the application. Care must be taken in structuring and managing this data at the database level to ensure acceptable application performance in operations, reporting, and analytics. Transaction Data relations can reach into the billions of records for the class of application contemplated here.

Secondary Classifications

There are some classes of data which exist for technical reasons and/or are optional components which are not essential to business management system operations.

Analytic Data

Analytic Data exists to facilitate reporting and analytic workloads. The Analytic Data consists of summarized Transaction Data with some facts drawn from the Master Data. In terms of structure, Analytic Data resembles typical data warehousing tables which serve the same purpose.

The goals of Analytic Data in the business management system includeL

• Allowing for the long term reporting of otherwise Purge Eligible Transaction data.

• Providing the means to reporting contextually relevant Analytic Data within the user interface of the business management system. Examples might include monthly customer sales on a customer form or weekly sales of items on an item form.

It is not a goal of business management system Analytic Data to make proper data warehouses and analytic tools unnecessary. Maintaining Analytic Data in the transaction processing system does come with database and application performance penalties. Taking in-application Analytic Data too far risks overall application usability; choosing what Analytic Data should be available in the application must be done with care.

When Analytic Data doesn’t enhance the normal transaction processing functions of the application, but may still be of analytic value within the business, a data warehouse solution with the appropriate reporting tools should be considered.

Analytic Data may constitute a significant portion of the overall data retained in the database, but should still be smaller than the Transaction Data (assuming the limitations on Analytic Data capture previously discussed).

System Data

There is a need to retain certain data simply to facilitate the technical operations of the business management system itself. This is the role of System Data. System Data can include relations for system oriented configurations and relations that exist to manage user logins or auditing.

Typically System Data will consume an insignificant amount of data storage space.

3.1.2 - Business Relationships

Historical Perspective

When working within a company, it is not uncommon to think about “our customers”, “our vendors”, “our partners”, and “our employees” as though these are specific kinds of distinct entities. However these terms are not describing classes of entities, but are describing relationships that exist between two entities, our company (an Entity in its own right) and the external party. This distinction between thinking of a “customer” as an entity vs. thinking of the “customer” as a relationship is subtle, but appreciating the nuance of the distinction can lead to important insights in how we might build business management systems.

Understanding the history of modelling business relationships can inform our approach to Business Relationships and allow for capabilities which more representative models bring.

Early Models

Many early business management systems were designed using the naive, but common sense approach of representing customers, vendors, etc. as specific kinds of entities. These systems would implement each kind of entity with different kinds of records (tables) in the system:

This works well enough in most cases, but the real world is more complicated than this model allows. For example a single external company may be a customer in some transactions, but also a vendor in others.

Under the early business systems model you would have to create two records to handle a situation like the example just discussed, one for the external company as customer and one for it as vendor; including duplicating all of the common attributes such as company name, addresses, etc. But maintenance of duplicated data is only one of the practical issues that arises out of this model. Representing single, external companies with multiple, unrelated records in the business system also partitions the knowledge of the complete relationship with the external company. The only way to create the complete picture in a such a system is to know outside of the system that the relationship with the external company is multi-faceted and to run independent (or specially constructed) reports to combine outside of the system.

Recent Models

While these complex relationships with external companies are not the most common scenario, they happen frequently enough that business systems evolved an improved model of business relationships. The updated model represents the external company as an Entity in the same sense that we defined in the Business Relationships section while associating it with a record which represents the relationship:

This recent model much more closely matches the reality of business relationships found in the real world and is probably the most common model adopted by currently popular business systems.

Many older business systems which were originally designed using the early model simply tacked on the “Entity” record type and linked it to the preexisting records representing entity classes. In these cases the business system typically only allows a single customer/vendor/etc. relationship to be defined for any single Entity. However in practice, though rare, there exist scenarios where a single, large external Entity can have multiple, simultaneously active Relationships of the same kind with the first party Entity; this happens when the corporate structure of the external Entity is organized into substantially independent divisions or departments. This forces the users of these systems to create Entities representing the divisions/departments independently; naturally incurring the cost that a full view of the Entity is effectively broken.

Indeed, while the more recent models of business relationship data do reflect real world realities of this data better, they still fail to model the most advanced scenarios and extended business organizations which are seen in practice. This weakness stems from an implicit assumption in the recent models that ideas such as customer or vendor are simply an extension of the Entity’s description: the Entity “is a” customer, the Entity “is a” vendor. While better than the old model where the customer/vendor/etc. ideas represented completely different entities, the recent models still fail to appreciate what we’re actually modelling.

Our Approach

The reason the recent models described above succeed as well as they do is that the model isn’t wrong, it’s merely incomplete. Properly understood, the recent model is not describing an Entity with its extensions into more topically focused descriptions where needed, it’s really modelling an Entity which has different Relationships with an implied, unmodelled Entity: the first party Entity or “us”.

By recognizing and being mindful that we are modelling Entities and the Relationships between them, and making that explicit in the data modelling, we can avoid the limitations of assuming too many facts about reality.

Explicit Model

Our basic modelling technique makes the complete Relationship picture explicit in the data model.

However, because we are not assuming an implicit Entity “us”, we can model relationships between arbitrary Entities. This becomes useful when we want to use our business system to manage the businesses of multiple Entities. For example, consider a company with subsidiaries; each subsidiary may operate with significant independence, yet each subsidiary’s financials are consolidated with the parent company and may act as a group in some scenarios, such as purchasing. In cases such as that, being able to explicitly model Entity/Entity Relationships allows the use of the same business system for management activities across the conglomerate while also allowing independence where needed. This same-system/independent-existence property of our model can facilitate other business structures, but those will be discussed elsewhere.