Updating Systems by Parts

One of the biggest problems about systems update is the offline system time for the end user. Mostly when the actions and changes are in the Database. As big is the amount of data and size of the database, as long it will take your system offline.

Was that necessity in decrease this time that a company for which I do database consulting, brought me. I had the need to imagine an update strategy in their systems in a way that the end user would stay less time as possible with offline system, or at least, with a minimum of impact in the customer operation.

The major trouble about it is to fit the software version with its correspondent database structure. Of course, when this update leads to a database structure change, as table creation, columns, etc. In a hot update, with users using the system, you can even get the database modifications, depending on the database, but there will be a moment, in some parts of the system, that might occur errors due the difference of database structure on the tables.

Was thinking about it that I suggested a modification in their update release process of database scripts and programs. Even their data structure didn't have been made in a modular way, at the beginning, I thought on a way tot ry to modularize its update, affecting only some company areas at time. In that way their customer IT team would also prepare and schedule their system update by areas.

For example, if the company has a reception area, products supply, billing and a research & development area, they can plan system using by areas, according to the timestamp that will less impact the area. As update the reception software in the time which their have less activity in that area, or the supply software in that time where they less do products movement, etc.

The process in its general way is quite simple. There will be an initial request for update. In this request the company will also prepare the database scripts, documentation and correspondent software version. Then there's come the main process. Those database scripts will have to be prepared according to the programs that uses that specific database tables. There will exists a group of core tables, which are common to most of the programs. Surrounding those core tables there will be the specific tables used by each program. As for example the supply program must have tables which are used just for this part of the program, and so on. The process output will be the update logs and the updated product (software and database structure).

We had a pilot with this new process into one of their customer and, instead of some small problems and adjustments, everything gone well and we had a nice feedback from this customer. Now is keep the process running and maturing for the next updates and releases. And my work here is done!