The Contextual Graph Database of Forms

*Paper databases that were so effective in the pre-computer era can be formalized and implemented in software to take advantage of 21st-century software and hardware.

In particular I describe a graph database and an access language that allows a wide range of enterprise systems to be easily, quickly, and safely implemented.

Learning From The PastThe predominant type of database used in enterprise systems has for the past four decades been the Relational Database.

With the adoption of relational databases there has been an increase in system failure.

See my article:What I’m Telling Business People About Why Relational Databases Are So BadThe following is what I have written in my book Avoiding IT Disasters to explain to business people why relational…codeburst.

ioIn response to some of the problems with relational databases there has been a move to what are called no-SQL databases.

These databases don’t follow the relational model or use the query language SQL.

One of the major problems with relational databases and the no-SQL alternatives is that they are general-purpose databases.

They are constructed to cover a wide range of data storage and access cases.

They can be used for enterprise systems, but they can also store pretty much any kind of data, whether it is process control samples, aerospace telemetry, or anything else that can be expressed using specialized data types.

A lot of power can be gained in software by having highly specialized algorithms that take advantage of unique characteristics of a particular problem domain.

After working on enterprise systems for decades I have concluded that there are special characteristics of enterprise systems that can be exploited to make system development and maintenance far easier.

As I pointed out in the following article, in the past (i.


, before computers), system failure was not really an issue.

Database Theories Used in the Past Were Superior to Today’sIn the past, before computerization, enterprise systems were done on time, on budget, and could be changed without…medium.

comThere are always some problems with processing information, no matter how you do it, but before computers these were just normal operational problems and not a cause for massive financial loss sometimes leading to the collapse of organizations.

In that article I talked about the databases constructed from paper forms that were so ubiquitous in organizations before the adoption of computer technologies.

In the paper era the primary way of storing business data was paper forms.

It is a very natural way of collecting and storing data.

It is so natural that not a lot of thought has been given to the database theory behind it.

These databases had evolved over a long period of time (paper forms have been used for centuries) to their zenith in the late 1940s.

In that era systems were routinely implemented without problems.

See my article:The Great Generation Was Really Good At Enterprise Systems — Today We SuckIn 1936 the United States congress voted to pay out the first world war bonuses that had been promised to veterans…codeburst.

ioThe success in implementing systems was not because those systems used humans as their computing elements but because of how the data was organized, i.


, the database structure.

That structure was the database of forms.

What follows here is a formalization of the database of forms into a graph database.

For a description of the kind of graph database I am referring to here see my article :Graph Databases with Prototypes and Types — Lance Gutteridge — MediumThis article is a description of a graph database that is useful for implementing enterprise systems.

It is basic graph…medium.

comAs this formalization is developed it will become evident that it is something that lends itself to computerization.

I will describe Formever, an open source computer implementation of this database in a future article.

This formalization may appear complicated.

Like all formalizations it tends to hide its inherent simplicity in the technical language that describe a formalization.

However, just as paper systems were understandable and easy to set up by business people, a computer implementation of this graph database produces software that is very easy for business people to use.

Another point to make here is that there is much more than the database to software that can author enterprise systems.

The database specifies how to store and access the data.

However there are other important considerations such as multi-user processing, form and report design, and a host of other necessary functionality.

So this database description is just the basic principals on which software can be built that will enable us to return to the effectiveness of system implementation and maintenance that was the norm before computers.

I have incorporated these ideas into the open source software Formever.

The Database Of Forms As A Contextual Graph DatabaseIn the following section I will show how forms naturally fit into a prototyped database.

The properties of a form node is a list of named values, i.


, fields.

We are all familiar with fields on a form.

Most fields are scalar in that they have a given single value.

There is, however, a vector-type field in that a field can be a list of named value collections.

These can be regarded as a collection of sub-forms.

This is common in paper forms with a standard example being a list of items on a supplier’s invoice where each item has properties like product code, quantity, and price.

This means that a form is essentially a sub-graph, having a primary node as the form itself and having the possibility of one or more attached collections of nodes.

These sub-graphs are homogeneous in type, that is, each member of a collection of sub-forms is identical in properties to the other members.

Time sheets, for example, are variable length with each detail line being a charge to a project.

Simple paper time sheetThese detail lines can be considered as nodes as they have a set of named properties.

We can regard them as sub-forms as they are in a sense small (often one line of properties) forms and have a prototype.

A time sheet as it would exist in a graph database.

So each form really defines a sub-graph.

Some forms don’t have any detail lines so they are a single node.

Other forms such as a supplier’s invoice or a time sheet are represented by a sub-graph of a parent node and a set of child nodes.

It is possible to have more than one set of detail lines.

In this case each set of detail lines forms a group of sub-nodes that are connected to the top node of the form.

While possible this is rare.

Most business forms have none or only one set of detail lines.

Each form can be treated as a node.

The fields on the form are its properties.

Each form has a prototype.

A time sheet has the identical properties to another time sheet, a supplier’s invoice has identical properties to another supplier’s invoice.

We can call this prototype a Master Form.

Like a JavaScript prototype the master form has fields that are functions.

These are in essence defined fields which we can call definitions.

(In this article I will often be comparing the graph database of forms to a JavaScript object model.

They have some striking similarities and JavaScript objects are something that most readers of this article are familiar with.

)In JavaScript we have references between objects which are internally implemented as pointers.

This is done by assigning an object to a variable.

In the paper era these references were done by unique identifiers.

Employee number, project number, etc.

So relationships between nodes (i.


, the directed lines between them which are called edges in the language of graphs — see the article on graph databases referenced above) are defined by two mechanisms.

Identifier a) (Black arrows) A property can be an identifier of another form.

This is done in business applications by a unique ID.

For example, an employee number, a project number, or a sequence number assigned by the system.

b) (Green arrows — see code example below)The identifier of a form can be formed from other identifiers.

For example, a general ledger code could have a branch id in front of it as each branch may have a separate chart of accounts.

So this forms a connection from the form to the form being referenced in the ID.

(See below for a discussion of these types of edges.

)Containment — containment is bi-directionala) (Red arrows)This is the relationship between a form node and a list of detail lines on that form.

Each detail line is also a node and is connected to the top level of the form.

b) (Blue arrows) This is the connection from a detail line to the top of the form.

Notice that detail lines can have form codes as properties and hence can have connections to to other forms.

In our time sheet example the detail lines refer to projects forms.

It is theoretically possible, especially when extending this model to computer implementations, to have detail lines within detail lines.

This was never really done with paper forms as there is no natural way of representing this on the two dimensional surface of a paper form.

As it is constrained by paper size there is a limitation to the length of a paper form.

Sometimes a set of detail lines would be continued onto another page but that was the extent of detail line complications.

So the database used in the paper era did not allow detail lines within detail lines.

As a result of my investigations into this I have concluded that allowing detail lines inside detail lines is a mistake.

It sounds powerful and is attractive to those of a computer science mindset, but it leads to immense complications and does not really bring any real benefit to an actual business system.

I believe that trying to accommodate hierarchies of arbitrary depth made the CODASYL specification overly complicated and in practice, not very useful.

So the database model I am describing in this article follows the paper restriction of having only one level of detail lines.

Form Codes (IDs)Organizations did, and still do, revolve around IDs.

All business have codes for the various entities in the organization.

Employee numbers, PO numbers, Invoice numbers etc.


This is a very important concept in organizations and provides the basis for business relationships that business procedures are based on.

We shall call these identifiers Form Codes.

A form code specifies a directed edge in the form-based graphical database.

For example in the above time sheet there is an employee number.

This indicates which employee the time sheet is for.

It allows a computing element (human or machine) to retrieve the employee information for the time sheet.

Codes can encode a lot of relationship information.

Take the following code for an example, G/L account 01–02–17–2000 which is of the format:company-branch-department-G/L CodeG/L Account node with the code defining edges to other nodesThis is a common technique in codes in that it qualifies the G/L account to belong to a particular company, branch and department.

But that means that a G/L account form with that code is related to those entities.

This code provides a 1–1 relationship between the G/L code and a company.

The reverse of this is a 1-M relationship between company and G/L code.

This breakdown of the code into constituent parts also dictates the editing format of the code.

In this case the company has to be a two digit number and be valid in that there exists a company form with that ID.

Another example might be a sub-project code that is a combination of the project code and the sub-project identifier.

Say for example 1234–02, which is sub-project 02 in project 1234.

Of course, a project may be qualified by a company or branch code.

In this way you move from a sub-project form and go to the project.

In reverse it identifies a 1-M relationship from projects to the sub-projects of that project.

There is a huge amount of information in a code when it is constructed properly.

A well-constructed code generates a host of useful relationships.

So it is essential that a proper representation of business data have a concept of a form code and the way it can be structured.

These codes provide a rich ecosystem of edges in the graphical database of forms.

This is one of the failures of relational databases.

Because they have been constructed more for marketing reasons, i.


, to appeal to the largest possible user base, they have not taken advantage of the special nature of business IDs.

Most IDs in relational databases are either treated as a whole field, which loses the information stored in the separate parts, or are broken up into separate columns which loses the concept of the ID as a whole.

Apologists for relational databases will claim that there are ways of handling this, which is true — but the point is that this powerful feature of business has to be handled by custom code, making this common business structure far harder to work with than is necessary.

One thing that I should point out about paper forms in the pre-computer era is that a lot of the time in smaller organizations the ID was an actual name.

For example on a time sheet an employee name might be used, and projects may be identified by the name of the project, e.


, “Acme Mill Plan.

” When you have people processing the data instead of computers, these kinds of IDs are acceptable.

However when the organizations were larger there was a need to use actual codes (numbers and letters) because the probability of name conflict starts to arise.

Notice in the simple time sheet above the projects are given as the number and the name of the project (e.


912 Johnston Bridge).

This was common in the paper days to help data processors make sure the project number was correct because humans can easily write down the wrong number.

Of course, in a computer system the person entering the data can be presented with a list of appropriate projects to choose from.

The name of the project can be displayed purely as information for someone viewing the form.

This is the kind of thing that occurs when moving these concepts of a graph database of forms to a modern computer implementation.

All of this will be covered in great detail in a future article.

SemanticsAnother way of looking at a directed graph is regarding it as a set of triples.

Each triple is a starting node, an edge and an ending node.

This reduces the graph to something like the rdf structures of the semantic web.

Each reference to another form defines an edge that can be named with the name of the reference property that defines it.

For example a supplier’s invoice has a reference to a supplier.

We could name the edge “supplier of”.

These edges can be chained in a path that could be something like “sales manager of sales person of sales order #12222.

”The edges defined by parts of codes can be named by the code concatenated with a name for the part.

For example an edge leading from a G/L account form to a branch which is part of the CO-BR-DP-ACCOUNT format of the G/L code can be named AccountCode:BR.

The edges that lead from a node to the prototype can be given the name of the prototype.

Which we will call the form type.

This is a very natural way to describe business data and it allows these relationships to be defined with a series of mouse clicks as each node is selected.

Master Forms (Prototypes)The graph database that is derived from paper form processing is a prototyped graph database with types (see the above referenced article on this kind of database).

That means that each node has a directed edge that leads to a prototype.

In the paper world there was often a model of the form, i.


, a master copy that was duplicated to produce all the paper forms that were to be entered into the system.

In the days before photocopiers this master form was often a printing plate that was made by a printing house so that copies of the form could be run on a printing press.

When photocopiers became common it was often just a clean copy of the form that could be copied many times.

So in our terminology for a graph database we term this prototype a Master Form.

(I will abbreviate this sometimes as MF.

)ProceduresIn the paper world the descriptions of calculations were kept in procedure manuals.

These procedures defined the calculations that were used in the particular organization.

For example it may have specified:Calculate Net Profit by subtracting Cost of Sales from Gross ProfitNow to make an effective formalization of the power of paper forms it is helpful to follow the JavaScript concept of having the functions as part of the node.

So we put in definitions as functions into the Master Form.

This means, just as in JavaScript where objects have functions as named members, these definitions exist in each of the nodes that inherit from that prototype.

They can be considered as defined fields that are on the form.

Notice that these are functions with no arguments.

They use values from the fields of the form and the fields from forms in the context sub-graph.

When it comes to a computer implementation of this database it becomes useful to embed data entry functionality into the master form.

This means functionality such as built-in support for data entry validation and data entry processing.

A Master Form is the natural place to store things like tab navigation specifications, field updating, and field hiding.

I will cover these issues in more detail when describing Formever, which is an open source implementation of an authoring environment that generates systems that run on these graph database concepts.

We should note here that these definitions, unlike JavaScript functions, are functions with no parameters.

It turns out that most of the time there is no need for arguments as the information needed is in the context.

There is an advanced feature called contextual references that I am developing for Formever that gives a way of specifying arguments for those more advanced cases that need that kind of functionality.

Data TypesThe graph database of forms is “typed” in that each property has a value that belongs to one of a fixed set of types.

To effectively formalize the graph database of forms we have to look at the data types that node properties can assume.

After considerable investigation I have determined that the following 12 data types are necessary and (so far) sufficient for expressing a very wide range of enterprise systems.

Form Codes — a unique ID for the form that may reference other formsForm Reference — a reference to another form via the form code — as discussed above this is one of the key ways of defining an edgeDetail Lines — a set of detail lines with a common prototypeDescription — a single line of text mainly used for namesNotes — a multi-line text field that can store variable length paragraph textQuantity — a combination of amount and unit that can contain amounts that have units of various dimensionalities (currency, weight, length, area, volume, dimensionless, energy, currency/unit)Comment: The whole area of business dimensional analysis and consistency is quite fascinating and done properly makes systems much easier to author.

This includes automatic unit conversion and multi-currency considerations.

Pattern Text — text that follows a fixed format, e.


, phone numbers, postal/zip codesDate — a particular dateDate/Time — a timestamp that is maintained in UTC time (in different time zones it may result in different dates)Choice — this is a choice of a set number of optionsStapled File — a file that is evocative of a picture or other information that is stapled to the form.

For example, in paper systems the original supplier invoice was often stapled to the internal supplier invoice form.

Action — this is more of a computer concept.

It is rendered as a button that connects to a master form procedure — in paper systems it would be a procedure that would be described separately in a procedures manual.

Now each of these field types has meta data that is used to control input and display.

For example a quantity has to specify the units it is expressed in, it has to specify the precision it is kept in (commonly two decimal points for currency), it has to specify the default sign representation (minus sign, parenthesis, CR/DR).

A description has to specify its maximum length.

A pattern text has to specify a pattern, for example (###) ###-#### for many North American phone numbers.

In the paper world these field properties were kept in procedure manuals and sometimes in unwritten but strictly observed organization protocols.

To formalize the paper-world database we need to make these more specific and express them as rules.

These are best located in the Master Form as more formal specifications that can be utilized by a computer algorithm.

One-To-Many Relationships (Form stacks)In the graph database we have been showing how form codes and containment can specify edges in the graph.

These are directed edges that are obviously a 1–1 relationship.

The reverse relationship is 1-M.

Think of the time sheet where it has an edge that leads to an employee node (“Employee of”).

The employee node will have a variable number of time sheet nodes that have an edge that leads to that employee.

The inverse of the 1–1 relationship of time sheet to employee, is the 1-M relationship of employee to time sheets.

As discussed above under the heading “Semantics” each of these edges defines a semantic relationship.

Base Form Stack: The collection of forms that are the target of edges with a given name.

We can define this as FS(edge name).

Note that the prototypes have an edge name.

This is simply a stack (in the normal sense not the computer sense) of forms, i.


, a pile of forms or a list of forms.

(I chose that wording because I wanted to have a term that was simpler for business people and more physically evocative.

)So we can see that an employee node has an associated form stack of time sheets.

In general all nodes have an associated form stack of the nodes that have an edge that connects them.

A form stack is really just a definition on a master form.

It is defined by the 1-M relationships formed by the graph edges.

So for example on a Vendor node we have the stack of all the nodes that are invoices from that vendor.

We can have a definition on the Vendor Master Form that specifies sorting and selection (filtering) of those nodes.

This is a form stack valued definition.

Again in the paper world this would have been in a procedure manual.

Something like “take all the invoices for the vendor and sort them by date and then select all the ones with an amount greater than $100.

” It is straightforward to see how this can be expressed in simple terms as a definition on a master form that can be evaluated by an algorithm.

It is just a matter of getting all the supplier invoice nodes that have edges leading to the vendor and applying the selection criteria to select a subset of those nodes and then to sort them based on the sort criteria.

Each Master Form defines a form stack of all nodes that are connected to it via an edge.

For example an employee Master Form defines a form stack of all employee forms.

We can immediately see that this is useful for report generation.

We can take the stack of employee forms and iterate through it.

For each employee form we can get the stack of time sheets and iterate through that.

Notice that by just saying get a stack of time sheets we are specifying the time sheets that have an edge that connects to that employee.

This is far simpler than trying to express this in an SQL statement that joins the two tables.

Context SubGraphsJust realizing that the paper systems were a graph database doesn’t totally explain why the systems in the paper era were so easy to develop.

An important reason is the concept of context.

Context is a simple concept on the surface.

It is a fact that humans always process things in context.

Suppose you are in a meeting and are reviewing people’s performance.

You are looking at their time sheets to evaluate their billable hours and how much sick time they have been taking.

Someone says “Let’s look at Mary Smith.

” Someone else says “How many billable hours this month?” and someone replies “160.

”Notice that once the context of “Mary Smith” had been set it was not necessary to qualify queries about the data with that information.

This is in strong contrast to the concept of joins that continually require the identification of tables.

For example:SELECT COUNT(EMPLOYEE_NAME) FROM TIME_SHEETS WHERE EMPLOYEE_NAME EQUALS “MARY SMITH”It is necessary in SQL queries to always specify the tables as there is no concept of context.

Now concept in the graph database of forms can be considered as the set of all forms that are reachable via edges from a given ‘context form’.

Consider our time sheet.

Here is the full context sub graph of the time sheet.

Notice that the time sheet leads to the employee form for Mary Smith (323) which further leads to the Classification form E1.

In our example above the context form is the employee form of Mary Smith.

When we consider the edges in the graph we find that each time sheet has an edge connecting it to an employee form.

Hence there is a multiplicity of edges that go from an employee form to time sheets.

So we have a very natural relationship from Mary Smith to the set of her time sheets and in this graph database once we have set the context form to Mary Smith all we have to do is reference time sheets and it is possible to evaluate the set.

Derived ReferencesThere is a natural operation that humans do that we have ignored in our databases.

This is the concept of a “derived” reference.

When we are following context through a contextual graph database we are following the edges defined by IDs.

IDs act as a pointer does in a computer implementation in that it uniquely identifies a form.

It is a 1–1 relationship.

When following these edges comes to a 1-M relationship, i.


many edges branch off the node, then normally the context sub-graph cannot be extended.

However there are instances when context will reduce the number of edges down to a single edge that can be followed.

Consider the following example.

We have a rate table for a project that lists the rate for every employee in the company.

When we start from a time sheet charge to a project we can follow the edge that leads from the time sheet detail line to the project.

From the project we can follow the edge that leads to the rate table.

Now at this point we have a 1-M relationship from rate table to employees as there are many edges branching out leading to different employee rates.

However, think of a manual department that is calculating fees for a time sheet.

The time sheet has an employee ID (it is the time sheet for a particular employee).

Hence from that context it is clear that the only edge that should be considered from the rate table is the one for the classification for that employee.

In our example Mary Smith is a senior engineer.

The first time sheet line is for 6.

5 hours for project 932.

Looking at project 932 we see that the rate table is RT01.

There are three rates on the rate table for different employee classifications.

However Mary Smith is an E1 so it is obvious that the rate of $150/hour should be used and hence the fee is 6.

5 hours x $150/hour which equals $975.

A human naturally assumes that the only rate worth considering is the one for the classification of the employee whose time sheet it is and uses that rate in the calculation of the fee.

When people are doing the computing this is so obvious that it is not necessary to describe this step in detail.

If we have a rate for an E1 employee, and the employee we are working on is an E1, there is no question of what rate to use.

This is the concept of a derived reference.

The sub-graph is filtered by context and hence 1-M relationships like the one from Rate Table to rate can be reduced to a 1–1 relationship.

This is represented in the context graph above as a purple connection.

As opposed to the fixed connections of reference and containment, a derived reference is a connection that is virtual in that it is dependent on context.

This derived reference also works if the rates in the table are separate forms (rate cards) rather than detail lines.

This is an approach often used in larger organizations when there are many different rates that change often.

A Key Example of Why A Graph Database is Far Superior to Relational DatabasesYou, dear reader, should pay very close attention to this example of a rate calculation above.

It is an exact reason why the paper systems were so easy to set up and why modern systems using relational databases and general purpose languages are so difficult.

Consider how this would be handled in a standard enterprise system today.

There would be 7 relational database tables involved in this calculation (time sheet, time sheet details, project, rate table, rate table details, employee, classifications).

This calculation would require the joining of these tables which would require a complicated SQL script.

Now there will be people who will claim to be able to write that statement in some short amount of script and in a short time.

But that totally misses the point.

Regardless of how clever you are and how short a script you can write, it is a fact that this requires an expensive technical expert a significant amount of time to do.

Even when the SQL is written it has to be located into a code base and interface code written to execute it and to transform the result-set into values that can be directly used by the software.

Compare this to what is possible in a context sensitive graph database.

A non-programmer can select a multiply definition.

He/she can then select the hours on the time sheet detail as the multiplicand.

As the multiplier he/she can select the project reference field, that displays a list of project fields one of which is the reference to the rate table.

Selecting the reference to the rate table will display the rate table line which has been selected by the context (the derived reference), clicking on this will give the fields of the rate table detail line, one of which is the rate.

He/she selects that and the fee calculation is finished.

Defining this fee calculation is an operation that takes five mouse clicks and is totally understandable to a non-programmer.

It takes around 5 seconds.

This is very similar to the kind of operation a clerk would have done doing a fee calculation in a manual system — fast and straightforward.

This is probably a 1,000 times faster than trying to construct and integrate a complicated SQL and doesn’t require a database expert.

This in a nutshell expresses why our current systems are so risky and expensive to implement and modify and yet how in the past systems were implemented and modified with ease.

ReportsReports are a central feature of any enterprise system.

Context makes reports extremely easy.

A report can be considered as a series of form stacks that terminate in a detail line.

For example suppose we want a report that shows for each employee all their time sheets and for each time sheet all the projects worked on.

We would start with a form stack of employees.

For each employee we ask for a form stack of time sheets.

Because of the edges in the graph it is just a mouse click to return a list of the time sheets for that employee.

For each time sheet it is again a mouse click to return the list of detail lines.

Each level of the report can be formatted from the context.

For example when formatting a time sheet line it is just a mouse click to reach through the edge that leads to the project and get the project name to put on that line of the report.

These report definitions can be stored on special Master Forms.

This keeps all of the business logic on the Master Forms.

There are many ways to combine context and reports that I will cover in future articles.

TimeTime is a large consideration in enterprise systems.

Organizations have their reporting based on accounting periods, quarters and fiscal years.

The business logic of organizations changes over time due to re-organization, policy changes, changes necessitated by client changes, and changes imposed by external agencies.

One of the reasons that current technologies have caused so much trouble in enterprise systems is that the resulting systems have been snapshots of a particular point in time.

The business rules are identified and then coded into the systems.

If there are significant changes then the system has to be modified, which creates a situation of data that existed before the change and data that exists after the change.

There is no flexibility in this boundary and essentially two versions of the system have to be maintained for a period of time necessary to get all the necessary reports under the old business rules.

One of the main reasons why the paper systems were so much more adaptable and easy to manage was that humans have a natural ease with the concept of as of.

Let us take an accounts receivable department for instance.

The department in the paper era would produce invoices based on a flow of paper forms.

Let us suppose the organization was selling goods.

The accounts receivable department received a flow of sales orders that were processed to produce invoices.

If the business rules of invoicing were changed it was done on an as of basis.

For example: As of January impose a 10% surcharge on all international clients with the description “Shipping surcharge.

”This is a natural instruction for humans to follow.

The A/R department would process all December invoices in the current way, but any January invoices for international clients would have the surcharge applied.

It didn’t matter that these orders were being simultaneously processed (which is common around the month end).

Human beings think nothing of looking at an invoice and deciding if the as of situation applies.

As of processing is a form of context.

When we consider the time flow of the database we can see that we can look at the context of time and look at the context sub graph associated with a particular accounting period.

In our formalization of the graph database of forms we see that all of the business logic is contained in the prototypes, i.


, the Master Forms.

If we consider time as a form of context then this means that a Master Form can be changed in an accounting period and this will be the prototype for nodes created in that period and subsequent ones.

This means that the business logic can be changed as of an accounting period.

Graph of periodicity in the databaseAll of the business logic is in the Master Forms.

When a MF is modified then any nodes created in that period will be based on the new MF.

This means that the business logic is as of a period.

If an invoice is changed so as to include a conditional surcharge then that change will take effect in the period that the updated MF is in.

Previous periods will not be impacted.

This mimics the as-of processing of paper systems that made so many operations really easy.

Conclusions:This article shows that it is quite possible to formalize the paper form database into a prototyped graph database with types and to achieve the ease of implementation and modification that was characteristic of systems done before computers were introduced into organizations.

In a future article I will show a detailed description of Formever which is an open source implementation of these ideas.

Formever lives up to the promise that is suggested by this article and allows non-programmers to develop very sophisticated enterprise systems as easily as one can set up a paper system.

Radical change is difficult and acceptance is slow.

Most IT people have a lot of time and expertise invested in current technologies.

Given that the monies involved in these technologies are much larger due to their complexity than a simpler approach would generate, it is hard to see why the industry would really want to change.

The only group suffering in the current regime are the organizations using enterprise systems and they have no real voice.

On a more optimistic note one reason for adopting this new technology is that system development is far less frustrating in this kind of system.

The current technologies pretty much guarantee that each system implementation is going to end in tense desperation when trying to drag some sub-standard system to a form of completion.

An easier and more reliable approach means a much more enjoyable and shorter implementation.

Also, having software that can be used by business people will enable that constituency to participate in enterprise system development.

Without having to become deeply involved in complicated IT technologies they will be able to bring a wider business experience to systems.

The result of that will be better systems.

If you want information on software that implements these ideas and gives a whole new way of developing enterprise systems please go to formever.

org website.

Also see my book Avoiding IT Disasters: Fallacies about enterprise systems and how you can rise above them (It reveals the real reasons why enterprise systems are failing — the ones that no one wants to talk about).

Photo by Pablo Heimplatz on Unsplash.. More details

Leave a Reply