4 thoughts on “Architecture’s Relationship to Business Outcomes

  1. Ah, sorry I messed it up! You were right the first time: hi as in ‘hi!’ (that’s what I meant by hello). I feel embarrassed now 😀 Everything else was spot on

    • It’s no problem at all! You got me 99% of the way there, with is infinitely farther than I could have done without your help.

  2. As I said, dropping my notes here. Not sure I’ll do this every time, but I’ve been waiting for this episode, so there you go!

    Why is software architecture important?
    2 ingredients of a startup:
    – Product (innovation)
    – Customer (marketing)
    Product Market Fit (PMF): creating a product that responds perfectly to the needs of the client.
    Software architecture (SA) is the way to orient the creation of the product toward PMF, and implementation is only the way to reach it.

    How to make a good architecture?
    3 mandatory ingredients:
    – Design patterns.
    – Layering.
    – Scenarios.
    Benefits of SA:
    – Better orientation toward PMF.
    – Less maintenance: the code becomes less resistant to changes.
    An architecture needs the right level of abstraction:
    – Too high: doesn’t guide the implementation enough.
    – Too low: destined to be wrong, because they are things we only realize during the implementation.

    The issue with agile.
    Agile and iterative processes only deal with what the customer needs at the moment, without thinking about what he might need in the future.
    This reduces risks, but also the chances to reach PMF because the customer generally doesn’t know exactly what he needs.

    Why big companies can’t achieve PMF?
    1. Risk aversion politic: leads to short term actions for short term outcomes. This is a reason why agile is so popular.
    2. Paper architects: software architects only in their title and salary. They have no clue how to design a product that will reach PMF.
    To detect a paper architect, ask him about design patterns and complexity (the Onion Test).

    Applicable advice for a company to lead a product to PMF
    2 key persons who will be able to orient the product toward the customer:
    – A product manager.
    – A lead architect.
    They will reproduce the CEO/CTO relationship we find in startups.
    Action plan
    1. Hire a (real) software architect for a mission.
    2. Let him choose his own team (devs, QA…) because he can’t work correctly with an implementation team he can’t trust.
    3. Make the architect and product manager work very close to each other.
    Propose an all or nothing deal to the architect:
    – If he succeeds, give him A LOT of money.
    – If he fails, fire him and his team, and start all over again.
    With such a deal, only the best architect who knows they can do it will apply.

    A few questions:
    – Don’t you think UML is a too low-level representation of an architecture? And if yes, what do you use instead?
    – Don’t you think the lead designer is almost as important as the lead architect since he plays a major role to orient the product toward PMF as well?
    – I’d be super interested to know about the book you’ve read, gotta buy them all ^^

    • First, your summary is amazing! Thank you so much for doing this – there’s definitely no pressure or expectation that you do this in the future, but it is greatly appreciated! I have to admit, I do seem smarter in summary than I do when I ramble on for 2 hours.

      Second, to answer your questions:

      – Yes, UML is too low-level for architecture by it’s design, but it’s invaluable for diagraming implementations. I hold the belief that a very-big implementation diagram (the true definition of Big Design Up Front, IMO) is not an architecture diagram, but wishful thinking. I have a background in graphic design, so I create my architecture diagrams in Microsoft Visio, and tailor the diagrams to the system, the audience, and the specific parts that are most difficult to convey in conversation. Here’s an example of an architecture diagram I made for one part of the software project simulation game I’m planning to release next year. I made it for myself simply because I needed to visualize what I needed to code before I coded it:


      – Yes, the lead designers role is just as important if not more so that that of the lead architect. Here is the design for the game that relates to my architecture diagram:


      – These are the books that I found most helpful near the start of my career, but don’t know if they’re still the best books to read today:

      Clean Code – Bob Martin

      Design Patterns – Gamma, Helm, Johnson, and Vlissides

      UML Distilled – Martin Fowler

      Refactoring – Martin Fowler

      Extreme Programming Explained – Kent Beck

      Test-Driven Development: By Example – Kent Beck

      Patterns of Enterprise Application Architecture – Martin Fowler

      Domain-Driven Design – Eric Evans

      Working Effectively with Legacy Code – Michael Feathers

      Enterprise Integration Patterns – Hohpe and Woolf

Add your thoughts