Gregor Hohpe Reveals The Best Platform Strategies For Success!

Gregor Hohpe. is a world-class expert on software architecture and the role of the architect, he is a technologist and expert on the topics of large-scale systems and the public Cloud as well as lots of other stuff. Gregor is currently part of the Serverless team working as an Enterprise Strategist for Amazon at AWS, 
Previously he was Technical Director in the Office of the CTO at Google, and before that was Chief SW Architect at Allianz the German Insurance giant.
Gregor is an international speaker, author of Several great books, as well as writing on his always thought-provoking blog, “The Architect Elevator”. and he’s just published a new book called “Platform Strategy”

___________________________________________

🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS

___________________________________________

🖇 LINKS

00:00:00 Intro
00:01:24 Start
00:01:38 What is a Platform?
00:03:21 "Platforms are Abstractions that Work!"
00:05:20 Why we Only Find Good Platforms Every 20 or 30 Years?
00:06:11 Good Platforms Remove Work
00:08:07 Should we Leave Building "Platforms" to Others?
00:12:04 Where Platforms Go Wrong
00:14:04 Good Platforms Change the Vocabulary
00:15:14 Common Mistakes in Platform Engineering
00:21:45 You Need VERY Skilled Devs to Build Effective Platforms
00:22:33 Focus on the Problem Not the Tech.
00:23:19 Sinking vs Floating
00:26:34 Keeping Options Open through Architecture
00:27:50 Platforms - the Pinnacle of Good Design
00:29:01 What Strategies Work?
00:32:43 Using Platforms to Join the Dots
00:35:27 Reducing Cognitive Load
00:40:10 New Programming Models for the Cloud

📚 BOOKS:

LINKS:

and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

#podcast #softwareengineer #platformengineering

[zoltannemeth]

Thanks for this video. Our devs have generally told us (I work as a member of a Cloud Platform Team) that they like having us define defaults in templates for cloud services that provide a “golden path” on the platform so they don’t have to spend time via trial and error. We don’t generally block devs for anything unless it is a cyber security requirement, most “default” settings in the templates can be easily overridden if the dev needs to for their specific situation. Also, we have had to build abstractions for identity systems (service principal creation and management, etc…) as the devs on every team don’t want to have to spend time figuring this out on their own, etc….
Just sharing some of our journey’s experiences.

[mixerman]

OK, I will now admit it. Gregor is much smarter than me ;-). I love the way he seems to read my mind - e.g. about "floating vs. sinking platforms" and the necessary "Decision discipline". Very similar to some of my own experiences, ideas and struggles but articulated so much more clearly. Looking forward to reading the new book.

[rodrigogalba]

This is a tremendous talk with so many tips and insights about this topic that needs to be clarified nowadays (to me at least). Thanks for this video.

[wentbackward]

Great to have you both sharing your thoughts together 1+1 > 2! Can't wait to get you both back into our firm for more talks!

[davidglaubman]

This is the stuff - I wish here was more of it. 
Many thanks for what PG Wodehouse's Uncle Fred might call "a pleasant and instructive afternoon."

As stated near the end, the tech domains (such as distributed systems) are long overdue for proper programming models that compile to executable code.
I would even argue that it makes sense to develop a regular (as opposed to embedded) DSL for certain domains that would allow more idiomatic expression than something like TypeScript.

btw, my initial exposure to DDD was a 1/2 day class taught by Eric Evans in 2006. There was this guy in the row in front of me who was far quicker than the rest of us in absorbing the content.

I knew who he was cuz I had just purchased his book "Enterprise Integration Patterns."

[brownhorsesoftware]

Great vid! It sounds to me like people often use the word platform when they really mean tool. From someone who has spent a lot of time working on both. A platform is something you stand on that gives you wide access to functionality. A tool is something that customizes that access.

[natenatters]

Great discussion! Ive just bought the platform strategy book, cant wait to see what else I learn :D

[mdjpurdon]

CDK - specifically the latest Typescript version - is a perfect example to me of well-managed complexity. Using SST alongside it is incredible; I can build complex IaC structures with just a few lines of code most of the time. However, if I need extra control, I can delve into the lower-level constructs, deciding how much complexity to take on to solve my problems. Also, for infrastructure elements that we find are commonly needed, like an audit trail, we create small custom constructs backed by unit tests. This simplifies the communication of our strategy with teams and requires very little documentation since they use the same ubiquitous API that everyone is used to with CDK. This is our platform, and it really feels like it reduces our cognitive load (*wink*) without confining us.

[nickpll]

The thing I struggle with is knowing what things should be centralised and what things should not? Most centralisation I see seems to cause problems and slow the organisation down, but at the same time, if every team does its own thing then will this not end up slowing down the organisation also? A simpler question to ask is "how important is organisational consistency?"

[herrerkan]

"They are happy with the P in there" such gold but missed the chance to say "They are happy with the PP in there" 😂

[thescourgeofathousan]

Platform Engineering unfortunately is being implemented (in my region at least) as a team or department and so is now a new Silo and reintroduces all the issues caused by silo’s we so briefly shed before DEVOPS was corrupted by those with interests in returning to the bad old ways with all new names slapped on.
I’m now seeing articles on medium and LinkedIn offering the bad old solutions to the bad old problems of silos which we have now reintroduced with all new silos. Sigh.

[GackFinder]

The IT industry will build so much utter nonsense under the umbrella of "platform engineering" that I as a consultant will probably be very rich by simply helping my clients to clean up the mess they will invariable make. "Platform engineering" is just yet another IT buzzword for something that isn't generally needed, and it will rarely, if ever, reach any kind of return on investment. In other words, "platform engineering" is simply waste. By the time you've provided your fully working "platform", all frameworks and tech stacks that it abstracts away will be old news, and your "platform" won't work with the new stuff. It's the utter folly and mythology of "reuse" all over again.