Why Architects MUST Code | Gregor Hohpe On Types Of Architecture & Their Importance
HTML-код
- Опубликовано: 3 авг 2024
- There are 3 types of software architecture. What are they, and which is the one you should be using? Gregor Hohpe talks to Dave Farley about software architecture and its importance in modern software engineering.
This is a clip taken from Gregor's FULL episode that you can watch HERE ➡️ • Gregor Hohpe On How So...
-------------------------------------------------------------------------------------
⭐ PATREON:
Join the Continuous Delivery community at access extra perks & content, join in our CD Discord discussions and support the CD RUclips channel.
JOIN HERE ➡️ bit.ly/ContinuousDeliveryPatreon
--------------------------------------------------------------------------------------
🔗 Reverse Engineering the Organisation ➡️ / reverse-engineering-or...
🔗 The Architect Elevator ➡️ architectelevator.com
🔗 Good abstractions are obvious but difficult to find, even in the cloud ➡️ architectelevator.com/cloud/a...
🔗 Think Like An Architect, Part 1: Famous Architects Sketch ➡️ architectelevator.com/archite...
🔗 Diving into the serverless engine room: ➡️ enterpriseintegrationpatterns...
🔗 Gregor's Books: Architecture, Cloud, and More ➡️ architectelevator.com/book/
🔗 Debugging Architects: ➡️ architectelevator.com/transfo...
-------------------------------------------------------------------------------------
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: ➡️ bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-------------------------------------------------------------------------------------
📚BOOKS:
📖 The Software Architect’s Elevator, Gregor Hohpe ➡️ amzn.to/3IEMf5o
📖 Enterprise Integration Patterns - Vol 2, Gregor Hohpe ➡️ amzn.to/3IStNr9
📖 37 Things One Architect Knows About IT Transformation: A Chief Architect's Journey, Gregor Hohpe ➡️ amzn.to/3m6eFgP
📖 Cloud Strategy: A Decision-based Approach to Successful Cloud Migration, Gregor Hohpe ➡️ amzn.to/3KJJRNn
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here
➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
-------------------------------------------------------------------------------------
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
_______________________________________________________ 
Наука
Programmers deal with putting something together that works. Apparently architects try to design systems that will ALSO withstand changes of various kinds, like upgrades, added features, changed implementations due to technology changes, maintenance by other people, etc. And to some extent there is design intended to deliver soon and repeatedly as a product is being completed, changed, or added to during the initial production cycle.
Software architecture today means a lot different than 5-10 years ago as well. Today Software architecture should include cloud and infrastructure architecture as well.
Not all types of software though, right?
I understand why you might want to include infrastructure or cloud in there but those are implementations. They themselves are not the architecture. Architecture will define how you use all these different parts and different implementations to leverage to a better product.
By the way as successful as the uptake to the cloud has been, it is all so entrenched. Certain people in Industry who do not trust running things on somebody else's hardware, especially when they hear about breeches all the time. But the reality is, for most people, the budget and scale necessary to provide the kinds of security and protection around some business systems is probably well beyond the budget for the hardware or the software that many teams have. But its not just the licenses, its the people to build, and maintain those integrations (which by the way the people is the part that I think the people forget to think about) a lot of these systems when architected don't just require Hardware or paying for services, it requires people to be able to Monitor and maintain it as well as to build new things to it.
The funniest business article I read in the 90s was a suggestion that all companies would become software companies but it really is true. Because it's your company without software how do you interact with the world anymore everything is computerized or connected to the web
As a chief arch in fortune 5 I've hired countless architects at many levels. The best have always been the ones who started in coding with the very best those who could still code some. Ironically some of the worst archs I've hired were those who were deemed 'rock star' coders.
hmm so a modern Architect is not the one to be the smartest (decision maker) in the room but the one who makes people smarter by providing different perspectives that could potentially refine the outcomes of decisions taken by the smartest people in the room.
I think that is a reasonable summary, though I'd probably describe it a bit differently. SW dev at any scale is a team sport. A team needs a variety of different skills and expertise, and these are rarely embodied in one person. So you need architects to bring one perspective and others to bring others. Together, they are greater than the sum of their parts.
I totally agree.
Designing on the fly - which is reality for me, blurs the architecture/engineering roles.
Or maybe that's the opposite. Maybe we tried to draw a line to create two distinct jobs/positions, where there once was only one job : developer. To me, a great developer should be able to re-design on the fly.
Interesting topics, thank you so much for sharing your thoughts and running this channel. Too bad that the audio levels/quality sometimes makes me jump off my chair. It's hard to hear what Gregor is saying too sometimes. Apart from the audio kudos to you my friend !
💯 big parts of [good] arch role is 1) people leadership / selling best engine room ideas to board room, 2) living in 1st derivative (first integral really... it's arch's job to account for the foreseeable perturbations in delivery i.e., the 1st derivative)
Postmortems like "the ____ impl rotted too quickly", "we planned to use ___ after PoC but didn't", "adoption was slow"... are all rate problems that are best solved in arch, not delivery
And many ARE foreseeable. An arch, I kick myself everytime an "I told you so" or "because of course it did" event occurs because (like a sports team mgr) could have should have been solved in the integral fn
Also love the analogy because trivial factors, like constants, drop out in delivery. It's the system dynamics that need to be dutifully scrutinized when arch has the football
I think it will be more important but with that said in a big enterprise company with lot of diffrent busniess stakeholders, complex enviroments time smiply are not there to be more technical day to day coding thats my experience
Then it's being done wrong
@@KrisBotha agree with that but a reality in many cases
@@GangetFans true I see a lot of examples myself 😬
Differentiate Architecture from Architect 👌🏽
Architect: should be simple to do this task!! Cmon developers!! It's an engineering problem! Actual engineers spending hours because its not actually simple because they're so disconnected.
When I hear "simple" or "just" it means either the person is an author of "this" or he/she has no clue what it's all about.
It should not happen, because, as stated in the interview, an architect should code!
Often this is a result of not understanding the Harry Collins book on tacit and explicit knowledge. A lot gets communicated in these meetings and a lot gets defined as stuff gets built but the problem is when you reach a point when it's not obvious what you should do next. Some people think Architects should figure that stuff out before its run into but work sometimes just tends to emerge
Vitrivius.
If no architect is in the team, a framework must be used at least... if there's an architect, then free flight is enabled and software can be designed.
No software design means no product, nothing... a pile of code that happens to do something somehow
I don't think that software design is *only* the province of architects, unless we consider all developers to also be architects. Architecture is part of a continuum of design that ultimately included every line of code that is written, and chosen over some alternative line.
If architects must code do they have to do pair programming? That's Dave's agenda.
If pair programming is beneficial, why not require pair architecture too?
There is no "must" for pair programming, but I would certainly argue that it is extremely beneficial particularly for architects. I also quite like pair-architecting as well as pair-programming. 😉
Architect is such a silly title in software. Applying reasoning and design to a problem, I mean that's the job of any good coder 🤔😂
If you've worked with many coders, you could probably understand why the role is necessary. Unless of course, you yourself, couldn't recognize the difference.
@@xianftw4806 I'm living in Germany where most coders have a masters degree. Everyone has the education to develop good designs while coding. So yeah, it's another approach to working 😂
@@marcotroster8247 The world isn't full of German coding masters - but you already knew that.