Gregor Hohpe On How Software Architects Transform Large Enterprises | The Engineering Room Ep. 15
Вставка
- Опубліковано 3 чер 2024
- Gregor Hohpe, author of "Enterprise Integration Patterns", talks to Dave Farley about software architecture and how architects can transform businesses. They chat about: Gregor's current role and work with AWS (Amazon Web Services), the challenge of finding new architectural models in the cloud, "Gregor's Law" AND MORE! Thanks to Gregor for joining Dave on this episode of the Engineering Room.
You can find more of Gregor's ideas and advice on his "Architect Elevator" blog, and his excellent books (see links below).
-------------------------------------------------------------------------------------
⭐ PATREON:
Join the Continuous Delivery community at access extra perks & content, join in our CD Discord discussions and support the CD UA-cam 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
_______________________________________________________
CHAPTERS
0:00 Welcome
0:29 Introducing Gregor Hohpe
1:55 Why is Architecture Important
4:53 Architecture as a Function, or a Role?
10:10 The Architect Elevator - Connecting Levels
14:40 3 Types of Architecture
16:40 Two Types of Change
19:30 Specialism v Global Optimisation
21:52 Tourist Maps not Blueprints
25:24 Platforms and Standardisation
29:45 Architectural Quanta and Abstraction
34:00 Operating Systems
36:08 Finding Meaningful Language for Cloud Architectures
40:40 Problems not Products
41:50 “It’s Too Academic”
43:00 From Automation to Innovation
46:20 Organisational Structure for IT
49:30 Engineering, Agile and Architecture
51:45 Gregor’s Law (Complexity, Constraints and Making Choices)
59:47 Keeping Options Open
1:02:20 Reduce the Cost of Being Wrong
1:08:00 Paradigm Shift is Hard (and can be risky!)
1:15:00 Finding New Models is the Fun Part!
1:16:30 Architects Should Debug!
1:20:30 Wrap Up - Наука та технологія
Greg is the person who has the biggest influence and motivation in my IT career, and Dave is hosting one of my favourite UA-cam channels. Thank you for setting this up, gentlemen!
My first professional coding project was an RS-232 driver written in Java for a RFID reader. The biggest thing I remember about it was the lack of unsigned byte in Java. Funny how these kinds of things change slightly but never really go away. I try to think about that experience in the context of what kind of challenges people are solving today that will be passe in 20 years, given the advancements in abstractions and everything.
I could picture an entry level programmer having to write something today using a platform or service but needs to be able to troubleshoot and learn how to figure out an esoteric bug with a library they are using, and having to navigate the back and forth of an issue report and patching it themselves.
That is the path towards that higher level of thinking that makes someone a capable architect or master engineer... Whatever we call it.
Thanks for the great conversation
Amazing discussion, Gregor rocks plain and simple. Lovely human being who thinks deeply and communicates clearly to everyone! What a joy to watch.
About "Meaningful language" and "Problems not Products": Great part of the discussion/video!
There are a number of layers of 'translations' needed from the business/user problem you need to solve (Problems), expressed in business and user terms, all the way down to the technical implementation (Product). Each layer has its vocabulary and proper mappings between the layers and vocabularies are needed.
It's much like Dependency Inversion this way. Describe *what* you want to do in one vocabulary (contracts/interfaces) and then choose *how* to implement that contract which may use an entirely different vocabulary. Delay that decision of implementation (don't worry yet that 'water' consists of two Hs and one O). Remove that complexity of actual implementation from the contract/interface.
Then dip into the implementations (and go back up) to validate the implementation.
Of course, don't go overboard. Don't over-engineer/over-design it with too many layers. Getting the balance right is an art :)
Great conversation between two people with a huge experience. Good for Sunday evening :)
No fluff, no bs. Love the content
Gregor said: "Any line of code that is not deployed is cost" so what about the code of unit tests then? I think many unit tests are useful but there are also unit tests that are not worth the cost of having them and we should delete them right? Especially we should delete many London style unit tests because those hard to understand unit tests are terrible for projects right?
I totally agree with Dave Farley that "quality in modern systems is our ability to change them". On the other hand London style unit tests use many mocks implemented by hacky mock libraries that are hard to understand and they easily break when changing the internal implementation despite the functionality remains the same. London style unit tests make the system much harder to change yet Dave still thinks London style unit tests are useful. What do you think?
If your software is of poor quality, it might not live long enough to benefit from the ability to change. So, tests are critically important. But I agree that tests should be as easy to change as your software. They should refactor with it (which, in most cases it can) and when needs change, you'd change the tests first.
@@architectelevator OMG are you the legendary Gregor Hohpe?
Thank you so much for setting this up !!
I believe we should increase the flexibility and complexity of design/architecture only when we really need it and never upfront.
Communicating architect's vision on how should we preceed managing complexity of a particular system is very hard. We may explore this more in the future.
What a great conversation. Thank you ❤️
Glad you enjoyed it!
Thank you very much for these very interesting interviews, the knowledge, experiences and perspectives that you "deliver" are reallly appreciated. Thanks!
Thanks 😎
You might even say he delivers continuously those interviews, knowledge and experiences.
@@davidhoppe7215 😁😎
I love the quote by Ralph Johnson: "Architecture is about the important stuff... whatever that is."
It’s funny and not wrong, but also not useful. I’ve always preferred Fred Brooks’s definition that architecture is “… designing to meet [users’] needs as effectively as possible within economic and technological constraints”. It’s all about making the tradeoffs that benefit users.
No other industry would allow such definitions. And IT shouldn't either.
A thought came through my mind a while ago and looks like true in most of the cases. As in Taoist philosophy yin and yang conjure each other, and these are opposing forces. My interpretation in software development context is: From restrictions comes freedom!
I usually say "constraint" rather than "restriction", but yes, I think that is very true.
It’s like when during an interview interviewers ask what AWS services are used for. And what is the bandwidth. And you’re like, “well, we needed postgres, we took postgres, we needed pubsub, we took pubsub, everything worked, no one seemed to complain.” So which AWS services did you choose for this project? And you’re like, “no idea, they’re mentioned by AWS name in two or three files out of a million in my project and few more times in my CV because it's fashionable and in most companies no one cares about it.”
Thank you so much. This is revolutionary
Glad you think so!
Yes there are several rugs that we should pull from programmers. One rug is trying to use TDD everywhere. The other is mocking everything outside the class under unit test and another rug is using mock libraries... I believe good unit tests are the next step in making system that are easy to change. Unfortunately right now 90% of programmers don't know how to write a good suite of good unit tests.
You should just admit you can not use these tools.
I see where this comes from and I've written (and in a way still have to) tests like that. This especially happens when you retrofit tests to existing code, don't hide enough detail or don't refactor.
I find myself writing tests that test more on a ceptual/behavioral level rather than ones that break with the slightest change in implementation when I go test first or interface first and refactor until I think the interface of the module is as simple as it gets.
I just watched a GOTO video by Gregor recently. He's got a great mind, and I appreciate the insight as it helps confirm that the thoughts I have regarding architecture and practices around it aren't my own new concepts but something we come to understand through the experience of learning.
Hi Dave, could you please, please, please upload episodes of The Engineering Room into some podcast platform?
Nice podcast here, but I struggle with the idea that nobody seems to know what architecture is. how can we start the discussion if there's no definition? It seems like there are ideas of what we want the term to mean, so we should start with those until we can isolate what is common to everybodys 'ideas', so that we can get a true definition, at that point we can start having the real conversation
What is a coffee mug? Does it need to have a handle? Is it made of ceramic? Is it still a mug when it holds half a liter or more? What if you only pour water in it?
Reality is often blurry but still we usually can talk about it quite well. We can ask for the cup and will be handed the mug (unless it's next to one without a handle, one made of glass and a tiny toy cup), right?
Good definitions are hard.
@@black-snow While it is true that good definitions are hard, I feel that your position here leaves us with nowhere to go. If it is impossible for us to define architecture in a satisfying way then the word might as well be done away with too.
But if there is a commonality between what software developers think when they discuss 'architecture' then we could use this as a starting point for the definition. This is why i suggest we look at what people want to describe when they say 'architecture' so we can figure out what we want the term to mean.
I've not got a satisfying rebuttal yet to the coffee cup analogy as its a fundamental problem
See IEC 62304 for one brilliant way to define and make architecture, which conflicts with Greg's statements, or basically conflicts with almost everything he says.
We want Alan Kay, can you bring him?
If an organization can benefit from a dedicated architect, the prime directive of the architect should be to make sure that the organization no longer needs an architect.
Regulations on software development increasingly require continuous maintenance of software architecture, and thereby requires architectual competence with software product manufacturers.