Interview with Tim Hayes, dbPAL Developer and CEO of IT-Map
Learn about the “big picture” of SQL Server-based software development from an industry veteran.
Tell us a little about yourself. How did you get involved in databases?
I started my IT career back in 1975 – at the time when I thought I was a late entrant into the game. Now, I guess you could call me an old-timer. My first computer was a Honeywell Level 61 – built in France. I was persuaded to acquire what would be their first ‘card less’ system in Europe. So I was brought up on character-based VDU’s and COBOL. I trained as an accountant, but learned systems design and programming so that I could understand what my staff were doing. I became so intrigued with building applications and squeezing performance out of computers that three years later I started a computer software business.
Over many years we developed tools to port our applications among the different mainframe platforms, and in 1996 we founded IT-Map. I came back to hands-on development with using Delphi as a platform. I became involved in client-server applications, which meant dealing with Oracle and SQL Server. My philosophy of porting an application to the operating environment as opposed to persuading clients to invest in hardware and new database platforms came into play. Delphi was promoted as being scalable from desktop to client-server, but the reality was far from that. We soon developed tools to migrate database schemas and data to and from different DBMS platforms, and also database access components that dealt with differing I/O standards.
To me there was nothing really fancy about working with relational databases compared with the old flat file systems. The application requirements remained the same. When developing a system, I always like to get a first class understanding of the data storage and process requirements. After that, designing the database normally follows the same old principles. I occasionally try out new ideas and techniques, but by and large when you have done the job hundreds of times, it tends to be a very mechanical.
Tell us a little about IT-Map. What is the company’s main focus?
IT-Map was a break-away from our older business, which was built around COBOL-based accounting systems. Funnily enough, only last week we signed a 5-year extension with a client for some of those systems, including a report writer that I first designed and built in 1979.
IT-Map started in 1996 as a new venture intent on taking modern technologies onboard and setting out to work with a different style of client. Our first product — IT-Map 2000 — was an IT Asset Management system that integrated a degree of tracking project management. The product inspiration came from the Y2K movement, and at the time we could claim to be probably the first company worldwide to produce a proper IT system for tracking all manner (not just networks) of hardware and software and being able to map the assets onto deliverable business systems (hence ‘IT-Map’). We were very successful, with many large clients across Europe, and to a lesser extent, in North America.
In those few years we had a good look at how our many different clients were managing various aspects of IT. The horror of Y2K was nothing to do with the fixes, it was the fact that most IT set-ups hadn’t a clue where to look and what the impact might be. That is still a problem today.
Essentially, despite many good attempts and ideas, the IT industry seems particularly bad at managing itself. There are several reasons for this. The first is that one really needs to treat the management of IT in a similar fashion as an old-fashioned factory or office management. You need controls. That goes against the grain where (and I suffer myself from this) software development is considered more an art form than a science. The second problem is the pace of change and the sheer range of technology now available and installed. Life was far simpler back 20 years ago.
So, IT-Map is all about producing software products that are aimed at making life easier for IT staff and management. We take problems that, as application developers, we face on a day-to-day basis and if we see a better or different way of doing something, then we look to building and publishing a software product to meet that need. We also buck industry trends by making our products realistically affordable.