Change is inevitable. Long-lived systems must be insulated from change, but must embrace change when the time is right.
Business constantly evolves, and changes to business processes and requirements force change on IT systems. Even if your business is stable, changes in your business partners will force change on you.
Technology constantly improves. You need to upgrade to the latest technology to give you the capacity and performance to meet growing business needs. You need to keep on supported versions, and that means you have to keep upgrading all your technology in step. Suppliers fail, and their products need to be replaced.
There is a never ending need to comply with new rules, both external regulations and internal standards and policies.
You can reduce the impact of change. Decoupling stops changes in other systems affecting your system. You can pick technologies that make it easy to stay current. You can design your system to evolve elegantly. But eventually your system will come under pressure to change.
For long-lived systems, the rule is simple. Change as soon as the requirement is clear. Keep up to date. Do not leave it until later. Your system may cope elegantly with, say, out-of-date technology or data differences, but this is not a reason to let your system slip behind. It is an opportunity to keep your system up-to-date even if other systems are not so flexible.
When you are updating your system, do a proper job. Do not just tack add-ons to the code, but refactor the code as if it had been designed to work in the new world. Change the documentation. Change the test packs.
Sometimes systems are not changed because it is not "justified". This is wrong thinking. You can not justify maintenance in the same way that you can justify projects. There is no obvious payback for many changes. Instead, you have to consider the cost of not making the change. If you do not keep a system up-to-date, the system will die and will need to be replaced prematurely. Your fifty thousand pound upgrade needs to be compared with a two million pound replacement.
Some find that keeping up-to-date is unacceptable because it is expensive and disruptive. I understand this, but avoiding maintenance is not the answer. If keeping up-to-date is too expensive or disruptive, put more priority on managing system life span, decouple more, select technology more carefully, design more carefully. This lets you keep up-to-date at low cost, with little disruption. Using cost and disruption as excuses for letting systems fall behind is completely irrational because the cost and disruption of not doing so are much higher.
To keep up-to-date, you need to understand when and where change is needed. Although it is easy enough to look at one factor (like database version) on one system, it is hard to keep an eye on everything across all your systems, all of the time. Next week I will cover what measurement and monitoring you need to identify when and where you need to change.
© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Tuesday, 24 April 2007
Tuesday, 17 April 2007
Long-lived systems: design
Long-lived systems do not just happen, they are designed that way. Long-lived design involves keeping things simple, and being risk-averse to the point of paranoia.
Long-lived design is common sense, but we rarely do it. The key to long-lived design is to assume that everything within and around your system will have to change. Nothing, not even your system, will stay unchanged.
Reduce the impact of change by decoupling your system from all other systems. Make no assumptions about the technology, data, location, processing or timing of any other system, except for defined flows of data and control. Do not take a short cut because your system is "short term" or the other system is "strategic". Be paranoid: your system or any other system could change tomorrow, or last for ever.
Do not expose the internal structure of your system to other systems, but do decouple the main internal parts of your system from one another. Clearly separate data, processing and user interaction. Base the interfaces between these on well-established standards. For example, communicate with your database using standard SQL - do not use proprietary access methods or extensions.
In longevity terms, not all designs are created equal. Client/server designs are particularly brittle. They require a strong coupling between the client software and the client machine, and a very chatty interface between the client and the server which is difficult to decouple. A simple web-based design is likely to be much longer lived.
Often your design will include commercial off-the-shelf (COTS) products as part of the system. Use established standards to integrate these, rather than the proprietary methods of the COTS product. This makes it easier to swap to another COTS product if you need to.
When designing decoupling (between your system and other systems, or within your own system), use established standards. It makes sense to encapsulate interface access points so that interfaces can be changed easily, but simple hand coded programs are usually best. Do not write your own decoupling framework.
As well as decoupling, design your system so that it can be clearly owned. If any part can not be clearly owned, it will not have the clarity of direction and decision required to keep it current. Designing architectural layers (such as "web servers", "application servers" and "databases") that are shared by multiple systems means that nobody can properly own the systems. It is OK to physically share hardware or server instances, provided that the systems within them are clearly separated and can be clearly owned.
Lastly, remember that every part of your system will have to be changed. Chances are, it will be changed by someone who is not half as clever as you. If you keep things simple and standard, they will do a good job and keep the system in good condition. If the design is too sophisticated, they will mess things up and condemn the system to early retirement. Simple design is long-lived design.
© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Long-lived design is common sense, but we rarely do it. The key to long-lived design is to assume that everything within and around your system will have to change. Nothing, not even your system, will stay unchanged.
Reduce the impact of change by decoupling your system from all other systems. Make no assumptions about the technology, data, location, processing or timing of any other system, except for defined flows of data and control. Do not take a short cut because your system is "short term" or the other system is "strategic". Be paranoid: your system or any other system could change tomorrow, or last for ever.
Do not expose the internal structure of your system to other systems, but do decouple the main internal parts of your system from one another. Clearly separate data, processing and user interaction. Base the interfaces between these on well-established standards. For example, communicate with your database using standard SQL - do not use proprietary access methods or extensions.
In longevity terms, not all designs are created equal. Client/server designs are particularly brittle. They require a strong coupling between the client software and the client machine, and a very chatty interface between the client and the server which is difficult to decouple. A simple web-based design is likely to be much longer lived.
Often your design will include commercial off-the-shelf (COTS) products as part of the system. Use established standards to integrate these, rather than the proprietary methods of the COTS product. This makes it easier to swap to another COTS product if you need to.
When designing decoupling (between your system and other systems, or within your own system), use established standards. It makes sense to encapsulate interface access points so that interfaces can be changed easily, but simple hand coded programs are usually best. Do not write your own decoupling framework.
As well as decoupling, design your system so that it can be clearly owned. If any part can not be clearly owned, it will not have the clarity of direction and decision required to keep it current. Designing architectural layers (such as "web servers", "application servers" and "databases") that are shared by multiple systems means that nobody can properly own the systems. It is OK to physically share hardware or server instances, provided that the systems within them are clearly separated and can be clearly owned.
Lastly, remember that every part of your system will have to be changed. Chances are, it will be changed by someone who is not half as clever as you. If you keep things simple and standard, they will do a good job and keep the system in good condition. If the design is too sophisticated, they will mess things up and condemn the system to early retirement. Simple design is long-lived design.
© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.
Subscribe to:
Posts (Atom)