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

preview_player
Показать описание
This presentation was recorded at GOTO Berlin 2019. #GOTOcon #GOTOber

Eberhard Wolff - Prolific Author of all Things Architecture. Working for 15+ years as an Architect & Consultant

ABSTRACT
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:

RECOMMENDED BOOKS

#SoftwareArchitecture #SoftSkills #Teamwork

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
Рекомендации по теме
Комментарии
Автор

"Solutions must solve problems." Love it.

tobwoerk
Автор

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

kingscrusher
Автор

42:10 "Don't be afraid to make decisions with unclear information", I needed this hear. Great tips, thanks!

pratikrane
Автор

"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.

brandonpearman
Автор

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

AmitLokare_
Автор

i used to listen some talks without watching it. this one i need to watch it closely!

faisalmorensya
Автор

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.

georgesmith
Автор

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

Miggleness
Автор

Very informative and clear on software architects role, responsibilities and decision-making.

santoshkrsahoo
Автор

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.

georgesmith
Автор

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

littech
Автор

I am software architect and i do the hard code if i should to do it. I refuse to do "productive" code, i mean my code is for the teams not for the customers. But i am the first to treat everything as code

RPereiraWRJ
Автор

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 :).

georgesmith
Автор

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

VilleWitt
Автор

IMO, one should separate Architecture and Architecture Description.

Every single system has or will have some Architecture (regardles whether we desribe it or not).
Architecture - the way how the system is made, it's just that.

The tricky part is the description of it, let's call it Architecture Description, that's what usually people mean when say "Architecture" and that's what has different shapes and colors.

For me, Architecture Description should capture everything significant from the system evolution perspective.
It can contain literally anything, there are no limits here. The only constraint is that the elements mentioned in the description should be important to know when trying to understand architecture or considering system evolution.

IMO, Architect should code and MUST get feedback on his decisions, for example, reviewing code which implements his solutions or/and talking to developers.

----------
Автор

What if an "Architecture" is implemented by a collaboration of 10 teams? What does a "Modern software architect" do in this case?

kishanbsh
Автор

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

JoseIsary
Автор

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?

cyril
Автор

17:50 " We want to modify the system without modifying the code "
How can this be possible ? Can someone give me an example please ?

samibenfadhl
Автор

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 !(:))

amauryfages