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.


 

Posted by No comments:

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...

 

Posted by No comments:
Labels:

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

Posted by No comments:
Labels: , , , ,

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
Posted by No comments:
Labels:

2024-05-26

2024-05-26 Sunday - Advice for those at the dawn of their IT Career

[image credit: Pexels on pixabay.com]
 

1. First, do no harm.
2. Don't leave a mess. Cleanup after yourself.
3. Listen, Look, Think, Act.
4. Be a good neighbor. Play nice.
5. Trust, but verify. Inspect what you expect.
6. Don't assume. Ask questions.
7. Help others.
8. Put things back in their proper place.
9. Rest before you get tired. Naps are good for you.
10. Don't rush, you might trip and fall

Posted by No comments:

2024-04-28

2024-04-28 Sunday - rustls ("A modern TLS library in Rust")

My weekend reading, doing a deep dive into the Rust source code for the rustls library, and its support for post-quantum (PQ) key exchange.

A modern TLS library in Rust 

 

NOTE:  "This crate provides experimental support for X25519Kyber768Draft00 post-quantum key exchange."
  • https://github.com/rustls/rustls/tree/main/rustls-post-quantum
  • https://docs.rs/rustls-post-quantum/latest/rustls_post_quantum/ 
    •  Crate rustls_post_quantum
      • "X25519Kyber768Draft00 is pre-standardization, so you should treat this as experimental. You may see unexpected interop failures, and the algorithm implemented here may not be the one that eventually becomes widely deployed."
      • "However, the two components of this key exchange are well regarded: X25519 alone is already used by default by rustls, and tends to have higher quality implementations than other elliptic curves. Kyber768 was recently standardized by NIST as ML-KEM-768."
[image source: https://github.com/rustls/rustls/blob/main/rustls-post-quantum/src/lib.rs]

    • See line #71:  [X25519Kyber768Draft00]:
        • "This memo defines X25519Kyber768Draft00, a hybrid post-quantum key exchange for TLS 1.3."
  • IETF Draft: Hybrid key exchange in TLS 1.3 (version 10)
    • [Note: Expires 2024-10-07]
    • "Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3."
    • 3. Construction for hybrid key exchange [selected quotes]
      • 3.1. Negotiation
        • "Each particular combination of algorithms in a hybrid key exchange will be represented as a NamedGroup and sent in the supported_groups extension. No internal structure or grammar is implied or required in the value of the identifier; they are simply opaque identifiers."
        • "Each value representing a hybrid key exchange will correspond to an ordered pair of two or more algorithms. (We note that this is independent from future documents standardizing solely post-quantum key exchange methods, which would have to be assigned their own identifier.)"
      •  3.2. Transmitting public keys and ciphertexts [selected quotes]
        • "Recall that in TLS 1.3 a KEM public key or KEM ciphertext is represented as a KeyShareEntry: ..."
        • "These are transmitted in the extension_data fields of KeyShareClientHello and KeyShareServerHello extensions: ..."
        • "For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the concatenation of the key_exchange field for each of the constituent algorithms. The order of shares in the concatenation MUST be the same as the order of algorithms indicated in the definition of the NamedGroup."
    • 6. Security Considerations [selected quotes]
      • "The shared secrets computed in the hybrid key exchange should be computed in a way that achieves the "hybrid" property: the resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an investigation of these issues. Under the assumption that shared secrets are fixed length once the combination is fixed, the construction from Section 3.3 corresponds to the dual-PRF combiner of [BINDEL] which is shown to preserve security under the assumption that the hash function is a dual-PRF."
      • "As noted in Section 2, KEMs used in the manner described in this document MUST explicitly be designed to be secure in the event that the public key is reused, such as achieving IND-CCA2 security or having a transform like the Fujisaki-Okamoto transform applied. Kyber has such security properties. However, some other post-quantum KEMs are designed to be IND-CPA-secure (i.e., without countermeasures such as the FO transform) are completely insecure under public key reuse; for example, some lattice-based IND-CPA-secure KEMs are vulnerable to attacks that recover the private key after just a few thousand samples [FLUHRER]."
      • "...this specification MUST only be used with algorithms which have fixed-length shared secrets (after the variant has been fixed by the algorithm identifier in the NamedGroup negotiation in Section 3.1)"

 

 

rustls Security Advisories:

 

Additional resources:

https://badssl.com/
"badssl.com is meant for manual testing of security UI in web clients."

https://github.com/chromium/badssl.com
"Memorable site for testing clients against bad SSL configs."


Cloudflare Research: Post-Quantum Key Agreement
https://pq.cloudflareresearch.com/
https://tldr.fail/
"On essentially all domains served (1) through Cloudflare, including this one, we have enabled hybrid post-quantum key agreement."

 

Noteworthy Articles:

  1. 2024-04-28: Google Chrome's new post-quantum cryptography may break TLS connections


References: 

NIST: 

Posted by No comments:
Labels: , , ,

2024-04-20

2024-04-20 Sunday - Suggested High Performance Laptops

 

[image credit: JoshuaWoroniecki on pixabay.com]

As an architect, I frequently need to explore various new/emerging technologies and architecture scenarios. To allow me to setup various configurations on my local machine - I want to have robust computing capabilities.

I'm continuing to research new laptop products, as they become available in 2024 - and will revise this blog post as I find better candidates.

Hopefully this information may be useful to other researchers, consultants, and teams.

Option #1: 

MSI Titan 18H"
(with most of my wish list configuration options (only missing RAID 1, with 2x 4TB SSD)

  • https://www.msi.com/Laptop/Titan-18-HX-A14VX
  • https://www.newegg.com/p/N82E16834156588 
  • https://www.amazon.com/MSI-Titan-Computer-i9-14900HX-Thunderbolt/dp/B0CY9RV1J9
    •  MSI Titan 18 HX 18" 
    • 120Hz 4K 18" UHD mini LED display, 3840 x 2400, HDR 1000, 100% DCI-P3
    • Intel Core i9-14900HX 24-Core (8P+16E, 2.20-5.8 GHz, 14th gen HX-series, "Raptor Lake")
    • NVIDIA GeForce RTX 4090, 16 GB GDDR6
    • 128GB DDR5 RAM (32 GB x 4)
    • 4 TB (2 TB x 2) NVMe Gen4x4 SSD [KM: Would upgrade to 4 TB x 2, RAID 1]
    • WiFi 7
    • LAN: Killer E3100G
    • WLAN: Killer WiFi 7 BE1750
    • Bluetooth 5.4
    • USB: 3 x USB 3.2 Gen 2 Type-A
    • Card Reader: SD7.0
    • Thunderbolt: 2 x Thunderbolt 4 w/ DP (1 also with PD3.1)
    • HDMI: 1 x HDMI 2.1
    • Ethernet: 1 x RJ-45 (2.5Gbps)
    • Audio Ports: 1 x Headphone/Microphone Combo Jack 
    • Speaker: Sound by Dynaudio, 4x2W Speakers 2W x2W Woofer
    • Keyboard: Cherry Mechanical KB SteelSeries per-Key RGB (99 Key)
    • Touchpad: Seamless EGB Haptic Touchpad
    • Webcam: IR FHD w/shutter 
    • Power adapter: 400-watt AC Adapter
    •  Battery: 4 cell (99.9Whr) Li-Ion
    • Windows 11 Pro 64-bit
    • 7.93 pounds 
      • Dimensions: 15.9 x 12.08 x 1.26 inches
      • Strange that it says 15.9

 

 

[image source: Amazon.com]


 

Option #2:

EXCaliberPC [2024] MSI Raider 18 HX

 

Option #3:

 EXCaliberPC [2023] MSI Titan GT77HX 

  • https://www.amazon.com/dp/B0BTM3M282/
    • 13VH-046US (i9-13980HX)
    • 128GB RAM
    •  8TB (2x 4TB) WD Black SN850X NVMe SSD (Seq. Read 7300MB/s, Seq. Write 6600MB/s) 
    • RTX 4080 12GB
    • 17.3" 4K UHD
    • Windows 11 Pro)


 

Posted by No comments:
Labels: , ,
Subscribe to: Posts (Atom)

Copyright

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