Brand Over Substance?

Monday 16 August 2010

I come from an age when the Spectrum was the new kid on the block. I remember the smell of the machine when I took it out its box. The comforting heat omitted from it when I switched it on and sat at it writing code for hours on end.

For those of you who don’t know, the Spectrum was a competitor to the BBC computer, Commodore 64 and later the Acorn. Despite it’s rubber keys and the need to be some form of contortionist to get the keyboard to type “Beep” or “Poke” I loved it.

I bought magazines about the latest games. I brought them to school and ended up arguing with fellow geeks about the merits of the Spectrum over the Commodore 64. Why there wasn’t enough RAM in a VIC 20, why the Oric (which made me think of the talking plastic cube Orac out of Blake’s 7) came too late and was a year too late and never going to take off.

After learning to code and writing a few games I realised that I couldn’t do things by myself anymore. Games were becoming a big business. In fact games were no longer something that could be knocked up by a spotty teenager in their bedroom upstairs. Games now required teams of graphics designers, sound engineers, testers, marketing moguls and hordes of developers.

The games Industry was starting to boom. Hardware suppliers started to build low cost, powerful gaming machines. It was GAMES WAR. It was Atari against the PC, it was the Amiga against the Atari, it was both of them against the Sega and then all three against the Nintendo. That was the start and it’s been relentless ever since.

Think of some of the technology battles that have occurred over the past 20 years;

  • Windows versus Apple
  • DOS versus OS2
  • VHS versus BETAMAX
  • IE versus NetScape
  • iPod versus Walkman
  • Sky versus BSB
  • HD DVD versus Blue Ray
  • Sega versus Nintendo
  • Play Station versus XBOX
  • Google versus MSN
  • Sky versus Virgin Media
  • iPhone versus Blackberry
  • iPhone versus Android

All of these have been great products but there is only ever one winner. Is it always the best product? What is it that makes the winner “float to the top?” Is it the quality of the product or is it the way the product is marketed and branded?

As a consumer what do I want? Do I want the product that everyone else has or do I want the best product? Personally I want the best product. I don’t go for designer labels and I don’t go for things that are in vogue, I go for the things that make a difference to me, make a difference to my business and above all helps the bottom line.

I run a software company that writes bleeding edge technology. This is my story about why we do what we do and why I think that what we have is all about substance. For us the brand comes second however if we get that right too then perhaps someone will write about us in the future and see us as “remember the way things changed in BI? Remember Connexica versus Business Objects, remember Connexica versus Microsoft?

When I started my life as an IT professional, I was an analyst programmer specialising in COBOL and IDMSX on ICL mainframes. It was not long before I got into Oracle and enjoyed the delights of SQL, Oracle Forms 2.3 and Report Writer version 1.0 (which was shocking…)

I then moved onto SQL Windows, Ingres, Informix, SQL Server, DB2, C, C++ and finally Java with a bit of .NET before I decided enough was enough – get other people to do the programming as keeping up–to–date with new technologies and standards is a young mans game!

Throughout this time, I concentrated on data access and management information solutions. Designing applications to put data into a database and finding ways of getting it back out again – what a fulfilling career!

All sounds simple, in fact it really is however despite your best efforts you can only do as good a job as the tools that you are using will allow.

If the database does not support stored procedures or functions you end up writing more code and things tend to go slower. If you need to program in a language that doesn’t have very good de–bugging facilities you end up having to take twice as long and resort to adding loads of print statements and stack traces to help you identify where you are in the code when things go wrong – back in the 80’s, the Spectrum had no de–bugger so I was in my element here!

Up until the last 10 years of my career I had no say in what software languages we used or what database technologies we adopted. They were all chosen for different reasons. Some because they were functionally great but the majority because they had a good brand and the guy making the decision felt a “warm glow” when they spoke to the supplier (as if things didn’t work out they could always defend their position by the fact the supplier was in the magic quadrant at Gartner or had a balance sheet that RBS or Northern Rock would have died for).

Throughout this time I battled to create the best software solutions possible based on the raw materials I had at my disposal. I was pretty successful although if these solutions were re–produced today using the latest and greatest, the users would have been blown away.

One of my greatest loves was SQL (Structured Query Language) which I learned on a series of excellent Oracle courses in the late 80’s. A lot of what I programmed subsequently was around accessing databases, and I became pretty good at getting the best out of Oracle and applying what I knew to other databases “to get data out” that either I or someone else had managed to “get the data in”.

I grew to be (and would like to think still am) a SQL expert who could write line after line of SQL to navigate around the most complex of database schemas to return the relevant data rows back to the screen or a report. Twenty years of experience meant that SQL was no trouble to me.

Unfortunately, in later years, implementing solutions to customers, I found that end users and other IT departments did not share the same depth of knowledge that I have in “getting data out of a database” (perhaps this is because they didn’t know how to “get the data in?”) and struggled to use the same tools I grew to love as a serious software developer.

I now realise that getting data out of databases is not easy. It requires a lot of expertise in understanding where the data is, how to get at the data and how to bring it back in a meaningful form. Let a user loose on a database who is not a “professor in databases” is like letting a tourist attempt to translate a foreign paper when they don’t understand the language. They may understand part of it but will never see the full picture.

5 years ago I got all excited about search technology. It wasn’t new but I was starting to use it more and more to find “stuff” on the web and was amazed how easy it was to get results and how quick it was to get answers to the most bizarre of questions. The fact the answers were somewhere amongst several million search results was irrelevant to start with, I was simply amazed at the scale and the speed of this new technology.

It was not long before I formed a few ideas in my head about how searching for stuff using a search engine was child’s play and how searching for stuff in a database was for the “weird and unwashed” – like myself.

“What would happen if we used search technology to search databases?”

“How great would it be if people that understood the business but didn’t understand SQL could finally get at their data?”

From this idea came CXAIR – A business intelligence tool that takes the best elements of search engine technology and combines them with the best elements of business intelligence. A master stroke!

It’s super fast, easy to use, easy to implement, based on the latest technology, an evolutionary leap from other business technology that sits on top of the now legacy database systems however… we’re not Microsoft. We’re not Oracle. We’re not Business Objects.

I run a UK company with a team of extremely gifted geeks who like me love software and love “getting data out” of systems – they’re not too bothered about “getting data in” as we leave this to the database specialists because after all databases are designed for “storing data” not “retrieving data”.

We understand business intelligence but don’t have the legacy the big boys have and have been able to come up with something that is fundamentally different from any other BI tool. It’s easy to use! It’s lightning fast! It’s installed and working in under a day!

We are all about substance. What we have is real and not over-egged by some giant marketing machine. What we have is amazing. Give us a call and we’ll show you what we mean.

Contact or email me personally at

Get in touch to discuss your requirements further