Most advanced business applications are built assuming a resource rich and programmer centric environment. They assume unlimited access to hardware, operating system resources and programming talent. They assume a business context where execution speed and scalability to thousands of simultaneous users are more important than development response times and maintainability. The core assumptions seem to be that clients have deep pockets, long lead times, projects with short lifespans and user bases that grow large over night. Everyone has delusions of grandeur about the Fortune 500 client.
formVista(tm), however, has specifically been designed using the opposite assumptions. In our experience in the small to medium sized business space:
the vast majority of online business applications are built on demand under ridiculously short time frames with limited budgets and very little access to hardware or operating systems.
They serve small user communities that rarely exceed a several dozen people.
Hosting is considered a commodity, often handled by third parties and clients rarely pay for dedicated servers.
There is always too much work for too few people.
Once an application is fielded, the client always starts to change everything.
Clients will come back years later wanting massive changes.
Most clients want the same kinds of things but every client wants something different.
Many clients want to do some things themselves.
There are more distinct roles with varied levels of technical experience involved in web application development than in other software endeavors and more often than not the programmer is not the most important one.
As heretical as it may sound, in most business cases the ability to respond to customer requests quickly and inexpensively while maintaining role independence is much more important than efficient runtimes or extreme scalability.
In the case of our MOBIE system, we did not need something that could power a high volume website like Slashdot.org or service thousands of simultaneous backend users. We did, however, need to get something very flexible built very quickly, make it installable in a large number of contexts, and make certain we could modify it later with a minimum of effort.
We decided to build our own framework because no other framework seemed to be focused on this set of problems.
