This post is in some ways a follow up to Chris’s previous post http://blog.soton.ac.uk/webteam/2012/08/01/fear-uncertainty-and-doubt/. Specifically:
Our software has no API (because it’s enterprise, unlike that crappy interoperable stuff)…
- ..so tough, you can’t have it
- ..and the SQL is too difficult to understand, it’s all like “table233.fieldA3″
- ..we’ll have to pay the people who make the software a fortune to get the data
This is a problem we encounter on a daily basis. We bought this thing and it does the bare minimum we needed for about £100,000. We are in an ever changing world and the requirements for the system change, sometimes before it is even deployed. At this point the enterprise solution becomes an albatross around your institutions neck. You start hearing phrase like “we can’t do that because we can’t add functionality to Banner easily” or “we can’t understand how to move our data out of syllabus+”.
Now you have a number of problems, not only can you not go forward and build the system in your grand plans, but you also can not go back. You can not go back because you have spent your £100,000, the money for this solution is spent. Even more concerning, in the unlikely event your institution will stump up the money for a project to replace this system, it is virtually impossible to get the data out (its the reason you want to replace the damn thing). This means if you find a new system that works in your new plan you have to go through a painful migration process. Add to that the potential that the system you are moving to will have the same problem by the time you have successfully done the move. What results is Enterprise Rot, you are land locked, your institution can’t innovate because your information systems are stifling you.
One thing it seems we never plan for when purchasing systems is an exit strategy. It is highly likely sooner or later, for what ever reason, you are going to have to leave your system. If you have a good exit strategy that is one less burden when choosing new systems. An enterprise solution will not have any discussion of what happens when you want to leave. Why would it? they don’t want you to leave, you are paying them. With an open source solution you download the code and try it out and find out how easy it will be to leave. Also with a good open source solution you are much more likely to be able to add functionality and export/import data so there might be less need to move.
I come from the repository world where the name of the game is data sharing. Our business is information modelling and preservation. Importing and exporting data is one of the core functions of all the major platforms. Most of the solutions are also open source which means that you have a lot of flexibility about how integrate the system into your business architecture. This makes learning about enterprise systems where this is not the case quite frustrating. I have discussed my feelings before at http://blog.soton.ac.uk/oneshare/2011/11/25/your-insitutions-data-mobility/
The Take Home
The aim of a business solution is to facilitate your business objectives. Your business objectives change frequently in response to environmental changes and often in unpredictable ways. It is vital you have solutions which facilitating your objectives not hamper them. Open source software provides some potential opportunities for exploring exit strategies before you commit to the solution.
If your institution is bogged down by enterprise disasterware tell us. It would be nice to have a list of bits of software which we should avoid buying. It would be good to have a list of bits of software which are recommended. Tell us about your personal horror stories. You can reply in the comments or tweet #disasterware. I there is any interest I might look at running something on this vein at next years Dev8D.