The JBoss Fuse EOL: A Strategic Pivot in the Age of AI

In the current landscape, where boardrooms are dominated by discussions on Generative AI and LLM integration, the "plumbing" of the enterprise, our core integration layers, often goes unmentioned until it leaks.

As of 2026, we have reached a critical inflection point: JBoss Fuse has officially reached End of Life (EOL).

For the CIO, this isn't merely a technical debt item on a Jira board; it is a significant security liability and a bottleneck to enterprise agility. Having spent two decades navigating the evolution from heavy-weight ESBs like TIBCO and WebSphere to the lightweight revolution of Apache Camel, I’ve seen this cycle before. However, the stakes in 2026 are higher. I developed a strategy that was fit for the need at hand, and my CIO loved it.

Here is the battle-tested strategy for navigating the post-Fuse world without falling into common vendor traps.

The Reality Check: Kubernetes is Not a Default

Red Hat’s push to migrate "everything" to OpenShift (Kubernetes) is a powerful narrative. Centrally, they are correct: Containers are the definitive packaging standard. The shift of responsibility from the application server to the orchestration layer (deployment, scaling, load balancing) is a net positive for the industry. I remember when I got my hands on Docker at an IBM conference a decade ago, I was blown away.

However, as a member of the IT executive team, a Chief Architect must also weigh the Total Cost of Ownership (TCO) against the Operational Readiness of the engineering and support team. 

1. The "K8s Tax": For many, raw control plane management has become a "gravy train" for vendors and a resource sink for enterprises that lack mature DevOps cultures.
2. Commodity vs. Competitive Advantage: If your integration volume isn’t in millions of transactions per day and your team hasn't mastered K8s, forcing a transition to a complex container orchestration platform creates a "skills gap" crisis that outweighs the architectural benefits.

 

The "Pragmatic Bridge" Strategy

When faced with an impending EOL, the "cleanest" architectural choice isn't always the best business choice. In a recent high-stakes migration, my team faced a specific set of constraints:

1. Imminent Support Expiry: No room for a 2-year "digital transformation" roadmap.
2. Resource Constraints: Limited Java expertise and zero K8s internal knowledge.
3. Efficiency Needs: Low-volume integrations that didn't justify a massive cluster footprint.

My Contextual Recommendation: Camel on Spring Boot

Get compliant, then get on cloud. We bypassed the Kubernetes mandate and opted for Standalone Camel via Spring Boot. 

Criteria	Why Spring Boot?	The Tradeoff
Talent Acquisition	Access to the largest pool of Java developers and architects globally.	Slightly heavier memory and CPU footprint compared to Quarkus.
Enterprise Readiness	Highly mature ecosystem with robust security libraries and "battle-tested" reputation.	Lacks some "bleeding edge" cloud-native optimizations like instantaneous startup.
Speed to Delivery	Rapid prototyping through "Starters" and familiar deployment patterns.	Requires external orchestration (like a PaaS) or manual logic for scaling.

By choosing Spring Boot, we stabilized the ship. We hired effectively, migrated the core logic, and mitigated the security risks of an unsupported JBoss environment all while keeping the underlying infrastructure simple and manageable.

 

Looking Ahead: The 10-Year Rewrite & The AI Catalyst

The reality of software is that it has a shelf life. Every decade, a re-architecture is inevitable. While we chose a "bridge" solution today to exit the Fuse ecosystem, the long-term goal remains a Turn-Key Cloud-Native Integration Platform.

The difference in 2026 is that we are no longer doing this manually.

• AI-Assisted Migration: We are leveraging AI for automated code generation and protocol mapping, turning what used to be a 12-month migration into a 4-month sprint.

• Incremental Modernization: By moving to Spring Boot/Camel now, we’ve created a portable codebase. When the organization is ready for a full Cloud-Native PaaS adoption, the "rewrite" will be a transition of environment, not a total loss of business logic.

Executive Takeaway

Don't let vendor pressure dictate your infrastructure complexity. If your team isn't ready for the "Kubernetes Tax," don't pay it yet. Secure your perimeter by migrating off JBoss Fuse to a manageable, standalone framework like Spring Boot. This buys you the most valuable currency in IT: Time. Time to build your cloud-native skills and time to let AI mature your codebase for the next decade of integration.

As a System Thinketh: Architecting the IT Landscape of the Organization

I recently read the 1903 classic As a Man Thinketh. I was blown away by the short but effective book by James Allen. I wonder if what he posits that a person is the literal sum of their thoughts could be applied to an IT Organization. While often filed under "self-help," this philosophy offers a profound framework for the modern Chief IT Architect, CTO, or Engineering VP.

My Core Thesis: My take on the book applied to an IT organization. We can assume that an IT org is a collective organism whose technical output and operational health are the direct "fruit" of its internal culture and engineering philosophy. To change the state of a system, one must first change the "thought patterns". People, process and technologies are a collective outcome of the habits, values, and standards of the individuals who demand it, build it and use it.

---

1. The Garden of IT Architecture and the Law of System Entropy

Allen famously compares the mind to a garden: if you do not intentionally plant "useful seeds," then "useless weed-seeds" will take root by default.

I often borrow the term System Entropy to explain this phenomenon to business leaders. If an Engineering Leadership team does not intentionally seed the organization with a "North Star" architecture and rigorous design principles, the vacuum will be filled by "useless seeds": technical debt, shortcut-driven development, and fragmented microservices. The climate is continuously changing too, doing the same kind of tasks to manage the landscape is not enough.

• The Translation: You are not a victim of your "legacy monolith." That monolith is the solidified thought-pattern of a previous era.
• The Action: To transform "outside conditions" (the codebase), I often point out the "hidden soil" (the engineering standards). Mastery begins with the internal commitment to quality before the first line of refactoring or unit test is even written.

2. Thought Crystallizes into Habit: The CI/CD Pipeline of the Mind

I loved the line in the book, where Allen argues that "thought cannot be kept secret; it rapidly crystallizes into habit, and habit solidifies into circumstance."

This is arguably the most accurate description of Software Delivery Velocity ever written. A "thought" (a developer’s decision to skip a unit test "just this once") quickly "crystallizes into habit" (a team culture that views testing as optional). This eventually "solidifies into circumstance" (a fragile CI/CD pipeline and frequent production outages).

Aspect	The "Weed" Thought (Reactive)	The "Useful Seed" (Proactive)
Design Review	Create no diagrams or super complicated architecture visuals to impress	Create level 1 and level 2 C4 diagrams to communicate
Code Review	"LGTM" - Lets Get This Merged.	Critical inquiry; mentoring; guarding the "garden."
Documentation	"The code is the documentation."	"Clarity is a gift to my future self."
Incident Response	Find someone to blame.	Blameless post-mortem; systemic fix. Address issues in a retrospective.
Refactoring	"We'll fix it in Phase 2."	"Leave the campground cleaner than you found it."

3. The Thought Factor in Achievement: Purpose-Driven Engineering

Allen suggests that Thought + Purpose = Intelligent accomplishment. Many IT departments suffer from "Resume-Driven Development" (RDD) or "Shiny Object Syndrome," where the thought (using a new GraphQL framework) lacks purpose (solving a specific business latency issue).

Without a clear purpose, engineering effort is scattered. True achievement in system design is the "crown of effort and diadem of thought." When an Architect aligns every technical decision with a business outcome, the market and the stakeholders favor that clarity.

4. The Jewel of Serenity: High-Stakes Incident Management

The final chapter of Allen’s work focuses on Serenity. He notes that "the more tranquil a man becomes, the greater is his success."

In the heat of a SEV1 production outage, the "tranquil heart" of a Lead Engineer is more valuable than any debugging tool. A leader who remains "strongly equitable" during a crisis prevents the "thoughts of fear" from paralyzing the team's ability to solve the problem.

Serenity in IT manifests as:

• Equanimity: Staying calm when the system is down.
• Self-Control: Resisting the urge to "cowboy patch" production.
• Resolution: Methodically following the runbook instead of panicking.

The Bottom Line

As an IT leader, your department's current state be it a high-velocity innovation engine or a bogged-down maintenance nightmare is not an accident of "unlucky circumstances." It is the fruit of the collective thoughts and habits of your team.

Circumstance does not make the organization; it reveals it. To improve the system, stop focusing solely on the "fruits" (the bugs and the delays) and start cultivating the "seeds" (the engineering mindset and cultural values).

Is WSJF "better" than traditional ROI calculations for Applications?

I love road trips, and i like analogy.  

The Premise: Two couples are planning a road trip.

The "Perfection" group: This group spends a year planning a single, perfect itinerary. They book every hotel, museum, and restaurant reservation months in advance. They have a massive, inflexible budget and a 50-page binder and a fixed budget line item for everything. If a restaurant is closed or a friend gets sick, the entire plan and budget is at risk. It's an all or nothing roadtrip. Everyone's holding their breath and each part of the plan feels risky.

The "Flow" Group: This group has a general idea of their destination (Philadelphia). They decide to drive for a few hours (Planning interval) and then check in with each other (PI Event). "Where do we want to go next?" they ask (Retrospective, Feedback). They agree to stop at the most interesting thing that's coming up soon (Weighted Shortest Job First). They choose what needs upfront planning, such as booking an event outing but not everything. They have a modest amount of cash on hand (their lean budget) and use apps like Airbnb or Yelp to find local spots (leverage suppliers). They let the person in the passenger seat make decisions on what music to play or where to eat next (empower local decision making). All of this feels balanced, and the group is in flow with flexibility.

I signed the Agile Manifesto in 2012. Since then I have selectively applied various lean, and agile principles, tools and techniques to software development processes. One key question that often comes up is "How do you measure ROI for applications" - this is a key question often overlooked. However, the economic benefits are an essential driver for investment decisions in technology

I have trained and certified in SAFe. It is essential for a team embarking on SAFe go through training across all levels in the organization. Epics and participated in prioritization of enablers and functional epics across a portfolio with leadership teams. The goal is to maximize economic benefit.  A pre-requisite to that is the way in which prioritization is done and what it's measured against.

Traditional Return on Investments consider "green or white dollars", where as SAFe prioritized "flow". WSFJ isn't an ROI methodology however I argue it is apt for many situations in IT investment choices.

Taking an Economic View in Practice

- Deliver Early and Often: This is valuable to ensure flow

- Operate within Lean Budget: Fund teams, this is akin to spending mostly "white dollars" - the staff.

- Understand Econonic Tradeoffs for Solutions: This is where a common consensus on Value needs to be defined first.

- Leverage Suppliers: Buy versus Build can significantly increase speed to market as well as ROI

- Sequence Jobs for Maximum Benefit: Weighted Shortest Job First is the way to sequence almost anything at any scale

- Empower Local Decision Making - ensure that the value determination is local to a group - perhaps product management team, and the duration is local to the development team estimation. 

Cost of Delay is an interesting way of determining Value and it's essential to bring everyone on board to the determination of Value. It's a post-mortem view of what happens if we don't so this? Thanks to Donald Reinertsen CoD is a priority.

CoD = BV+TC+RR | OE

BV is Business Value e.g. reduction in operating costs, or increase in revenue

TC is Time Criticality - e.g. regulations, reputational harm

RR is Risk Reduction e.g. Security risk via SSO

Opportunity Enablement e.g. Enabler epics

CoD / Size is used in SAFe. 

"Those who do the work size the work" Steve Adolph has a good video on his.

Basically, WSJF delivers the low hanging fruit without impact to the most important things business wants by much. You get some value really quickly, versus nothing for a very long time.

Conclusion

ROI calculations almost always depend on the agreed-upon "Value" score. This is where almost all 'returns' on application value falter. This is a highly subjective, non-scientific area and there is no standard methodology that has been universally and easiliy adopted. The value is contextual and each leadership team must define what and how they can generally align on value by assigning metrics to it. 

Cost of Delay is a great way to define Value for software and technology delivery for applications. 

Event Driven Architecture Standardization for Efficiency and Scale

This is a rehash of my blog post on "Debate Over Domain-Agnostic Connections"  back in March 2010 when I pushed for event driven architecture as a technologist and got push back from the development team who were doing simple point-to-point integration. I have rewritten the post using a prompt that recasts into a structured output that addresses business fit as well as technical fit.

Standardized Event-Driven Architecture for Business Agility

Recommendation to use Domain-Agnostic Connection Factories for Service Integration Bus is crucial for achieving a unified, scalable, and resilient enterprise-wide integration platform. This decision will enable a foundational Event-Driven Architecture (EDA) that directly supports our goals of faster time-to-market and improved system resilience.

Supporting Rationale

Enhancing Business Agility & Resilience

This approach unifies our messaging framework, enabling seamless interoperability across diverse business domains. It mitigates the risk of fragmented integration silos that can impede cross-departmental data flow and innovation.

By abstracting the underlying messaging resources, we can more easily integrate new business units or third-party services without extensive code changes, directly accelerating our ability to respond to market demands.

Operational & Technical Rationale: Standardizing for Efficiency and Scale

Reduced Complexity

Using a single connection factory streamlines development, as engineers no longer need to manage separate code paths for different messaging types (e.g., Topics vs. Queues). This reduces boilerplate code and cognitive load, leading to fewer errors and faster feature delivery.

Improved Scalability & Maintainability

The architecture provides a consistent, standardized pattern that is easier to document, test, and automate. As we scale our microservices and integration points, this consistency will be vital for operational efficiency and platform stability.

Proof Points & Details

Executive Proof Point

 The Proof of Concept (POC) demonstrated a 25% reduction in integration development time for a new service, validating the efficiency gains. Furthermore, a single, documented approach minimizes training overhead for new teams and reduces long-term operational costs.

Practitioner Details

The design uses the JMS 2.0+ standard ConnectionFactory interface, which is the current industry best practice. This pattern allows for code to be written once and deployed to multiple messaging endpoints, such as TopicConnection for broadcast events and QueueConnection for point-to-point transactions. This is not about making development harder; it’s about freeing developers from low-level plumbing so they can focus on business logic.

Analogy

Think of a universal remote control. Instead of needing a different remote for your TV, sound system, and streaming device, one remote can control them all. The ConnectionFactory is our universal remote for enterprise messaging—it simplifies the user experience without sacrificing functionality.

Conclusion & Next Steps

This architectural decision ensures our integration platform is built for the future, not just the current project. It will lead to:

Business Outcome

Improved system resilience and faster time-to-market for new services.

Technical Outcome

A standardized, scalable framework that reduces technical debt and improves maintainability.

The path forward is clear. We will update the project wiki with detailed technical examples and a reference implementation. I will continue to work directly with team leads to ensure a smooth transition and address any further questions, ensuring we maintain a collaborative approach as we move forward.

C4 should be the de-facto diagramming style for SAFe Agile Teams

Intro

Let me first start with how I wrote this, because it's important. In my career I have crafted several architectural decisions. The most challenging presentations are when I have had to address both technical and business audiences. Technical story telling is an essential skill. As the Senior Director of IT Strategy and Architecture, I applied the "Pyramid Principle" extensively. You start with the answer, then state the why, how, and next steps. Usually, presenters don't do this. Instead they "build up" to the answer. Meanwhile, their audience has "lost the plot". Ever since I adapted this communication style, effectiveness of my communication has been lauded.

The Answer

Pilot C4 Diagramming Standard for the next PI (Planning Increment).

To deliver software that is timely, high-quality, and aligned with business goals, you should adopt the C4 diagramming style as the standard for visualizing architecture. C4 provides a clear, layered way to represent systems that works for executives, architects, and developers alike.

The Why

Executive Perspective

(a) Shared Understanding Across Audiences

C4 diagrams scale from high-level context (business view) to technical detail (developer view), ensuring everyone. From stakeholders to engineers everyone can interpret the architecture without the need for heavy tooling. Just enough design facilitates acceleration of the solution.

(b) Agility with Discipline

Unlike heavyweight modeling approaches, C4 is lightweight and iterative, making it compatible with agile teams while still ensuring design intent is explicit.

(c) Risk Mitigation 

Consistent visual models surface integration, security, and scalability risks early, reducing costly redesigns.

Practitioner Perspective

(a) Clarity of Scope and Boundaries

Context and container diagrams make dependencies, APIs, and infrastructure responsibilities unambiguous.

(b) Scalability and Deployment Readiness

Component and container views map directly to runtime environments, cloud services, and CI/CD pipelines.

(c) Knowledge Retention

C4 diagrams are simple enough to maintain as living documentation, reducing reliance on tribal knowledge.

The How

Like Google Maps, C4 lets you zoom in and out: executives see the “city map” (context), architects see the “neighborhood layout” (containers), and developers see the “street-level details” (components and code).

Leading organizations and open-source communities use C4 to replace ad-hoc diagrams with a consistent, widely understood notation.

Practitioner Example:

1. Context Diagram: Shows how the system interacts with users and external systems.
2. 
   Container Diagram: Breaks down major applications, services, and databases.
3. Component Diagram: Details the internals of each container and key responsibilities.
4. Code Diagram: Optional, zooming into classes, libraries, or modules for critical areas.

Practically, Context and container diagrams should be developed and maintained. The component and code diagrams usually have diminished return on time investment.

Leading Indicators

Business Outcomes

• Reduced communication gaps between business and IT.
• Faster alignment on architectural decisions, accelerating time-to-market.
• Lower risk of rework by ensuring shared understanding upfront.

Technical Outcomes

• Consistent, lightweight architecture diagrams across teams.
• Easier onboarding for new developers and faster knowledge transfer.
• Clear alignment between architecture, infrastructure, and code.

Decision

• Decide to adopt C4 as the standard architecture visualization method across projects.
• Provide teams with starter templates and simple guidance.
• Pilot the C4 approach in the next project increment and review effectiveness with both stakeholders and developers.

Conclusion

You can steal this, customize it and use it for your company. Good luck!!

SSL versus TLS

Data communications channels are often insecure, subjecting messages transmitted over the channels to passive and active threats (Barkley, 1994). Internet protocols connect various networks and data packets are transmitted over them. An entire protocol stack exists over which computers exchange messages. For example, Web-browsers sent Hyper-text Markup Language (HTML) messages over the Hyper-text Transfer Protocol (HTTP) which sits on top of the TCP/IP stack. Additional protocols are now in places that create secure channels for such communication, Secure Sockets Layer (SSL) sits between the HTTP and TCP/IP protocols, so for secure Web-page transfers HTTP is transmitted over the standard port 443 of SSL rather than the unsecured port 80 assigned to HTTP. Together this results in HTTPS (HTTP over SSL) communication. Secure socket layer and TLS are security protocols primarily used for network transport of messages.

Secure Sockets Layer

The Secure Sockets Layer (SSL) protocol is a security protocol that provides communication privacy over the Internet by allowing client-server applications to communicate in a way that is designed to prevent eavesdropping, tampering or message forgery (Freier, Karlton & Kocher, 1996). SSL is composed of a handshake protocol and a record protocol, which typically sits on top of a reliable communication protocol like TCP. SSL evolved into its latest version 3.0 resulting in the transport layer security protocol.

Transport Layer Security

The primary goal of The Transport Layer Security (TLS) protocol is to provide privacy and data integrity between two communicating applications; this is used for encapsulation of various higher level protocols (Dierks & Allen, 1999, p. 3). The TLS is actually a combination of two layers, the TLS Record Protocol and the TLS Handshake Protocol. The TLS Record Protocol has two basic properties: connection privacy and reliability. The TLS Handshake protocol has three basic properties: peer identity authentication, shared secret negotiation, and negotiation reliability.

One advantage of TLS is that is independent of the application protocol (Dierks & Allen, 1999, p. 4). Higher-level protocols can be layered on top of this protocol. This leaves the decision of TLS initiation of handshaking and authentication certificate exchanges to the judgment of higher-level protocol designers. The primary goals of the TLS protocol, thus, are to provide cryptographic security, interoperability, and extensibility. These are fundamental requirements of enterprise security.

 

The Human-AI Partnership: Why Mastering Touch Typing is Your Next Generative AI Superpower

Generative AI requires humans to establish thought partnership rather than allow AI to take over critical thinking skills. I believe that typing prompts effectively and efficiently is a key skill today. Human-computer interfaces are getting better everyday, there are many modes of computing. For serious AI users, getting rid of the computer keyboard. Learn QWERTY from the 1870s or Dvorak, Colemak. Get used to typing effectively with AI GPTs interactively and effortlessly.

Like many people I too perfected the awkward dance of looking at my keyboard as I typed and then glacing up at the screen. So what's the problem? Well, I realized there are many problems with doing that. I learned to type on my dad's manual typewriter as kid, and making a typing mistake was costly. I typed slowly and deliberately looking at each key as I punched it with all the force to make an impression on the paper behind the ribbon. With that habit set, I transfered it over to coding on a keyboard in just the same and continued with that for most of my life. Until COVID-19 lockdown. 

During the lockdown of 2020-2021 I had a lot of free time. It occurred to me that the way I typed interrupted my flow, created friction between my thoughts and what I typed and did not help my neck and spine ergnomics. I took it upon myself to learn how to type. I humbly decided to get back to the basics of writing with a keyboard. 

According to Quora only 1% of people can type above 90 WPM.

Touch Typing @100 WPM FTW

I made it my mission to improve that, I don't do that anymore I never look at my keyboard, I simply look at the screens and my fingers are trained to find the keys via my kinesthetic sense. This simple yet monumental shift has helped me tremendously in life, career as well as my digital health due to improved ergonomics. Touch typing is not just about speed or a flex for me, it is actually good for my spine and posture, it has helped with note taking and enhanced my productivity significantly.

Left Hand

- Index R T F G V B

- Middle E D C

- Ring WSX

- Little P ;: /?

- Backspace and Delete

Right Hand

- Index Y H N U J M

- Middle I K <,

- Ring O L .>

- Little QAZ

Fig. Typing with all ten fingers

Fig. My typing speed peaked at 101 WPM in 2023. 

I call it good enough for most people, especially a technologist. Typing at the speed of light isn't necessary - just at the speed of thought. Typing fast enough while focussing on the words rather than the mechnics is an important skill. Why not just dictate? I think there are really good dictation tools that can help with speech to text, and it works if you are able to articulate well. In my case, I find editing text skills, and typing are still essential to valuable work. It is also not possible to always have a distraction free, quiet room to be able to dictate and if you care about privacy, it is best to simply stick to typing. Good typing skills are a "forever skill" - is it a no-regrets training because over time, the return on your investment isn't just better typing - it's better flow and improved thinking.  If you force yourself to think slower than you type, the you must learn to type faster. The faster I typed the better my thinking flowed. Optimal speeds of speech are around 200-250 WPM, I can type at around 90 wpm today, so it's still kind of slow. I do think that it's much better than my best non-touch typing at 65wpm that has a lot of interruptions to optimal flow. Touch Typing is a Win-win. 

Typing Club

I signed up for Typing Club and began practicing and training my fingers to find the keys on the keyboard with the correct finger. My typing speed plummeted from 67 (max) down to 20-40WPM range. After a month of this I was ready to give up and really questioned the value of the pain that I was enduring. 

The goal is that each finger should know how to reach the correct key, and it is imperative that technique be mastered slowly. Patience is required. I picked QWERTY for myself just because I was not ready to embark on another layout. I probably won't. I am aiming for good enough. I don't want to type at 200WPM, I am happy with being close to 90+ on a good day.

I would highly recommend completing the basic training offered by https://www.typingclub.com

My Journey of 10 months with 10FastFingers

Which typing site has the most common words for typing practice? 10FastFingers has good statistics and a collection of tests that lets you type away at one minute tests as well as longer tests with the most popular words in the language. 

I spend a few minutes of break on 10FastFingers - its just out of habit. What I have discovered is that my typing speed tells me a lot about my energy levels, focus levels and has a lot to do with the quality of my sleep.

I started practicing typing in 2020 for the first time ever. Until September I literally did not know why there was a bump on the F and J keys on keyboards.

September 11th 2020

This record came in with a eye on the keyboard method. This is the high water mark. This was never achieved again. Most subsequent tests came in at 70 WPM.

Fig. Looking at the keyboard and typing the best I knew how!

September ranging from 55-70, mostly getting to 60-62 wps on average 

The 78 WPM was from my non-touch typing skills. Personal record.

Early morning typing. Mouthed the words. Looked at the words to type, the keyboard and the word that I was typing. Not using my little fingers and not using my forefingers properly.

Starting mid-September 2020 I embarked on a journey to learn touch typing i.e. no look typing

Oct 3rd 2020

My average touch typing speed has reduce by half or more, my error rates are very high. I need to make a lot of corrections on the DAS Keyboard. It is a struggle. 

Sadly its around **35 WPM** with 90% accuracy.

Goal is to increase the touch typing to 100% accuracy with 40 WPM by end of the year with 99% no look touch typing.

Oct 30, 2020 

I am able to hit 50 wpm or higher with ease by Oct 30, 2020.

These results were really making me question the whole endevour. I almost gave up. I slept on it, and then decided to analyze.

I reflected on what I was missing.

Main issues in october that I identified:

- Letter C - instead of using the middle finger i use the index finger

- Letter R and T - i use mostly the middle finger unless there is a sequence. I must always use the index finger.

- I need my left hand to learn better typing.

Nov 4, 2020

I was able to get my Words-per-minute up, but the error rate was close to 10%. As I pushed higher, my error rate increased beyond 11%. 

Fig. 66 WPM Low Accuracy

I went for 400 characters per minute typed, pushed harder - I had a need for speed!

I went for 400 cpm - and hit it ! Of course the number of errors were much higher. But it is possible to hit that number. I can be in the 80s if it try harder. I think hitting 425 correct key strokes may do it. It is all going to be muscle memory. The most efficient memory of all - it is all about procedural memory.

I hit a higher number in competition with greater accuracy.

Pivot to Accuracy First

I decided that it was time to stop pushing speed. Instead, a refocus on perfection was in order. At any cost, I must not be willing to type fast at a rate where the accuracy drops.

Fig. Nov 13, 2020 - 100% accuracy but speed drops to 44 WPM.

Back to the drawing board, I must focus on accuracy and technique and let the speed follow from there on out.

December 2020

Fig. 60 WPM at 100% accuracy.

I was able to hit 60 wpm with 100% accuracy.

Fig. 95% accuracy

Fig. 94% accuracy

I hit the 80s in 2021

Fig. Low Accuracy but touched the 80 wpm mark

I wanted to improve my accuracy and at the same time my speed improved as well. I was a happy camper.

Fig. 85 WPM 2-12-2021

Fig 86 WPM higher accuracy

Fig. 86 with high character count

Fig 86 at 98% accuracy

Fig. Almost perfect accuracy at 88 WPM!! 

Each typing result at this level gave me tremendous motivation and purpose to forge ahead. The lockdown was creating all kinds of time for me, and I knew that I was close to my goal of hitting the high 90s or even a 100. So close!

Fig. Accuracy 98%

Fig. Accuracy 98%

Jun 2, 2021 I was hitting 95 WPM at accuracy greater than 95%.

I had purchased the IQUNIX F96 Mechnical Keyboard

Brown switches, and also the DAS Professional Keyboard with the clicky blue switches.

Neither keyboard had any markings on the keys. This was purely a flex. Only "real" geeks could use my computer.

I watched a lot of videos for motivation, tips and tricks to keep improving.

I used a few other sites as well for fine tuning, variety and fun.

KeyBR

A site that is driven by Artificial Intelligence that detects issues in common key combinations and provides practice specific to an individual weakness. KeyBR helped me by learning what key combinations were my weakest and helped practice those specific areas. It's simply a great free resource for fine-tuning.

MonkeyType: A clean, minimalistic site that really helped me track down my rate during the minute of typing, and it is also extensible in many ways. I would use this a lot.

Type Rush: This site provides a boat race as well as car race with full gamification like prize winnings. It was fun to compete and added an element of pressure to perform against others. As I typed the car went forward. I won many races, and it does get progresively more challenging.

Key Hero: I most enjoyed the quotes, and paragraphs provided by this site. If you do NOT fix the errors, a penalty is added to the infal WPM score. I am not a fan of how the scoring is done. I consistently scored low on these test, and paradoxically enjoyed them.

Conclusion

It was well worth it. This one skill is a forever skill and has continued to pay me dividends. I enjoy thinking, and writing. It enables me to use my mind creatively, and think better. I use my skills today to prompt AI to help partner with me and my touch typing skills are an essential tool, skill and method that help me get the most in and out of my brain.

References

1. https://10fastfingers.com/typing-test/english
2. https://www.keyhero.com/free-typing-test/
3. https://zty.pe/
4. https://www.ratatype.com/typing-test/
5. https://www.how-to-type.com/touch-typing-lessons/how-to-type-home-keys/
6. https://medium.com/@mantasd/touch-typing-how-long-does-it-take-to-reach-100-wpm-129ba855d038
7. https://www.keyhero.com/free-typing-test

Not Only SQL

NO SQL is basically a highly scalable disruptive data storage technology. The basic downsides included proprietary APIs (no standard SQL), evolving capabilities, loads of vendors, lack of skills.

Here’s some information from the net…

FoundationDB – has the added advantage of providing data consistency.
 
MapR - SQL capabilities over large-scale distributed systems including Hadoop and NoSQL databases
 
GridGain - brings in-memory capabilities to MongoDB. Achieves elastic scale and automatic transparent re-sharding
 
Scientel - Gensonix® stores structured/unstructured data in Relational, Hierarchical, Network, and Column formats, and scales to trillions of real-time transactions.
 
Accumulo - enable online model building and dynamic indexing to support both retrospective analysis and enrichment of streaming data.
 
Microsoft - Windows Azure Tables offer the best of both scalability and ACID guarantees.
 
RavenDB - a schema-less document database that offers fully ACID transactions, fast and flexible search, replication, sharding, and a simple RESTful API
 
eXist-db - High-performance native XML database engine and all-in-one solution for application building.
 
Cloudant - providing strong-consistency for single-document operations.
 
Aerospike - optimized for SSDs through a highly parallelized, distributed architecture.
 
StarCounter - an in-memory database that processes millions of database transactions per second on a single machine.

Role of Senior Architects

A key strategy is delegation. This works well if you are comfortable with it.

I espouse a personal philosophy that says if a decision can reasonably be made by someone with a more narrow scope of responsibility, defer the decision to that person or group.

Trust, but verify. Review. Review. Review. Ask open ended questions and have an open channel of communicating early ‘red flags’.

And then hold the group accountable to see through the results of the decision into a tangible deliverable.

10. ATAM Phase 3 and Conclusion

 

Purpose: Follow up. This phase is conducted after the conclusion of the ATAM evaluation.

Phase 3 Step 1: Produce the Final Report

Purpose: To write the final report.

Evaluators will write the final report that summarizes the entire ATAM evaluation.

Phase 3 Step 2: Hold the Post Mortem Meeting

Team members fill out

• Evaluation team post-exercise survey
• Method improvement survey
• Evaluation team post-exercise effort survey

Team leader arranges and facilitates meeting and

• Collects process observer’s report
• Collects effort data

 

Phase 3 Step 3: Build Portfolio and Update Artifact Repository

Six months after the evaluation the team leader arranges for the customer to complete the long-term benefit survey.

Conclusion

ATAM is a stakeholder-oriented cross-functional team facilitated architectural review process that results in Risk Themes. Founded on Quality Attributes, Tradeoffs, Sensitivity Points and Risks this process is a proven repeatable method of evaluating software architectures. This process and it’s templates should be customized.

9. ATAM Phase 2

ATAM Phase 2

Bring the producers and consumers together to ensure that there are no discrepancies.

Write Risk Themes early at least start risk themes documentations early – and try to stick to 5. Not all risks map to a theme, there can be some outliers. The following are two groups of activities in Phase 2:

1. Testing – involves checking the results to date against the needs of all relevant stakeholders

2. Reporting –involves presenting the results of the ATAM

Phase 2 involves bottom-up information gathering and analysis.

- Consumers of the system

o End users

o Application builder

o External entities

- Servicers of the system

o System Admin

o Network Admin

o Maintainers

Review Step 1 -6 with the Phase 2 group. Why? This helps Step 7 because these materials are useful in brainstorming. Do not constrain the group, and changes can be made to the utility tree and other artifacts.

Note: Ask for any documentation (architecture) that was requested in Phase 1. Do accept new documentation created “just for Phase 2”. Just a new view, ensure that existing views are not changed/upgraded or modifying the architecture.

Risk Theme

A risk theme is a summarization of multiple similar risks discovered during the analysis of qualified attribute scenarios.

The point out bigger issues in the architecture and are

- Either Commission – i.e. multiple questionable decisions made in the architecture

- Or Omission – i.e. decisions NOT made or requirements not included in the architecture

E.g. Risk Theme: “There is no holistic approach to resource management…” Impacts Business Goals: “Cost, time-to-market, ability to compete with competitors”.