2025-01-08

2025-01-08 Wed - Some Recent Aggregated Key Observations - Coaching and Mentoring

[image credit: Tama66 on pixabay.com]

 

 

Today's meditation:
Recently, I had an opportunity to offer several folks some much needed career coaching/mentoring.

Sometimes, those conversations require some pointed advice, and some harsh truths. Especially when the person is laboring under delusions that are actively harming their efforts.

As a generic summary of some aggregated key observations:

No, you are not being discriminated against.

Here's why companies and recruiters are not responding to your application submission:

Your resume is like a tragic construction project that was abandoned mid-build.

Your resume is a recitation of places you have worked - but doesn't reflect WHAT you CONTRIBUTED, the IMPACT you had, or the RESULTS you produced....and, more importantly, you have not QUANTIFIED those details.

As a metaphor, your competition (for any job in your field of specialization) have invested time & effort to build a career, experience, and credentials - that would best be characterized as "showing up in a Ferrari" - while you have been satisfied with building a career that might best be characterized as "showing up in a Yugo".

You have made ZERO effort to distinguish yourself.

You have made ZERO effort to demonstrate thought leadership.

You have demonstrated ZERO effort to show that you are curious - and have been continually learning.

You have made ZERO effort to build a professional network.

You have not even tried to leverage the very meager professional network you have haphazardly built by happenstance.

You have NOT done THE WORK - to prepare yourself to compete in this job market.

You are NOT owed a job.
You must EARN the right to a job.

You have simply SHOWED UP - and exigent supply-demand forces have allowed you to have a job, in the past.

You have apparently depended on LUCK and HOPE - and that is no longer a feasible job search strategy.

You have been COASTING.

You need to GET OUT OF NEUTRAL.

You need to LIGHT A FIRE in your belly.
 

2024-12-31

2024-12-31 Tuesday - 2024 Reflections

[image credit: Markéta Klimešová (MAKY_OREL) on Pixabay.com]

 

 
 Stats:
  • [2] client engagements completed 
    • Client #1: ~$260B+ annual revenue, automotive/manufacturing sector
      • Enterprise Architecture consulting services
    •  Client #2: ~$5B annual revenue, health & wellness sector
      •  Enterprise Architecture consulting services
  • [301] commits to my personal knowledge management GitHub repositories




 
 
 
  • [90] architects interviewed/assessed
  • [32] individual career coaching/mentoring sessions given
  • [9] resume reviews completed
  • [6,700+] miles traveled
    • [10] Cities visited 
  • [39,603] lines recorded in my 2024 Technology Reading List notes
  • [18] blog posts published
  • [5] books/manuscripts reviews completed - technical
  • [1] books/manuscripts reviews completed -science fiction
 
Noteworthy 2024 LinkedIn Engagement
 

 
 

 


2024-12-14

2024-12-14 Saturday - Today's Meditation: Analysis & Design

 

[image credit: MItodru Ghosh on unsplash.com]

Today's meditation:
Ready-Fire-Aim is a poor strategy in lieu of minimally adequate Analysis & Design.

Analysis & Design are intrinsic to creating long-term sustainable value.

However, Analysis & Design are approaching the point of being endangered skills:

Analysis helps us clarify and understand:

- What are the requirements?
- What is needed?
- Why?

- What do we have?
- What are the gaps?

- Who & What will be impacted, and how?

- What can be kept?
- What must be replaced?

- Is this the right thing to do?
- What are the *possible* consequences if we delay, or do nothing?

- What are other possible alternatives?

- How much *might* this cost (to create, to run, to maintain)?

- Do we have the right capabilities?
- Do we have the right people?
- Do we need to invest in training?

Today, there is rarely & barely sufficient attention given to Design - and Analysis is paper thin, at best.
 

2024-10-31

2024-10-31 Thursday - 20 Beneficial Architecture Team Member Practices & Habits

[image credit: Alexas_Fotos on pixabay.com]

 

  1. Understand the business side of the equation, deeply.
  2. Research the competition, thoroughly.
  3. Continuously experiment with new technologies.
  4. Hone your coding skills - and maintain a sufficient edge, such that you could step in to help a delivery team with a moment's notice.
  5. Invest in building depth in data modeling & data analytic skills.
  6. Develop expertise with different modeling tools.
  7. Invest in developing depth in designing & implementing AI/ML/DL solutions.
  8. Master the tools that you use daily.
  9. Teach and mentors others within (and outside of) your organization.
  10. Read voraciously within your area of specialization.
  11. Read outside your area of specialization.
  12. Your success depends on your ability to think deeply in terms of patterns and abstractions.
  13.  Develop a robust catalog of talks/presentations that you can give on short notice, on key topics, in your area of specialization.
  14. Invest time in reading the source code that runs your company's business.
  15. Relentlessly automate your professional workflows.
  16. Volunteer to tackle the hard problems that no one else wants.
  17. Write a daily journal.
  18. Share what you learn - by writing/publishing articles.
  19. Pause to look around - and see who you can help.
  20. Invest time in building relationships - and your professional network...by helping connect/create opportunities for others.


 

2024-08-04

2024-08-04 Sunday - Today's meditation: Strategic Initiaitve Planning

 

[image credit: pixabay.com]


Today's meditation: Strategic Initiative Planning

If you asked me to help your organization launch a strategic initiative, there are important steps that I would recommend - and the order is critical:

(ordered with intent...phased, incremental, and iterative are implicit - while Big Bang - or Big Design Up Front - is most certainly not)

 

1. WHY:

Our initial discussions are going to focus on getting crystal clear on why you think this strategic initiative is important, what problems do you think it will solve - or what opportunities do you think it will create.

What are the market forces driving this initiative idea?

What are the possible 2nd and 3rd order consequences of chosing this particular strategic initiative (versus other possible alternatives) to your organization?


2. WHAT:

Everyone involved in this strategic initiative must be crystal clear on your priorities, objectives, desired outcomes, and goals.

What are the geographic areas in which this initiatve will be implemented?

What are the business requirements, and non-technical requirements?

What are the key metrics that will be critial - when measuring the success of this initiaitve?

What is the initial expected budget for this initiative?


3. HOW:

A clear understanding of the WHAT is vital, before we try to solve for the HOW.

What are the organizational artifacts (e.g., vision, roadmaps, policies, standards, specifications, constraints, etc.) - that will shape (or limit) the choices in developing an implementation approach?

How will this initiative be achieved?

What are the current set of business and technical capabilities?

What are the current businesses procsses - and what gaps may exists there, as well?

What resources are available, and what gaps may exist in the organizations skillsets.


4. WHEN:

When must this initiative be delivered/achieved?

Once we understand the potential gap between the organization's existing (and required) skillsets, or if the delivery date is so urgent that it won't allow sufficient time to upskill the organizatoin's personnel - then the WHO can be determined.

 

5. WHO:

Based on an understanding of the preceding, THEN we can begin assessing WHO is appropriate, and whether the work can/must be performed by personnel within the organizaiton - or whether exigent forces require engagement with one or more third-parties (vendors, partners, SMEs, contigent staff, etc.)

 

Far too often, I have observed ogranizations skip (or ignore) one or more of these steps - or seek to reorder the approach (e.g., selecting WHEN, before any other consideration is sufficiently examined, defined, understood). The outcomes then - easily predictable...

 

2024-06-19

2024-06-19 Wednesday - Researching Approaches to Measuring EA Value

[image credit: aleksandra85foto on pixabay.com]

This post is a placeholder for a collection of selected articles, suggested as background reading...(discovery-in-progress...)

Research Papers

Enterprise architecture management value creation mechanisms (2024)

by  Sofia Tiitinen (Enterprise Architect, SOK)

https://jyx.jyu.fi/handle/123456789/93267

https://jyx.jyu.fi/bitstream/handle/123456789/93267/URN%253ANBN%253Afi%253Ajyu-202402061758.pdf

See: 4.1 Perceived EAM Value
"None of the respondents completely agree with being satisfied with their organization’s current EAM practices. About 70% disagree with the claim"

*** Pages 37-39
See: TABLE 8 Perceived EAM Value

Page-40:
"Overall, of the synthesized constructs of EA Product Quality, EA Service Quality, EA Culture/Attitude, EA Product Use, and EA Service Use, presented in chapter 2.4.4, all were present in EAM value creation."

*** Important, Page-46
5.3 Limitations
"The results do not come without limitations to validity. With 47 respondents, the sample size of the primary research was significantly limited. The total methodology of the study was novel, with certain exploratory features. Thus, the results are advised to be interpreted as preliminary. The great majority of respondents worked in large organizations with over a thousand employees, meaning this demographic is best suited when interpreting the results. It may be that EAM value is more likely to be achieved in the complex environment of a large corporation. Additionally, all but one respondent worked in organizations operating in Finland, meaning the results do not in their large part represent the experiences of professionals working in organizations not operating in Finland. Thus, it can be concluded the results may not represent the complete population of EAM stakeholders."

***
"Another notable limiting factor is difficulty in measuring EAM value due to its typically indirect and/or intangible nature (Kluge, Dietzsch and Rosemann, 2006; Tamm et al., 2011)." 


Towards the Definition of Enterprise Architecture Debts (2019)

By Simon Hacks, Hendrik Höfert, Johannes Salentin, Yoon Chow Yeong, Horst Lichter

"In the software development industry, technical debt is regarded as a critical issue in term of the negative consequences such as increased software development cost, low product quality, decreased maintainability, and slowed progress to the long-term success of developing software. However, despite the vast research contributions in technical debt management for software engineering, the idea of technical debt fails to provide a holistic consideration to include both IT and business aspects. Further, implementing an enterprise architecture (EA) project might not always be a success due to uncertainty and unavailability of resources. Therefore, we relate the consequences of EA implementation failure with a new metaphor --Enterprise Architecture Debt (EA Debt). We anticipate that the accumulation of EA Debt will negatively influence EA quality, also expose the business into risk."
 

Industry Analsyst Research & Advisory Publications

Gartner

 

EA Tool Vendors

LeanIX

  1. Value of Enterprise Architecture

 

Other Papers, Blog Posts, Articles

  1. Capturing Value from Enterprise Architecture: Understand your field of play, solve tough challenges and drive transformational change (2022), by Christian Schröder (Enterprise Technology and Financial Services, Bain & Company)
  2. Calculating the ROI of Your Enterprise Architecture Practice

 

Suggested Books

  1. The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment, 2nd Edition (2021), by Svyatoslav Kotusev
    • "Due to complex historical reasons, the notion of enterprise architecture was always surrounded by endless speculations, dangerous myths, non-existing best practices, unfulfilled promises, expensive failures and grave disappointments. Traditionally the entire discourse around enterprise architecture was dominated by shallow advice and faddish approaches (e.g. well-known EA frameworks) infinitely distant from the practical realities, but nonetheless aggressively promoted by commercially motivated consultancies and gurus." 

 

Addendums

2024 Addendums

2024-05-28

2024-05-28 Tuesday - Proposed Definition for Technical Debt

I posted this answer, in response to a question posed by  Sonya Natanzon, on LinkedIn 

Noteworthy: Sam Holiday, PhD, offered a definition which focuses on the strictly monetary/cost aspects

I've created a poll on LinkedIn that may be of interest.

[source: Kelvin Meeks, LinkedIn poll]

 

 

My proposed definition:


Technical Debt (noun):
1. A consequence of the accrual of one or more intentional trade-off decisions - or the unintentional absence/lapse of governance, oversight, and maintenance.

2. Technical Debt may arise from poor design choices, or exigent decisions, that were contrained by available time, skill, or budget.

3. Over time, Technical Debt may exhibit unexpected secondary aspects - such as brittleness, cascading system failures, security vulnerabilities, degraded performance, incompatibilities, failure to meet regulatory and compliance requirements, etc.

4. Technical Debt is usually a symptom of deeper underlying root causes. 

  • For example: 
    • Absence of governance; 
    • Insufficient budgets for long-term maintenance; 
    • Absence of a technology roadmap; 
    • Absence of necessary-and-sufficient Application Portfolio Management protocols; 
    • Absence of End-of-Life (EOL) management; 
    • Absence of Security protocols for technology management (static code analysis, vulnerability monitoring, vulnerability remediation, etc.); 
    • Absence of Principles, Policies, Standards, Specifications; 
    • Absence of appropriate Enteprise Governance mechanisms (e.g., Technology Governance Board, Technology Reference Model, ...);
    • etc.
  • Consider governance in the context of a forcing-function. In the absence of governance functions (at multiple levels, in multiple dimensions) - there's only the willingness and initiative of the individual. Judicious application of governance - can help ensure a minimal consistency in how some safeguards can be established (and enforced) - to minimize/avoid unconstrained levels of Technical Debt from accumulating.

5. Technical Debt may represent a type of decay that requires remediation.
  • When something is no longer supported, constitutes security vulnerabilities, or is no longer compliant - it becomes a type of technical debt. 

  • Consider if a company selected Java 8, or Windows Server 2008 (at some point in the past), but refused to ever upgrade. Over time, that decision - reflects a type of technical debt (e.g., in which there are consequences, such as: it has security vulnerabilities; it is no longer being actively maintained; security patches are no longer supported, etc.). It isn't a strictly monetary expenditure per month consideration. However, upgrading to a newer version (that is supported) is the technical debt remediation that is required. 
  • Not upgrading to the supported version of [x] - which may have negligable productivity impact - but may expose the company to an incalculable level of fines, penalties, monetary losses, and reputational damages - if there is a security breach tied to a known vulnerability that would have been remediated by upgrading. 

6. Technical Debt, by my definition - is not a purely monetary consideration of ongoing costs - but encompasses a more holistic viewpoint of the consequences of failing to remediate some deficiency with respect to the technical aspects of design or implementation - that is a consequence of actions taken, or actions avoided.


Suggestions, discussion contributions, and other perspectives:

I thank the folks that have participated in the public LinkedIn discussion threads, or granted me permission to share these private exchanges, of their thoughts on the definition of Technical Debt:

  • [a suggested addition, with respect to governance] "...a lack of understanding or practice of risk management- acceptance, avoidance, transference, etc. Unless a proper risk assessment is done, it is difficult to make financial decisions." 
    • Jeff Zygmunt
    • 2024-05-30, private LinkedIn message exchange (shared with his permission)
  • "Current technology or lack of technology that, due to age, negligence, or changes in standards represents the risk of a monetary or opportunity cost."

 

Suggested Background Reading:

Standards:

  1. ISO/IEC 25002:2024 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Quality model overview and usage

Articles by others:

(articles in order of expected reading value)

  1. https://en.wikipedia.org/wiki/Technical_debt
  2. https://www.sonarsource.com/learn/technical-debt/ 
  3. Holt Hackney:
    1. 2024-06-13: New Research Suggests Architectural Technical Debt Is Most Damaging to Applications Amid $1.52 Trillion Technical Debt Crisis  (Architecture & Governance Magazine)
      1. Rafalin: "Today’s technical debt reduction measures like code quality and performance observability tools and code vulnerability scans don’t focus on architectural technical debt."
      2. "The research study surveyed more than 1,000 U.S.-based architecture, development and engineering leaders, and practitioners at large enterprises as well as smaller digital-first companies."
      3. https://vfunction.com/resources/report-microservices-monoliths-technical-debt/
  4. McKinsey Digital:
    1. 2020-10-06: Tech debt: Reclaiming tech equity
      •  By Vishal Dalal, Krish Krishnakanthan, Björn Münstermann, and Rob Patenge
  5. Ward Cunningham's c2 wiki
    1. https://wiki.c2.com/?TechnicalDebt
    2. YouTube: Debt Metaphor
  6. Martin Fowler:
    1. Posts tagged: "Technical Debt"
    2. 2009-10-14: Technical Debt Quadrant
    3. 2019-05-21: Technical Debt
  7. Henrik Kniberg: [LinkedIn]
    1. 2013-10-11: Good and Bad Technical Debt (and how TDD helps)
  8. Gerben Wierda: [LinkedIn]
    1. 2018-09-08: Agile, Dirt, and Technical Debt
  9. neopragma: Dave Nicolette
    1. 2019-03-30: Technical Debt: The Man, the Metaphor, the Message
  10. appenwarr.com
    1. 2023-06-05: Tech debt metaphor maximalism 
  11.  Adam Tornhill: [LinkedIn]
    1. YouTube, GOTO 2019: Prioritizing Technical Debt as if Time and Money Matters
      1. Expected watching value: low-medium
      2. Primarly focuses on just the software aspects of Technical Debt 
  12. Georgiana Gligor: [LinkedIn]
    1. Today Software Magazine (Issue #47): Paying Technical Debt: a Top-Down Approach 
  13. Steve McConnell: [LinkedIn]
    1. Managing Technical Debt 
  14. Aaron Erickson:
    1. 2009:10-10: Don't "Enron" Your Software Project
  15. Gene Hughson
    1. 2013-11-04: Technical Debt - What it is and what to do about it

Books on Amazon.com  (in descending order of publication year)

  1. Unveiling Tech Debt: A Business Leaders Guide to Measuring and Managing Enterprise Tech Debt Leverage (2024)
    1. Estimated reading value: Very Low?
    2. Of possible note, see Chapter-6 Measuring and Managing Tech Debt, starting on page-70: Quantify Your Tech Debt.
    3. Pages: 88
  2.  Technical Debt Management in software projects using Scrum: An Action Research (2023)
    1. Estimated reading value: Low-Medium
    2. This book's value may primarily be as a bibliography to other works - as it has a copious amount of citations.
    3. Pages: 84
    4. Additional links:
      1. https://www.linkedin.com/in/frederico-zenoglio-de-oliveira/
      2. DOI:10.1109/Agile.2015.7
      3. https://www.semanticscholar.org/paper/Managing-Technical-Debt-in-Software-Projects-Using-Oliveira-Goldman/10e8eaf24a5247526a35211e9c0149370bf2f5e6
      4. https://speakerdeck.com/fredericooliveira/managing-technical-debt-in-software-projects-using-scrum-an-action-research
        1. See last slide, where he offers to send the full paper. 
      5. https://ieeexplore.ieee.org/document/7284597
      6. https://www.researchgate.net/publication/305865096_Managing_Technical_Debt_in_Software_Projects_Using_Scrum_An_Action_Research
      7. https://www.agilealliance.org/resources/research-papers/managing-technical-debt-in-software-projects-using-scrum/
        1. "Because of project time constraints and ease of use, we reduced the use of the proposed metrics to two:" 
          1. "Principal"
          2. "Current Amount of Interest"
  3. Technical Debt in Practice: How to Find It and Fix It (2021)
    1. Estimated reading value: Medium
    2. Covers variations of Technical Debt outside of just the software/source code
    3. Pages: 288
  4. Understanding Technical Debt: Your Guide to Navigating in the Age of Digital Disruption (2021)
    1. Estimated reading value: Medium
    2. In particular, see Part-3, for the section on "How to measure it?"
    3. Pages: 168
  5. Sustainable Software Architecture: Analyze and Reduce Technical Debt (2019)
    1. No Preview or Table of Contents available
    2. Primarly focuses on just the software aspects of Technical Debt
    3. Pages: 307
  6. Managing Technical Debt: Reducing Friction in Software Development (SEI Series in Software Engineering)  (2019)
    1. Estimated reading value: High
    2. In particular, see Chapter-8: Costing Technical Debt
    3. Pages: 272 
  7. Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis, 1st Edition (2018)
    1. Estimated reading value: medium
    2. Primarly focuses on just the software aspects of Technical Debt
    3. Pages: 276
  8. The Mikado Method, First Edition (2014)
    1. In particular, see the discussion in Appendix A: Technical debt
    2. Pages: 240
  9. Refactoring for Software Design Smells: Managing Technical Debt 1st Edition (2014)
    1. Estimated reading value: Low-Medium
    2. Primarly focuses on just the software aspects of Technical Debt
    3. Pages: 258

Research Papers:

  1. Towards the Definition of Enterprise Architecture Debts (2019)
    1. "In the software development industry, technical debt is regarded as a critical issue in term of the negative consequences such as increased software development cost, low product quality, decreased maintainability, and slowed progress to the long-term success of developing software. However, despite the vast research contributions in technical debt management for software engineering, the idea of technical debt fails to provide a holistic consideration to include both IT and business aspects. Further, implementing an enterprise architecture (EA) project might not always be a success due to uncertainty and unavailability of resources. Therefore, we relate the consequences of EA implementation failure with a new metaphor --Enterprise Architecture Debt (EA Debt). We anticipate that the accumulation of EA Debt will negatively influence EA quality, also expose the business into risk."
    2. arXiv:1907.00677
    3. https://doi.org/10.1109/EDOCW.2019.00016
  2. Technical Debt Management in Agile Context: A new framework and case study in a large financial institution
    1. SAC '24: Proceedings of the 39th ACM/SIGAPP Symposium on Applied ComputingApril 2024, Pages 826–833
    2. https://doi.org/10.1145/3605098.3635946
  3. Hidden Technical Debt in Machine Learning Systems
    1. Advances in Neural Information Processing Systems 28 (NIPS 2015)
    2. https://papers.nips.cc/paper_files/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html
 

A few possibly useful tools/techiniques (as 2nd/3rd order proxies) for approximating some aspects of potential Technical Debt magnitude:

(work-in-progress, entries to be added/elaborated, when I have time...)
 
Frequency/Cluster Analysis of bugs/defects, per source code file, or per line of code:
  1. (tools to be listed...)
 
Line Counting tools:
  1. cloc 
    1. line counting utility
  2. codescene
  3. ohcount
    1. line counting utility  
  4. sonarqube  
  5. tokei
    1. line counting utility
 

Cyclomatic Complexity Static Code Analysis, Software Measurement tools:

  1. (tools to be listed...)
 

Dependency Analysis tools:

  1. (tools to be listed...)
 

Lifecye Analysis: End-of-Life (EOL), End-of-Support (EOS)

  1. Flexera Technopedia
  2. See the Veterans Administration's Technical Reference Model (TRM) - for an excellent example.
    1. Note, in the Decision tab of their UI (see example: JDK Oracle Java Standard Kit Edition) - the Lifecycle information, provided by version - within a timeline context.

Addendums: 

2024-07-13 Sat

2024-09-26 Thu

Copyright

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