In a previous blog I suggested 3 rules for Protecting your Software Investment from “yourself” — i.e. your own need to integrate, enhance and extend your Enterprise Software Systems:
Now we will dive deeper into what I mean with these three terms, starting with “separate”.
Let’s look at this from the reverse point of view. You have adopted a really useful IT system. It is making your business more competitive. Your natural tendency is to make “more” use of it, isn’t it? What does “more” look like? Certainly new reports to extract information in the best form for your organization. Where are they going to go? Probably into the “reports directory”. You go further and decide to create views of the system’s data to facilitate analysis. Where are these likely to end up? Directly in the system database. Your IT person suggests a stored SQL procedure to automate some data processing or a script, or a tie in to another IT system. Someone adds a table or a column to the database. All of a sudden, like they say in the tourist gift shop — “You broke it, you own it!”
Typically these things start very informally and then evolve under their own momentum until your vendor notifies you of a major upgrade, and you realize that you can’t deploy it.
Why can’t you deploy it? Your IT team cannot tell you what impact the upgrade will have, because they didn’t design it. Your vendor can’t, because they do not know all the changes you implemented. The only thing that everyone knows is that if it breaks your system, it is quite possible that you will NOT be able to safely go back to where you were before. That is not acceptable. So you don’t upgrade.
Separate in this context means: you do not try to stop “add-ons” growing up around the core system, but the day you install it you set the policy that all add-ons, even “just” reports, must be kept separate from the core system. Here are some directions to keep your IT separate:
- Reports go in a separate “our reports” directory.
- Views go in a separate database, as do stored procedures and if you must have them, add-on tables.
- Extra database table columns go in the separate database too. Yes, it is clunkier, but the cost of incompatibility far outweighs the inconvenience to the person who is proposing to add them. If that deters them, then the value of the extra data might not be that great after all.
- Extra scripts, web pages, etc go in separate directories. If that is not technically possible, then the change should have to be justified to management, who should be resistant, and if approved, then documented.
- Changes to executable code should be strongly resisted. If unavoidable, they should be carefully documented, including where the original executable is kept and how to reverse the changes before an upgrade.
So now our system is “clean” and can be safely upgraded, or replaced, in the future. We are still going to allow integration and enhancement, so how do we control that? More next week!