It is currently Fri Sep 21, 2018 8:52 am


All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 13 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: CPRS LOC
PostPosted: Thu Mar 24, 2011 10:06 pm 

Joined: Mon Jan 10, 2011 10:09 pm
Posts: 28
Location: INDIA
Real Name: laxmikanth
Began Programming in MUMPS: 25 Dec 2010
so,Whts the best way to go ahead??
tlwiechmann wrote:
:shock: Wow!


Top
Offline Profile  
 
 Post subject: Re: CPRS LOC
PostPosted: Fri Mar 25, 2011 8:33 am 
User avatar

Joined: Wed Nov 17, 2010 8:37 am
Posts: 136
Real Name: Terry L. Wiechmann
Began Programming in MUMPS: 0- 0-1971
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...

_________________
Terry L. Wiechmann


Top
Offline Profile  
 
 Post subject: Re: CPRS LOC
PostPosted: Mon Mar 28, 2011 12:18 am 

Joined: Mon Jan 10, 2011 10:09 pm
Posts: 28
Location: INDIA
Real Name: laxmikanth
Began Programming in MUMPS: 25 Dec 2010
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...


Top
Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ]  Go to page Previous  1, 2

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net