Dear HITS:
Your coments are useful but they do not go far enough in that they must
state that the investment of resources by a Supplier to reconfigure VistA
to serve general non-VA enterprises will require statement of clear
targets (Functions, data, behavior, technology) that both Suppliers and
Acquirers (Customers!) clearly recognize. These clear targets must come
from the using beneficiaries who are members of various healthcare
professional specialties. These specialites are only partly oriented to
both the need and the action steps; this has partly caused the present
public lamentations about healthcare being asleep at the switch while the
other part has been the Suppliers wanting to sell what they already have
without any goals as to where it may be going (because of the lack of
clear targets). The VA has partly incorporated some of the needed common
conventions that will help clarify targets but few clearly understand both
the conceptual content and the implementing technologic approach. The
VistA disseminators must address both of these areas of deficiency and
adopt an "Enterprise View, Life Cycle principles (including the Zachman
Framework approach). The material is there and, you are right, we must not
"Wait for Godot" but must make the effort and get the material effectively
organized to potential Acquirers to understand what they must do and what
others will do.
I will say though that there is much in the hopper that has not been
described and I believe that efforts are headed in the proper direction.
The key is to probe how to inform the VistA community of how these steps
are converging and what more can be done in both convergence and
information dissemination. Several of us for years have said that the
"Bottom of this iceberg is education/information, not technology". You
know the WV organization Officers - work through them and much will
happen.
Arden W. Forrey PhD
Dept of Restorative Dentistry
University of Washington School of Dentistry
206-616-1875 Phone
206-543-7783 FAX
On Wed, 13 Jul 2005, HITS wrote:
Let me refer you to the Chaos Report
(http://www.standishgroup.com/sample_research/chaos_1994_1.php) which tells
us that the main reasons most IT projects fail (over-budget/late) is exactly
that reason. And then, let me ask you to step back and take a different
perspective. Look at this like a business - a humanitarian business - but a
business non-the-less. If we are going to provide accurate health
information (what VistA is actually all about), then we MUST have definitive
parameters from which to work. Saying that it will cost more to change
directions after we are almost done with development is exactly correct -
and that is exactly the point. The fact that we have a vision - a desire to
make healthcare more affordable, more accessible - does not mean we have to
take an additional year or two to get SOMETHING out to the public. The
beauty of VistA is that it is not a static program, but a living system,
capable of being patched AFTER we have something out there that will benefit
the public.
Okay, back to the business aspect - we have a bad reputation. We have the
greatest product going in the arena of health care. We have the capability
of providing patient information around the globe at Internet speeds to
virtually and and all systems running, and we are having a hard time selling
it. Why? Because we have the reputation of taking untold amounts of time
to 1: make a decision; and 2: act on that decision.
Okay, I'm pontificating now, so I'll quit. Let me leave you with this -
more than once a group of people have come up with awesome ideas/technology
to benefit mankind and improve some aspect of life on this blue marble. And
more than once, they have failed because they lapsed into esoteric diatribe
instead of moving forward with practical applications.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Gregory Woodhouse
Sent: Wednesday, July 13, 2005 10:16 AM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] philosophy???
I guess I owe you a better response than that. In the post mortem of
virtually every project with which I've been involved, there have
been complaints of "scope creep" or inadequate analysis. It seems as
if we believe that, through a herculean effort, we can anticipate
every eventually, every feature the user will need to be able to use
the system productively, every possible risk that might hamper the
project's success, every possible platform or personnel problem, and
so forth. That's just not realistic. We can (and should) plan, but in
practice, that plan simply will not account for everything. So what
do we do? Well, there's the old 50% rule, which may be okay for
estimating timelines, but what if you choose an architecture that
makes it difficult to adapt to change? It is often said that the
further along the development cycle you are, the more expensive
change is. (It costs more to make design changes than changes to
requirements, more to modify code than to make design changes before
coding starts, and so on.) There's a lot of truth to that, but could
it simply be an artifact of the way we traditionally develop
software? If we choose an implementation strategy where design is
"locked in" once we start to code, then change will be more expensive
than if we use an approach which is more flexible. That is not
impossible, not even all that difficult, but it is something we have
not traditionally done, given our "Just make it work" attitude (or
maybe philosophy?)
===
Gregory Woodhouse
[EMAIL PROTECTED]
"The whole of science is nothing more than a refinement
of everyday thinking." -- Albert Einstein
On Jul 13, 2005, at 9:08 AM, Gregory Woodhouse wrote:
Tell that to the folks at MIT. Trying to build a robot capable of
walking by simply programming into it *how* it should move its legs
is all but a hopeless undertaking.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"The most incomprehensible thing about
the world is that it is at all comprehensible."
--Albert Einstein (1879-1955)
On Jul 13, 2005, at 8:44 AM, HITS wrote:
Whether you are talking about uncertainty or non-determinism as it
relates
to philosophy or computer science doesn't seem to really matter.
What
matters is that you have an idea, a vision if you will, of where
you are
wanting to go; a firm grasp on where you are now; and a solid plan
on how to
get from point A to point B. Both uncertainty and non-determinism
are
anathama to solid development (IMHO). Even the most cloudy of
visions can
be clarified by clear intermediate goals that take you toward the
cloud.
The closer you get to the cloud, the more the mists separate;
sometimes into
more than one cloud; sometimes not.
Bottom line - plan the work; work the plan.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Gregory Woodhouse
Sent: Wednesday, July 13, 2005 8:05 AM
To: hardhats-members@lists.sourceforge.net
Subject: [Hardhats-members] philosophy???
I wonder if my post last night emphasizing the difference between
uncertainty and non-determinism (and the similarities which I think
tend to go unnoticed) wasn't a might too philosophical. It reminds me
of a time a week or so ago when I was sitting in a cafe reading a
book about provability and a woman started a conversation with me (it
turned out that she was a philosophy student at UC Berkeley).
Immediately, I could see the look in her friend's face: "Oh no! Not
again!" Ever since then, I've been wondering if some formal training
in philosophy might, perhaps ironically, turn out to provide useful
background for parts of computer science, if not software
development. As strange as that sounds, I believe that thinking about
the nature of the task of developing software really can help to make
one a better programmer. I can hear it now: This guy is bonkers!
Maybe so, but as a simple example, one question we would do well to
ask ourselves a little more often is, What am I REALLY doing here?
Basic design questions, such as whether a variable pointer (or
multiple inheritance) is the right way to solve a given problem often
hinge on the answer to a question such as this. and theoretical as it
may seem early on, it doesn't take much time trying to support or
enhance the code you've written before it becomes clear that the
question was really a practical one, after all.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"Design quality doesn't ensure success, but design failure can ensure
failure."
--Kent Beck
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar
happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest
in dual
core and dual graphics technology at this free one hour event
hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar
happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest
in dual
core and dual graphics technology at this free one hour event
hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar
happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in
dual
core and dual graphics technology at this free one hour event
hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
