How to Become a Great Software Architect • Eberhard Wolff • GOTO 2019

  • Published on Feb 18, 2020
  • This presentation was recorded at GOTO Berlin 2019.
    Eberhard Wolff - Prolific Author of all Things Architecture. Working for 15+ years as an Architect & Consultant
    Software architecture is very simple: You only have to split up one system and use modern approaches such as DDD or Microservices. This presentation shows completely different qualifications that a good software architect must have.
    The focus is on the technical decisions that an architect has to make, how to best deal with such decisions and how to find out on what basis decisions can be made. And because software projects always take place in a team, soft skills and teamwork [...]
    Download slides and read the full abstract here:
    Eberhard Wolff & Hanna Prinz • Service Mesh •
    Eberhard Wolff • Microservices Book •
    Eberhard Wolff • Microservices - A Practical Guide •

    Looking for a unique learning experience?
    Attend the next GOTO Conference near you! Get your ticket at
    SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
  • Science & TechnologyScience & Technology

Comments • 41

  • kingscrusher
    kingscrusher 2 years ago +24

    Having revisited this video - everything in it makes absolute sense. It comes down to solving the problems and knowing the quality priorities.This is arguable THE BEST video on software architecture going on GOTO. Also the Pandemic example is particularly relevant now - and it is a collaborative game we have to play now. Great stuff and many thanks. I did not truly get it the first time on going through this video - but it makes absolutely great sense now. Cheers, K

  • Tobias Wörenkämper
    Tobias Wörenkämper Year ago +24

    "Solutions must solve problems." Love it.

  • Brandon Pearman
    Brandon Pearman 6 months ago +6

    "Puts enormous pressure of the architect" Most companies I've seen, the architect is an ivory tower god which forces decisions on the team but then takes little to no responsibility for them. Its the devs which must wake up in the middle of the night when the system falls over. Its the devs which must explain to business why they take so long to implement a simple feature on an over engineered system.

  • George Smith
    George Smith 6 months ago

    Great video (upvoted). Only for this part @16:20 to 16:30 - I disagree that usability should drive scalability. The system should be inherently scalable, independent of what the UI components look like or how they interact with each other to make the system more usable. Ultimately, if the system does not scale well at specific loads, it will NOT be usable at those load levels as well :).

  • George Smith
    George Smith 6 months ago

    Completely agree that an architect is someone who creates/designs software architectures. This person could be a developer but could also be a former system administrator - the latter is the common case in cloud environments when we talk about infrastructure.
    However, in both cases, there are clearly architectural tasks vs. coding and system administration tasks. If you perform the former you are fulfilling the architect role. If you perform the latter, you are fulfilling the engineering role.

  • Amit Lokare
    Amit Lokare 5 months ago +2

    Very nicely articulated here by the speaker. Lot of things are clear now

  • Petroleum Blockchain

    Traditionnal VS Modern architecture is such a caricature. Anyway. Seems this presentation is kind of making the architect to fit the existing organizations. But that's a too low level approach, and as such, it won't solve any problem, but ease the existing one, no matter if the problems are or not softer. Fact is: Dev team need an architect to get their app to fit the ecosystem of the organization. The want the perimeter (interfacing with business, the eco-system and so) into which they can play. Someone has to take this decision, and it is the architect. Without an architect, there might be endless debate accross the team. The output of the architect is the input of the dev team. And the interaction between the architect and the dev team must be scoped to the architecture understanding. Then only, if the architect can have an added value in lower details of the architure, then up to the team to get such discussion. At the moment the architect enter in the are of the dev team outside this scope, its a problem: Dev teams are specialized team, and must be cosidered as such.

  • George Smith
    George Smith 6 months ago

    Also, I would say internationalization is a feature, not so much a quality of a system. One could make an argument that it affects usability because if you cannot easily translate the interfaces, then the system will not be as usable to people of particular language background. This feature, however, has no bearing on the technical qualities of the system - the system would perform in the same way in English as it would German :).

  • Code Coffee
    Code Coffee 5 months ago +1

    Wonderful presentation.

  • George Smith
    George Smith 6 months ago +1

    Should architects code? How many times have you seen a coach go on the field to play soccer with the team? I will tell you - every time during practice, as long as his/her health allows - in the US soccer is more a women's sport :). So, to connect here with Eberhard, architects should code but only to demonstrate best practice, or to implement components that are very critical to implement and hard and/or time consuming to describe. Going back to the soccer metaphor, a real match is equivalent to the code going in production. The training session code something that goes into CI/CD pipeline that is preferably part of a POC :).
    And by the way, difficult components, in my experience, are the ones that encapsulate complex integrations with 3rd party systems. If you integrate with internal systems, the patterns should be very clear and the tools should be readily available - this is usually the case in big software companies. However, when you integrate with external systems, you need and architect to read that system's documentation, consult other architects and relevant business stakeholders, and then figure out what the best and/or most realistic approach is to integrate the systems. Budget and time also get to play a role, not just technical suitability and best fit :).

  • Miggleness
    Miggleness 2 years ago +23

    Eberhard: "i dont think that such a team exists"
    Experience: "yes they do, and you're right it is sad"

  • Demet Tuncer
    Demet Tuncer 2 years ago +2

    I did not plan to become one :) It happened and in Berlin, it happened %) I hope TUB makes 'things' out of my epistemological jump and its epistemological launch both as soft and hardware.

  • Adil ALLACH
    Adil ALLACH 4 months ago +1

    Great presentation

  • Ville Witt
    Ville Witt 2 years ago +3

    This is the first place I've heard about the board game Pandemic. I just ordered it. Speaking of Zeitgeist! Oh, and team-building.

  • Šime Tokić
    Šime Tokić 2 years ago +1

    Great talk!

  • julian ramirez
    julian ramirez Year ago +1

    Thanks a lot.

  • George Smith
    George Smith 6 months ago

    Agile does not mean the architect enforce decisions. The architect and should enforce design decisions and leave implementation decisions to the team, so long as the implementation decisions do NOT negatively affect the design. I've done this in practice and works beautifully. And it does not require specific expertise, e.g. if I am not a NodeJS expert, I can still design the components and how they should behave, including their quality attributes. However, I will not and should not enforce which caching library or which circuit-breaker library the developers should use. They should use the one they are comfortable with, as long as that not affect negatively the circuit-breaker pattern because of library deficiencies => affects availability, recoverability, and generally the quality of the system as a whole.

  • Cyril
    Cyril Year ago +1

    I liked it but didn't really get the conclusion that the modern architect shouldn't code. Lets say there is a self organized team of 6 people. How are you supposed to fill up your time only with architecture and no coding? Sure at the beginning there will be many decisions and 'architecture stuff' but it levels of as the project progesses. Or what scale are we talking about? Team of 50 people?

    • Rambo
      Rambo 7 months ago

      Certainly there should not be a rule banning somebody from stepping into the most interesting phase of software development - coding. An architect who is hands on understands the pain a lot better than the other guy

  • Amaury Fages
    Amaury Fages 9 months ago +1

    If "Architect" doesn't code, he's a Solution Architect or an Entreprise Architect. Software Architects do code obviously. Solution and Entreprise are "Modern Architects" and basically you can replace the word with "Manager/Leader 5.0 with Technical knowledge". I'm both of the roles depending of the context, Harvard Management certified and most of my time is communicating with teams, coaching, helping them decide and also doing business/selling stuff and powerpoints, of course a good architect is a good powerpointER !(:))

  • Joel Mamedov
    Joel Mamedov 2 years ago +8

    An Architect is primarily a bridging role between business (those that wants everything quick and not to pay for it) and IT (those that show up at work in their pajamas).
    In other words, an architect is an adult in the room that is responsible for creating a solid bridge that two-way and congested traffic can flow over it.
    Wearing a tie could help.

    • Van Hoa Phan
      Van Hoa Phan 2 years ago +4

      if you think Architect is the adult in the room, you'r cute. Very cute.

    • Eve Graumann
      Eve Graumann 2 years ago +3

      according to that definition, every proper software engineer is also an architect.

  • Nzechi Nwaokoro
    Nzechi Nwaokoro Year ago +28

    33:50 starts talking about pandemic not know what was in store the following month

    • n_s_
      n_s_ 3 months ago

      I had to check the conference date once again

    • magnus v
      magnus v 8 months ago

      Yeah, that was a bit eerie.

  • Shreedhar Kc
    Shreedhar Kc 3 months ago +1

    Wow pandemic game! It a real life game now isn’t it?

  • José Isary Muñoz Reynoso

    It seems as team software manager. The talk didn't mention nothing about, boundaries an component's policies

  • Ait Acine dev
    Ait Acine dev 8 days ago

    is nodejs developper can follow this way of architect ??

  • madhur dixit
    madhur dixit Year ago +3

    reference to pandemic in 2019 :O

  • Loki49th
    Loki49th 2 years ago +5

    "How to know in advance?": Well, if you know what you are doing you should have a basic idea of the pros and cons and how hard it would be to change it to sth. else?!
    So the definition, which is supposed to be better than Fowlers and it is basically "Find solutions for problems, (oh I missed 'technical')"?
    One of the worst goto talks I have seen but proably the title of the video is misleading.

  • B D
    B D 8 months ago

    I marvel at bilingualism like his

  • Francisco YouTube
    Francisco YouTube 2 years ago +11

    Start here 42:16

    • Joules K
      Joules K Year ago

      Play reverse like you read your books. (Not supported by human-central YT)

  • Alessandro B. G.
    Alessandro B. G. Year ago +5

    This lecture is boring

  • Hans Vetter
    Hans Vetter 2 months ago

    Useless bla bla !

  • Jeff Childers
    Jeff Childers 2 years ago +2

    woot this type of guy IS what is wrong with programming as a profession. His opinion is just that.... dropping Fowlers name doesn't make it less of a strawman argument.

    • c0okiemon5ter
      c0okiemon5ter Year ago +1

      @maccrazyg5 @postblitz he said it; the architect has to "grow the team".

    • maccrazyg5
      maccrazyg5 2 years ago +6

      @postblitz I believe part of the role unfortunately, is getting teammates on board with your initiatives, which is a frustrating soft skill requirement but nonetheless a key to success.

    • postblitz
      postblitz 2 years ago +4

      ​@Merlijn Boogerd The technical considerations for the product are alright. The self-organizing dogma is completely false because it is shouldered upon some VERY broad assumptions about the team, its make-up and the quality of the communication involved. It assumes "we don't need no know-it-all architect" or "enforcing ideas" because the team is capable of somewhat-obiective, selfless and grounded discussion coupled with a healthy dose of humility, patience and all the good virtues which enable people to discuss a problem & hear everybody out.
      The reality is that a team can be composed of less-experienced people along with people who are experts at emotionally manipulating people with their less-than-sound or obviously-biased judgements. An experienced DBA will argue in favor of DB-centered decisions which will lead to a DB-centered architecture which the younger, less experienced or less-well-argumented people in the team will be unable to counter-argument for. Conflicts are perceived as toxic, regardless of their informational value because the emotional component and "being a team-player" will always be a priority in such a context. It's a recipe for disaster and relies heavily on the initial work HR/PMs puts together to form the right team.
      Having a traditional architect with traditionally enforced steps removes much of this overhead and can often lead to better results. It's all about how much you can trust that team to pull something off. A team of slackers and job-security-focused individuals do nothing for your company - though they will obviously have a good time, especially with internal projects which never see the light of day.
      tl;dr: Contrary to theory, in real life not all people have the best in mind for the project or organization. They want the minimal amount of work for the maximum amount of pay, promotions, days off, perks etc.

    • Merlijn Boogerd
      Merlijn Boogerd 2 years ago +2

      Respectfully, that's quite a leap to how I perceived this video. Do you care to elaborate on the statement that his "type" is the cause for things going poorly in software development?
      Some of the main points I took away from this video: Understand the business problem; Make your understanding of the problems measurable; Solve business critical problems first instead of technical ones; Have realistic expectations regarding your own capabilities; Delegate decision-making to the experts when appropriate; Work with them and facilitate alignment between teams; Take your time to reflect on costly decisions before you make them.
      I don't think any of these are particularly contentious statements; at least not to the point that you ought to do the exact opposite?