intltechventures.blogspot.com: April 2020

2020-04-29

2020-04-29 Wednesday - What Are Your Training Topic Priorities?

Create your own user feedback survey

I'm brainstorming some additional ideas for a weekly survey that might be fun and informative - here's my current draft of a weekly schedule - publishing one every Wednesday.

Additional suggestions welcomed.

2020-04-23

2020-04-23 Thursday - Today's Meditation - Where & How Do I Add Value

[This is also my posting to answer the question: "What do you do?"]

My original LinkedIn post on this topic.

As a consultant - that focuses specifically on providing services in the areas of Architecture and Software Engineering Consulting & Leadership - I recently spent some time distilling my thoughts on where & how I add value. It was a clarifying exercise, and a worthwhile meditation for this day.

A bit of elaboration on those areas:

IT Strategy & Roadmaps

This can involve both long-term strategic planning - as well as interim tactical planning.
Ideation of transition plans for moving from the AS-IS, to the TO-BE - and any interim staging / transition plateaus / scaffolding that may need to be introduced.
This is not just about the technology aspects of strategy and roadmaps - but is closely integrated with the business plan - to include competitor analysis, alliances, partnerships, merger/acquisition opportunities, as well as creating competitive advantage.
Another vital component of this type of work is understanding the Change Management dynamics - and planning the collaboration and coordination appropriately.

IT Governance

Governance, regardless of the size of the organization, is essential to avoid chaos, waste, and inefficiencies. The amount of ceremony and formalism are the only real essential differences.
Do you know what IT assets you have - and what it costs to maintain/keep them (hardware, software, licenses, etc.)?
Are you legally compliant with respect to the software licenses that you are using?
Do you have a documented understanding of what your Business Capabilities and Business Functions are?
What are your Technical Capabilities - and how do those capabilities map to your current | planned technology stack - and your enterprise roadmap?
How are those capabilities and functions delivered?
Are there any gaps or inefficiencies - or duplication - in how those capabilities and functions are delivered?
Are there any material risks/concerns with respect to the way that those capabilities and functions are delivered (security, performance, reliability, scalability - to name just a few aspects that fall under the purview of IT Governance)?
What is the projected end-of-life of a given application (or technology) - and how will you plan for the transition?
What are the vulnerabilities that may exist for a given application, or technology?

Technology Thought Leadership

A famous quote often attributed to hockey legend Wayne Gretzky: "Skate to where the puck is going to be, not where it has been". There is a useful corollary in that phrase - for IT leadership.
While you may have your IT Strategy and Roadmap well established - and you may have your IT Governance processes fully implemented - the landscape of technology is constantly changing underneath your best intentions.
Technology Thought Leadership is more art than science. It requires experience - but it also requires good instincts - and an intuitive level of being able to discern what is a technology fad - from what will be a truly sustainable technology trend. What is a differentiator vs. what may merely be fancier drapes.
To be able to provide this kind of thought leadership requires "Think Time" - and the ability to leverage a global network of professional connections (today, my carefully curated network includes over 5,400+ [as of 2023] world-class executives, leaders, managers, engineers, inventors, creators, thinkers) to help me monitor the pulse and the heartbeat of what trends may be emerging, which are thriving - and which may be beginning their decline.
Sustaining this kind of thought leadership requires a substantial investment of time in reading, exploring, experimenting - and conversations with other thought leaders across multiple business sectors - and fields of expertise.

Architecture Design

An essential component of holding any position of Architecture and Engineering Leadership - is the ability to roll-up your sleeves and craft a world-class architecture design - leveraging current/emerging patterns, and identifying the best-in-class technology platforms, services, libraries, tools, etc.
The key difference between the level for a practitioner of any craft (novice, advanced beginner, competent, proficient, and expert) - is in their ability to properly consider the scope & scale of trade-offs and balance-of-forces - and being able to integrate those concerns within a conceptual weaving that approaches the level of a maestro composer writing a symphony.

Design Reviews

Equally important to the ability to craft an architecture design - is the ability to guide others (Enterprise Architects, Business Architects, Security Architects, Infrastructure Architects, Integration Architects, Solution Architects, DevOps, Tech Leads, Principal Engineers, etc.) in the design review process.
This may involve reviewing Enterprise Architecture Roadmaps, Solution Architecture Designs, Transition Plans, Data Architecture - or Data Models, or diving into the API or algorithm-level Detail Design Documents.
Sometimes, it requires doing deep dives in Code Analysis & Code Reviews.

Teaching, Coaching & Mentoring

Another essential aspect of any position of Architecture and Engineering Leadership - is the ability to teach, coach, develop, and mentor others.
People are the most important component of any business.
This is where the true value of leadership emerges - for it is in acting as a "force-multiplier" - assisting other members of the organization to experience personal and professional growth in their career development - that you truly create lasting and sustainable value.
Ignoring the need to continually invest in the development of personnel - is the surest way to cripple the effectiveness of any organization.

Proof-of-Concepts

You can read all of the Gartner and Forrester Reports; you can read articles in CIO magazine, the Wall Street Journal, InfoQ, and the unending cornucopia of opinions that are published in blogs and on various platforms like Medium.com, or LinkedIn.com, etc.
But, there are often cases - that unless you have personally kicked-the-tires and taken it for a test drive - you can put at risk the very survival of a business - if you haven't invested the effort to personally perform some level of proof-of-concept examination of a potential solution, or new technology.

Research & Evaluations

Beyond the periodic need to perform Proof-of-Concepts for evaluation of potential solution candidates - it is important to also maintain awareness of new and interesting developments in various areas of technology. What is on the horizon? What is just beyond the horizon?
Additionally, when the business wishes to contractually engage third-party service providers - an essential aspect of risk mitigation is the Architecture & Engineering research and evaluation of those potential vendors - which may include collaboration during the prelude to a Request for Information (RFI), Request for Quote (RFQ), or a comprehensive Request for Proposal (RFP) process.
Research & Evaluations also serve several other purposes:

Researching and evaluating new emerging technology (in particular, many Open Source solutions) - provides you with context and a frame of reference - when/if you need to evaluate commercially available solutions.
Tremendous breakthroughs occur frequently - in terms of techniques, efficiency, performance, capabilities, features, etc. - and only by seeking out the emerging edge of those technology breakthroughs - can you be well-enough informed to provide input for the Technology Thought Leadership, Strategy, and Roadmap discussions. This requires spending some time allocated to reading recently published research papers, and PhD thesis papers.
When technology breakthroughs can simplify process flows, reduce (or eliminate) manual procedures, reduce cycle times, improve response times, enable the development/delivery of new services and business capabilities, etc. - those all contribute to creating competitive advantage for the business. That's why Research & Evaluations are a vital part of any Architecture & Engineering Leadership role.

The 70+ recommendations on my LinkedIn profile may also provide insights into additional dimensions of value that others have perceived when my services were engaged...

This blog post touches on my approach to continuous learning.

2020-04-22

2020-04-22 Wednesday - JDK 15 - Remove the Nashorn JavaScript Engine (JEP 372)

I noted the following in a recent JDK 15 InfoQ article:

Remove the Nashorn JavaScript Engine (JEP 372)
https://openjdk.java.net/jeps/372

"Remove the Nashorn JavaScript script engine and APIs, and the jjs tool. The engine, the APIs, and the tool were deprecated for removal in Java 11 with the express intent to remove them in a future release."

"The Nashorn JavaScript engine was first incorporated into JDK 8 via JEP 174 as a replacement for the Rhino scripting engine. When it was released, it was a complete implementation of the ECMAScript-262 5.1 standard."

"With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and modified, we have found Nashorn challenging to maintain."

2020-04-20

2020-04-20 Monday - Eclipose 2020-03 and StatET 4.1 with R 3.6.3

I'm currently working with Eclipse 2020-03 - but the latest release of StatET (4.1) - appears to be compatible with Eclipse 2019-12. So, I'm installing it on 2020-03 - and will do some testing this week to assess whether it is compatible.

Eclipse StatET Plugin (Tooling for the R language)

https://marketplace.eclipse.org/content/statet-r

https://projects.eclipse.org/projects/science.statet

https://download.eclipse.org/statet/releases/4.1/E201912

After installing the plugin - I noted that there were no StatET plugin related errors in the log - a promising (initial) indicator.

I also took the opportunity today to update my R installation to 3.6.3 (for Windows)
Note: Changes in R 3.6.3

Don't forget to configure StatET to point to your R Environment location:

2020-04-20 Monday - Stephen Wolfram: Cellular Automata, Computation, and Physics | AI Podcast #89 with Lex Fridman

2020-04-16

2020-04-16 Thursday - Microsoft AI Spots Critical Bugs 97% of the time

AI spots critical Microsoft security bugs 97% of the time
https://venturebeat.com/2020/04/16/ai-spots-critical-microsoft-security-bugs-97-of-the-time/

"The work suggests that such a system, which was trained on a data set of 13 million work items and bugs from 47,000 developers at Microsoft stored across Azure DevOps and GitHub repositories, could be used to support human experts."

"Coralogix estimates that developers create 70 bugs per 1,000 lines of code and that fixing a bug takes 30 times longer than writing a line of code; in the U.S., $113 billion is spent annually on identifying and fixing product defects."

2020-04-16 Thursday - $10B DoD JEDI Contract Update

https://www.bloomberg.com/news/articles/2020-04-15/pentagon-watchdog-clears-microsoft-s-10-billion-cloud-contract

"The Defense Department's watchdog found no evidence that the Pentagon's controversial decision to award a $10 billion cloud-computing contract to Microsoft was the result of interference from President Donald Trump, though it said its probe was limited by the White House."

2021-05-10 Update:

Report: Pentagon may cancel JEDI cloud computing contract amid legal battle and political criticism

https://www.geekwire.com/2021/report-pentagon-may-cancel-jedi-cloud-computing-contract-amid-legal-battle-political-criticism/

"The Pentagon is reportedly considering ditching the $10 billion cloud computing contract awarded to Microsoft amid recent complaints from lawmakers and Amazon’s ongoing legal challenge"

2020-04-15

2020-04-15 Wednesday - Center on Rural Innovation (CORI) - launching an Innovation Fund

Center on Rural Innovation (CORI) - Innovation Fund

https://www.corifund.com/

"The Center on Rural Innovation (CORI) is launching the CORI Innovation Fund to invest in growth businesses located in qualified Opportunity Zones in the United States to enhance economic growth and job creation in small communities. The Fund will seek to find attractive technology-enabled operating businesses in rural geographies, which are under-served by traditional venture capital institutions. We will identify, fund, and support the best tech entrepreneurs American small towns have to offer."

Also see:

The Rural Opportunity Map

Relevant News Items

2020

https://www.nytimes.com/2020/04/14/opinion/stimulus-infrastructure-covid.html

2020-04-09

2020-04-09 Thursday - Failure To Perform Root Cause Analysis

Photo by Uljana Maljutina on Unsplash

source: https://unsplash.com/photos/rL7-pSUEj18

There is so much that is factually wrong in these two articles - due to a material lack of understanding of the root-cause of the problem:

"Obsolete 1950s computer code is causing unemployment chaos amid huge lines: Appeal for retired programmers who know obscure COBOL language to fix outdated computer system in states across US"

https://www.dailymail.co.uk/news/article-8203927/Appeal-retired-programmers-fix-outdated-computer-amid-unemployment-chaos.html

"...struggling to process the large volume of unemployment claims "

"COVID-19 Response: New Jersey Urgently Needs COBOL Programmers (Yes, You Read That Correctly)"

https://josephsteinberg.com/covid-19-response-new-jersey-urgently-needs-cobol-programmers-yes-you-read-that-correctly/

This article provides a deeper examination of the root-causes:

"Why New Jersey’s Unemployment Insurance System Uses a 60-Year-Old Programming Language"

https://slate.com/technology/2020/04/new-jersey-unemployment-cobol-coronavirus.html
" The state’s unemployment insurance application website had broken under the weight of the more than 200,000 applications it received in a single week,"
"New Jersey is hardly the only state stuck with technology from the last millennium. The New York Times reported that New York’s and Connecticut’s unemployment systems are also both more than 40 years old and haven’t been able to keep up with the flood of new applications."
"Washington, D.C., asks unemployed workers to file their applications using Internet Explorer, a browser that Microsoft officially retired five years ago"
"States have been starved of funding they need for running their unemployment insurance systems, money that under the 1935 Social Security Act is supposed to come from the federal government"
"But while New Jersey’s unemployment system is undoubtedly buckling under the weight of the COVID-19 jobs crisis, the COBOL programming language, or the mainframes it runs on, are probably not to blame. After all, COBOL systems process trillions of dollars of transactions daily for the world’s largest banks, which are clearly not strapped for the cash they’d need to make upgrades. COBOL might be deeply uncool, but it’s hardly a dead language."

A few points/conjectures I would like to share - from my perspective:

1) COBOL is not necessarily obsolete - the vendors that offer this language continue to make improvements and enhancements - and new versions are still being released - with new features and capabilities (1, 2, 3, 4, 5, 6).

2) A given company's installation may be of an obsolete version of COBOL - but to classify the language itself as obsolete - is a gross mischaracterization.

3) If the problem, as alluded to in the article, is one of scalability - the code itself may not be the root-cause problem - it may be the lack of scalability in the underlying infrastructure.

4) If the root-cause problem is a lack of flexibility/configurability in the design of the application code - then it is much more than just an issue of obsolete COBOL code - it speaks to a larger problem of an obsolete underlying data architecture.

5) COBOL is hardly an obscure programming language. Archaic, undoubtedly. Verbose, certainly. Unfashionable, absolutely. But, in almost any large company that has been in business for more than 30-40 years - and certainly in most government agencies - it is more correct to say it is endemic across IT organizations.

6) Unless a programmer was previously working on a specific application's code base - any system's code is going to be initially OBSCURE to them - regardless of the age of the programming language (and, it is highly likely that it will be MORE obscure - the newer the language - and certainly EVEN MORE obscure if the business domain is new/foreign to the retired programmer).

7) Ipso facto: Relative complexity of legacy monolithic architectures vs modern distributed architectures. I know this will be a controversial statement - and it may seem counter-intuitive - but, obscurity is a word perhaps best reserved for applications built on modern highly distributed architecture patterns - with thousands of microservices.

8) It is highly unlikely that the code itself is the root cause of the issue. Typically, applications written in COBOL, for such large-scale problems (i.e. unemployment claims) are designed as back-end, nightly batch processing jobs - and an ancient/legacy COBOL program would typically be written to process one record at a time. The greater likelihood of the root cause is in the ARCHITECTURE of the application written in COBOL - and would have nothing to do with the programming language capabilities/limitations itself. Greater still, is the likelihood of limitations of the underlying computing hardware and data storage/access mechanisms - which again - have little to do with the choice of programming language itself.

9) With the exception of modern cloud-native application architectures - very, very few legacy systems (regardless of programming language) - would have had a justifiable reason for designing/adopting an application architecture (AND the attendant investment in the necessary underlying infrastructure) that would accommodate obscene/extreme highly elastic scalability requirements of 3x, 4x, 5x, ..., 20x, ... volume during their nightly batch processing windows - it would be inconceivable that business stakeholders would have justified such additional architecture complexity, cost, and effort - when these legacy systems were originally proposed/funded/constructed.

10) Many legacy/older batch-based processing systems (regardless of their programming language) have trouble meeting their NORMAL batch processing windows (SLAs) - based on existing application architecture and underlying hardware infrastructure limitations/constraints - which are usually NOT germane to their particular choice of programming language.

11) You can't QUICKLY fix those outdated systems by just throwing retired COBOL programmers at the problem. Just as you can't make a baby in one month with 9 mothers and 9 fathers.

12) It is highly likely that MANY of those in the potential pool of aging (or, retired) COBOL programmers never evolved beyond the ideas of how they designed similar original systems - and so, many of them will lack {awareness of | experience with} the significant advances that have been made in technologies and architecture patterns for high performance distributed computing - the fundamental technical and conceptual tools and ideas necessary to fix the underlying performance/scalability design issues of those legacy COBOL systems.

Architecture decisions are a complex calculus of constraints - however, little luxury is afforded by business constraints/priorities - to allow their continual re-assessment (or, alteration) on an ongoing basis - or, in any form approaching near real-time. UNLESS, you have already performed the refactoring and migration work to a Cloud Native Architecture.

And thus, architecture decisions - made at fixed points (for the design of these problematic legacy systems) - are bounded by constraints of available time, budget, resources - against an ever-changing landscape of shifting business requirements (and priorities) - and ever-climbing mountains of technical debt - that frequently experience seismic upheavals due to regulatory or competitive market forces.

When a Black Swan event arrives - those who cry "You should have modernized!" - are ignoring the very real business constraints under which these systems have been maintained - often by long-suffering heroic actions of unsung COBOL programmers and IT Managers.

As NJ Governor Murphy's administration tackles this complex problem - it is important that the following concerns are considered:

Don't over-engineer the interim solution
Have experienced senior level architects review any proposed changes that impact stability, security, scalability, or performance.
Develop a long-term modernization plan - this doesn't (and shouldn't) necessarily mean a rip-and-replace. An incremental upgrade/update in-place is likely going to be the far more cost-efficient approach.
Beware of any consultants that are pushing (selling) any wholesale rewrite/replacement of the entire system/application.

Complete rewrites often fail - spectacularly.
Complete rewrites usually take much longer than estimated - and likewise for the estimated costs.
There is an estimated 200 billion lines of COBOL code - it is likely much of that code can be reused - and may only require some level of refactoring.

Additional articles that may be of interest:

What crashing COBOL systems reveal about applications maintenance

https://gcn.com/articles/2020/05/12/keeping-mainframes-up-to-date.aspx

Cobol Programmers Answer Call to Shore Up Unemployment Benefits Systems

IBM will offer free COBOL training to address overloaded unemployment systems

https://www.inputmag.com/tech/ibm-will-offer-free-cobol-training-to-address-overloaded-unemployment-systems

https://community.openmainframeproject.org/c/calling-all-cobol-programmers/15

2021-04-12 Update:

2021-04-12 Reflections on “Darth Misty the Mainframe Sith” by Misty Decker (Product Marketing Director at Micro Focus) - who also shared with me this recent news item:

2021-03-27 COVID unemployment hearing probes state computer system, claims process

"The state unemployment insurance system remains dysfunctional a full year after New Jersey shut down parts of the private sector due to the COVID-19 pandemic, according to testimony at a virtual hearing held by Republican lawmakers on Friday."
"Computer consultant Bill Hinshaw, founder and head of Cobol Cowboys, said a thorough modernization could be done in no more than several months and probably for no more than $25 million"

2020-04-04

2020-04-04 Saturday - AlphaGo - The Movie

AlphaGo - The Movie | Full Documentary

https://www.youtube.com/watch?v=WXuK6gekU1Y

With more board configurations than there are atoms in the universe, the ancient Chinese game of Go has long been considered a grand challenge for artificial intelligence. On March 9, 2016, the worlds of Go and artificial intelligence collided in South Korea for an extraordinary best-of-five-game competition, coined The DeepMind Challenge Match. Hundreds of millions of people around the world watched as a legendary Go master took on an unproven AI challenger for the first time in history.

Directed by Greg Kohs with an original score by Academy Award nominee, Hauschka, AlphaGo chronicles a journey from the halls of Oxford, through the backstreets of Bordeaux, past the coding terminals of DeepMind in London, and ultimately, to the seven-day tournament in Seoul. As the drama unfolds, more questions emerge: What can artificial intelligence reveal about a 3000-year-old game? What can it teach us about humanity?