Part 4: The failed promise of graphical mapping
In the first post of this blog series, Re-thinking Integration, I explained how I have spent a great deal of time examining my assumptions about what middleware needs to deliver.
At the forefront of my original assumptions was my belief that the majority of mapping could be done graphically with only a small fraction requiring scripting.
The reality that I’ve personally observed in my customer’s integration projects tells a very different story. The amount of code used greatly exceeded the amount of work that was being done graphically. In fact, it was looking more like 90% scripting and 10% graphical mapping.
It was quite humbling to be honest. Here we were trying to deliver graphical mapping tools when customers relied heavily on scripting.
While I recognize the error in this misconception, it is one that is shared across our industry.
The entire middleware industry is built up on the promise that integration can be achieved “without programming”, that it can all be done with graphical point-and-click mapping.
It’s a nice and enticing marketing message. Unfortunately, it does not appear to be true.
Why do graphical mappers fail to deliver on their promise?
The over promise of what GUIs can deliver is not a phenomena that is unique to our industry. Since the 1970’s there have been countless claims of products that would eliminate the need for programmers.
Remember the HTML editor Front Page from Microsoft? On the surface it appeared simple, but behind the scenes it was really just hiding all of the ugly HTML code it was generating.
That is often the case with graphical solutions to technical problems. They appear to offer huge benefits and cost savings to the end user – and do offer the means of a temporary solution to relatively simple problems – however, this ease comes at the expense of true control over your solution.
If you talk to any web developer and ask what they would do if they had to expand a website designed with FrontPage – or any other drag-and-drop editor – nearly all of them would say they’d throw away the code and start from scratch.
Graphical tools often make it less visible to see what is really going on ‘under the hood’.
Can’t we build a better graphical mapper?
Though I now know better, I initially and perhaps instinctually stuck with my original assumptions: that we needed to make a better graphical mapper. I resolved to make a graphical mapper that was more flexible and avoided the need to resort to writing code.
However, with every prototype, I continued to face the same problems that every graphical mapper runs into:
- It’s difficult to comprehend the order in which data is transformed. The order of execution is not intuitive or transparent.
- They work for simple problems (such as scenarios often displayed in sales demos) but quickly become overwhelming with the complexities of real-world integration problems.
- They don’t handle conditional business logic that occurs frequently in real-world interfaces well.
- They tend to be awkward at handling issues relating to repeating parts of the data being mapped.
- It’s often hard to find the functionality you are looking for nested deep down in a GUI which makes them time consuming to learn and slows down experienced users.
It seems that every general purpose middleware product that I have ever looked at is following the same unimaginative design. They all seemed very cumbersome.
As a programmer, I appreciate code. I like the flexibility it gives. Why not embrace it and love it? Instead of trying to make tools to eliminate code, make tools that allow customers to take control and overcome the challenges they face with it.
Why not take a completely different approach to middleware?
The question I was asking myself had changed from “How can we achieve integration without code?” to “How can we make code based integration work better?”.
I’ve never seen a graphical mapper that does a better job dealing with real-world integration logic than what can be achieved by using plain code.
Instead of trying to replace code, we need to acknowledge that it is the most efficient way to implement transformation logic. The focus needs to be placed on making tools that suck the cost out of writing and maintaining that code.
Why not make a new unconventional GUI that makes scripting easy rather than trying to replace it?
That’s exactly what we’ve done. While Iguana 5.0 still contains our graphical point-and-click mapping for simple integration problems, it features this new innovative approach to middleware by making scripting easy.
Iguana 5.0 will be on display at HIMSS next week at our booth #3621, so if you’re going to be there, please stop by and see it for yourself.
I urge you to stay tuned for the next and final post in this blog series, where I will focus on the specifics of what Iguana 5.0 delivers.
President and CEO, iNTERFACEWARE™
Remember to subscribe to our blog or follow us on twitter (twitter.com/interfaceware) for product updates, future resources and discussions.