The business world deals with change constantly. Whether internally initiated or driven by external forces, there are always business, technical and even social pressures ready to drive a change in the way companies function.
This naturally has an impact on IT systems, specifically the applications business needs to function effectively. Every business application must therefore be flexible enough to regularly adapt to changes without requiring extensive reprogramming and redesign. The alternative is to have costly software turning into a legacy application in as little as three to four years.
Given the rate of change in business today, once an application is implemented there will already be certain factors that need to change, and the demands for modifications will constantly increase over time. There are three primary reasons business software will have to be changed:
* To adapt to functional changes in the business.
* To adapt to business model changes, such as moving to software as a service, organisational upscaling or downscaling, mobile interfaces, Web service centres and more.
* To cope with technology changes.
An obvious point to start to ensure your application does not become a legacy application as soon as it is deployed, is to ensure that your architecture enables it to adapt to constant change. You should evaluate the software architecture for the following quality attributes:
* Conceptual integrity.
The architectural concepts of cohesion, coupling and encapsulation can be used to evaluate the modifiability and variability of your design. Low coupling refers to a relationship in which one module interacts with another module through a stable and well defined interface where implementation specifics are well hidden through encapsulation. High cohesion is achieved by grouping related functionality together.
When designing your system, you follow a certain methodology and strict design guidelines, but very often these are abandoned once the application is live and business pressures dictate change. A critical success factor in the ongoing maintainability and agility of your application is how well you can protect the conceptual integrity of your application while still performing day-to-day maintenance.
Central to ensuring application integrity is the ability to distinguish between the core of the application and periphery. At the heart of the application are the key processes.
From the core of the application you should provide integration points. The goal of these integration points should be to allow implementation specific functionality to be added or manipulated while not affecting the application integrity. Using the integration point mechanisms, you can also allow for the integration of periphery and third-party applications while defining clear boundaries beyond which additional systems cannot proceed.
The core of the application will exist for a decade or two. Any changes required come at a high cost because they affect every other component of the application, and therefore it is important to protect the integrity of the core to ensure future evolution of the software.
When developing your system, you start off with your design and coding comes second. When maintaining the system, the code will be modified and over time the integrity of the system and its structure according to the original design will gradually fade. Refactoring is the action of working against this decay of the code. Refactoring is the process of changing software in such a way that it does not alter the external behaviour of the code, yet improves its internal structure. It is a disciplined way to alter code in order to maximise code re-use and minimise the chances of introducing bugs.
Ensuring that you have exactly the right balance when refactoring your software requires a combination of knowledge, skill and experience in the technical as well as business environments of your application. To help achieve this balance, system refactoring should have clearly defined goals to ensure that your refactoring programme enhances the conceptual integrity of your application.
Keeping your solution current is a continuous process and requires a combination of skill and experience. From my experience, I can recommend the following:
* Good design and architecture costs more initially, but pays off as the system ages. Investing in good design from the start will also make implementing changes easier, faster and generally less costly.
* Stick to your design principles during the maintenance portion of the application lifecycle.
* Evolve your design and application framework using refactoring methods. Ensure that refactoring serves to enhance conceptual integrity.
* As applications grow, they become exponentially more complex. As complexity increases, you have to increase your quality goals in line with the complexity curve.
* Listen to the hints suppliers and the rest of the industry provide. Vendors will indicate future directions by labelling functions they plan to discontinue, or maybe by dropping subtle hints about 'fresher' versions of the function. When these hints are issued, it is time to move off that piece of software or functionality and onto the recommended way of doing things. If you postpone this action until the vendor announces two years later that the function/software is now definitely discontinued, upgrading or migrating will be much more costly.
* Understand the technology hype cycle. Not all new technologies will have an impact on your application or business. When such a new technology arrives on the horizon, you need to be aware of the technology hype cycle. Expose yourself to as much information regarding this technology as possible. This will help you to develop your own radar in order to evaluate the hype cycle and, using this information judge whether and when new technology will have an impact on your application or business.
The cliché that states change is the only constant is more relevant today than ever before. Fortunately, with the appropriate planning and forethought, business applications can be designed and maintained to be flexible enough to allow for regular updates without having to re-invent the wheel for each change.
JC Oberholzer, software architect at SDT Financial Software Solutions
For more information contact Sumari Lottering, SDT Financial Software Solutions, +27 (0)12 360 0100, email@example.com