Without a doubt, many of our customers see significant benefits when they automate their end user tasks. Some customers have seen over $25m a year in time savings in their first automated solution rolled out to their users. This stands to reason though. Given the incredible manual steps needed to be undertaken by users to say, cancel a credit card, open a new account, initiate a wire transfer, open a new mortgage (the list goes on). Sometimes we see hundreds of manual steps across multiple applications and the user spends more time at the keyboard figuring out the next step than they do helping the customer get more from their organization.

Simple logic says, if you can automate these workflows, which for years have been mostly manual, the benefits are huge. Time saving, reduced training time, elimination of errors, happier customers, more up-sell opportunity and all the related “stuff”.

But user applications up until now lack the ability to be automated. Even new web applications and portals lack the ability to take data out of or into other systems without heavy IT investment up front. Multiply that by the fact they are probably still running some mainframe, client server and java apps as well and it is easy to see why most users are manual users.

OpenSpan has really changed that. We have a vast number of users, now running automated workflows in large and small mission critical environments. Each day, I am constantly amazed by the types of use cases our users are using us for. There is now almost no limit to what end user tasks can be automated. Cool.

Last week I mentioned that I would follow-up my original post on the Google Chrome OS with a post on how OpenSpan could support the Google Chrome OS (and Linux in general). I emphasize could, because we currently have no plans to support the Google Chrome OS or Linux. Thus, this post is really just informed speculation on how our technology could be applied to Linux.

Diagram 1
Diagram 2
Diagram 3Typically, when we talk about OpenSpan, we focus on our Windows translator, Scout, as the base layer which everything builds upon. In fact, we often say “OpenSpan sits in between the application and Windows”. We then talk about how we use the Scout layer to detect when additional technologies are loaded into an application so we can load translators to expose those technologies. For example, to explain how we support Java, we might whiteboard something like Diagram 1.

However, Diagram 1 isn’t really correct. There’s actually another layer below Windows, the instrumentation layer, responsible for hooking x86-64 byte code. Of course, once you’re dealing with byte code, you’re dealing with the processor, not the OS. Thus, our hooking library can hook functions on both Windows and Linux systems. When we add the instrumentation layer, our Java stack looks like Diagram 2.

So what would it look like if we added Linux to the mix? You might think that adding Linux would mean two different stacks, one on top of Windows, another on top Linux. However, this isn’t the case. For technologies that run on both Windows and Linux, the stacks would actually reconverge at that layer. Diagram 3 shows what our Java stack looks like with Linux.

Of course, there’s only a few UI frameworks that work on both Windows and Linux (see list here), most importantly Java and HTML. Unfortunately, HTML is a markup language rather than a binary specification so we have to adapt to each browser rather than HTML itself. However, we could still create a common set of HTML element objects that interact with each browser implementation through an abstraction layer. It gets even more interesting if you start thinking about server technologies.

To summarize, above the OS layer, most multi-platform technologies will reconverge on a common set of classes. Thus, although we will need to write a Linux layer, we will not need to write a new Java layer or two separate FireFox layers. Don’t get me wrong, supporting Linux would still require a significant degree of effort. However, it is a manageable amount of effort because we can build on the layers we already support.

How do you differentiate as to what is a cloud application and what is a client server application (thin client or fat client). Does it really matter?

There are so many plug ins for the browsers now, along with so many browser incompatibilities I feel nothing much has really changed. You could argue, and I will, browsers are just fat clients. Enterprises have to do so much QA before rolling any web app into production, it really is just a client server app in all sense of the word(s). Sure, the user perceives the application runs in the browser and nothing is installed on the client but that’s really a mirage. Under the covers, all sorts of technology is loaded on demand to run client side. And all the browser vendors want to win the browser war…and break the standards – and we know how long this war will go on !

Not only that, but we are YET AGAIN confusing the users with so many different types of web applications that pretty much all behave differently in terms of UI consistency. Even the same applications behave differently in different browsers and the UI for each is pretty much all over the place. My wife is confused as to when and when not to hit backspace (you can lose everything you typed in many web apps if you are not careful), she can drag and drop in GMAIL now but in no other web app she uses but that doesn’t stop her trying and getting tied in knots. UI standards are out the window now! Only one sad consistent remains – copy and paste (and even that was left out of the Iphone – for a while – LOL).

So, my opening question, does it really matter? I think it does. This is exactly HOW we created so many legacy applications that we are forced to support today so we have learnt very little. This is great for OpenSpan because we offer capabilities for normalizing and automating cross-application workflows across most application platforms (Fat, Thin, Web, Java, windows, Host or whatever) but thats not the point of this post. Where are we going wrong? I know applications that were written and then rewritten within just 5 years of each other and are now completely legacy today. i.e. no new development but no replacement being built (no IT budgets). I know, because we are bridging them to work with newer technologies. BTW – I said 5 years ago, but we have some users with 30 year old apps and 1 year old apps as well, in exactly the same boat!

I think my point is further validated when you look at the huge difference between web (cloud) applications and their user interfaces. They all seem so different. Take GMAIL. You could fairly argue, it’s a terrific UI and Google have done a marvelous job making a dumb browser run what looks to be a very clever RICH client application. BUT – look at the resources GOOGLE has, few companies have the development / QA budgets that Google has (and Enterprises cannot afford to have applications 2-3 years in Beta to iron out bugs!). And to be fair, email is not as mission critical as losing a mortgage payment, medical diagnosis, wire transfer or interest calculation. We are used to losing emails like things get “lost in the post” (or junk folders).

I will write more on this subject I am passionate about (can you tell :) ).. But let me end with this for now. We all talk about how the pendulum swings, about every 10 years, right ? Well, in my view, the next pendulum is someone coming up with the next SUPER 4GL (RAD) development environment that allows cloud applications to be built quickly, full transaction roll-back-roll-forward, deploy anywhere, on-demand, run locally (and with core business logic when connection down) and all, so much more… it might be Silverlight, it might be Chrome or it might be something from nowhere (it might already be here and I missed it :)).. but it’ll be here soon!

For me, whatever it’s built on, I can guarantee, in a few months or a few years, it’ll be another legacy app that’ll need my help!

Today, Google announced on their blog that they are working on a OS based on their Chrome browser and Linux. The blogosphere has been expecting this announcement for a couple of years now. It’s been pretty obvious that Google was positioning itself to compete against all of Microsoft’s core products, adding first Google Apps to compete with Office and then Google Chrome to compete against Internet Explorer. A Google OS is the final piece, taking on Windows.

I find it amusing the excitement that a Google OS generates. It seems to speak more to a dislike of Microsoft than to an excitement about Google. After all, if Google is successful, it will be in a more dominant position than Microsoft ever was, controlling the operating system, productivity applications, email and search (which effectively controls the Internet). That doesn’t sound like a particularly desirable outcome. We all know monopolies tend to stagnate. After all, it took FireFox to drive Microsoft to improve Internet Explorer, Java to drive Microsoft to scrap COM and now Google Apps to drive Microsoft to update Office. I would hate to see Google replace Microsoft as another monopoly.

On the other hand, operating systems are a bit of a special case. Having a single dominant operating system leads to innovation at the next layer. OpenSpan only has to develop for Windows currently, which lowers our costs and allows us to focus more effectively. Standards are supposed to alleviate this problem, but standards are equally problematic. I was a web developer when Netscape and Internet Explorer both rolled out their own implementations of HTML 4.0. Having to develop cross-browser scripting code was an absolute pain in the ass. I’ve had similar experiences dealing with different Java server environments, each with their own little quirks. “Write once, run anywhere,” usually means “Write once, debug everywhere.” Moreover, standards tend to be produced slowly and are very rarely perfect. Browser and JVM creators are notorious for jumping the gun and rolling out versions that are compliant with an interim standard, but not the final standard. They are also notorious for rolling out innovations that are not compatible with other browser or JVM implementations. Developers are constantly presented with the choice of targeting the lowest common denominator and sacrificing functionality, targeting a specific implementation and sacrificing market share, or targeting multiple implementations and sacrificing time and money.

Of course, Google will argue that they will not be dominant or monopolistic, because the Chrome OS is designed to bring web applications to the desktop. Here’s Google’s description of the Chrome OS architecture:

“The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform. All web-based applications will automatically work and new applications can be written using your favorite web technologies.”

Google’s statement reminds me of the Palm webOS (on the Pre), which allows you to build softphone apps that use web technologies. These local apps are built with HTML and javascript, but they still rely on webOS services to interact with the local system. Is this how the Google Chrome OS will work? Or will the Chrome OS only allow users to interact with applications in the cloud, ie. no local storage, etc.? Most likely, the Chrome OS will do both, and some applications will be compatible with Windows, Mac and Linux and some will not.

If Google wants to demonstrate a commitment to open standards, it could roll out a Chrome OS virtualization layer to run applications on Windows. This would actually be a pretty smart strategy, extending the reach of the OS while deflecting potential criticism. Likewise, to gain widespread adoption, providing a Windows virtualization layer to run Windows applications on the Chrome OS will be required. Ultimately, virtualization may make much of this mute, particularly if we move from machine virtualization to OS virtualization (thus eliminating the need for OS licenses). It will also be interesting to see if Google open sources the entire Chrome OS. The Chrome browser is mostly open source (as Chromium), although Google does add some small functionality (mainly branding) on top of the open source implementation.

The most fascinating aspect of this will be Microsoft’s eventual response if Google is successful. Right now, Google’s search revenue funds free applications like Google Apps, Chrome and the Chrome OS. Google is going to need to make money off of these eventually, as I’m guessing most people don’t want advertising on their desktop. In the meantime, however, being free is a really big competitive advantage for Google. Will Microsoft eventually be forced to make Windows free as well? Will Microsoft have to move more aggressively to a cloud model to compete? Whatever happens, Google has succeeded in making the desktop market interesting for the first time in a long time, and it hasn’t even released anything yet.

Today or tomorrow I’ll follow up this post with some thoughts on how the changing OS market impacts OpenSpan and provide some insights on how our architecture is already positioned for the post-Windows world.

One thing for sure, as a BPO, is that you are often running other people’s applications. We all know it’s hard to optimize what you own, let alone doing that with someone else’s application. This is one of the key reasons we established the OpenSpan BPO Services partner Program.

OpenSpan can get inside nearly any application that runs on the desktop and expose all of it’s UI elements as an extremely robust API you can do what you like with. Whether you own that application or not. We don’t need the source code to do this!

That means, for any BPO running someone else’s application, you can automate it to your hearts content. Cumbersome agent workflows can be made highly efficient using the OpenSpan Studio that we train the BPO development/IT teams how to use. Using the visual drag and drop designer you can optimize these agent workflows in short order and start rolling out to their desktops rapidly.

Game changing for any BPO – Robust Integration and automation on the desktop.

See this press release for STREAM GLOBAL SERVICES. A world class BPO on the OpenSpan program.

No, we are not talking about injecting beer into a turkey but we are talking about the latest blog post by our VP of Development, Damon Lockwood. I wouldn’t do his post justice by paraphrasing any more of it. So, please enjoy..

Do it On the Desktop

I will be back shortly myself after a little absence of blogging! Hope you missed me!