News 06/29/07

TPD - the funny part of the web-everything argument is that all browsers run on an OS which runs on a PC which also runs other fat-client software (i.e., anti-virus) that needs patching. The processor, disk and memory power that sits on the desktops outstrips anything just about any company has in their data center. Why not just push the vendors to provide Microsoft SMS, LANDesk, Zen and whomever else's software distribution packages du jour so that for the applications that are processor intensive, there is a fat client on the desktop that can crunch data. I find people have jumped at the web-everything and they don't think about using the right tool for the right purpose. Web is great at some things but terrible at capturing large amounts of edited discrete data and it is not great at manipulating large data files outside of fairly rigid views. The even more ironic part is that most vendors hit the wall and then distribute a fat Java applet that performs like a dog or an ActiveX control. The "Rich Internet Applications" or Smart Clients attempt to strike a happy medium between strong user experience, network performance optimization, utilizing the local computing power, and ease of software distribution. All this Web 2.0 hype is just adding to the complexity of the pile of technologies we are putting between the user and the data. The more complexity, the more places security holes can be found, the more places for messages to go into the abyss, and the more places for poorly trapped error messages to display. Mr HISTalk and others have blogged countless times about the poor software quality from the vendors. As the uninformed push them to add layers to a legacy or even a newer technology architecture to make it web, to add services, we need to be sure they are doing the hard work of managing system integrity, performance, and security.

I am not claiming you are one of those types, in fact from when I have read your blog, you are very creative but I do see this as a trend and now you have business and clinical executives just wanting to make everything web without considering the overhead of adding another layer to an already shaky architecture. We need to use the right tool for the right purpose while understanding the consequences of this action. Does making something web really provide an advantage that is work the cost and risk?

A lack of IPOs is indicative of the market. I believe investors want proven solutions with names they know and trust. Other than market listing to ease being bought-up by another company or invested-in by multiple venture capitalists, there is no advantage. Private equity, allows greater control and in some ways more streamlined decision-making for long-term investments... like the Meditech and Epic models. Theoretically, private companies should have more flexibility with investing in R&D and re-architecting. I can't speak for Meditech but Epic has a sound R&D model and strategy. Re-architecting - no one wants to try and build a better foundation because of the risk and long-term prospects of delivering a rebuild of thousands of features in a short period of time.

Reply to Art_Vandelay: I agree with most all of your comments. The thing that is starting to happen is a shift from "Fork-lift Upgrades" to "Re-deploy existing assets" to enhance the user work experience by adding web enabled applications on top of existing systems. Since there is a lower cost for web applications it makes sense to try and use SOA's to move existing processes to the web because of its wider access features. If institutions could design their scheduling application to add web viewing access any users who want to view scheduling can see it anywhere their is a web browser in a VPN.

TPD - agreed - the trick is finding a vendor who has a clue about SOA and defining the internal standards properly. Usually - there is a significant amount of clean-up that needs to occur before publishing the service. Even where the platform may support exposing a service, the bad habits of the 20+ coders (on-shore and off-shore) may need to be cleaned-up so that all the edits actually occur as they are supposed to occur (just my experience). The lack of internal application layer standards and documentation in many legacy systems makes it difficult to quickly expose services. Also, some of the platforms just don't rapidly support service layers. For those who have a client-server application, the editing logic often exists in both the client and the server (also without rhyme or reason), so when developing a service, you need your brightest and best analyzing the environment to validate the edits are in-place. If you don't garbage gets into the database or comes back to the displays.