DGAF Architecture Framework

Mission Statement

"Building systems that matter, while avoiding the pitfalls of overthinking, over-planning, and unnecessary stress. Focus on what’s important, leave the rest to be figured out when necessary."

Core Principles of DGAF

• Pragmatism Over Perfection: Aim for a solution that works right now without worrying about future-proofing for every possible edge case. DGAF Rule: "If it works and nobody's crying, it’s good enough."
• Simplify, Always: Over-engineering is the enemy. Stick to solutions that can be explained in a sentence, or better yet, a meme. DGAF Rule: "Why build a rocket ship when a skateboard will get you there?"
• Fail Fast, Learn Faster: Mistakes are not only acceptable but encouraged, as long as you learn and adapt quickly. DGAF Rule: "It’s fine, you can fix it in production."
• Documentation Is For Boring Days: Focus on building; documenting can happen when you're feeling extra responsible or when someone actually asks for it. DGAF Rule: "If no one asks for documentation, it probably doesn’t need to exist."
• Collaboration Without Meetings: Communicate through action and shared tools, not endless meetings or needless bureaucracy. DGAF Rule: "If it takes more than two emails, you’re doing it wrong."
• Refactor When It Hurts: Don’t fix what isn’t broken. Refactor only when it's causing actual pain (or if you’re bored). DGAF Rule: "Let’s deal with that in version 2.0."
• Prioritize Developer Happiness: A happy team builds better systems. Sacrificing well-being for architecture purity isn't worth it. DGAF Rule: "If it’s too stressful, it’s probably the wrong solution."

DGAF Approach to Architecture Phases

• Vision: "What do we really need to do?"
  DGAF Principle: Focus on the minimum requirements. Dream big, but build small.
• Design: "What’s the simplest way we can do this and still be proud?"
  DGAF Principle: Don't design an empire if a single page of notes gets the idea across.
• Implementation: "Let’s get this thing live and see what breaks."
  DGAF Principle: Roll it out, watch the chaos, and fix things when they explode (but ideally before).
• Maintenance: "We’ll handle that after the coffee kicks in."
  DGAF Principle: Handle critical issues promptly, but don't sweat the small stuff.
• Iteration: "Version 1 is just the beginning...or the end. Whatever works."
  DGAF Principle: If users aren’t screaming, it’s fine to leave things as they are.

Roles in the DGAF Framework

• The Architect: The person who guides the team by simplifying and cutting through the noise, while occasionally stepping in to fix things when absolutely necessary.
  Mantra: "What’s the least amount of architecture we can get away with?"
• The Developer: The heroes who take the simple plan and execute it in the fastest way possible, usually ignoring unnecessary details along the way.
  Mantra: "I can make that work, but it might involve duct tape."
• The Stakeholder: The person who thinks they care about the big picture but mostly just wants results.
  Mantra: "How soon can we get this live?"

DGAF Tools and Techniques

• DGAF Model Canvas: A visual planning tool with only three sections:
  • What’s the goal?
  • What’s the quickest way to reach it?
  • What can we ignore for now?
• The Duct-Tape Prototype: Skip wireframes and MVPs. Build something fast and dirty; if it works, clean it up later.
• The No-Worry Pipeline: CICD pipelines that focus on delivering code, not perfection. Just deploy it and watch for fires.