Gregor Hohpe

When presenting to executives, rather than give the answer, I first present the intellectual framing, aka my mental model or "map".

Splitting the conversation into two parts has a great advantage. If your audience disagrees with you, but articulates their point of view based on your framing, you are still ahead: you're having an elevated discussion thanks to the mental model you set. If you only spew out an opinion, you easily get stuck in a "who's right" debate, which is the last thing you want in an executive session.

Sharing the map first has another advantage: if there isn't agreement on the map, it's pointless to discuss options. How can you debate the best path if you have different coordinate systems or aren't sure you're looking at the same territory?

A common mistake is coming into an organization, seeing a lot of opportunity for improvement, and pushing hard to make things better. Although well-intentioned, this approach is unlikely to effect lasting change, and may cost the new arrival their job.

Driving change requires goodwill and credibility. You are convinced that the changes you propose will improve things, but to others this may not be clear at all. In their eyes, they are taking a risk. And why would they trust you?

My latest #ArchitectElevator blog post introduces the notion of #PoliticalCapital for architects who drive change, so they can find more ways to earn political capital and meaningful ways to spend it.

Link below!

Organizations see GenAI as a solution to their problems. Instead, it's going to compound their existing problems and dysfunctions.

This has happened with many new technologies. Cloud was supposed to make infrastructure cheaper and more reliable. Instead, it strained the already poor relationship between dev and ops. Integration and APIs were meant to create composable ecosystems. Instead, they became a new no man's land in the trench war between silos.

If GenAI speeds up software delivery, the internal friction will become unbearable. If GenAI makes software development a commodity, it'll highlight the lack of product strategy and critical thinking.

Yes, the light at the end of the tunnel is an oncoming train.

Resisting commoditization is a natural instinct: being a commodity means low margins and being replaceable.

But that's the narrow scope view. making things a commodity fuels the next wave of innovation: imagine a place where electricity isn't a commodity, and think what that'd do to your ability to innovate.

so, always push to the right, as aptly shown in my gesture 😂

The prolonged disruption of AWS' UAE region with 2 availability zones down (mec1-az2 and mec1-az3) is sure to trigger renewed calls for #MultiCloud.

Instead, I recommend taking a close look at three other aspects:

1) Understand the risk. The risk is #regional, not tied to a provider. The folks who took out ME-CENTRAL can just as easily take out Azure or any other data center. So, the mitigation is reducing your regional exposure, not your vendor exposure (unless you like to play provider Whac-a-mole)

2) Fully utilize the capabilities of the cloud you already have--I almost guarantee you're not. Moving to another region is no fun, but all the tools are there: the cloud is automated and has global capabilities. The providers have been somewhat direct that this is the client's work. Quote from an actual vendor meeting: "we give you all the tools, but we don't move applications for you". A tough message for clients, but spot on. #Automation is key: it gives you a speed advantage (everyone else will be looking for capacity) and predictability.

3) Review your internal processes and bridge #compliance with #technical design. There used to be no perceived penalty for compliance to say "no, you can't replicate any of that data because, you know, the regulator!". Now it has to be "let's organize data by whether it can be replicated or not, and also identify what data isn't needed in case of DR (caches, logs, etc)".

A lot of organizations still haven't lived up to the fact that the cloud requires a different operating model. They still think #Resilience can be achieved through procurement or infrastructure.

No sane person would keep driving their (ICE) car with the below warning sign on. Without oil pressure, your engine will quickly die from excessive friction. And if you push the accelerator harder to overcome the friction, it only dies faster.

Yet, that's what so many organization do. When things move slowly due to excessive friction, they don't remove the friction, but just push harder. They just burn more energy with no result. and wear out their employees in the process, quite literally.

What do you think, does the world need a book on "Transforming IT with car analogies"? I may sufficient content...

Kelsey Hightower thoughts on #PlatformEngineering at PlatformCon:
- your platforms host data and applications. So you better understand data or applications
-Since 1999 people struggle with copying software to a machine and making it run
- Engineering is designing around what’s already there, build around those constraints. You won’t be able to do everything brand new
- People will use AI to generate shell scripts and call it innovation

#Architects should avoid being an #oracle, except this one.

Some folks see enterprise / chief architects as some form of oracle where you go to get answers. While that's charming, one person making decisions on behalf of all others seems like a tall order. It also runs the risk of making decisions in a vacuum, chasing abstract ideals instead of acknowledging real-world constraints.

But the Matrix oracle is different. She does not tell people the future. She tells them what they need to hear to fulfill their mission. Sounds like a good role for an architect, right?

What better way to end 2025 than with a Matrix metaphor. See you all after the reboot!

Aspiring #architects look to add more skills to their repertoire. That's useful, but becoming a great architect requires synthesizing the different skills, meaning it's about multiplying, not just adding. A blog post:

A lot of IT ambitions remain wishes: cross-functional tribes working on agile in-house microservices platforms, yet features aren't delivered any faster, customer feedback can't be incorporated, and availability is still mediocre.

The reason is often that the org just renamed existing constructs without fixing the root cause of their symptoms. It's like taking a pain killer and expecting healing.

My latest blog post on the #ArchitectElevator helps you move from renaming to reshaping: https://lnkd.in/gD85sJTB

#Platforms can start much smaller and grow much bigger than most folks imagine. A #MinimumViable platform can be a piece of documentation or agreement on common ways of working. And it can evolve into a powerful ecosystem with internal events and customer testimonials.

Content credit: Jean-Francois L.. As always, get deeper platform insights in our #PlatformStrategy book

A new saying of mine in large organizations is "Don't be ChatGPT" as a warning to people who:
- merely disseminate minutes / documents
- rephrase or summarize what was already said
- coordinate across parties (unless it's in super complex, political settings)
- share blatantly obvious content (we have a front-end and a back-end!)

You are so replaceable that the model that will do it will run on the next Raspberry Pi. Make sure you add real insight and critical thinking. All else, leave to the machines.

To me the irony of the GenAI discussion is not how mighty artificial intelligence is, but by how much we underutilize our human intelligence. We're making it pretty easy for the tools.

#Platform teams can easily forget that they provide distinct benefits to their project customers and their corp stakeholders.
Reuse is something that excites stakeholders. Dev teams just want speed, and often they have learned that shared solutions are slow or require too many compromises.

A tale of cars (surprise!):
I have a DeLorean (for over 30 years, it was cheap, and I am not giving it away). I had some work to be done when it moved to Germany with me. I tried 2 major specialists:

One has a warehouse full of workers, quoted me a million things to "fix", including many I was aware of (that dent in the fender has been there since it joined my family and, yes, it used to have a car phone installed - I wish I still had that time piece!). They also threatened me after I posted a picture of my car in their workshop without their explicit permission.

The other one is a one-person show, super relaxed guy who makes much of his money on parts and has no interest in managing a large crew. He told me I am free to choose what I want him to do, the main thing I need is patience. Covid hit, the car spent 3 years at his shop, we did quite a few things when he had time and I had money (he did ultimately convince me to trash the original alternator, which is utter rubbish). He picked me up at the train station when I came to get the car, I took it on the freeway, drove 300km back to Germany, and passed the TUV en route. I then recalled the display cabinet he had with the gifts that customers had sent him, including a few from Japan.

When I see "thought leadership" (always with air quotes) on social media, you can immediately tell which type of person / business is behind it. You can't blame anyone for wanting to make a living and pay for kids' education (in countries where you have to pay). But the strong smell of "everyone else is wrong, I am enlightened and can show you the true path" always turns me off. I once told my client that if they told me after a workshop: "look, this is utter nonsense and entirely useless", I'd apologize for taking their time and wouldn't send a bill.

The major irony in this is that many of these folks advise their customers to take a long-term, strategic view on architecture decisions, when they themselves focus entirely on the transaction and not the long-term value of a customer relationship.

ps: the garage below is neither shop, as you can tell from that random Rolls Royce cluttering the photo :-)

If your #EnterpriseArchitecture team isn't connected to your #Platform team, you have a problem. Most EA teams publish reference architectures, principles, and "guard rails". Those should all be reflected in your internal platform. The platform should also feed your application inventory / landscape repository.

It's easy to draw these lines in a simple sketch, but they often imply an entirely different approach to platforms and architecture.

The world is full of people who paint a rosy picture of what future #EnterpriseIT should look like: AI enabled, highly automated, platform-based, low-friction, transparent, serverless, you name it.

The world needs a lot more people who can slug it out on a daily basis to drive change with empathy, have the energy to make a visible improvement but also the patience to see a transformation through to delivering broad results, be engrained in a system that they are looking to change.

The former appears glamorous, the latter grunt work. The reality is the inverse.

(photo: Greetings from the engine room. That's where the magic happens)