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.
Tell Us
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.
I think that linked data (both open and internal-only) is going to shake up this aspect of the enterprise world. We’ll probably see a round of attempts to lock you into their linked data solution, or other daftness.
That said, UNIT4 (who make our financial system Agresso) have seen the way the wind is blowing and are talking to us about how their systems can facilitate linked data, both open and internal. This is heartening.
Once a few key bits of infrastructure do this by default, we’ll hit the tipping point where data mobility (is that a term?) starts to be a question in new data-system procurement.
The wheels of our central IT grind slowly, and sometimes frustratingly, but we’ll get there, one dataset at a time.
ETL software can simplify your exit strategy. And your update strategy. And your Reporting strategy. Emphasise on can, obviously it still requires effort and access to people with sufficient business knowledge.
Thanks Patrick for sharing your experience, this reminded me of something I read about ‘vaguely” a while ago:
http://open-services.net/
their focus is on using linked data principles to enable lifecycle integration between different tools.
Since I didn’t read much details about them, I don’t know if they would be of any good in this case. But they seem to have some influential SW vendors as members, which could indicate that these vendors may have some software (beta?!) that abide by the standards OSLC.
In their specifications http://open-services.net/specifications/
under “Integrated service management” there is
“Reconciliation” in which they discuss data integration.
So hopefully the future would be brighter, but history could be repeating itself.