2 thoughts on “The Architect’s Dilemma

  1. Congratulations on the database schema!
    Since you expressed some doubt over how informative this podcast was:
    I think you shared some valuable insights here, also it did deal a whole lot with “the softer side of software development” (for example getting product management on your side to be able to push your design through).
    Although I do agree that data should be the single most important part of your design (it is the hardest to change), I think every programmer faces the Architect’s Dilemma to some extent.
    I think the crux of the issue lies in finding the balance between future extensibility, flexibility and the immediate concrete goals of the program / framework / library.
    In my limited experience any modular design is a good start, and usually you have to go through a couple of extensions and refactor the interface a bit 🙂 But that’s just from a non-architect grunt.

  2. Wrapping things up:
    The architect’s dilemma: when a software architect’s long-term strategy is at odds with the executive’s short-term strategy.
    Executives want short and predictable results, whereas architects bring long and unpredictable results.
    ➔ Their value is hidden.
    Executives are often very pragmatic people. They can only be persuaded by strong logical arguments.
    ➔ Never disagree with an executive in public (meetings…). Get a one-to-one conversation with them.
    Creating a good software architecture:
    – Model a domain (Domain-Driven Design by Eric Evans).
    – Implement (with Design Patterns).
    – Reach design stamina (Design Stamina Hypothesis by Martin Fowler).
    ➔ An architect needs to be able to build and tear down MVPs as fast as possible.
    An architect needs to understand the client, but more importantly, the BUSINESS.
    ➔ Make relationships with business people (executives, salesmen…), and get along with the product manager.
    The most critical parts for an architect are the ones that are the least likely to change.
    ➔ The database is the top of the pyramid, and the most critical part to design. Refactor a database is pure hell.
    ➔ The Presentation layer is the bottom of the pyramid, and shouldn’t deserve as much attention. It changes constantly and is easy to refactor.
    Tip to judge the quality of your design: sleep on it, and if you can’t refactor it in the morning, it’s all good.

    Great episode as always. Also, I would agree with Peter concerning the direction you want this podcast to be (technical or not). To me, you already have the perfect balance because you express how soft skills help you achieve your goals as an architect. The bridge between the two is very clear.
    The perfect juxtaposition of this episode would be the one on Planting Seeds, which is mostly non-technical, but you incorporated elements of software architecture because it is necessary to explain the subject.

Add your thoughts