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.