Recently, Eric asked me to speak at one of our company meetings about the future of the OpenSpan platform. He didn’t want me to speak about releases or features, but rather about the platform as a whole. What is our vision for the OpenSpan platform?

This is actually a topic I think a lot about. For every feature we design and every release we plan, I ask the question: “How will this push the platform forward?” One of the things I think we’ve done very well at OpenSpan is to stay true to the principles that led us to create OpenSpan in the first place. When Stephen and I first started planning the platform we each brought two sets of distinct experiences to the table.

Stephen had spent the past several years creating visual programming environments. He believed strongly that the barrier that prevented more business analysts from programming was not the concepts of programming but rather the syntax of programming. Ultimately, many of the concepts programmers use everyday, conditions and loops in particular, are familiar to every advanced Excel or Access user. Other concepts, such as types, casts, threads and objects are either unnecessary for many tasks or presented in such a way as to be impenetrable to the lay person. Stephen was committed to providing an environment where business users could develop or participate in the development of automations.

I had spent the past few years creating custom desktop automation solutions for enterprise customers with diverse application requirements. I had become painstakingly familiar with the available APIs: COM libraries for Lotus Notes, Internet Explorer, Office, Siebel and others; MSAA and windows functions for Win32 applications; HLLAPI, EHLLAPI, etc. for mainframe emulators. I had also become painfully familiar with the limitations of these APIs: narrow or incomplete APIs; little or no support for events; frustratingly inconsistent implementations of supposedly standard APIs. My experiences had convinced me that there was a better way to automate these applications.

In our very first face to face conversation, Stephen and I decided two things: OpenSpan would be accessible to both developers and non-developers and OpenSpan would be completely reliable. If you clicked a button with OpenSpan, it would click every time.

I would be lying if I claimed that we knew that these principles would lead us to our current automation engine and injection library. Some ideas like controls, targets and match rules evolved quickly. Other ideas like asynchronous links and keys evolved in response to customer requirements. Whatever happened, though, we stayed true to our principles. When we reached the limits of message hooks and accessibility interfaces, we scrapped them and wrote an injection and hooking library from the ground up. When we encountered a control we didn’t support, we reverse engineered the platform to get at the real object. When a public interface didn’t supply the events we needed, we made our own with some well placed hooks.

Over time, some new principles evolved:

1. A button is a button is a button. In other words, hide the platform implementation details. Every control in OpenSpan should act the same regardless of the actual platform.
2. Never hide functionality. If a platform provides functionality that another platform does not provide, expose it. A great example of this is HTML controls. They follow the same pattern as other OpenSpan controls, but add extra properties to manipulate the inner HTML, set attributes, etc.
3. Always talk to the object. Pretty quickly it became apparent that every time we tried to take a shortcut, it burned us. GDI hooking. Sucks. MSAA. Sucks. Message hooks. Suck. There’s always something to tweak or modify or re-implement for each environment. The only API you can rely on is the one the original developer of the application used. So what if it’s not exposed? Sure, it takes more time initially, but we only need to do it once and then it works every time. I’m very proud of the fact that OpenSpan implementations never need engineers on site to develop integrations. If there is a control we don’t support, we write a translator and publish it for all of our customers. One and done.
4. Know everything about the object. It’s not enough to talk to the object. We know when an object is created. We know when an object is destroyed. We intercept events before the object receives them. ‘Nuff said.
5. There is no such thing as too advanced. Early on we had a debate about threading. Should we hide threading from our users? Should the platform make threading decisions for them? Ultimately, we decided not to hide threading because doing so would inevitably limit our users. We made threading accessible by making it easy to visualize. Do people screw themselves up with threading? Sure, but people burn down their house with turkey fryers every year too. That doesn’t mean fried turkey doesn’t taste good.
6. Developers do not always want to drag and drop. This one is pretty obvious. Even though we want the platform to be accessible to non-developers, we want it to be just as accessible to developers. For developers, sometimes it’s just easier to write code. And when it is easier, there’s nothing more frustrating than not being able to. From the very beginning, we made sure that developers could write C# and VB .NET scripts and use their own .NET components in automations.

So what is our vision for the OpenSpan platform?
OpenSpan was built from the ground up to be a accessible and reliable desktop automation platform. Those two simple words, accessible and reliable, have directly guided the evolution of our most valuable IP: automation and injection. Our vision is to extend those two technologies into new areas. We are actively working on new ways to expose them to developers including our upcoming Visual Studio plug-in, Lotus Expeditor container and translator SDK. We are also working to apply these technologies in new environments. In the future, we will move beyond the desktop to provide automation and injection on the server. When we do, you can be sure it will be just as accessible and reliable as our current platform.

As many of you know, OpenSpan began making a big push into SOA technologies last year. We even came up with a new marketing slogan: “OpenSpan the last mile of SOA.” While we’ve always had the capacity to consume web services, we wanted to add the ability to expose our automations as services. This culminated in the announcement last week of the OpenSpan Platform SOA Desktop Edition, which allows you to create an automation within or across applications and then expose that automation as a service deployed on the desktop (we call this desktop service enablement). While many of our customers are very excited about this new capability, I have been asked by others “that’s cool but what’s the point?”

I have to admit this reaction makes me want to jump up and down screaming: “What’s the point! What’s the point! Are you kidding! This isn’t just cool! This is totally freaking awesome!”

But… after taking a deep breath, I realize that this is really our fault for not explaining ourselves clearly. As anyone who’s read my blog knows, I think the software industry has treated the desktop environment like some provincial backwater for a quite a while now. Sure you need it to keep your empire running but you sure don’t want to go there if you can avoid it. Even though most of us spend most of our working lives in the Windows environment, the desktop is just the place everyone’s applications happen to end up. All of the cool stuff happens on the server.

Gradually, that opinion seems to be changing. ClickOnce, JNLP, WPF, Adobe Flex and other emerging desktop technologies are using the web as a delivery mechanism while using the power of the desktop to create rich interactive applications for users. Even Web 2.0 and AJAX are examples of this trend. The server delivers the HTML and JavaScript for the site once. After the initial delivery, all of the presentation and interaction logic runs on the desktop, only calling the server when new data is required. However, one thing hasn’t changed, once these applications get to the desktop they are still running in silos, usually isolated from the rest of the desktop for security purposes and unable to interact with the desktop environment.

OpenSpan desktop service enablement is the platform that allows these applications to integrate with the rest of the desktop. With OpenSpan services exposed at the desktop, these applications can now call services on the local machine just like they would their own backend services. What if your AJAX portal could now display not just data from your backend, but from your soft phone running on the desktop, the host system with your billing data, and your Java email application? What if your users could click a link in the portal and generate calendar invitation in Outlook? What if they could click another link and start an automated billing process?

OpenSpan desktop service enablement allows you to integrate any server delivered application with the rest of your desktop. Now, instead of using OpenSpan windows forms, you can create a user interface using the technology of your choice but still use OpenSpan to pull and push data, invoke automations and respond to events. Instead of being a “dumb” application that OpenSpan automates and monitors, your application can be a “smart” application that interacts and controls OpenSpan. That’s not just cool, that’s totally freaking awesome.

When we first started OpenSpan we didn’t really have any marketing. When it came time to produce some glossies, we all sat around the table trying to come up with a good catch phrase. We kicked around things like “Empowering Your Enterprise Applications” and “A Remote Control for Your Enterprise Applications.” Sometime during that discussion I suggested “Do It on the Desktop.” It was short, funny and memorable. Plus, it would make a great trade show t-shirt. Mostly, however, it summed up our philosophy really well.

Unlike most of our competitors, our technology started on the desktop and was designed for the desktop. From the beginning we did more than just automate applications. We added functionality. We modified behavior. We responded to events. We saw the desktop as the forgotten foundation of the enterprise. Every knowledge worker spends most of their day in front of a screen, moving windows around, entering data, cutting and pasting. We knew we could make those users more productive if we just made their applications work together.

In the end, we didn’t make “Do It on the Desktop” our catch phrase. Since then we’ve gotten a marketing department and they’ve come up with some great catch phrases like “The Last Mile of SOA” and “The New Enterprise Desktop.” For the technology organization, however, our catch phrase will always be “Do It on the Desktop.” I’m still hoping for some t-shirts.