In my last article, I wrote about the very poor state of I.T ticketing tools. A comment left by Aaron, got me into publishing this article about a very interesting subject that we are all aware of, VENDOR LOCK-IN.

As Aaron pointed out, vendor lockin is a HUGE problem when it comes to ticketing systems. There is really no easy way to export your existing data from such a system and re-import it into a brand new system. This can sometimes leave companies with poor and unmaintained ticketing software. In the end, everybody loses, but the company who is raking in the profits each year from their volume licensing of their ticketing platform.

This is one key aspect I wish to change about ticketing platforms. I want to develop a system, where I can easily import my clients existing data into, for them to use almost right away without requiring much migration time. In this article, I will briefly explain how I will go about creating this type of system. After working with web development and mainly Django, I have learned quite a bit about data migration and portability. Using an Object Relational Mapper, which I believe every single application in the entire world or known universe should use, makes it easy to switch from one database to another. A Django project called South, aims to take this a step further. Rather than migrating from one database to another, it can easily migrate from one database configuration to another. This is how I will build a ticketing system, with the spirit of an ORM.

Now, you are most likely scratching your head... An ORM for a ticketing platform? How would you map existing datasets from another ticketing system into this new system? I am glad you asked. This is not as difficult as you may think it is. Basically, the existing database will need to be inspected for it's basic table format. Once the table format is known, the ORM can be made aware of this format to map each field into the ticketing platform itself. The tickets from the old system which are in a Closed or Resolved state will be Read-only. All new tickets created, will be placed into a new database using the same ORM, but support new and extended features of the new ticketing platform. Migration costs for this type of system will be rather minimal, as all the deployer needs to know and enter is the existing database connection string, and where to map each field. Most existing ticketing systems use well known and standard databases, such as MSSQL, Oracle, or MySQL. Since Python supports many database backends, one would exist for almost every database type in existence.

Django already has a pretty handy inspectdb management command, which can be easily adopted for such a system I am describing above. For more complex database configurations, the system may require some additional customizations to work. Python already supports LDAP and other authentication backends, supporting the existing ticketing systems authentication layer shouldn't be too difficult. Most larger companies authenticate via their Active Directory(LDAP), which is easy to configure in Python.

I am putting a considerable amount of thought around data portability, and the ability to use data from an existing ticketing system. Migration is going to be a key component in development. This I believe will give my product an edge over existing ticketing systems on the market. Where other ticketing tools keep you from easily migrating your data, the tool I build will not. If I need to customize the migration component to adopt to a clients existing ticketing system, I will put in all my efforts to do so. I know that each existing ticketing system on the market currently stores data very differently, but I aim at making all this data play in harmony with a new ticketing platform.

As previous commenters noted in my previous article, the lack of proper non-IE compatibility. One plan is for a mobile-accessible version for field technicians. With advances in mobile technologies with apps, smartphones and tablets, I.T. field technicians should be utilizing this type of technology. This will create a more seamless Help Desk experiencing for both end-users and the engineers working to solve the problems. However, my first goal is to build a very stable web-based solution and grow from there.

For a different take on ORMs, read
http://thoughts.davisjeff.com/2012/02/26/taking-a-step-back-from-orms/ or http://database-programmer.blogspot.com/2008/06/why-i-do-not-use-orm.html . BTW, ORM also stands for object-role modeling (a technique similar to E/R modeling). For a different approach to "ticketing", see http://esr.ibiblio.org/?p=3940 .