Since 2017 we have been on a mission to correct the internal structures of SoEasy. It has not been easy because for 25 years prior, we have been building individual systems for people that they held on their local computer infrastructures.
This meant we had to move everyone off their PC's, place their version of the program on a managed server, and then work out what components were customised to the site and convert everyone over to that code.
Covid was also a hindrance because we couldn't go to sites and process the conversions. However since the lock downs have been removed, we have now moved all custom sites to cloud2 and been able to complete the process.
What is the Single Code Objective?
Development of SoEasy was started in the very early 1990's using a monolithic programming technique. The code was like the writings of a book. It started loading facilities right from the start of the first icon click. Printers would be set up, then user account, files, variables, and features that would be needed in every area of the program. For example, Invoicing would be dependent of features inside cashbook so those features would be open during the entire user's session.
This meant that a change anywhere could affect another area. For example, a change in the cash book, would effect invoicing. It was very complicated. If we tried deploying those changes to other users, we could have ongoing issues for some time. Our software was deployed on thousands of computers and lived through many operating system changes. As many thousands of modifications were made over the course of many years, not everyone upgraded their system and as we grew, this model eventually cause huge problems. The silicon valley software industry recognised this issue and huge investments were made to changed into new code styles but we could not make the change because we were in a language that had not evolved.
In about 2018 we decided to stop selling our software and focus 100% on the issue of converting our code into a different structure. Before we could do this though, we had to decide what that structure would be. This took a lot of modeling because it had to be perfect.
In Generation III we have three main components which we call the "Single Code"
1. The User Account: Identifies a users access to the system, the organisation/s they work with, and their statistics
2. The Organisation Data: This includes current data, historical data, and temporary data
3. The containerised program code: The code is structured into self managing segments which are stored in easily identifiable folders. The master code is know as CODEA
for example:
\\CODEA
\CASHBOOK
\PRINTERS
\COA
\USER
\DATABASE
\INVOICE
All users share the same common code BUT for three exceptions:
Exception 1: If an organisation uses a different version of a container such as invoicing. For example: A mechanic's workshop
Instead of the system loading the \INVOICE module, the instance automatically uses \INVMECH
Exception 2: We are repairing/improving an issue in a component
We temporarily switch a site or our development to CODEB which is an exact copy of CODEA.
We make the changes, test it, deploy it to CODEA
Exception 3: A customisation
Our programmers or a third party programmer is engaged to create a site customisation.
This can be made on a local PC and will link to our server through peer-to-peer connectivity
There is a lot more to it than this but basically we have worked out how to resolve all the issues we have experienced in the past. Generation III (3) is the transition from Monolithic Code to Containrised Code.
Where Are We At?
After years of development and converting users to run on our managed servers, we are this weekend, doing the final merge of all user code. Once this is completed, we will work during the next two months to finish all the code conversions to the GIII format which is technically identified as PROCEDURE(Action,Option,PassedValue,Result)
It has been a very long journey. We are all looking forward to the completion of GIII.