AWG Meeting Minutes and Recording: Moving VistA Forward - a Modest Proposal for Reengineering VistA, K.S. Bhaskar, Dec. 17 2013

Minutes on Moving VistA Forward - a Modest Proposal for Reengineering VistA, K.S. Bhaskar:

Thanks to Bhaskar for an interesting discussion on reengineering VistA.  Although the title says "A Modest Proposal", we know any reengineering of a complex large scale enterprise system is never modest and always a huge undertaking - requiring a long term vision and large financial commitment over many years.   That said, Bhaskar presented the lessons learned from a successful reengineering of the "FIS Profile" - a large scale enterprise M-system based application that runs the three largest real-time core banking systems in the world.  

Back in the late 90's the "FIS Profile" application faced similar concerns to those that apply to VistA today, and over a period of several years, the FIS team slowly evolve the "FIS Profile" from M language to a more maintainable higher level scripting language called Profile Scription Language (PSL).  During the reengineering process, the team also made many improvements such as separation of UI from business logic, ensure application consistency after a crash by enabling transaction fences, support stateless message processing, etc.

Some of the key lessons learned:

Horizonal reengineering instead of vertical reengineering!!!

  • Revolution through evolution
  • Avoid encapsulation
  • Choose a language and compile it into M
  • Re-architect as you go
  • Integration beats Balkanization
  • The value of M technology is as an execution engine

For detailed descriptions, please check out the slides and the recording.

Links:

• FIS GT.M: http://fis-gtm.com• FIS Profile: http://fis-profile.com• FIS PIP: http://fis-pip.com• Anti-patterns: http://sourcemaking.com/antipatterns/software-architecture-antipatterns• K.S. Bhaskar / ks.bhaskar@fisglobal.com / +1 (610) 578-4265 

We will not having any meetings until the third week of January.

Tentatively scheduled presentations:

January 10th - Special session on VistA Novo Demo, Salim Samy, Mitre

January 14th - Socratic Grid - Open Source Clinical Decision Support, Emory Fry, MD, CMIO, Cognitive Medical Systems, Inc.

Happy Holidays.

 

 

like0

Comments

AWG Meeting Minutes and Recording: Moving VistA Forward - a Mode

K.S. Bhaskar's picture

Thanks for a good summary, Peter. Just one comment, I would say
something like "as an adjunct to" or "in contrast to" rather than
"instead of", because they're not mutually exclusive, even though they're
two different ways of addressing the issue.

Regards
-- Bhaskar

On 12/19/2013 11:16 AM (US Eastern Time), petercyli wrote:
>
> Minutes on Moving VistA Forward - a Modest Proposal for Reengineering
> VistA, K.S. Bhaskar:
>
> Thanks to Bhaskar for an interesting discussion on reengineering VistA.
> Although the title says "A Modest Proposal", we know any reengineering
> of a complex large scale enterprise system is never modest and always a
> huge undertaking - requiring a long term vision and large financial
> commitment over many years. That said, Bhaskar presented the lessons
> learned from a successful reengineering of the "FIS Profile" - a large
> scale enterprise M-system based application that runs the three largest
> real-time core banking systems in the world.
>
> Back in the late 90's the "FIS Profile" application faced similar
> concerns to those that apply to VistA today, and over a period of
> several years, the FIS team slowly evolve the "FIS Profile" from M
> language to a more maintainable higher level scripting language called
> Profile Scription Language (PSL). During the reengineering process,
> the team also made many improvements such as separation of UI from
> business logic, ensure application consistency after a crash by
> enabling transaction fences, support stateless message processing, etc.
>
> Some of the key lessons learned:
>
> *Horizonal reengineering instead of vertical reengineering*!!!
>
> * Revolution through evolution
> * Avoid encapsulation
> * Choose a language and compile it into M
> * Re-architect as you go
> * Integration beats Balkanization
> * The value of M technology is as an execution engine
>
> For detailed descriptions, please check out the slides
> <http://www.osehra.org/sites/default/files/130826-1reengineeringvistaprop...
> and the recording
> <https://osehra.webex.com/osehra/lsr.php?AT=pb&SP=EC&rID=7949867&rKey=da2....
>
> Links:
>
> • FIS GT.M: http://fis-gtm.com• FIS Profile: http://fis-profile.com
> FIS PIP: http://fis-pip.com• Anti-patterns:
> http://sourcemaking.com/antipatterns/software-architecture-antipatterns• K.S.
> Bhaskar / ks.bhaskar@fisglobal.com <mailto:ks.bhaskar@fisglobal.com> /
> +1 (610) 578-4265
>
> We will not having any meetings until the third week of January.
>
> Tentatively scheduled presentations:
>
> January 10th - Special session on /VistA Novo Demo/, Salim Samy, Mitre
>
> January 14th - /Socratic Grid - Open Source Clinical Decision Support/,
> Emory Fry, MD, CMIO, Cognitive Medical Systems, Inc.
>
> Happy Holidays.
>
> Promote content
> Group sticky:
>
> Not Sticky
>
> Featured content:
>
> Not Featured
>
> --
> Full post:
> http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
> <http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/3463

--
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

like0

AWG Meeting Minutes and Recording: Moving VistA Forward - a Mode

Stephen Hufnagel's picture

Good day Bhaskar,

Your presentation was most interesting; but,

you advise against encapsulation, it seems essential during a transition period; where, new features might be added while legacy repurposing is simultaneously occurring over a potentially extended period of time.

If you disagree, I would appreciate an explanation.

Thank you for your help and consideration,

Steve

____________________________________________

Stephen P. Hufnagel PhD, Health IT Architect and Data-Interoperability Engineer

The Information Applications Group (TIAG)

1760 Reston Parkway, Suite 510, Reston, VA 20190

703-437-7878, Shufnagel@tiag.net

PERSONAL: PO Box 8097, Falls Church, VA 22041

703-575-7912-mobile and preferred phone

703-995-0841-eFAX, Hufnagel@acm.org

"It is not the critic who counts, not the man who points out how the strong man stumbled, or where the doer of deeds could have done better. The credit belongs to the man who is actually in the arena; whose face is marred by the dust and sweat and blood; who strives valiantly; who errs and comes short again and again; who knows the great enthusiasms, the great devotions and spends himself in a worthy course; who at the best, knows in the end the triumph of high achievement, and who, at worst, if he fails, at least fails while daring greatly; so that his place shall never be with those cold and timid souls who know neither victory or defeat." Theodore Roosevelt. (Paris Sorbonne, 1910)

From: Apache [mailto:apache@groups.osehra.org] On Behalf Of "Bhaskar, K.S"
Sent: Thursday, December 19, 2013 11:23 AM
To: architecture@groups.osehra.org
Subject: Re: [architecture] AWG Meeting Minutes and Recording: Moving VistA Forward - a Modest Proposal for Reengineering VistA, K.S. Bhaskar, Dec. 17 2013

Thanks for a good summary, Peter. Just one comment, I would say something like "as an adjunct to" or "in contrast to" rather than "instead of", because they're not mutually exclusive, even though they're two different ways of addressing the issue.

Regards
-- Bhaskar

On 12/19/2013 11:16 AM (US Eastern Time), petercyli wrote:

Minutes on Moving VistA Forward - a Modest Proposal for Reengineering VistA, K.S. Bhaskar:

Thanks to Bhaskar for an interesting discussion on reengineering VistA. Although the title says "A Modest Proposal", we know any reengineering of a complex large scale enterprise system is never modest and always a huge undertaking - requiring a long term vision and large financial commitment over many years. That said, Bhaskar presented the lessons learned from a successful reengineering of the "FIS Profile" - a large scale enterprise M-system based application that runs the three largest real-time core banking systems in the world.

Back in the late 90's the "FIS Profile" application faced similar concerns to those that apply to VistA today, and over a period of several years, the FIS team slowly evolve the "FIS Profile" from M language to a more maintainable higher level scripting language called Profile Scription Language (PSL). During the reengineering process, the team also made many improvements such as separation of UI from business logic, ensure application consistency after a crash by enabling transaction fences, support stateless message processing, etc.

Some of the key lessons learned:

Horizonal reengineering instead of vertical reengineering!!!

* Revolution through evolution
* Avoid encapsulation
* Choose a language and compile it into M
* Re-architect as you go
* Integration beats Balkanization
* The value of M technology is as an execution engine

For detailed descriptions, please check out the slides <http://www.osehra.org/sites/default/files/130826-1reengineeringvistaprop... and the recording <https://osehra.webex.com/osehra/lsr.php?AT=pb&SP=EC&rID=7949867&rKey=da2... .

Links:

• FIS GT.M: http://fis-gtm.com• FIS Profile: http://fis-profile.com• FIS PIP: http://fis-pip.com• Anti-patterns: http://sourcemaking.com/antipatterns/software-architecture-antipatterns• K.S. Bhaskar / ks.bhaskar@fisglobal.com / +1 (610) 578-4265

We will not having any meetings until the third week of January.

Tentatively scheduled presentations:

January 10th - Special session on VistA Novo Demo, Salim Samy, Mitre

January 14th - Socratic Grid - Open Source Clinical Decision Support, Emory Fry, MD, CMIO, Cognitive Medical Systems, Inc.

Happy Holidays.

Promote content
Group sticky:

Not Sticky

Featured content:

Not Featured

--
Full post: http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist... <http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3463

--
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

like0

AWG Meeting Minutes and Recording: Moving VistA Forward - a Mode

Mike Henderson's picture

While I was absent from Bhaskar's presentation, I think his slide points to
the paradox within which the evil of encapsulation can lurk. Specifically,
those application elements whose logic is most gnarled, and that are thus
most difficult to validate, are those which are *least *safe to
encapsulate, because encapsulation fossilizes their problems. The nature
and scope of the problems being fossilized, of course, make those elements
the *most *tempting to encapsulate!

A credible re-engineering strategy will target such elements for intensive
examination and rework. It will not infrequently be found that such
elements are not bound to any identifiably consistent business logic. A
corollary is that the business processes that use them are themselves
candidates for being re-engineered, because they have been forced over time
to adapt to the increasing number of tangles within the code that was
supposed to facilitate those processes.

The good news in all this is that Bhaskar's presentation illustrates that
the Augean stables are capable of being mucked out, and reasonably posits
that encapsulation is a useful element of a mucking-out strategy. I am
inclined not to insist on the adoption of a technology that enforces
encapsulation. However, the case for doing so is powerful, particularly in
the medical-device use cases that apply to imaging and blood bank software.
From an overall quality point of view, encapsulation may be a mandatory
element to mitigate risk within any development framework.

Mike Henderson, FHL7
Director, Open Source Product Management
OSEHRA
900 N. Glebe Road, Suite 4-016
Arlington, VA 22203 USA
(o) +1 571 858-3383
(m) +1 240 351-5908

On Thu, Dec 19, 2013 at 1:12 PM, Stephen Hufnagel <hufnagels@osehra.org>wrote:

> Good day Bhaskar,
>
>
>
> Your presentation was most interesting; but,
>
> you advise against encapsulation, it seems essential during a transition
> period; where, new features might be added while legacy repurposing is
> simultaneously occurring over a potentially extended period of time.
>
>
>
> If you disagree, I would appreciate an explanation.
>
>
>
> Thank you for your help and consideration,
>
> Steve
>
> ____________________________________________
>
> *Stephen P. Hufnagel* PhD, Health IT Architect and Data-Interoperability
> Engineer
>
> The Information Applications Group (TIAG)
>
> 1760 Reston Parkway, Suite 510, Reston, VA 20190
>
> 703-437-7878, Shufnagel@tiag.net
>
> *PERSONAL*: PO Box 8097, Falls Church, VA 22041
>
> 703-575-7912-mobile and *preferred phone*
>
> 703-995-0841-eFAX, Hufnagel@acm.org
>
>
>
> "It is not the critic who counts, not the man who points out how the
> strong man stumbled, or where the doer of deeds could have done better. The
> credit belongs to the man who is actually in the arena; whose face is
> marred by the dust and sweat and blood; who strives valiantly; who errs and
> comes short again and again; who knows the great enthusiasms, the great
> devotions and spends himself in a worthy course; who at the best, knows in
> the end the triumph of high achievement, and who, at worst, if he fails, at
> least fails while daring greatly; so that his place shall never be with
> those cold and timid souls who know neither victory or defeat." Theodore
> Roosevelt. (Paris Sorbonne, 1910)
>
>
>
> *From:* Apache [mailto:apache@groups.osehra.org] *On Behalf Of *"Bhaskar,
> K.S"
> *Sent:* Thursday, December 19, 2013 11:23 AM
> *To:* architecture@groups.osehra.org
> *Subject:* Re: [architecture] AWG Meeting Minutes and Recording: Moving
> VistA Forward - a Modest Proposal for Reengineering VistA, K.S. Bhaskar,
> Dec. 17 2013
>
>
>
> Thanks for a good summary, Peter. Just one comment, I would say something
> like "as an adjunct to" or "in contrast to" rather than "instead of",
> because they're not mutually exclusive, even though they're two different
> ways of addressing the issue.
>
> Regards
> -- Bhaskar
>
> On 12/19/2013 11:16 AM (US Eastern Time), petercyli wrote:
>
> Minutes on Moving VistA Forward - a Modest Proposal for Reengineering
> VistA, K.S. Bhaskar:
>
> Thanks to Bhaskar for an interesting discussion on reengineering VistA.
> Although the title says "A Modest Proposal", we know any reengineering of
> a complex large scale enterprise system is never modest and always a huge
> undertaking - requiring a long term vision and large financial commitment
> over many years. That said, Bhaskar presented the lessons learned from a
> successful reengineering of the "FIS Profile" - a large scale enterprise
> M-system based application that runs the three largest real-time core
> banking systems in the world.
>
> Back in the late 90's the "FIS Profile" application faced similar concerns
> to those that apply to VistA today, and over a period of several years, the
> FIS team slowly evolve the "FIS Profile" from M language to a more
> maintainable higher level scripting language called Profile Scription
> Language (PSL). During the reengineering process, the team also made many
> improvements such as separation of UI from business logic, ensure
> application consistency after a crash by enabling transaction fences,
> support stateless message processing, etc.
>
> Some of the key lessons learned:
>
> *Horizonal reengineering instead of vertical reengineering*!!!
>
> - Revolution through evolution
> - Avoid encapsulation
> - Choose a language and compile it into M
> - Re-architect as you go
> - Integration beats Balkanization
> - The value of M technology is as an execution engine
>
> For detailed descriptions, please check out the slides<http://www.osehra.org/sites/default/files/130826-1reengineeringvistaprop... the
> recording<https://osehra.webex.com/osehra/lsr.php?AT=pb&SP=EC&rID=7949867&rKey=da2...
> .
>
> Links:
>
> • FIS GT.M: http://fis-gtm.com• FIS Profile: http://fis-profile.com• FIS
> PIP: http://fis-pip.com• Anti-patterns:
> http://sourcemaking.com/antipatterns/software-architecture-antipatterns•K.S. Bhaskar /
> ks.bhaskar@fisglobal.com / +1 (610) 578-4265
>
> We will not having any meetings until the third week of January.
>
> Tentatively scheduled presentations:
>
> January 10th - Special session on *VistA Novo Demo*, Salim Samy, Mitre
>
> January 14th - *Socratic Grid - Open Source Clinical Decision Support*,
> Emory Fry, MD, CMIO, Cognitive Medical Systems, Inc.
>
> Happy Holidays.
>
>
>
>
>
> Promote content
> Group sticky:
>
> Not Sticky
>
> Featured content:
>
> Not Featured
>
> --
> Full post:
> http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/3463
>
>
>
> --
>
> GT.M - Rock solid. Lightning fast. Secure. No compromises.
>
> _____________
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i) delete the
> message and all copies; (ii) do not disclose, distribute or use the message
> in any manner; and (iii) notify the sender immediately. In addition, please
> be aware that any message addressed to our domain is subject to archiving
> and review by persons other than the intended recipient. Thank you.
>
> --
> Full post:
> http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/3463
>
>

like0

AWG Meeting Minutes and Recording: Moving VistA Forward - a Mode

Mike Henderson's picture

That last paragraph should say: "*the factoring out of encapsulation*"!

Mike Henderson, FHL7
Director, Open Source Product Management
OSEHRA
900 N. Glebe Road, Suite 4-016
Arlington, VA 22203 USA
(o) +1 571 858-3383
(m) +1 240 351-5908

On Thu, Dec 19, 2013 at 5:20 PM, Mike Henderson <hendersonm@osehra.org>wrote:

> While I was absent from Bhaskar's presentation, I think his slide points
> to the paradox within which the evil of encapsulation can lurk.
> Specifically, those application elements whose logic is most gnarled, and
> that are thus most difficult to validate, are those which are *least *safe
> to encapsulate, because encapsulation fossilizes their problems. The
> nature and scope of the problems being fossilized, of course, make those
> elements the *most *tempting to encapsulate!
>
> A credible re-engineering strategy will target such elements for intensive
> examination and rework. It will not infrequently be found that such
> elements are not bound to any identifiably consistent business logic. A
> corollary is that the business processes that use them are themselves
> candidates for being re-engineered, because they have been forced over time
> to adapt to the increasing number of tangles within the code that was
> supposed to facilitate those processes.
>
> The good news in all this is that Bhaskar's presentation illustrates that
> the Augean stables are capable of being mucked out, and reasonably posits
> that encapsulation is a useful element of a mucking-out strategy. I am
> inclined not to insist on the adoption of a technology that enforces
> encapsulation. However, the case for doing so is powerful, particularly in
> the medical-device use cases that apply to imaging and blood bank software.
> From an overall quality point of view, encapsulation may be a mandatory
> element to mitigate risk within any development framework.
>
> Mike Henderson, FHL7
> Director, Open Source Product Management
> OSEHRA
> 900 N. Glebe Road, Suite 4-016
> Arlington, VA 22203 USA
> (o) +1 571 858-3383
> (m) +1 240 351-5908
>
>
> On Thu, Dec 19, 2013 at 1:12 PM, Stephen Hufnagel <hufnagels@osehra.org>wrote:
>
>> Good day Bhaskar,
>>
>>
>>
>> Your presentation was most interesting; but,
>>
>> you advise against encapsulation, it seems essential during a transition
>> period; where, new features might be added while legacy repurposing is
>> simultaneously occurring over a potentially extended period of time.
>>
>>
>>
>> If you disagree, I would appreciate an explanation.
>>
>>
>>
>> Thank you for your help and consideration,
>>
>> Steve
>>
>> ____________________________________________
>>
>> *Stephen P. Hufnagel* PhD, Health IT Architect and Data-Interoperability
>> Engineer
>>
>> The Information Applications Group (TIAG)
>>
>> 1760 Reston Parkway, Suite 510, Reston, VA 20190
>>
>> 703-437-7878, Shufnagel@tiag.net
>>
>> *PERSONAL*: PO Box 8097, Falls Church, VA 22041
>>
>> 703-575-7912-mobile and *preferred phone*
>>
>> 703-995-0841-eFAX, Hufnagel@acm.org
>>
>>
>>
>> "It is not the critic who counts, not the man who points out how the
>> strong man stumbled, or where the doer of deeds could have done better. The
>> credit belongs to the man who is actually in the arena; whose face is
>> marred by the dust and sweat and blood; who strives valiantly; who errs and
>> comes short again and again; who knows the great enthusiasms, the great
>> devotions and spends himself in a worthy course; who at the best, knows in
>> the end the triumph of high achievement, and who, at worst, if he fails, at
>> least fails while daring greatly; so that his place shall never be with
>> those cold and timid souls who know neither victory or defeat." Theodore
>> Roosevelt. (Paris Sorbonne, 1910)
>>
>>
>>
>> *From:* Apache [mailto:apache@groups.osehra.org] *On Behalf Of *"Bhaskar,
>> K.S"
>> *Sent:* Thursday, December 19, 2013 11:23 AM
>> *To:* architecture@groups.osehra.org
>> *Subject:* Re: [architecture] AWG Meeting Minutes and Recording: Moving
>> VistA Forward - a Modest Proposal for Reengineering VistA, K.S. Bhaskar,
>> Dec. 17 2013
>>
>>
>>
>> Thanks for a good summary, Peter. Just one comment, I would say
>> something like "as an adjunct to" or "in contrast to" rather than "instead
>> of", because they're not mutually exclusive, even though they're two
>> different ways of addressing the issue.
>>
>> Regards
>> -- Bhaskar
>>
>> On 12/19/2013 11:16 AM (US Eastern Time), petercyli wrote:
>>
>> Minutes on Moving VistA Forward - a Modest Proposal for Reengineering
>> VistA, K.S. Bhaskar:
>>
>> Thanks to Bhaskar for an interesting discussion on reengineering VistA.
>> Although the title says "A Modest Proposal", we know any reengineering of
>> a complex large scale enterprise system is never modest and always a huge
>> undertaking - requiring a long term vision and large financial commitment
>> over many years. That said, Bhaskar presented the lessons learned from a
>> successful reengineering of the "FIS Profile" - a large scale enterprise
>> M-system based application that runs the three largest real-time core
>> banking systems in the world.
>>
>> Back in the late 90's the "FIS Profile" application faced similar
>> concerns to those that apply to VistA today, and over a period of several
>> years, the FIS team slowly evolve the "FIS Profile" from M language to a
>> more maintainable higher level scripting language called Profile Scription
>> Language (PSL). During the reengineering process, the team also made many
>> improvements such as separation of UI from business logic, ensure
>> application consistency after a crash by enabling transaction fences,
>> support stateless message processing, etc.
>>
>> Some of the key lessons learned:
>>
>> *Horizonal reengineering instead of vertical reengineering*!!!
>>
>> - Revolution through evolution
>> - Avoid encapsulation
>> - Choose a language and compile it into M
>> - Re-architect as you go
>> - Integration beats Balkanization
>> - The value of M technology is as an execution engine
>>
>> For detailed descriptions, please check out the slides<http://www.osehra.org/sites/default/files/130826-1reengineeringvistaprop... the
>> recording<https://osehra.webex.com/osehra/lsr.php?AT=pb&SP=EC&rID=7949867&rKey=da2...
>> .
>>
>> Links:
>>
>> • FIS GT.M: http://fis-gtm.com• FIS Profile: http://fis-profile.com• FIS
>> PIP: http://fis-pip.com• Anti-patterns:
>> http://sourcemaking.com/antipatterns/software-architecture-antipatterns•K.S. Bhaskar /
>> ks.bhaskar@fisglobal.com / +1 (610) 578-4265
>>
>> We will not having any meetings until the third week of January.
>>
>> Tentatively scheduled presentations:
>>
>> January 10th - Special session on *VistA Novo Demo*, Salim Samy, Mitre
>>
>> January 14th - *Socratic Grid - Open Source Clinical Decision Support*,
>> Emory Fry, MD, CMIO, Cognitive Medical Systems, Inc.
>>
>> Happy Holidays.
>>
>>
>>
>>
>>
>> Promote content
>> Group sticky:
>>
>> Not Sticky
>>
>> Featured content:
>>
>> Not Featured
>>
>> --
>> Full post:
>> http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
>> Manage my subscriptions:
>> http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>> http://www.osehra.org/og_mailinglist/unsubscribe/3463
>>
>>
>>
>> --
>>
>> GT.M - Rock solid. Lightning fast. Secure. No compromises.
>>
>> _____________
>> The information contained in this message is proprietary and/or
>> confidential. If you are not the intended recipient, please: (i) delete the
>> message and all copies; (ii) do not disclose, distribute or use the message
>> in any manner; and (iii) notify the sender immediately. In addition, please
>> be aware that any message addressed to our domain is subject to archiving
>> and review by persons other than the intended recipient. Thank you.
>>
>> --
>> Full post:
>> http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
>>
>> Manage my subscriptions:
>> http://www.osehra.org/og_mailinglist/subscriptions
>> Stop emails for this post:
>> http://www.osehra.org/og_mailinglist/unsubscribe/3463
>>
>>
>

like0

AWG Meeting Minutes and Recording: Moving VistA Forward - a Mode

K.S. Bhaskar's picture

An important point is that automated conversion will not transform 100%
of the code. Some part of it will need to be converted by hand. In our
case, for example, I remember that there were a couple of modules that
stood out as being the most complex, and at the heart of everything (in
the most simplistic view, everything in banking is either a deposit or a
loan). Re-engineering them took extra TLC from knowledgeable people.

One thing that I think we did right is to write the PSL compiler in PSL
(and yes, this required bootstrapping). This meant that as the PSL
compiler got better, the compilation process also got better.

One lesson I wish we had learned earlier in the project was to invest
more aggressively in automated testing sooner.

Regards
-- Bhaskar

On 12/19/2013 05:21 PM (US Eastern Time), Mike Henderson wrote:
> That last paragraph should say: "*the factoring out of encapsulation*"!
>
> Mike Henderson, FHL7
> Director, Open Source Product Management
> OSEHRA
> 900 N. Glebe Road, Suite 4-016
> Arlington, VA 22203 USA
> (o) +1 571 858-3383
> (m) +1 240 351-5908impl
>
>
> On Thu, Dec 19, 2013 at 5:20 PM, Mike Henderson <hendersonm@osehra.org
> <mailto:hendersonm@osehra.org>> wrote:
>
> While I was absent from Bhaskar's presentation, I think his slide
> points to the paradox within which the evil of encapsulation can
> lurk. Specifically, those application elements whose logic is most
> gnarled, and that are thus most difficult to validate, are those
> which are /least /safe to encapsulate, because encapsulation
> fossilizes their problems. The nature and scope of the problems
> being fossilized, of course, make those elements the /most
> /tempting to encapsulate!
>
> A credible re-engineering strategy will target such elements for
> intensive examination and rework. It will not infrequently be
> found that such elements are not bound to any identifiably
> consistent business logic. A corollary is that the business
> processes that use them are themselves candidates for being
> re-engineered, because they have been forced over time to adapt to
> the increasing number of tangles within the code that was supposed
> to facilitate those processes.
>
> The good news in all this is that Bhaskar's presentation
> illustrates that the Augean stables are capable of being mucked
> out, and reasonably posits that encapsulation is a useful element
> of a mucking-out strategy. I am inclined not to insist on the
> adoption of a technology that enforces encapsulation. However, the
> case for doing so is powerful, particularly in the medical-device
> use cases that apply to imaging and blood bank software. From an
> overall quality point of view, encapsulation may be a mandatory
> element to mitigate risk within any development framework.
>
> Mike Henderson, FHL7
> Director, Open Source Product Management
> OSEHRA
> 900 N. Glebe Road, Suite 4-016
> Arlington, VA 22203 USA
> (o) +1 571 858-3383 <tel:%2B1%20571%20858-3383>
> (m) +1 240 351-5908 <tel:%2B1%20240%20351-5908>
>
>
> On Thu, Dec 19, 2013 at 1:12 PM, Stephen Hufnagel
> <hufnagels@osehra.org <mailto:hufnagels@osehra.org>> wrote:
>
> Good day Bhaskar,
>
> Your presentation was most interesting; but,
>
> you advise against encapsulation, it seems essential during a
> transition period; where, new features might be added while
> legacy repurposing is simultaneously occurring over a
> potentially extended period of time.
>
> If you disagree, I would appreciate an explanation.
>
> Thank you for your help and consideration,
>
> Steve
>
> ____________________________________________
>
> *Stephen P. Hufnagel*PhD, Health IT Architect and
> Data-Interoperability Engineer
>
> The Information Applications Group (TIAG)
>
> **1760 Reston Parkway, Suite 510, Reston, VA 20190
>
> 703-437-7878 <tel:703-437-7878>, Shufnagel@tiag.net
> <mailto:Shufnagel@tiag.net>
>
> *PERSONAL*: PO Box 8097, Falls Church, VA 22041
>
> 703-575-7912 <tel:703-575-7912>-mobile and /_preferred phone_/
>
> 703-995-0841 <tel:703-995-0841>-eFAX, Hufnagel@acm.org
> <mailto:Hufnagel@acm.org>
>
> "It is not the critic who counts, not the man who points out
> how the strong man stumbled, or where the doer of deeds could
> have done better. The credit belongs to the man who is actually
> in the arena; whose face is marred by the dust and sweat and
> blood; who strives valiantly; who errs and comes short again
> and again; who knows the great enthusiasms, the great devotions
> and spends himself in a worthy course; who at the best, knows
> in the end the triumph of high achievement, and who, at worst,
> if he fails, at least fails while daring greatly; so that his
> place shall never be with those cold and timid souls who know
> neither victory or defeat." Theodore Roosevelt. (Paris
> Sorbonne, 1910)
>
> *From:*Apache [mailto:apache@groups.osehra.org
> <mailto:apache@groups.osehra.org>] *On Behalf Of *"Bhaskar, K.S"
> *Sent:* Thursday, December 19, 2013 11:23 AM
> *To:* architecture@groups.osehra.org
> <mailto:architecture@groups.osehra.org>
> *Subject:* Re: [architecture] AWG Meeting Minutes and
> Recording: Moving VistA Forward - a Modest Proposal for
> Reengineering VistA, K.S. Bhaskar, Dec. 17 2013
>
> Thanks for a good summary, Peter. Just one comment, I would
> say something like "as an adjunct to" or "in contrast to"
> rather than "instead of", because they're not mutually
> exclusive, even though they're two different ways of addressing
> the issue.
>
> Regards
> -- Bhaskar
>
> On 12/19/2013 11:16 AM (US Eastern Time), petercyli wrote:
>
> Minutes on Moving VistA Forward - a Modest Proposal for
> Reengineering VistA, K.S. Bhaskar:
>
> Thanks to Bhaskar for an interesting discussion on
> reengineering VistA. Although the title says "A Modest
> Proposal", we know any reengineering of a complex large
> scale enterprise system is never modest and always a huge
> undertaking - requiring a long term vision and large
> financial commitment over many years. That said, Bhaskar
> presented the lessons learned from a successful
> reengineering of the "FIS Profile" - a large scale
> enterprise M-system based application that runs the three
> largest real-time core banking systems in the world.
>
> Back in the late 90's the "FIS Profile" application faced
> similar concerns to those that apply to VistA today, and
> over a period of several years, the FIS team slowly evolve
> the "FIS Profile" from M language to a more maintainable
> higher level scripting language called Profile Scription
> Language (PSL). During the reengineering process, the team
> also made many improvements such as separation of UI from
> business logic, ensure application consistency after a
> crash by enabling transaction fences, support stateless
> message processing, etc.
>
> Some of the key lessons learned:
>
> *Horizonal reengineering instead of vertical reengineering*!!!
>
> * Revolution through evolution
> * Avoid encapsulation
> * Choose a language and compile it into M
> * Re-architect as you go
> * Integration beats Balkanization
> * The value of M technology is as an execution engine
>
> For detailed descriptions, please check out the slides
> <http://www.osehra.org/sites/default/files/130826-1reengineeringvistaprop...
> and the recording
> <https://osehra.webex.com/osehra/lsr.php?AT=pb&SP=EC&rID=7949867&rKey=da2....
>
> Links:
>
> • FIS GT.M: http://fis-gtm.com
> <http://fis-gtm.com%E2%80%A2> FIS Profile:
> http://fis-profile.com• <http://fis-profile.com%E2%80%A2>
> FIS PIP: http://fis-pip.com• <http://fis-pip.com%E2%80%A2>
> Anti-patterns:
> http://sourcemaking.com/antipatterns/software-architecture-antipatterns
> <http://sourcemaking.com/antipatterns/software-architecture-antipatterns%...
> K.S. Bhaskar / ks.bhaskar@fisglobal.com
> <mailto:ks.bhaskar@fisglobal.com> / +1 (610) 578-4265
> <tel:%2B1%20%28610%29%20578-4265>
>
> We will not having any meetings until the third week of
> January.
>
> Tentatively scheduled presentations:
>
> January 10th - Special session on /VistA Novo Demo/, Salim
> Samy, Mitre
>
> January 14th - /Socratic Grid - Open Source Clinical
> Decision Support/, Emory Fry, MD, CMIO, Cognitive Medical
> Systems, Inc.
>
> Happy Holidays.
>
> Promote content
> Group sticky:
>
> Not Sticky
>
> Featured content:
>
> Not Featured
>
> --
> Full post:
> http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
> <http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/3463
>
>
>
> --
>
> GT.M - Rock solid. Lightning fast. Secure. No compromises.
>
> _____________
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please:
> (i) delete the message and all copies; (ii) do not disclose,
> distribute or use the message in any manner; and (iii) notify
> the sender immediately. In addition, please be aware that any
> message addressed to our domain is subject to archiving and
> review by persons other than the intended recipient. Thank you.
>
>
> --
> Full post:
> http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
>
>
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/3463
>
>
>
>
>
> --
> Full post: http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3463

--
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

like0

AWG Meeting Minutes and Recording: Moving VistA Forward - a Mode

Stephen Hufnagel's picture

Thank you for your most thoughtful feedback.

Automated and in particular certain built in testing is indeed essential to robustness during transition.

Thank you for sharing your lessons learned in your innovative approach,

Steve

From: Apache [mailto:apache@groups.osehra.org] On Behalf Of "Bhaskar, K.S"
Sent: Thursday, December 19, 2013 9:54 PM
To: architecture@groups.osehra.org
Subject: Re: [architecture] AWG Meeting Minutes and Recording: Moving VistA Forward - a Modest Proposal for Reengineering VistA, K.S. Bhaskar, Dec. 17 2013

An important point is that automated conversion will not transform 100% of the code. Some part of it will need to be converted by hand. In our case, for example, I remember that there were a couple of modules that stood out as being the most complex, and at the heart of everything (in the most simplistic view, everything in banking is either a deposit or a loan). Re-engineering them took extra TLC from knowledgeable people.

One thing that I think we did right is to write the PSL compiler in PSL (and yes, this required bootstrapping). This meant that as the PSL compiler got better, the compilation process also got better.

One lesson I wish we had learned earlier in the project was to invest more aggressively in automated testing sooner.

Regards
-- Bhaskar

On 12/19/2013 05:21 PM (US Eastern Time), Mike Henderson wrote:

That last paragraph should say: "the factoring out of encapsulation"!

Mike Henderson, FHL7

Director, Open Source Product Management

OSEHRA

900 N. Glebe Road, Suite 4-016

Arlington, VA 22203 USA

(o) +1 571 858-3383

(m) +1 240 351-5908impl

On Thu, Dec 19, 2013 at 5:20 PM, Mike Henderson <hendersonm@osehra.org> wrote:

While I was absent from Bhaskar's presentation, I think his slide points to the paradox within which the evil of encapsulation can lurk. Specifically, those application elements whose logic is most gnarled, and that are thus most difficult to validate, are those which are least safe to encapsulate, because encapsulation fossilizes their problems. The nature and scope of the problems being fossilized, of course, make those elements the most tempting to encapsulate!

A credible re-engineering strategy will target such elements for intensive examination and rework. It will not infrequently be found that such elements are not bound to any identifiably consistent business logic. A corollary is that the business processes that use them are themselves candidates for being re-engineered, because they have been forced over time to adapt to the increasing number of tangles within the code that was supposed to facilitate those processes.

The good news in all this is that Bhaskar's presentation illustrates that the Augean stables are capable of being mucked out, and reasonably posits that encapsulation is a useful element of a mucking-out strategy. I am inclined not to insist on the adoption of a technology that enforces encapsulation. However, the case for doing so is powerful, particularly in the medical-device use cases that apply to imaging and blood bank software. From an overall quality point of view, encapsulation may be a mandatory element to mitigate risk within any development framework.

Mike Henderson, FHL7

Director, Open Source Product Management

OSEHRA

900 N. Glebe Road, Suite 4-016

Arlington, VA 22203 USA

(o) +1 571 858-3383 <tel:%2B1%20571%20858-3383>

(m) +1 240 351-5908 <tel:%2B1%20240%20351-5908>

On Thu, Dec 19, 2013 at 1:12 PM, Stephen Hufnagel <hufnagels@osehra.org> wrote:

Good day Bhaskar,

Your presentation was most interesting; but,

you advise against encapsulation, it seems essential during a transition period; where, new features might be added while legacy repurposing is simultaneously occurring over a potentially extended period of time.

If you disagree, I would appreciate an explanation.

Thank you for your help and consideration,

Steve

____________________________________________

Stephen P. Hufnagel PhD, Health IT Architect and Data-Interoperability Engineer

The Information Applications Group (TIAG)

1760 Reston Parkway, Suite 510, Reston, VA 20190

703-437-7878, Shufnagel@tiag.net

PERSONAL: PO Box 8097, Falls Church, VA 22041

703-575-7912-mobile and preferred phone

703-995-0841-eFAX, Hufnagel@acm.org

"It is not the critic who counts, not the man who points out how the strong man stumbled, or where the doer of deeds could have done better. The credit belongs to the man who is actually in the arena; whose face is marred by the dust and sweat and blood; who strives valiantly; who errs and comes short again and again; who knows the great enthusiasms, the great devotions and spends himself in a worthy course; who at the best, knows in the end the triumph of high achievement, and who, at worst, if he fails, at least fails while daring greatly; so that his place shall never be with those cold and timid souls who know neither victory or defeat." Theodore Roosevelt. (Paris Sorbonne, 1910)

From: Apache [mailto:apache@groups.osehra.org] On Behalf Of "Bhaskar, K.S"
Sent: Thursday, December 19, 2013 11:23 AM
To: architecture@groups.osehra.org
Subject: Re: [architecture] AWG Meeting Minutes and Recording: Moving VistA Forward - a Modest Proposal for Reengineering VistA, K.S. Bhaskar, Dec. 17 2013

Thanks for a good summary, Peter. Just one comment, I would say something like "as an adjunct to" or "in contrast to" rather than "instead of", because they're not mutually exclusive, even though they're two different ways of addressing the issue.

Regards
-- Bhaskar

On 12/19/2013 11:16 AM (US Eastern Time), petercyli wrote:

Minutes on Moving VistA Forward - a Modest Proposal for Reengineering VistA, K.S. Bhaskar:

Thanks to Bhaskar for an interesting discussion on reengineering VistA. Although the title says "A Modest Proposal", we know any reengineering of a complex large scale enterprise system is never modest and always a huge undertaking - requiring a long term vision and large financial commitment over many years. That said, Bhaskar presented the lessons learned from a successful reengineering of the "FIS Profile" - a large scale enterprise M-system based application that runs the three largest real-time core banking systems in the world.

Back in the late 90's the "FIS Profile" application faced similar concerns to those that apply to VistA today, and over a period of several years, the FIS team slowly evolve the "FIS Profile" from M language to a more maintainable higher level scripting language called Profile Scription Language (PSL). During the reengineering process, the team also made many improvements such as separation of UI from business logic, ensure application consistency after a crash by enabling transaction fences, support stateless message processing, etc.

Some of the key lessons learned:

Horizonal reengineering instead of vertical reengineering!!!

* Revolution through evolution
* Avoid encapsulation
* Choose a language and compile it into M
* Re-architect as you go
* Integration beats Balkanization
* The value of M technology is as an execution engine

For detailed descriptions, please check out the slides <http://www.osehra.org/sites/default/files/130826-1reengineeringvistaprop... and the recording <https://osehra.webex.com/osehra/lsr.php?AT=pb&SP=EC&rID=7949867&rKey=da2... .

Links:

• FIS GT.M: http://fis-gtm.com• <http://fis-gtm.com%E2%80%A2> FIS Profile: http://fis-profile.com• <http://fis-profile.com%E2%80%A2> FIS PIP: http://fis-pip.com• <http://fis-pip.com%E2%80%A2> Anti-patterns: http://sourcemaking.com/antipatterns/software-architecture-antipatterns• <http://sourcemaking.com/antipatterns/software-architecture-antipatterns%... K.S. Bhaskar / ks.bhaskar@fisglobal.com / +1 (610) 578-4265 <tel:%2B1%20%28610%29%20578-4265>

We will not having any meetings until the third week of January.

Tentatively scheduled presentations:

January 10th - Special session on VistA Novo Demo, Salim Samy, Mitre

January 14th - Socratic Grid - Open Source Clinical Decision Support, Emory Fry, MD, CMIO, Cognitive Medical Systems, Inc.

Happy Holidays.

Promote content
Group sticky:

Not Sticky

Featured content:

Not Featured

--
Full post: http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist... <http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3463

--
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

--
Full post: http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...

Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3463

--
Full post: http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3463

--
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

like0

AWG Meeting Minutes and Recording: Moving VistA Forward - a Mode

K.S. Bhaskar's picture

Steve --

To me encapsulation and transition are orthogonal issues, but let me try
to explain what I mean by encapsulation and also how transition works in
the process I outlined.

The encapsulation that I said should be avoided is where one wraps lower
level code with an API (e.g., an RPC) and /never changes the encapsulated
code/. In time, that will cause the encapsulated code to become
obsolete, and in turn cause the API to become obsolete, and eventually
cause the application to become obsolete. I have no issues with wrapping
code with API layers. The important point is that /no part of the code
base must be encapsulated in such a way that it cannot be maintained/, or
conversely, /one must retain the ability to, and be prepared to, maintain
any and every part of the code base/.

During the transition, which can take years, the application certainly
cannot go into functional stasis. Where vertical and horizontal
re-engineering intersect, there needs to be some thoughtful technical
planning & project management. Let's say the Treblig module is to be
enhanced (vertical re-engineering) while Navillus, the horizontal
re-engineering project is underway, i.e., the code modules are in some
combination of M and M' (M prime). The important point is that as the
Navillus project transforms source code from M to M', and including
improving structure, replacing direct global references with database
management system calls, etc. it makes no functional changes to the
code. The Navillus project is developing two tools - to convert patterns
of M code to M' code, and to compile M' code into M code.

The Treblig project takes a snapshot of the code to work on. Since M and
M' code coexist in the same module, in theory, it doesn't matter whether
they make their changes in M code or M' code because the tools developed
by Navillus can transform code either way. In practice, when the Treblig
project modifies existing code, it will use whatever language that chunk
of code is written in, and it will write new code in M'.

Importantly, the Treblig and Navillus teams /must/ plan to cooperate.
Perhaps at the beginning of every sprint Treblig should take the latest
version of the Navillus tools and run their latest code through the M to
M' converter, and then compile it into M and then run their tests on it
to validate the round-tripping.

In retrospect, in my pithy sayings slide, I should have added something
like "If you had to do it all over again, you'd do it better and get it
done in less time," or "You will make mistakes". In the course of the
project we learned enough so that if we had to do it all over again, we
would not make the same mistakes again (I suppose we would make different
mistakes…).

Regards
-- Bhaskar

On 12/19/2013 01:12 PM (US Eastern Time), Stephen Hufnagel wrote:
>
> Good day Bhaskar,
>
> Your presentation was most interesting; but,
>
> you advise against encapsulation, it seems essential during a
> transition period; where, new features might be added while legacy
> repurposing is simultaneously occurring over a potentially extended
> period of time.
>
> If you disagree, I would appreciate an explanation.
>
> Thank you for your help and consideration,
>
> Steve
>
> ____________________________________________
>
> *Stephen P. Hufnagel*PhD, Health IT Architect and Data-Interoperability
> Engineer **
>
> The Information Applications Group (TIAG)
>
> **1760 Reston Parkway, Suite 510, Reston, VA 20190
>
> 703-437-7878, Shufnagel@tiag.net <mailto:Shufnagel@tiag.net>
>
> *PERSONAL*: PO Box 8097, Falls Church, VA 22041
>
> 703-575-7912-mobile and /_preferred phone_/
>
> 703-995-0841-eFAX, Hufnagel@acm.org <mailto:Hufnagel@acm.org>
>
> "It is not the critic who counts, not the man who points out how the
> strong man stumbled, or where the doer of deeds could have done better.
> The credit belongs to the man who is actually in the arena; whose face
> is marred by the dust and sweat and blood; who strives valiantly; who
> errs and comes short again and again; who knows the great enthusiasms,
> the great devotions and spends himself in a worthy course; who at the
> best, knows in the end the triumph of high achievement, and who, at
> worst, if he fails, at least fails while daring greatly; so that his
> place shall never be with those cold and timid souls who know neither
> victory or defeat." Theodore Roosevelt. (Paris Sorbonne, 1910)
>
> *From:*Apache [mailto:apache@groups.osehra.org] *On Behalf Of
> *"Bhaskar, K.S"
> *Sent:* Thursday, December 19, 2013 11:23 AM
> *To:* architecture@groups.osehra.org
> *Subject:* Re: [architecture] AWG Meeting Minutes and Recording: Moving
> VistA Forward - a Modest Proposal for Reengineering VistA, K.S.
> Bhaskar, Dec. 17 2013
>
> Thanks for a good summary, Peter. Just one comment, I would say
> something like "as an adjunct to" or "in contrast to" rather than
> "instead of", because they're not mutually exclusive, even though
> they're two different ways of addressing the issue.
>
> Regards
> -- Bhaskar
>
> On 12/19/2013 11:16 AM (US Eastern Time), petercyli wrote:
>
> Minutes on Moving VistA Forward - a Modest Proposal for
> Reengineering VistA, K.S. Bhaskar:
>
> Thanks to Bhaskar for an interesting discussion on reengineering
> VistA. Although the title says "A Modest Proposal", we know any
> reengineering of a complex large scale enterprise system is never
> modest and always a huge undertaking - requiring a long term vision
> and large financial commitment over many years. That said,
> Bhaskar presented the lessons learned from a successful
> reengineering of the "FIS Profile" - a large scale enterprise
> M-system based application that runs the three largest real-time
> core banking systems in the world.
>
> Back in the late 90's the "FIS Profile" application faced similar
> concerns to those that apply to VistA today, and over a period of
> several years, the FIS team slowly evolve the "FIS Profile" from M
> language to a more maintainable higher level scripting language
> called Profile Scription Language (PSL). During the reengineering
> process, the team also made many improvements such as separation of
> UI from business logic, ensure application consistency after a
> crash by enabling transaction fences, support stateless message
> processing, etc.
>
> Some of the key lessons learned:
>
> *Horizonal reengineering instead of vertical reengineering*!!!
>
> * Revolution through evolution
> * Avoid encapsulation
> * Choose a language and compile it into M
> * Re-architect as you go
> * Integration beats Balkanization
> * The value of M technology is as an execution engine
>
> For detailed descriptions, please check out the slides
> <http://www.osehra.org/sites/default/files/130826-1reengineeringvistaprop...
> and the recording
> <https://osehra.webex.com/osehra/lsr.php?AT=pb&SP=EC&rID=7949867&rKey=da2....
>
> Links:
>
> • FIS GT.M: http://fis-gtm.com• <http://fis-gtm.com%E2%80%A2> FIS
> Profile: http://fis-profile.com• <http://fis-profile.com%E2%80%A2>
> FIS PIP: http://fis-pip.com• <http://fis-pip.com%E2%80%A2>
> Anti-patterns:
> http://sourcemaking.com/antipatterns/software-architecture-antipatterns
> <http://sourcemaking.com/antipatterns/software-architecture-antipatterns%...
> K.S. Bhaskar / ks.bhaskar@fisglobal.com
> <mailto:ks.bhaskar@fisglobal.com> / +1 (610) 578-4265
>
> We will not having any meetings until the third week of January.
>
> Tentatively scheduled presentations:
>
> January 10th - Special session on /VistA Novo Demo/, Salim Samy, Mitre
>
> January 14th - /Socratic Grid - Open Source Clinical Decision
> Support/, Emory Fry, MD, CMIO, Cognitive Medical Systems, Inc.
>
> Happy Holidays.
>
> Promote content
> Group sticky:
>
> Not Sticky
>
> Featured content:
>
> Not Featured
>
> --
> Full post:
> http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
> <http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
> Manage my subscriptions:
> http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post:
> http://www.osehra.org/og_mailinglist/unsubscribe/3463
>
>
>
> --
> GT.M - Rock solid. Lightning fast. Secure. No compromises.
>
> _____________
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i) delete
> the message and all copies; (ii) do not disclose, distribute or use the
> message in any manner; and (iii) notify the sender immediately. In
> addition, please be aware that any message addressed to our domain is
> subject to archiving and review by persons other than the intended
> recipient. Thank you.
>
>
>
> --
> Full post: http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3463

--
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

like0

AWG Meeting Minutes and Recording: Moving VistA Forward - a Mode

Terry Luedtke's picture

Hello Bhaskar,

I just watched the recording of your presentation and found it very interesting. Thank you. I do have one question about the “Avoid Encapsulation”. As I understand the slides, you don’t mean the object-oriented definition of encapsulation where code and internal data structures are hidden in one section of code is hidden from other sections of code. But, rather, that no code is restricted from the reengineering effort. For example M code behind an API could be refactored into PSL without affecting the API or exposing internal structure. I’m concerned that the text “Avoid Encapsulation” will set off alarm bells in developers who have been drilled in “good programming practices”. Perhaps text along the lines of “Every line of code must be available to be reengineered” would be less likely to be misunderstood?

--
Terry Luedtke DoD/VA Interagency Program Office
terry.luedtke@va.gov<mailto:terry.luedtke@va.gov> 801 I St, NW
Washington, DC 20001

On programming: “You need the willingness to fail all the time. You have to generate many ideas and then you have to work very hard only to discover that they don’t work. And you keep doing that over and over until you find one that does work.” - John Backus, inventor of the Fortran programming language

From: Apache [mailto:apache@groups.osehra.org] On Behalf Of "Bhaskar, K.S"
Sent: Thursday, December 19, 2013 11:23 AM
To: architecture@groups.osehra.org
Subject: Re: [architecture] AWG Meeting Minutes and Recording: Moving VistA Forward - a Modest Proposal for Reengineering VistA, K.S. Bhaskar, Dec. 17 2013

Thanks for a good summary, Peter. Just one comment, I would say something like "as an adjunct to" or "in contrast to" rather than "instead of", because they're not mutually exclusive, even though they're two different ways of addressing the issue.

Regards
-- Bhaskar
On 12/19/2013 11:16 AM (US Eastern Time), petercyli wrote:

Minutes on Moving VistA Forward - a Modest Proposal for Reengineering VistA, K.S. Bhaskar:

Thanks to Bhaskar for an interesting discussion on reengineering VistA. Although the title says "A Modest Proposal", we know any reengineering of a complex large scale enterprise system is never modest and always a huge undertaking - requiring a long term vision and large financial commitment over many years. That said, Bhaskar presented the lessons learned from a successful reengineering of the "FIS Profile" - a large scale enterprise M-system based application that runs the three largest real-time core banking systems in the world.

Back in the late 90's the "FIS Profile" application faced similar concerns to those that apply to VistA today, and over a period of several years, the FIS team slowly evolve the "FIS Profile" from M language to a more maintainable higher level scripting language called Profile Scription Language (PSL). During the reengineering process, the team also made many improvements such as separation of UI from business logic, ensure application consistency after a crash by enabling transaction fences, support stateless message processing, etc.

Some of the key lessons learned:

Horizonal reengineering instead of vertical reengineering!!!

* Revolution through evolution
* Avoid encapsulation
* Choose a language and compile it into M
* Re-architect as you go
* Integration beats Balkanization
* The value of M technology is as an execution engine

For detailed descriptions, please check out the slides<http://www.osehra.org/sites/default/files/130826-1reengineeringvistaprop... and the recording<https://osehra.webex.com/osehra/lsr.php?AT=pb&SP=EC&rID=7949867&rKey=da2....

Links:

• FIS GT.M: http://fis-gtm.com• FIS Profile: http://fis-profile.com• FIS PIP: http://fis-pip.com• Anti-patterns: http://sourcemaking.com/antipatterns/software-architecture-antipatterns• K.S. Bhaskar / ks.bhaskar@fisglobal.com<mailto:ks.bhaskar@fisglobal.com> / +1 (610) 578-4265

We will not having any meetings until the third week of January.

Tentatively scheduled presentations:

January 10th - Special session on VistA Novo Demo, Salim Samy, Mitre

January 14th - Socratic Grid - Open Source Clinical Decision Support, Emory Fry, MD, CMIO, Cognitive Medical Systems, Inc.

Happy Holidays.

Promote content
Group sticky:

Not Sticky

Featured content:

Not Featured
--
Full post: http://www.osehra.org/blog/awg-meeting-minutes-and-recording-moving-vist...
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3463

--

GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

like0