The Simple DevOps Value Framework: Why Business Beats Architecture

Nicole Forsgren’s talk at DORA highlighted the provocative line “Architecture matters…Technology doesn’t,” which inspired a reflection on the relationship between business, architecture, and technology in DevOps.

Business, Architecture, Technology (BAT)

From a DevOps perspective, three dimensions—business, architecture, and technology—form the core of decision‑making. The author proposes a simple mnemonic, BAT, and illustrates it with a diagram.

Business matters...Architecture doesn’t

Architecture matters...Technology doesn’t

For startups with unclear business direction, the advice is to start with a monolithic application and only adopt microservices when the business becomes stable enough to justify the added complexity.

Microservice adoption carries both clear benefits and challenges; Martin Fowler’s diagram (shown below) captures this trade‑off.

Economic analogies are used to explain architectural investment: just as a down‑payment on a house represents initial architectural effort, loans represent technical debt that must be repaid over time. Excessive debt harms speed and opportunity cost, while a balanced, expandable architecture supports rapid iteration.

People, Process, Tools

The classic “People‑Process‑Tool” (PPT) model is presented, emphasizing that people are the most critical factor, followed by process, then tools.

People matters...Process doesn’t

Process matters...Tool doesn’t

Examples such as Google’s three‑language strategy (C/C++, Python, Java) and Etsy’s migration from MongoDB back to MySQL illustrate how unified technology stacks can improve communication and reduce maintenance overhead.

Tool selection alone does not guarantee DevOps success; the way tools are applied within processes, and the mindset of the people using them, are decisive.

Principle, Method, Practice (PMP)

The author introduces the PMP triad, arguing that principles (the “why”) guide methods (the “how”), which are realized through practice (the “what”).

Principle matters...Method doesn’t

Method matters...Practice doesn’t

Agile frameworks (Scrum, Kanban, SAFe) share underlying principles despite surface differences. The article stresses that without a solid principle foundation, methods become fragile and practices lose direction.

Conclusion

The nine elements—business, architecture, technology, people, process, tools, principle, method, practice—are interdependent and must be considered together. A pragmatic, economically‑aware approach to architecture, combined with unified stacks and a strong cultural mindset, enables startups to deliver value quickly while keeping technical debt manageable.