Mumpster
http://mumpster.org/

CPRS LOC
http://mumpster.org/viewtopic.php?f=26&t=338
Page 2 of 2

Author:  Laxmikanth [ Thu Mar 24, 2011 10:06 pm ]
Post subject:  Re: CPRS LOC

so,Whts the best way to go ahead??
tlwiechmann wrote:
:shock: Wow!

Author:  tlwiechmann [ Fri Mar 25, 2011 8:33 am ]
Post subject:  Re: CPRS LOC

I don't know what your specific goals are but I think it is probably a no brainer to assume that you want to end up with a running VistA (facsimile) system at a customers site.

I've had several years experience with migrating these older technology systems to new technology through work with the Department of Defense generally and the US Navy specifically. Without getting into the details, the end recommendation always kept the MUMPS database. We showed them they could have "new" technology while keeping the best of proven, high performance "old" technology they spend $ billions for. Of course, having said that, they totally ignored our recommendations... :roll:

Regardless of the approach, the key is to do the transition "incrementally" - small steps that can be accomplished successfully. Definitely do not try a wholesale conversion - the probability of failure is very high.

In terms of approaches, this depends upon your customers goals. I can say this with a high degree of certainty, if you try to convert the entire VistA system, the probability of success is near zero. VistA is an extremely complex, integrated application that is very dependent upon MUMPS technology. If your customer insists on getting rid of MUMPS, I would start a totally clean rewrite (different technologies) possibly using VistA (parts) as a model. Of course, the cost of this will be totally prohibitive not to mention performance issues.

Without getting into detailed descriptions, here's one very general approach I would recommend. Note, this approach assumes you will, at a minimum, save the MUMPS system and VistA data.

- Get to know VistA as it stands today. In fact, as a first phase, get it up and running in a real environment as is. You will learn a lot about it through this process.

- Next, approach the conversion from the outside. Using your technology of choice, convert the CPRS GUI - that should keep you busy for a while :) While doing this you should be looking at the internal layers and preparing for that conversion if required.

- Personally, I can recommend conversion of the File Manager/Kernel layers based on work we did, but why? This is where the complexity lies. There's an old saying: "If it isn't broke, don't fix it!". In my view, rewriting these layers is an all or nothing scenario and it is a really big task. Also, IMHO, doing a conversion is a black hole.

To summarize more bluntly:

- If your customer insists on a total conversion, recommend a different approach. It's just not practical.
- If they agree to keep the MUMPS system and data, determine how deep they want to go with the conversion. Make it incremental and try to avoid going beyond the client layer.

Hope this helps...

Author:  Laxmikanth [ Mon Mar 28, 2011 12:18 am ]
Post subject:  Re: CPRS LOC

Thanks a lot Terry...

Your deep insight is very much helpful to me.
Will definitely get back to you with much more specific project plan for your inputs
tlwiechmann wrote:
I don't know what your specific goals are but I think it is probably a no brainer to assume that you want to end up with a running VistA (facsimile) system at a customers site.

I've had several years experience with migrating these older technology systems to new technology through work with the Department of Defense generally and the US Navy specifically. Without getting into the details, the end recommendation always kept the MUMPS database. We showed them they could have "new" technology while keeping the best of proven, high performance "old" technology they spend $ billions for. Of course, having said that, they totally ignored our recommendations... :roll:

Regardless of the approach, the key is to do the transition "incrementally" - small steps that can be accomplished successfully. Definitely do not try a wholesale conversion - the probability of failure is very high.

In terms of approaches, this depends upon your customers goals. I can say this with a high degree of certainty, if you try to convert the entire VistA system, the probability of success is near zero. VistA is an extremely complex, integrated application that is very dependent upon MUMPS technology. If your customer insists on getting rid of MUMPS, I would start a totally clean rewrite (different technologies) possibly using VistA (parts) as a model. Of course, the cost of this will be totally prohibitive not to mention performance issues.

Without getting into detailed descriptions, here's one very general approach I would recommend. Note, this approach assumes you will, at a minimum, save the MUMPS system and VistA data.

- Get to know VistA as it stands today. In fact, as a first phase, get it up and running in a real environment as is. You will learn a lot about it through this process.

- Next, approach the conversion from the outside. Using your technology of choice, convert the CPRS GUI - that should keep you busy for a while :) While doing this you should be looking at the internal layers and preparing for that conversion if required.

- Personally, I can recommend conversion of the File Manager/Kernel layers based on work we did, but why? This is where the complexity lies. There's an old saying: "If it isn't broke, don't fix it!". In my view, rewriting these layers is an all or nothing scenario and it is a really big task. Also, IMHO, doing a conversion is a black hole.

To summarize more bluntly:

- If your customer insists on a total conversion, recommend a different approach. It's just not practical.
- If they agree to keep the MUMPS system and data, determine how deep they want to go with the conversion. Make it incremental and try to avoid going beyond the client layer.

Hope this helps...

Page 2 of 2 All times are UTC - 8 hours [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/