The web is swallowing everything in the software world. Everything from accounting applications to clinical apps are turning into web applications. The trend is there, and it is so strong, that betting on emergence of a web based application for pretty much anything is possible now.

You think that there are many things for which you can say “that’d never be a web app”? Think again. Sure, it is taking some time, but the trend is very strong.

The reason behind this is one of the most costly aspects of software life cycle:  deployment & maintenance. Maintenance usually includes repeated deployments, so I’ve joined these phases.  If you develop any product, you’ll see that issues around deployment and maintenance is taking a huge amount of your time, and therefore costing you a lot. The cost is so great, that pushing applications to web, even with considerable limitations is paying off for the vendors.

In doing this, vendors are aiming for even lower costs by investing into certain web technologies, since the web based application domain is much more fragmented than a first comer would expect. For many solutions javascript + HTML is enough. It is a good combination, especially if you’re interested in the mobile extensions. Personally, I think javascript + HTML is introducing a significant cost into software development for the web. Due to nature of the development process with these technologies, you will have a higher alternative cost in many cases, usually without noticing it. There is hope for this combination though, but I’d give it at least 3 years before we can carry the mature practices of other technologies into this space. This is a big topic, so I won’t go into it in depth here.

Now an interesting question is: what would happen if we move some key tooling in EHR domain into web. I’m talking about modelling tools like archetype & template designers & editors, and more. Personally I think this is a good idea. The problem (at least for me) is: I have some evil plans for very capable user interfaces for next generation of these tools, and I want to use proper tooling platforms for creating them.

My tooling platform is Eclipse, everyone who has worked with me longer than a week knows that. Eclipse is great, but in terms of UI technology, its various limitations worry me. Yes, people have build lots of complex tools with Eclipse, but I still want more power for UI layer, and I still want to keep the framework’s good bits.  On top of all of that, I want to extend my tooling to the web. Now this is pushing the limits of technology we have. I can always develop solutions to problems I encounter on the way, but it is too expensive to do so! I’d rather see these concerns incorporated into my framework of choice.

Eclipse  people have been following trends, and they have been hearing about this kind of issues for quite some time now. So the next generation of the framework, E4, is going to be a huge jump forward in terms of its architecture. The whole tooling concept matured in Eclipse is going to move forward with web rendering support. This means running the tooling framework in the browser. Needless to say, this will be a big, big step forward. Eclipse is targeting Flash runtime as its web front end. And silently, this is proving all my points about the limits of HTML, even with HTML 5.  I’ve not had the time to look into documents in depth, but I guess it won’t be hard for others to plug silverlight rendering engines, or even HTML 5 rendering to E4 architecture, in the future.

For the moment, Flash is certainly the right choice. First of all, Flash player 9, has a huge installation base. The current player version is 10, but version 9, released in 2006, has managed to find its way into almost all desktop computers, even the ones in slow changing corporate & enterprise setups.

I can’t emphasize the importance of this enough. You’ll find alternatives like Silverlight and JavaJX out there, but JavaFX requires Java runtime 6.13 or later (or something like that) and Silverlight requires its own plugin installed. I also don’t see Silverlight taking off in  non-MS platforms (another long discussion I’d like to avoid for now) Flash is simply out there (imagine X-Files  intro playing  at the background)

Now if you put together all the things I want for openEHR tooling: Eclipse + Nice & capable UI + Web enablement + easy deployment (drums rolling…)

The answer is Eclipse + Flash integration with current technology (possible) and migration to E4 in two-three years or so.  I’ve also been looking into other technologies to support Eclipse’s UI layer, namely the QT framework, but that locks me into desktop space.

I have a feeling that an early entry into web based tooling will become a huge advantage in 5 years or so. If I invest into desktop technologies too heavily now, I’ll probably get stuck in it. The fact that everyone learns after their first 10 years in software business is: products & business models get stuck into whatever founding technology & architecture they are build on. It is incredibly hard to re-write products, or jump into other domains like distributed architectures, or web based applications.  So not giving up on power we need, but investing into desktop technologies that has a link to web is the critical strategy. CKM on its own is a success story, but its advantages in terms of collaboration is slightly masking its other benefits around the issues I’ve listed above. CKM does not build models, it only helps keep track of their evolution. Why not move the rest of the clinical tooling into this space? Archetype editor? Even the IHTSDO workbench. We either have the necessary technology now, or it will be there in almost a couple of years.

You see, just because of this vision only, Eclipse is worth investing into. Of course I need to take a better look into docs for E4, because my assumption is, I’ll be able to merge the complex Flash based GUIs in Eclipse I’ll be building soon, into emerging architecture in the future. If that assumption is wrong, I’ll have to reconsider some things, but architecture wise, I can’t see it being very hard.

So, this whole thing is about a trend, where not only end users, but also more technical communities begin to migrate to web. The technology is emerging, and cost argument is valid for everyone. Today, I believe Flash (Flex framework running on top of it) is the right choice for this. In 5 years or so, I expect Adobe to provide tools that’ll simply keep everything same, but render to HTML5 instead of Flash runtime. I’ll be betting on that.

So here I go, and announce my vision for openEHR tooling (heroic, but also emotional strings at the background): an Eclipse based framework, that will become web  enabled  in two years or so. I’ve managed to put together a large amount of work in many technologies to enable this, and very slowly, I’m binding them together. Let’s see how it goes.