How to Become a Great Software Architect • Eberhard Wolff • GOTO 2019
Вставка
- Опубліковано 18 лют 2020
- This presentation was recorded at GOTO Berlin 2019. #GOTOcon #GOTOber
gotober.com
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:
gotober.com/2019/sessions/854...
RECOMMENDED BOOKS
Eberhard Wolff & Hanna Prinz • Service Mesh • leanpub.com/service-mesh-primer
Eberhard Wolff • Microservices Book • microservices-book.com
Eberhard Wolff • Microservices - A Practical Guide • practical-microservices.com
/ gotober
/ goto-
/ gotoconferences
#SoftwareArchitecture #SoftSkills #Teamwork
Looking for a unique learning experience?
Attend the next GOTO Conference near you! Get your ticket at gotocon.com
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ua-cam.com/users/GotoConf... - Наука та технологія
"Solutions must solve problems." Love it.
That's the very definition of a solution..
42:10 "Don't be afraid to make decisions with unclear information", I needed this hear. Great tips, thanks!
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
"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.
eh, ive at Cerner they were senior software devs with a significant grasp of the environment, the day to day code and the integration
they were the people who could see problems in the designs that would hit a hard reauirement or not be scalable or other key problems
they were required with difining all interfaces, all requirements for deliverables between major modules and programming any significantly difficult pieces
most of them now leads at faang, they were great.
@@ravenecho2410 Yeah so the devs are responsible. There is a point where Senior devs move off the team into an architect position and they still know the code back to front and need to guide the new devs but over time they will probably lose touch with the code base(unless its a very small company or each architect has a very narrow responsibility, then they could keep up with the changing code base)
Exactly, I left a organisation just because architect didn't know what he was enforcing and most of solutions went south.
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.
Very nicely articulated here by the speaker. Lot of things are clear now
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
i used to listen some talks without watching it. this one i need to watch it closely!
33:50 starts talking about pandemic not know what was in store the following month
Yeah, that was a bit eerie.
I had to check the conference date once again
Very informative and clear on software architects role, responsibilities and decision-making.
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.
Eberhard: "i dont think that such a team exists"
Experience: "yes they do, and you're right it is sad"
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 :).
This is the first place I've heard about the board game Pandemic. I just ordered it. Speaking of Zeitgeist! Oh, and team-building.
Really liked this talk, thank you
17:50 " We want to modify the system without modifying the code "
How can this be possible ? Can someone give me an example please ?
Plug and play with the modules, switch on or off using configuration or admin panel
What if an "Architecture" is implemented by a collaboration of 10 teams? What does a "Modern software architect" do in this case?
Great talk!. Wonderful presentation..
Wonderful presentation.
It seems as team software manager. The talk didn't mention nothing about, boundaries an component's policies
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.
Thanks a lot.
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 :).
Thanks for sharing
Great presentation
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?
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
Wow pandemic game! It a real life game now isn’t it?
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.
Great talk!
reference to pandemic in 2019 :O
is nodejs developper can follow this way of architect ??
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 !(:))
Thx. So an architect is simply a soccer coach
Nice game "pandemic" 😀 on 2019
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.
Ma'am could you share some tips for an aspirant.
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 :).
Start here 42:16
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.
according to that definition, every proper software engineer is also an architect.
if you think Architect is the adult in the room, you'r cute. Very cute.
"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.
Really? Does anybody knows who is this guy? Any background except some books? What great software he really have developed as an architect?
The industry still doesn't have great architects, it even doesn't know what the software architect is. Have we had great architects, we would have at least good software. We don't, yet.
I really love this world where everybody can teach others how to become "great! software!! architect!!!" even not being such a person.
About the lecture itself, don't waste your time. Seek for the lectures from O'Relly on software architecture where real people speak about real problems, not about theory.
Useless bla bla !
it interesting how this talk might resonate with some yet some may think it is useless.. i think it all depends on where you are in the journey.. it will make sense.. eventually..
This lecture is boring
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.
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?
@@mr-boo 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.
@@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.
@@maccrazyg5 @postblitz he said it; the architect has to "grow the team".
No. Just no.