[Info-vax] OpenVMS developmen integration with Azure DevOps.

[Arne Vajhøj]

On 9/4/2021 11:10 AM, kemain.nospam at gmail.com wrote:
>> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Arne
>> Vajhøj via Info-vax Sent: September-04-21 10:58 AM On 9/3/2021 4:05
>> PM, kemain.nospam at gmail.com wrote:
>>> Not sure, but perhaps its possible (likely?) the article was
>>> modified by a non-technical editor?
>> 
>> That is certainly possible.
>> 
>> But then it may be more of "fiction based on true events" than 
>> "documentary".
> 
> You could say the same about any article if you analyzed every
> sentence that had technology in it.
> 
> My point is that while there may have been some editing by a 
> non-technical editor (when does that ever happen?), that does not 
> mean the parts of the article is "fiction".

There may be some basis in a real story.

But like 1/3 of the article is simply false.

That is over my threshold for being taken serious.

>>> Having stated this, the article drives home the point that many,
>>> many companies in the last number of years have been bamboozled
>>> into converting to the next big shiny technology only to find
>>> that the grass is not always greener on the other side. They
>>> often learn a very painful and very expensive lesson. Experienced
>>> programmers that understand the company culture and business
>>> logic used in these Apps are critical resources to a companies
>>> future success.
>>> 
>>> Its why many Med-Large Customers with battle proven applications
>>> that run the business now (albeit on older technologies) now
>>> typically choose a strategy of "upgrade and integrate" v.s. the
>>> strategy that vendors all to often push of "rip and replace".
>> 
>> It is a fact that many big IT projects fail. Going over time, over
>> budget and below expected functionality is common. Being cancelled
>> after spending lots of money is not unheard of.
>> 
>> Add unrealistic expectations, poor project management and
>> inexperienced developers and failure changes from potential risk to
>> almost certainty.
>> 
>> Having developers with domain/company experience is critical for 
>> maintenance, enhancements and small system migrations. But for
>> large system migrations then I would prioritize experience with
>> large system migrations over domain/company experience.
> 
> While good SW/HW architecture planning is certainly important, one of
> the toughest parts of large system migrations is not so much the 
> technical bits and bytes, but rather understanding and unravelling
> the unique business, legal, culture and regulatory requirements that
> went into all the highly custom application code that supports and/or
> runs the company critical applications.
>
> In many large migrations, these are often not fully understood
> because the original programmers are either not there anymore, or
> perhaps the Apps do not have good documentation (bad docs is also not
> all on the programmers as they sometimes are way overworked and
> forced to make trade-offs to meet deadlines).
>
> When large migrations fail, it is usually not for technical reasons
> only, but rather a failure to integrate the technology with the
> business requirements.

This is exactly why I think it is more important with people that
know big projects and know how to ensure that everything get
covered than people who knows the existing code base.

> Hence, why many Customers today prefer "upgrade and integrate" and
> not "rip and replace".
The cost and risk of such migrations rightfully scare many
higher management.

But I think the most important reason for not migrating is
the opportunity cost - the business benefits that could have
been gained if everybody had not been tied up in a migration.

But at some point it may be forced on them:
- something critical goes EOL
- the integration cost with other systems becomes too
   high

Arne