A War Story
Once upon a time, the author worked as an administrative assistant for one of Norway’s 400 public schools of music and arts. To keep track of students, teachers, lessons, and rental instruments, the school had licensed a special-purpose database application, made and sold by a six-person consulting firm started by a former band director and recreational programmer on the other side of the country. The software was constantly under development, and a couple of times per year, the consultants would fly out to individual schools to train us in the use of new features and collect feedback for further development. A common kind of request would be adding another field to an entity type in the database. For instance, we might ask if we could “get a checkbox in the ‘Student’ form to indicate whether their parents had signed the audio recording release form yet.” The consultants were generally very helpful, and sure enough, three months later there would be a patch released with the new field in the database. One day, however, they balked. “Sorry. There is no more room in the dialog box.”
Tailored Database Applications
The story above, which could be retold for thousands of organizations worldwide, illustrates a number of points about database applications “in the wild.” First, there is an unbounded number of use cases which may seem perfectly obscure to the world at large, but which may be of great importance to a small number of people or organizations (such as those those that deal with the intricacies of running a public Norwegian music school). Second, it takes a lot of effort, and a lot of attention to detail, to implement database applications for production use in such environments. Third, there inevitably ends up being a gap between users and developers, and the configuration of tables, attributes, and relationships (the database “schema”) is hard to change. Moreover, users are no longer fully in control of their data. On one occasion, continuing the story above, we paid the consultants about $2,000 to migrate a “record first created at [date]” field from an ancient FileMaker database to a newer system on “only” a week’s notice. Fourth, tailor-made database applications require their users to undergo training and learning periods which may be expensive in terms of both the consultants’ and the end-users’ time. Not to mention customer support: software that is under constant development is unlikely to be free of critical bugs, technical or usability-related. This is true even, and maybe especially so, for large organizations; while a larger number of potential target users may well decrease the marginal cost of custom software development, total training and support costs increase all the more.
A few other things are worth mentioning. Tailor-made database applications, like the one in the story, do very little other than provide basic Create/Read/Update/Delete (“CRUD”) facilities on their underlying relational database. While the applications often include certain special features hard-coded for the schema in question (for instance, our system could send text messages to students based on their “cell phone number” field), these are typically not the main reason for using the application. Rather, people use database applications because they need to manage many different entities (students, teachers, lessons, instruments… or parts, suppliers, warehouses…) and the relationships between them. These are, in fact, exactly the kind of tasks that relational databases were made for handling well. Unfortunately, a relational database provides only the “back end”—a programmer must still be hired to develop the user interface.
Last, tailor-made applications seldom reach anywhere near the same level of maturity as more general-purpose ones. Features that are taken for granted in other applications may never get implemented in a tailor-made application, simply because the development time would not be justified for the size of the user base. In the music school system example, the developers found the table widget available in their framework inadequate for their needs, and decided to roll their own (presumably due to the limitations inherent in two-dimensional table views, see our later discussion). It was only after two years that they released a patch to allow the mouse wheel to be used to scroll the table up and down.
Ultorg is the commercial implementation of SIEUFERD, a recently completed research project from the Massachusetts Institute of Technology. It is a general-purpose user interface that provides the same functionality as a typical tailor-made database application, without requiring custom programming:
- Connect to any Oracle, SQL Server, PostgreSQL, or MySQL database.
- Instantly combine data from dozens of related database tables, and show the data on the screen using automatic table or form layouts.
- Use spreadsheet-like operations such as filters and formulas to express arbitrary database queries, without taking your eyes off the data.
- Maintain different perspectives of the data for different use cases. For instance, a customer perspective may show all the information we have about a single customer, while the product catalog may show products ranked by revenue, and which customers have ordered them. Editing can be done from any perspective.
MIT News: Democratizing Databases (July 8, 2016)
The Register: A bad day for DBAs: MIT boffins are replacing you with a mere spreadsheet (July 12, 2016)
For more information, or to schedule a demo, contact Ultorg LLC at firstname.lastname@example.org.