The Brave New World of Middleware – Part 5

February 17, 2011 · by emuir ·

Part 5: Redesigning the Modern Interface Engine

As HIMSS is right around the corner, I’m growing increasingly excited to showcase Iguana v5: our redesign of the modern interface engine.

In previous posts in this blog series, I’ve explored the headaches faced by integration engineers, the complexities in the economics of integration and the failed promise of graphical mappers.

I challenged myself to question the old assumptions of integration. I challenged my company to refuse to accept the limitations of integration engines in terms of visibility and control that users can have over their interfaces.

We changed the question we were asking ourselves from “How can we achieve integration without code?” to “How can we make code based integration work better?“. Not only did we find the answer, we’ve also opened the door to endless integration possibilities in the process.

Now I ask you to challenge yourself. Challenge not only what you expect from an interface engine but also challenge what you can do when integration is truly made easy.

I invite you to begin that challenge with Iguana v5. To explore more about what the latest version of Iguana offers please visit our Re-Thinking Integration page.

We will be proudly demonstrating the capabilities of Iguana v5 at HIMSS in Orlando next week. I personally encourage you to take the time to stop by our booth #3621 to see it in action.

I would also like to express my appreciation to those of you who have reached out to me over the past few weeks to offer your opinions and support of our new approach to middleware. I’ve thoroughly enjoyed the discussions that we’ve had.

Eliot Muir
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.

The Brave New World of Middleware – Part 4

February 15, 2011 · by emuir ·

14 Comments

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 Brave New World of Middleware – Part 3

February 9, 2011 · by emuir ·

3 Comments

Part 3: The Integration Engineer

An old friend and customer of mine once told me that the two most important tools in his job as an integration engineer were Iguana and his phone but not in that order.

The majority of his time was spent talking to his customers to determine the requirements needed to integrate his system at their site.

Off the shelf applications that instantly meet the unique needs of a given healthcare institution’s workflow are scarce at best. Interfacing can be accurately viewed as ramming a square peg into a round hole, complete with all the sweat and frustration.

My friend, as I’m sure many other integration engineers do, found himself at odds with the development and quality assurance teams in his company. They are often more formally process driven and simply don’t have the same customer facing perspective that is required of him.

Integration engineers have to be very focused on understanding the needs of their customers and be able to deal with problems as soon as they are discovered. As a result, their primary focus is the customer, not the integration tools.

The Brave New World of Middleware – Part 2

February 3, 2011 · by emuir ·

Part 2: It’s all about economics

There is an old joke I enjoy, that I think has a lot of relevance to software.

There was a guy who always cut his pot roast in half before cooking it. His wife was curious as to why he always did it that way. He replied that this was the way his mother had always done it. His wife went to her husband’s mother and asked her why she did this. The mother replied that this was the way that her mother had always done it. Finally, the wife went to her husband’s grandmother and asked her why she did this.

The grandmother replied, “It was because I didn’t have a dish large enough to put an entire pot roast in!”.

In software we often make this mistake. Our products evolve and have features added without questioning the original assumptions and decisions that led to the existing design.

This easily leads software companies to lose sight of the actual problems that they are trying to solve for their customers. I found it helpful to remind myself why people find value in purchasing middleware. At the crux of it all, it’s about economics.

Normal software economics are wonderfully profitable. Once you have sold enough units, every additional unit sold thereafter yields pure profit.

With this economic model, the cost of actually developing software can be very high as it doesn’t have to be the most efficient process.

But when you sell your software into a market where it has to be integrated, this rosy picture all comes crashing down.

The Brave New World of Middleware – Part 1

February 3, 2011 · by emuir ·

Part 1: Re-thinking Integration

There is a great deal of excitement around the offices of iNTERFACEWARE these days and I wanted to personally reach out to you and explain what all the buzz is about.

Over the past few years, I have invested a great deal of time and energy into re-thinking my assumptions about what middleware needs to deliver.

My expectations of what is needed are drastically different now than they were back in 1997, when I wrote the first version of Chameleon.

In fact, nearly a decade and a half later, there is only one core assumption that remains unchanged. The goal of middleware remains the same: to provide value by minimizing the cost of maintaining interfaces.

Unfortunately, in software it is all too easy to get lost in the weeds and lose sight of the real-world problems of your customers while you wrestle with the internals of your own code. By stepping back and seeing the actual problems for what they are, we can often find more elegant solutions.