> On Jun 2, 2006, at 3:58 PM, Tim.Churches wrote:
>
> > Wayne WIlson wrote:
> >>
> >> 2a) I am 'embedded' in the US health care delivery system,
> >> managing computer
> >> servers. Our current trend is to obsolete computers every 3 to 5
> >> years,
> >> replacing them with ever more powerful and power consuming
> >> models. I have been
> >> on the 'bleeding' edge of trying to conserve power, but in less
> >> than three years
> >> of growth, we have exhausted the capacity of our power feeds
> >> coming in ~ 30KW
> >> and our cooling capacity for that power load.
> >
> > Yes. I had cause to visit one of the data centres for the govt health
> > organisation for which I work a few weeks ago, to inspect our
> > population
> > health servers (which occupy just one rack). I was surprised to notice
> > several new racks of servers, each absolutely full of "blade" servers
> > each with 20 or 30 CPUs in each unit i.e. hundreds of CPUs per
> > rack, and
> > there were several such racks.
Actually I looked up the specs for the hardware in question, and in fact
there must have been only about 150 CPUs in total. Still a lot of
horsepower.
> > Drooling at all that computational
> > power,
> > I asked what they were for. The answer: "They are Citrix servers
> > for the
> > XYZ application." For those unfamiliar with it, Citrix is a (closed
> > source) technology which allows Windows desktop sessions running on
> > central servers (the huge bank of blade servers) to be remotely
> > controlled from Windows desktops via a thin client. Rather like VNC
> > for
> > Windows, but a bit more sophisticated. The XYZ application was a
> > Windows
> > GUI app which needed to be accessed from wards in hundreds of public
> > sector hospitals, and the use of Citrix and the centralised virtual
> > Windows desktops very appropriately avoided the hassle and expense and
> > difficulties of installing the application in so many locations.
> > However, knowing that the GUI application in question did not have a
> > terribly complex interface, I could not help but reflect that had the
> > software been implemented as a Web application, then only a handful of
> > central servers would have been needed to service it. The (valid)
> > arguments were that redeveloping the application in question as a Web
> > app would have cost more than the banks of Citrix servers etc
> > needed to
> > deploy it as a Windows GUI application, and that the Citrix servers
> > could be used for other Windows apps in the future. All true. But
> > there
> > is a lesson there for software developers who wish their code to be
> > deployed in places where there are not the funds available to purchase
> > large banks of Citrix servers...
>
> ...on the other hand, the budget for one Citrix deployment of the
> scale you are describing is probably sufficient for a an agile web
> application development project which is comprehensively robust and
> well engineered enough to compete as an alternative to the server and
> power and sysadmin intensive solution you are describing. And if
> the web app is developed in once in open source, then the entire
> dynamic of options available to frontier sites is altered. But you
> expect to hear me say this because it is what I have been doing while
> embedded in a rural health care setting in California....
I don't disagree, but playing Devil's advocate here, some
counterarguments by IT management might include (composing
FOSS-promoting rejoinders to these counter-arguments is left as an
exercise for the reader):
1) But the Citrix deployment is good for any application which runs on
Windows via a GUI, and there are hundreds of such applications of
potential utility in our hospitals, so the investment is not just for
this one application - it will be amortised over dozens of applications.
2) We sought quotes for developing a Web version of the software in
question from the usual three-letter IT consulting agencies, and the
cost was greater than that of the Citrix hardware and software deployment.
3) Anyway, software development is failure-prone so why should we carry
that risk? Much better to chose the successes that have made it to
market, and let the developers wear the cost of the failures. If we
commission software, then we have to carry the cost if the development
fails, or is costs or timelines blow out, as they usually do.
4) Did you say that we should form consortium of health authorities to
spread the development costs? Oh no, that would be like herding cats!
5) There is a shortage of really good software developers anyway, and
they are all working in the finance and insurance sectors where the pay
is higher.
> Btw, check out these folks
>
> http://www.inveneo.org/
>
> Their solutions are developed in San Francisco and prototyped in Africa.
Now that is really cool! I bet they can't wait for mesh-network WiMax
technology to become affordable, which will be good for about 5km per
hop even without line-of-sight (see http://en.wikipedia.org/wiki/WiMax )
- but the augmented WiFi stuff they are using now is also a fabulous use
of what is now very cheap technology.
Tim C
SPONSORED LINKS
| Software distribution | Salon software | Medical software |
| Software association | Software jewelry | Software deployment |
YAHOO! GROUPS LINKS
- Visit your group "openhealth" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
