For you the designer it is important that you understand what Formever is trying to do and why it is doing it. This article will give you an overview of where Formever is going.
When I started to design Formever I decided to try and meet a set of very aggressive objectives.
- Allow designers to develop effective, efficient multi-user systems in a week or less
- Handle change to the business logic on a temporal basis
- Have incredibly reliable code
- Be scalable with ‘ever valid’ data
- Have a model
- Be internationalized in a way that allows ‘deep’ localization
These objectives are in their essence aimed at really helping you the designer. Having written many enterprise systems and felt the pain I have learned over the years what things I would really like a system development environment to have. These are objectives I think this kind of software needs to be really useful to designers and help them have a successful and enjoyable business.
A major issue is the ongoing maintenance of a system. This is an issue that many of the standard ways of developing systems seem to ignore. You the designer will be out there servicing clients (perhaps internal to your organization – but clients nevertheless) on an ongoing basis. From a business point of view this is where the money is. Formever allow you to make money on the build, but to be honest, that is a somewhat confused time. You have a group of directors who work for the client and who don’t really know what they want. Using Formever’s flexibility you can quickly throw up a system and get feedback and home into a system that fits them like a custom-made glove. That said, there is a lot of misunderstanding on the client’s part that you have to work to clear up. After a while they will start to get into Formever and those misunderstandings will die down.
If these client issues force you to go over your budget expectation it is best not to pass that back to the client but just to absorb it. Formever allows you to develop systems so quickly compared to other really expensive technologies that you can make sure you have lots of contingency in your quote. However, that said, when you get a reliable system running and the client is requesting feature enhancements that is the time when you get top dollar. As I have mentioned before if these client request can be done in a few hours or at most days, then you can charge a top rate and the client will pay it gladly.
Business Hint: Establish your top rate right from the start. Make it the basis of quotes. Remember you can always discount a rate. You can give introductory discounts, or whatever, but discounts have limited terms that can be specified. Expiring a discount is far, far easier than going to the client and telling them your rate has increased.
What you don’t want is a bunch of system unreliability that gets the client upset and forces you to spend precious time on the system when you could be making money elsewhere. What you want is a system you can change without having a massive coding effort and a large, complicated and error-prone data export/import task. So, these objectives are all objectives that aim to make your work easier and more profitable. Let us look at these objectives in more detail.
Allow non-programmers to develop effective, efficient multi-user systems
This is the heart of what Formever is for. Formever is designed as an authoring tool that allows you the designer to build systems that your clients will love.
Also, I think the build process should be enjoyable. I enjoy creating things. I don’t enjoy a continual frustration of overly-difficult coding in a unreliable environment that forces me to spend more time on the technical minutia rather than the client’s actual needs. Formever gives you that immediate feedback that increases the enjoyment of the creative process. You can add a background image to a form, drop in a new field, add some business logic and immediately see it working.
Formever meets this objective by the following:
- Making the construction of business logic just point and click – there is no wrong in Formever logic as you are not offered illegal choices – the business logic you build is always correctly formed (of course you have to make sure it does what you want it to)
- Using context to greatly simplify authoring business logic. Context is one of the hidden operators in business processing and Formever is the first system to really use it. (There will be a much more detailed discussion of this later).
- Giving point and click tools to set up access rights – this is usually a tedious task but Formever makes it really straightforward
- Give all the power to administer directors that use the system to the executive director – the executive director is the super user on a Formever system. It could be you, the designer, or an administration person at the client. The executive director can add and remove other directors, change their passwords, or force log them off – all the capabilities that you need to run a multi-user system. This means that you the designer have total control over the system. You don’t have to come to the Formever company to approve new directors. The Formever company stays out of the relationship between the system and the various directors. That is your area – it is totally your system to control as you see fit.
- Handles multi user issues automatically – multi-user is a very tricky area. It is very easy to have logic holes in the multi-user strategy that cause occasional unexpected issues that are almost impossible to explain. As a designer this wastes time and hence costs money. Formever takes care of all of these issues. For example, take the issue of having multiple directors add the same employee. These kinds of confusions happen in business and the system has to be able to handle it. In Formever it is done by automatic ‘reservations’. When a director enters in the employee number it will turn green or red. Green means that it has been reserved for them i.e. no other director can enter it. Red means that some other director has it reserved and it cannot be used by this director. You can see how this makes absolutely sure that the same number cannot be entered twice. When a form is edited Formever makes sure that only one director can edit it. When a sequential code is asked for Formever makes sure that they are issued in order with no duplications and no gaps. These kinds of features just work in the background without any effort on your part.
Can a system be built in a week or less? That is an interesting question. On one level the answer is yes. You can build a fully functional enterprise system in a week or less. Our whole approach has been to get the client to describe the system they want and then build it. Going back to the client exposes any misunderstanding and allows the client to play with the system so they can then tell us in detail what they want. No requirement documents – no design documents – none of that essentially useless work of making documents that no one reads. In Formever the system is the documentation. We have planned a future feature that will give you an HTML description of the system with links. Because this kind of documentation is generated by the actual system it is always correct.
Most systems are totally tied to the development schedule of the software. It usually takes so long that all other tasks can get done first no matter how slowly they are done. However, with Formever the development is a matter of a week or two (usually dictated by how much time the designer has to work on that particular project). What we have then observed is that the client is the one who holds up things. It is hard to get meetings with client on that fast a schedule, and clients are usually really bad at providing needed information (lists of clients, list of projects, lists of employees etc.). So the development normally takes a few months.
The good news is that most of that time is spent waiting for the client so that other projects can be worked on. To really fully utilize the fast development of enterprise systems using Formever requires doing several systems at the same time. While waiting for a client to produce information you can be working on another client’s system.
This is a huge advantage for you the designer. You can take on new clients because you are not bogged down in a massive development effort that can take years.
Handle change to the business logic on a temporal basis.
This is pretty much as important an objective as fast development. Even if the development is fast it still leaves the situation when changes have to be made. We all know that change is the one constant of business so it is ridiculous that none of the standard tools used to do enterprise system have built in functionality to handle change.
However, that is the current state of the art. Most systems require a complete dump and rewrite of data when major changes occur that change the data model. This requires programmers to intercede by changing the code and often moving the data to a new data model. The problem is that all of the data is now in the new format and old results cannot be redone.
I saw this cause massive problems in many companies and resolved that Formever would handle this problem.
Formever can change business logic every accounting period and still go back and recreate exactly the processing environment of each previous accounting period.
This solves the problem of tracking organizational changes. A simple example is an employee name. In one period it might be John Smith. Then John legally changes his name to John Brown in the next period. In that and subsequent periods his name will be reported as John Brown. If you go back to the previous period it will still be John Smith.
This applies to the business logic as well. If you change the calculation of a definition in a future period say six months in the future. Then the change will only take place at that time. Up until then the old definition will apply.
Have incredibly reliable and dependable code
This objective may seem somewhat obvious and not necessary. Doesn’t everyone try to have reliable code?
Well that is true. I’m sure anyone building software of any kind is trying to make it as reliable as possible but as we all know a lot of software, if not most software, is anything but reliable.
The trend today is to use software that runs in browsers. Think SalesForce, NetSuite and FreshBooks. To be blunt about it, there is no way browser based software can be reliable. There are five major browsers (at the time of writing) Chrome, FireFox, Safari, Edge and IE. Each of these has slight differences that can cause code to behave in unexpected ways. Add to this the fact that a user can set properties on the browser that impact behavior (like blocking popups and setting any of the myriad option flags a modern browser has). And further add the fact that all of these browsers have adopted an ‘evergreen’ model where they are continually pushing updates (complete with fixes to previous bugs and often with new bugs that will be fixed in another update). So how do you guarantee reliable rock-solid predictable behavior in these circumstances? The answer is that you can’t.
This isn’t much of a problem for a photo site. Who really cares if the images is the wrong orientation or some of the photos disappear for a while? Those kinds of consumer applications work well on the web and consumers have come to expect occasional random behavior.
For enterprise systems the situation is different.
There is a philosophical issue here. It is my belief that enterprise systems should be totally predictable in their behavior. In the browser world errors are brushed off as they are often impossible to reproduce as the software keeps on mutating and users purposefully or accidentally set different browser modes.
Accountants have always had a reputation for being very cautious and conservative. They want to guarantee that the results they report are as accurate as humanly possible. I have adopted the accountant’s attitude because I believe it is the right one for enterprise systems. Any system of mine has to be totally reliable and predictable in its behavior.
The current big vendors of enterprise computing seem to have a different view. Their code is either delivered via the chaotic browser environment or it is built with standard computer languages and hacked into being customized. I believe that the current long, sorry trail of failed and sub-standard systems is the result.
This is an issue that is important to you the designer. You don’t want to build a system for your company or a client and have it fail. Now this is not so clear as it may seem. The normal hourly rate for enterprise system building is very high. Some consultants think that system unreliability is a way of making lots of money. When the system fails they are called in and get to charge a lot of hours to fix it.
I have been building systems for companies for decades and my experience is that this a bad way of making money as it is stressful and negative. If the system is continually having errors the client is upset and angry. Sure, they will pay the bills, after all what choice do they have, but they are certainly not happy about it. In addition, unsatisfied clients will question every expenditure and argue over all the details trying to regain some power in the relationship. To my mind life is too short for that kind of negativity and tension.
If you put in a system that runs day in and day out with no real issues the certainly there is less emergency maintenance. That saves on stress. I can’t stand the phone calls when the client is panicking over a system problem and I have no idea how to fix it. That is why I made Formever reliable. In addition, in my experience, clients that have good systems are much easier to deal with and will want to add new features as they see the advantages of using their system in all areas of their organization. You might not get the same number of billable hours that an unreliable system will generate but those extra features are happily paid for by a satisfied client as they see they are getting real value for their money. They also won’t question your high rate, as you are not spending month after month sitting in their office, drinking their coffee, and running up eye-watering invoices. Instead, you are more like a lawyer or tax accountant. Someone who costs a lot but brings specialized expertise to the organization in small bursts of quality service that has a high ROI. You get enthusiastic testimonials and referrals as well. It is a much better professional life to have many happy clients who provide a continual steam of revenue by requesting new features.
Formever has been built using something I call ‘low entropy programming’. In simple terms, that means that the code is very, very reliable because it is as simple as I can make it. Most of the errors you run into will be caused by your business logic being not quite right – something similar to a wrong formula in a spreadsheet – easily diagnosed and corrected.
In addition to this reliability there is a whole sub-system of instrumentation. If an error does occur Formever collects and sends to us a complete log of how it came about. Sometimes we have corrected an error and issued a new update before the client realizes that it occurred.
Finally, I should mention Formever update strategy. Updates are sent to the servers and pushed to the client the next time they log in. This means that the server and client are always identical versions. In fact, a major reason that Formever is so reliable is the fact that the server code is a super set of the client code – i.e. they are essentially identical. This removes a lot of errors that other server-based software has, that is caused by the client code getting out of step with the server code. Those out-of-step problems are unavoidable for those trying to deliver software via browsers.
Formever servers require no monitoring. They just run. I check the logs if there is something untoward but almost always it is a communication problem or an O/S problem on the local machine.
Scalable
Scalability was an obvious design goal. An enterprise system should be scalable as it is hard to predict growth in an organization. So Formever is designed so it can be ramped up to more and more directors and higher business volumes. This is important to both the organization and designers. If a system won’t scale there can be points where it has to be totally rewritten. This is obviously a bad thing, as redesigns tend to be incredibly disruptive.
There are two kinds of scaling:
- Scaling of a particular system. This is when an organization starts doing more and more activity so the number of forms increases correspondingly. Formever is set up so that we can move accounts from server to server. Indeed, it is quite economic to give an account a whole server and that server can at the push of a button be upgraded in memory and number of cores.
- Scaling of the whole Formever cloud. A lot of cloud applications mix all the user data in one giant database. The problem with this is that as they get more and more customers the database reaches a point where performance suffers. They are then forced to start to use complicated database sharding technologies or having to re-architect their software, which sometimes cannot be done in time to save their clients immense pain.
Formever on the other hand puts clients in groups on many servers. As the client base grows so does the number of servers. Which means that the computing resources grow with demand. This also allows great flexibility in putting the client’s data on a server in the jurisdiction of their choice. Formever works on AWS as well as Digital Ocean. We can add other such services, like Google Computer, very easily.
Has a model
This objective is not so obvious and requires some explanation.
When it comes to software used in the enterprise the really powerful applications have a model. What are the most useful software packages used in the enterprise? The office suite come immediately to mind – word processing, presentation and spreadsheet.
One thing to note about these three programs is that they each have a strong model.
Take word processing for example. The model is a document. As soon as you say document then users start requesting features. Can you use different fonts? Columns? Pagination? Spell checking? Tables? Etc. etc. etc.
Having a strong model immediately has users begging for features.
Take presentation software like MS PowerPoint. The model is a slide show. Of course, you want bullet points, fonts, backgrounds, images, video, slide transitions, slide show with a timer, notes and voice over. This just names a few obvious features that immediately pop to mind. Again, a strong model begs features.
The spreadsheet model is a little more abstract. That is because only accountants ever really used paper spreadsheets in the physical world. But once you get the idea of a grid of cells with each cell containing a value or a formula. You can see that you want to total columns and rows. Then you can start to see all the functions you might want like net present value (NPV) or adding up the sum of products. You want to be able to set fonts, set colors and, of course, graphing results. Having multiple spreadsheets in a book is a natural as well. Users are always wanting spreadsheets to do more. They continually suggest additions. This is the power of a model.
I have long realized that powerful software has a model, a model that begs for features. One of the problems with enterprise software is that none of it has a real model. They are just a random collection of screens with thrown-together logic that are aimed at specific functionality. There is, however, no pattern, no structure and while a few specialized features may seem desirable users are at a loss to suggest how to really improve the software in any significant way.
It was one of my objectives to make sure that Formever has a model. That model, like the office suite models, is so simple as to be almost obvious. It is the model of forms.
With Formever it is the designers who request new features. I have requests all the time for features from designers. There are so many obvious extensions that would help various systems. The directors on the other hand only really see a system that fits their needs like a glove. Directors can request new capabilities for their system, but it is designers who see the design-environment and continually want more power.
Now there is certainly lots of software that is based upon forms. FileMaker Pro for example is centered around screens with fields i.e. a form. But those forms are just forms. Sure, they have scripts behind them but it is up to the programmer to figure out how to put them together, how to make them relate to each other, and nothing is automatic because it is so general. Being general can seem to be powerful, but in business software it is not. It is the specific that is powerful because it can use the situational knowledge to save the designer work.
However, to do that you need to make the right decision as to being specific. If you choose the wrong specificity your model will not help very much. You will always be fighting to do things that run across the grain and the constraints of specificity instead of being helpful will be a decided hinderance.
Internationalized for deep localization
I have always thought that a lot of countries don’t have good enterprise system choices because of language and the differences between local business environments. Most enterprise systems are built from packages with fixed functionality. The manufacturer may or may not provide a version for a particular locale. Sometimes they just dump in a version from what they think is a similar locale (say Australia to Canada) and hope for the best. It is amazing how two seemingly similar locales can have very different business practices and business terminology.
A key objective is internationalization (I18N – because there are 18 letters between the I and N). I18N is the process of making the code easily localizable. Localization (L10N) is the process of taking the software and making it work in a particular locale – i.e. a place with a language and some different ways of presenting data – like the way dates are done for example 1/3/2019 for 1st of March 2019 in some parts, and in the U.S. 3/1/2019 for the same date.
I18N normally requires things like not putting text into images (it is to be avoided because it requires someone localizing to make a new image). It normally requires that all the text be located in known places with labels so that they can be changed.
I18N is something that is near impossible to retrofit. It needs to be designed in from the start.
Formever has done exactly that. All of the messages in Formever are kept in tables as are all of the scripts that generate the point and click definitions and procedures. This means that Formever can automatically translate all of the messages and system names that are static for all applications.
Formever also has a way of translating forms and data. This means that it is possible to have different directors using Formever working in different languages on the same data.
This means that it is possible to have different directors using Formever working in different languages on the same data.
It also means that the actual language of Formever can be translated as well. Each Formever definition is a statement of how to calculate a particular value. This statement can be translated so a Chinese designer can work in Chinese. It is even possible for designers using different languages to work on the same business logic, each in their own language.
Absolute Security
Security is essential. I thought so when I started Formever and since that time security problems have intensified to a point I never would have thought possible.
This is key to you the designer. Your clients will want to know their data is safe and with Formever it is. Nothing is transmitted or stored in Formever without being strongly encrypted. Most enterprise systems use relational databases which are fiendishly difficult to encrypt. That means that most databases are not, and they depend on the perimeter security of the server to stop intruders. You can see from the daily news of security breaches how well this works. (see my Medium.com article “Risking other people’s data by using relational databases”).
Formever has a much more efficient and secure data storage system. Every form that is written to Formever’s persistent store is encrypted with 128 bit encryption. (If you are wondering if this is enough see my Medium.com article “What’s the deal with encryption strength – is 128 bits enough”).
Formever also includes optional true 2-factor authentication. If you want you can set up a client so that every director requires a YubiKey to sign in. This means that they have to possess that YubiKey (something they have) as well as know the password (something they know). The YubiKey generates a one time, totally secure password that is checked on YubiKey servers by Formever.
Unlike other systems this is mathematically provable security.
Conclusion
This has been a description of the objectives behind Formever. The idea is to produce software that will do everything to make the development of business Enterprise systems as easy as possible and yet allow powerful and sophisticated systems. It is a project that is ongoing. Because of the powerful model behind Formever it seems that there are always more features that are begging for implementation.
For more information see the article on Ever Valid Data.