System modernization and System design

Modernization efforts come in varying levels of complexity. We recently undertook a modernization initiative for a client who wanted to migrate their existing database portfolio from Sybase to Oracle. While Oracle's SQL Developer helps with migrating the database and its various objects, the applications talking/connecting to these databases have to be remediated manually.  It is during such times we see the importance and value of time invested in good system design.  

A lot of the applications we encountered for remediation followed a consistent design. At a high level, one could view that design as an application made up of a stack of three horizontal layers - UI, Business Domain and Data Access. Most applications also consisted of a testing layer could be seen as a vertical layer, that tested one or more horizontal layers. For the most part, the unit tests (part of the Test layer) would test the Classes of the data access layer which comprised of Data Access Objects (DAO's) and Data Transfer Objects (DTO's), but because of the clean separations of the various layers you could in theory test any layer. While I am not going into the details of what each layer does, it’s not hard to guess what each layer might be doing.  

What I described in the last paragraph are two very simple things, 1) Structuring or designing the application layers such that boundaries with interfaces are enforced and in place and 2) consistently following a simple in design/structure across multiple applications.  In my opinion, as simple as these things are they matter a lot in the long term. The code written for one of these layers could be horrible but if the boundaries are enforced with well-defined interfaces, a change effort -of any kind- could be undertaken fairly easily.  An example could be that DAO layer is implemented to work with a specific RDBMS product today but in the future can be modified relatively easily to incorporate a ORM based RDBMS neutral approach or  a different RDBMS which was our case. I am giving an example of the DAO layer but this idea can be expanded to any of the layers that you find in today’s business systems.

I think in this day and age, business systems should be architected and designed for change more than anything else.  And change is best accommodated when systems are simple to deconstruct. When I write code, I deliberately re-prioritize why I am writing it, at first, for me or somebody else to read and understand, and then for the computer to execute. The computer could care less how you wrote the code. If it was just for the computer you might as well write in 0's and 1's. Note that this does not mean sacrificing on time or space efficiency choices. The same way when making design choices I put them in the context of long-term change and maintainability.

More often than not, these simple steps result in software that is relatively easy to maintain for most non-edge case scenarios. Code and Design that is fluid and can adapt over time is one of the most important things, especially in today’s time when requirements and business needs change so quickly. So the next time you work on a design or write code deliberately, change your thought process and see if that results in a better design. Worst case, you can be confident that you have explored different options before finalizing something.