Thursday, August 24, 2023

2023-08-24 Thursday - Researching Alternatives to Flexera Technopedia

Flexera Technopedia References

This blog post is a placeholder to organize some of my research on possible alternatives to Flexera's Technopedia.

      1. [source:, screenshot of post, 2023-09-01]


Flexera YouTube Channel:

  2. IT Visibility – Technopedia Catalog and Identification

Glossary of Terms:

  • End-of-Life (EOL)
  • Product Lifecycle Management (PLM) 


Possible Sourcing Alternatives:

  1. (vendor's own product support web site)
    1. NOTE: There are quite a few software/technology product pages that provide some good EOL and Lifecycle information, or links to the vendor site.
    2. For example, Java Development Kit (JDK)
    1. NOTE: As of 2023-09-01, there are only 253 products listed

Backlog to research

  1. Zluri
  2. Augmentt 
  3. Zylo
  4. BetterCloud
  5. Binadox
  6. ManageEngine
  7. AssetSonar
  8. Ampliphae
  9. Cledara



Background Notes:  

Technopedia used to offer an URL where you could lookup information on a given technology. However, sometime prior to 2021 - that URL was deprecated:


[image credit:]


Tuesday, August 22, 2023

2023-08-22 Tuesday - Argue for your limitations and, sure enough, they're yours

[Kanji: "Shuhari", image source:]

Today's meditation:

Argue for your limitations and, sure enough, they're yours.”
~ Richard Bach, Illusions: The Adventures of a Reluctant Messiah

A favorite book, from my youth.

This quote came to mind today, after I had a chance to reflect on a series of *vigorous* idea exchanges with someone - regarding our *very* different views on the foundational definitions of what is architecture.

In Japanese martial arts, there is a concept known as "Shu-ha-ri" (Kanji: 守破離 Hiragana: しゅはり)

"shu (守) "protect", "obey"—traditional wisdom—learning fundamentals, techniques, heuristics, proverbs."

"ha (破) 'detach', 'digress'—breaking with tradition—detachment from the illusions of self, to break with tradition - to find exceptions to traditional wisdom, to find new approaches. In some styles of Japanese music (gagaku and noh), it is also the middle of the song."

"ri (離) 'leave', 'separate'—transcendence—there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms; transcending the physical - there is no traditional technique or wisdom, all movements are allowed."

Which roughly translates as "to keep, to fall, to break away" or "follow the rules, break the rules, transcend the rules".

Some architects insist on rigid adherence to certain ideas, definitions, frameworks, standards - that have their roots in thinking that is 30+ years old. When confronted with evolving interpretations of ideas - they react - instead of responding.

It is difficult to let go of what is old, worn, and comfortable - but that is where the "Ha" comes in - to break out of the cycle - and "Ri", to experience new growth.

New interpretations - that challenge existing preconceptions - for what architecture encompasses - is healthy, and necessary.

Clinging to the "Shu" - is to become brittle, and break. For the vitality of the roots to wither and die.

There are thousands of different types of martial arts - many of them share the same principles, concepts, and patterns - but they find different ways to express their essential differences.

Those variations do not make those martial arts less - they enrich the ecosystem.

Variation of interpretation isn't wrong, and it doesn't make one style's interpretation of the martial arts better - or worse - than another.

The same should be the mindset of IT practitioners of the different schools of thought in Enterprise Architecture, Business Architecture, agile practices, etc.

The measure of anything - is whether it is effective.

Will your block stop a kick, or a punch?

Will your approach to architecture deliver results?

We shouldn't be so attached to frameworks like SAFe, TOGAF, or notations, or anything that makes our thinking rigid - and prevents us from moving naturally - and responding to change.

There is a Zen teaching: “The Finger Points at the Moon".

The finger is the spiritual teaching, and the moon is the truth.

This is a reminder not to be too attached to words and/or teachings and not to confuse either with what they are pointing to.

If ISO definitions work for you - and you can deliver results - then use them.

But do not allow your attachments to blind you to growth - and learning new ways.

If another has discarded attachments to strict adherence to some made-up things - be cautious concluding that they must not know what they are doing. Keep what works - Discard what doesn't.

Allow for the possibility that they they have embraced "Ri".

"Ri" is where real progress begins.

Friday, August 18, 2023

2023-08-18 Friday - Today's Meditation - Reference Architecture as Abstraction

[image credit: 422737 on]

 Today's meditation:

I think many IT teams have "lost the thread" on the value of abstractions in design.

A pattern is not a detail design specification, nor is it an implementation specification, nor is it a solution architecture.

Likewise, a Reference Architecture *SHOULD* be kept at an abstract level - and not be misconstrued as a Solution Architecture (which is almost always implementation specific).

However, the major cloud vendors - to include Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) - have decided to classify implementation-specific architecture guidance as "Reference Architecture".

Within their respective *WALLED GARDEN* - it is plausibly reasonable - ONLY within the contexts of their specific cloud services environment - as an acceptable exception to classify that type of an artifact as a Reference Architecture.

However, it is not appropriate to let that smudging of the line of Architecture View taxonomy, definition, and distinction - to expand beyond those narrowly defined contexts.

A Reference Architecture SHOULD be something that can be reused, as a macro-level pattern - regardless of the specific technology in any environment.

To put this another way - your Reference Architecture - SHOULD be at the technical capabilities / standards level - not the technology-specific implementation / solution architecture level.

This allows us to define views, the context, use cases, scenarios under which it is fit-for-purpose - and not fit-for-purpose, as well as its limitations, forces & constraints, NFRs, etc. - that are appropriate for a given Reference Architecture - without worrying about the target platform upon which it may be implemented.

The literature within the field of Information Technology - lacks consistency and clarity on this basic definition - and the lack of such clarity - introduces significant issues with getting alignment and agreement - when introducing the concept of Reference Architectures and Patterns into an organization. And thus, more's the pity.

As I mentioned in the 2nd paragraph of this posting - with intention - I have stipulated my view & definition of Reference Architecture with the proviso of "SHOULD" - I allow that there are edge cases (e.g., Walled Garden) .

The benefits of adopting such discipline in how we define and use Reference Architectures:

  • Reuse
  • Clarity
  • Conciseness 
  • Consistency

And designs that consistently address:

  • Availability
  • Scalability
  • Reliability
  • Performance
  • Security

#patterns, #ReferenceArchitecture, #EnterpriseArchitecture, #SolutionArchitecture, #DetailDesign, #SAD, #Specification, #Abstraction, #Reuse  


Finally, none other than Gregor Hohpe (Sr. Principal Evangelist, AWS - and author of the books The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise; and Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions) weighed in with this comment on my original LinkedIn post:


Saturday, August 12, 2023

2023-08-12 Saturday - I am a writer - and so I write

[image credit: JillWellington on]

I am a writer, and so I write.

Sometimes I write to explore, sometimes to express, sometimes to memorialize.

I write for myself, not for an audience.

I write, as a I would to share a thought with a friend.

I write because it brings me joy.

Perhaps a piece will resonate with you today. Or maybe tomorrow. Or maybe in a year. Or perhaps ten.

Some writing is like that. You must be in the right frame-of-mind to receive some messages. Therefore, I leave these words upon these digital crossroads. Perhaps you will come back to them again some day.

Some bits will be OK, some will be rough. Some will be shite. I accept that.

I see the patterns that elicit the most responses, but I do not write for clicks, views, or likes.
I write from what moves me. From my passion. I seek to find my authentic voice.

I write, because I am a writer.

I write to explore my own thoughts.

I write to hold up a lamp in the darkness. Perhaps the light will resonate with others. If so, perhaps we are of the same tribe...and through our writing, we may find each other.

2023-08-12 Saturday - On The Value of Patterns

[image credit: ValdasMiskinis on]

A recent conversation with a colleague has given me pause to think about one of the more severe stumbling blocks - that I now believe - Enterprise Architects are perhaps far too...

unaware of (to be generous), 

or have made a conscious choice of perceptual blindness (possibly), 

or are simply operating with an unconscious inattentional blindness (likely). 

My university education was in the field of classic computer science - so I have an inherent bias towards thinking in terms of data structures, algorithms, and patterns.

Patterns are such a foundational cornerstone of how I think, and how I approach problems & solutions - it is just a part of my professional DNA.

I cannot comprehend working on any endeavor of software engineering, or at any of the various levels of architecture (enterprise, security, infrastructure, information/data, system, software, solution, ...) without leveraging patterns (either intentionally, or unconsciously). 

To be sure, there are numerous real-world solutions, and mountains of bad code - that were created with no conscious and intentional use of patterns, although unconscious choices of patterns did occur (e.g., Spaghetti is a pattern - it's just, more precisely, an example of an anti-pattern).

Patterns are building blocks.

They can be defined from the micro to macro scale.

They are the basis for any ability to achieve reuse.

They (generally) should not be implementation specific.

They are not implementation specifications.

They are not solution (detail) designs.

Nor are they solution architectures (which by definition, must be implementation specific).

Patterns exist (and suffer) with many different taxonomies - but they do exist.

By studying patterns, you reduce the cognitive load to understand, or design, anything - and it can be very helpful in bringing clarity and precision to any communication.

Patterns support consistency, repeatability, reliability - in the design of any solution.

Most patterns require stipulation of the types of problems (or conditions) under which a given pattern is appropriate - and those for which it would be inappropriate. 

About that stumbling block I mentioned earlier. Sadly, the utility and value of patterns are not universally understood by everyone that works in Information Technology (IT). It is quite often dismissed as too theoretical. Nothing could be further from the truth. Patterns are the bedrock upon which reliable systems are built.

To explore the depth of someone's understanding of patterns, I use a simple discussion exercise, that goes something like this:

Imagine that your company [A] has a new business requirement to send Customer Information updates to partner [B].


  • There is no current integration between [A] and [B], for this data.

From just that baseline description - the relative degree of experience and expertise of an individual can be quickly assessed - based on the questions they ask, before they begin proposing a solution.

Walking someone through this exercise, can also be very useful, to help explore their understanding of patterns. 

To help with this discovery effort, I use three different sets of requirements, that I assign to three different project phases

What is interesting to me, in observing how someone responds to just the limited integration requirements of Phase-1, is which patterns do they turn to first? What questions do they ask? Do they discuss any trade-offs in their consideration of possible choices? Or, do they leap to a solution, before asking any questions? To what degree do they understand/explore the possible Non-Functional Requirements (NFRs)?


  • Partners: 1
  • NFR: Data Latency MUST BE Less than 24 hours.

Phase-2 requirements, forces someone, who may be just on the edge of making a different integration solution decision - usually to reveal much about their experience, their preferences, their depth of understanding for long-term change management, solution maintainability, operational impact, and potential trade-offs. Observing the questions that someone asks at this point in the discussion...where their thinking goes, how they weigh the different potential often very is any dearth for just such considerations.


Phase-3 requirements are where someone's depth and breadth of experience and expertise are really discovered. No one can hide from this revealing change in requirements. All is laid bare.


  • Partners: 1,000
  • NFR: Data Latency MUST BE less than 60  seconds (which, although not explicitly stated, implies an NFR for Scalability)

The long-term implications of any patterns proposed/chosen, across these three sets of fairly simple requirements - can be a great teaching tool, for those that are willing to listen - and engage in an open and honest dialogue.

Hopefully, participants in such discovery discussions, may deepen their appreciation of the nuances of various concerns that a pattern-based approach can help encapsulate and encompass, in a repeatable, and reusable, manner.

Without understanding the implications of pattern choices - some folks may continue to just use techniques that they have grown comfortable with - but which can be woefully inadequate for the requirements stipulated. This has implications for many Non-Functional Requirements (NFRs):

  • Accuracy
  • Adaptability 
  • Availability
  • Change Management
  • Compliance 
  • Configuration Management
  • Cost, initial and Life-cycle cost 
  • Data Integrity
  • Data Latency
  • Data Quality
  • Disaster Recovery 
  • Efficiency
  • Extensibility
  • Failure Management
  • Fault Tolerance 
  • Interoperability
  • Maintainability
  • Network Latency
  • Observability
  • Operability
  • Performance
    • Response Time
    • Memory Utilization
    • CPU Utilization
  • Reliability 
  • Repeatability
  • Resilience 
  • Re-usability
  • Scalability
    • Capacity
    • Elasticity 
    • Throughput
  • Security
    • Authentication
    • Authorization
    • Encryption
    • Exploitability
    • Attack Surface Area
  • Stability
  • Support-ability

A good pattern should address a relevant set of NFRs for a particular problem/solution context. This helps teams be holistic in how they approach solution design - and it can help them avoid missing key/critical concerns.




Suggested Books
(still working on this list, will add [n] numbering later...)

[-] Christopher, Alexander, et al (1977).  A Pattern Language: Towns, Buildings, Construction (Center for Environmental Structure Series)

[-] Davis, Cornelia (2019).  Cloud Native Patterns: Designing change-tolerant software,  First Edition

[-] DiBernardo, Michael, et al, (link retrieved: 2023-08-12). The Architecture of Open Source Applications

[-] Fowler, Martin, et al (2002). Patterns of Enterprise Application Architecture. Addison-Wesley. ISBN 978-0-321-12742-6

[-] Freeman, Eric T.; Robson, Elisabeth (2021). Head First Design Patterns, 2nd Edition

[-] Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 978-0-201-63361-0

[-] Hohpe, Gregor; Woolf, Bobby (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. ISBN 978-0-321-20068-6, [companion web site]

[-] Indrasiri, Kasun, et al (2021). Design Patterns for Cloud Native Applications: Patterns in Practice Using APIs, Data, Events, and Streams, 1st Edition

[-] Resnick, Pini, et al (2020). Cloud Native Transformation: Practical Patterns for Innovation, 1st Edition

[-] Richardson, Chris (2018). Microservices Patterns: With examples in Java, First Edition, [companion web site]   


YouTube Videos

  1. Christopher Alexander - Patterns in Architecture
    1. The 1996 ACM Conference on Object-Oriented Programs, Systems, Languages and Applications (OOPSLA). San Jose, California, October of 1996
  2. ...

Monday, August 07, 2023

2023-08-07 Monday - The Tao of Corporate Stewardship...


[image credit: jplenio on]

The Tao of Corporate Stewardship...
(or, the mystical ideal client organization)

0. You value: Superior Customer Service, Flawless Execution, Exceptional Products/Services.
1. You value your people.
2. You invest in the development of your people.
3. You plan, for both the tactical - and the longer-term strategic goals/vision.
4. You are deliberate - and follow-through.
5. Your culture isn't just aspirational words - it is a reflection of your reality.
6. You value the contribution of all team members (employees, vendors, consultants).
7. Your cadences are sustainable - and you recognize the folly of burning people out.
8. You value creativity - and innovation.
9. Risk-taking is encouraged - in a measured and carefully planned way.
10. Data drives decisions - but in the absence of data - intuition is accorded its due respect, and is valued. Approximations are valued over paralysis.
11. Initiatives are planned - with sustainable efforts, and funding.
12. You value the ability to execute - and reward your employees who deliver exceptional performance.
13. You regularly trim the deadwood - and won't hesitate to whip out your high-powered McCulloch Chainsaw.
14. You demand integrity in everything, from everyone.
15. Your divisions, departments, and teams are focused - this isn't a social club.
16. Your entire business is focused - the attention of the organization is not scattered.
17. You do what you say you will do, when you say you will do it.
18. Your employees frequently use words like "love", "best", "excellent" to describe their work experiences - and your products/services.
19. Customers are eager to recommend your products/services.
20. Your leaders are the recognized go-to thought leaders in your industry.
21. You value leaders who lead - and shun abdication of responsibility through leadership/management by committee.
22. "Get Shit Done" is valued over "let's have another meeting."
23. You abhor waste, and useless make-work activities, for appearances sake.
24. Your justice is swift for unethical behavior: Immediate termination, with extreme prejudice.
25. Your guidance to employees during their Day-1 orientation: "Lead, follow, or get the hell out of the way"



Sunday, August 06, 2023

2023-08-06 Sunday - My criticisms of Yann LeCun's recent MIT presentation

Today, Dr. Yann LeCun posted on LinkedIn, about his recent talk at MIT ("Objective-Driven AI: towards AI systems that can learn, remember, plan, reason, have common sense, yet are steerable and safe", link to his slides)

My 1st comment:

"The configurator configures the agent for a deliberate ('conscious') tasks."

My suggestion:
A governance function (named in his honor, "The LeCun Inhibitor Function"?) that will prevent any tasks performed by an AI, from causing harm, or by omission, allowing harm to occur.

"Objective-Driven AI systems will be made subservient to humans"

How, without a governance function?

"Disinformation, propaganda, hate, spam,...: AI is the solution!"

That will only work, if you have a governance function.

"What if bad people get their [hands on] powerful AI? Their evil AI will be inferior to the Good Guys’ AI police."

That right there illuminates the problem that I (and, I suspect, many of your critics) have with your position on the very real potential risks of AI causing harm. You, sir, are in denial.

Your view is grounded in some idealistic and ***very*** Pollyanna-type assumptions.

Police, in the real world, are not a preventative prophylactic - they are an after-the-fact attempt at error correction (and almost always insufficient to undo the harm committed), in almost all cases.

The implication of your statement is ALSO a totalitarian control of all AI activity.
Who will perform and regulate that function, for the entire world? Meta? To believe that, would be delusional.

My 2nd comment:
Based on LeCun's statements that I have cited from his presentation, my analogy:

He is driving a massively powerful (and very dangerous) race car - but he is ignoring the posted speed limits, caution signs, and driving very aggressively to reach his destination - no matter the risks. When told that he needs to slow down in the curves, he wants to accelerate. When told he needs better brakes, before increasing the horsepower, he effectively says, "we'll add them later".

The keys should be taken away from him, and his license to drive revoked. 🤣


© 2001-2021 International Technology Ventures, Inc., All Rights Reserved.