Isotupa Consulting Inc.
473 Oakfield Crt.
Waterloo, Ontario, N2T 1X5
tel. 519 885-5187
June 14th, 2003
Dynamic data structures and stable applications
The headline of this article seems to contain a paradox. The corporate reality is that most data structures are evolving as data needs change over time. This usually means that applications using these data structures have to be upgraded. Software upgrades usually cause havoc in the organization as they are either initially unstable or work in a different manner than users are used to. In this article, I compare different options that are available for the software developer to help his end user organizations to maintain their applications with evolving data needs.
The first and most common option is to use the vendor defined data structures for the application. I have not yet encountered any client organization that is satisfied with using vendor defined (forced) data structures – they all seem to have their own specific needs. If an application is not meeting the data needs of the users, it leads to a low user buy-in and significant losses in productivity. If data is not essential or is not shared between multiple applications this option may be acceptable. Significant drive has also been made to create industry standard data models, but these models tend to be based on the lowest common denominator or have lots of unnecessary package. If the software developer completely controls the data structures, the user interface can be made very rich through custom made editor forms. There are also many source code or ASP code generator tools to allow quick creation of the base coding from the data structures.
A second option for the application is to edit data through a dynamic data grid that links directly to database. That would allow data structures to be changed dynamically. There are several drawbacks to these tools as the entered data is not validated while it is being entered. The application itself must be very primitive and it can have very little control over the data being edited. This may be good enough for a prototype or for a one-off project tool. But it will not have the appearance of a professional application.
A dynamic data-editor could be the answer. This kind of tool allows sophisticated control over the editing process and the appearance of the data editor. This tool is a must for asset, inventory and other data rich applications where the end-user organization maintains – and changes – the underlying data structures often. Of course, the application architecture and business logic has to be cleverly built around this tool to allow these data structure changes by the end user. Fairly sophisticated data validations can be built to occur at runtime. However, everything that can be achieved in a custom made editing form may not be possible to perform in a dynamic form. For an application that performs a lot of “tricks” or special actions at GUI, has a stable backend data structure and doesn’t integrate with corporate databases, the dynamic editor forms are not necessarily a good answer.
A developer should aim to let the end user organization to maintain and customize as much of their database backend as is practical. Should an application really care if customer A likes to enter purchase dates for their ‘Whatsmacallits’ as a required field and customer B does not have purchase dates for their data, also customer B does not want to see any purchase date fields and their corporate backend doesn’t allow this data. This can be done without customized (maintenance nightmare) versions. Try using our ICI Data Editor Form toolkit to code this maintenance magic into your applications.
Peter Isotupa, M.Sc (Tech)
Isotupa Consulting, Inc.