Delivery is like a Relay Run
As promised in my earlier blogs. I am writing a blog a month and I write about Architecture, Governance and Changing the Process or the Imp
Complexity? It is everywhere! All of us Architects have experience with our different customers and their complex and bulky application landscapes. And the numerous cha
Complexity? It is everywhere!
All of us Architects have experience with our different customers and their complex and bulky application landscapes. And the numerous cha
Architecture as a Coaching Discipline There is an old, persistent stereotype of the Enterprise Architect. They sit in a metaphorical ivory tower, disconnected from the
Architecture as a Coaching Discipline
There is an old, persistent stereotype of the Enterprise Architect. They sit in a metaphorical ivory tower, disconnected from the
AWS’s S3 outage
AWS’s S3 outage
Martijn Veldkamp
“Strategic Technology Leader | Customer’s Virtual CTO | Salesforce Expert | Helping Businesses Drive Digital Transformation”
March 1, 2017
Tuesday’s Amazon Web Services mega-outage affected not only websites big and small, by disrupting their backend storage, but also a lot of apps and Internet of Things gadgets relying on the technology. The AWS storage offering provides hosting for images for a lot of sites, and also hosts entire websites, and app backends including Nest.
In fact, the five-hour breakdown was so bad, Amazon couldn’t even update its own AWS status dashboard: its red warning icons were stranded, hosted on the broken-down side of the cloud.
The S3 buckets in the US-East-1 region became inaccessible at about 0945 PST (1745 UTC) taking out a sizable chunk of the internet as we know it.
AWS has many many regions, and US-East-1 is just one of them. Developers are supposed to follow Disaster Recovery architecture and Best Practices and spread their applications over different data centers.
For various reasons – from the fact that programmers find distributed computing hard to the costs involved – this redundancy isn’t always coded in. And so here we are.
Phenomenal understanding of Nano Banana what I wanted to express with this article
AI of course, still in love with nano banana
Balancing Act: Robustness with Customer Focus
Martijn Veldkamp
“Strategic Technology Leader | Customer’s Virtual CTO | Salesforce Expert | Helping Businesses Drive Digital Transformation”
December 5, 2025
In large-scale enterprise IT, there is a constant, almost gravitational tension between two opposing forces.
On one side, you have the market. It demands speed and radical customer focus. It wants new features deployed yesterday. On the other side, you have Governance. It demands stability, compliance, and zero-risk operations. For years, the industry buzzword was “Agility.” The narrative was that if we just adopted enough scrum teams and microservices, the tension would vanish. But in regulated sectors treating every system as a “move fast and break things” playground isn’t happening.
Strategic architecture isn’t about choosing between speed and stability. It is about architecting a landscape where both can exist in harmony. The biggest thing I see in transformation roadmaps is the attempt to apply a single methodology to the entire IT landscape.
If you treat your core transaction systems like a marketing app, you introduce unacceptable risk. Conversely, if you treat your customer-facing channels with the heaviness of a SAP4Hana migration, you will be disrupted by a startup before you finish your requirements document.
To simplify and modernize a complex application landscape, we have to recognize that different distinct layers breathe at different rates. Speed layering.
Systems of Record, where change is slow, deliberate, and expensive (by design). We want friction here because the cost of error is too high.Systems of Differentiation, where unique business processes live. It connects the core to the customer. We need flexibility here to configure new products, but we still need structure.Systems of Innovation, where we test new customer journeys. If an idea here fails, it should fail fast and cheap without shaking the foundation.
The Architect role shifts from being the “standards police” to becoming city planners. We don’t just draw diagrams, we define zones. We tell the organization: “Here, in the innovation zone, you can use the newest tech and deploy daily. But here, in the core, we measure twice and cut once.”
Implementing this strategy is rarely a technology problem, its a people challenge. It requires coaching stakeholders to understand that “slow” isn’t a dirty word, it’s a synonym for “reliable.” It requires mentoring solution architects to recognize which layer they are building in and to choose their tools accordingly.
When we get this right, we stop fighting the tension between Innovation and Stability. Instead, we use the solid foundation of the core to launch the rapid experiments of the future. We achieve a landscape that is calm at the center, but agile at the edge.
That is how you build an IT strategy that survives the long term.
Tailbone evolution
Tailbone evolution
Are we trading long term wisdom for Fool’s Gold?
Martijn Veldkamp
“Strategic Technology Leader | Customer’s Virtual CTO | Salesforce Expert | Helping Businesses Drive Digital Transformation”
June 6, 2025
I want to stop everybody celebrating that AI writes your code. I think you might be cheering for the obsolescence of true problem solving skills. Leaving behind a legacy that no one truly understands. For now I and thus this article has more questions then answers.
The AI code rush
It spits out code in seconds, a great short-term win. But what’s the long term cost when no one on your team, not even your architect, can truly articulate why that code is the right solution, or how to maintain it when the AI’s ‘understanding’ hits a wall?
Our tailbones are harmless evolutionary leftovers. Well, if you ever fallen on your tailbone, you may beg to differ on the harmless part. Of course the primary point of a vestigial organ is its lack of original function, not whether it can still cause pain. But, what if our continued reliance on AI for quick coding is actively atrophying something far more critical. The necessary deep and nuanced understanding of the very problems we’re paid to solve? Are we supposed to evolve into mere AI prompters, losing the ‘muscle’ of genuine architectural foresight and domain mastery?
The sedcution of speed vs necessity of depth
The siren song of AI-powered development is deafening. Well at least the marketing is in my internet bubble. Instant code, accelerated timelines, the allure of hyper-productivity. To me these are potent but short term gains. I think that in our rush to ship faster, we are sacrificing the long-term pillars of robust, sustainable software: genuine problem understanding, maintainability, and refactorability.
The great Jos Burgers said: “It’s not about the technical capabilites of the drill, it’s about the hole, preferably without drilling”. I think we are focussing on the wrong thing. Lines of code or solving the problem? Code is a means, not the end. Software development, at its heart, isn’t about producing code. It’s about solving a problem for a user or a business. That solution doesn’t end when the code compiles. It lives, it breathes, it needs to be adapted, debugged, refactored and scaled. As a team you iterate towards a better understanding of the problem and how the solution fits. This is where the my questions arise from.
AI Ownership?
Do you truly understand the problem domain, or even the solution you’ve implemented, if an AI generated significant portions of it based on a prompt? What do you do when the inevitable bug appears? What do you refactore to meet the ever evolving business needs This just isn’t an individual developer concern. It’s a profound future challenge. The roles of Lead Developer and Software Architect have always been more than just delegating coding tasks. They are the keepers of the faith, the custodians of the system’s integrity, the champions of its long-term vision. Yeah, I want to link some bands to these. 😉
How do we review and take ownership of generated code if the team’s (or even my own) understanding of its intricacies is superficial? Are we shifting from code quality in a human context to validating the output of a black (or at least opaque) box? What will we do in the future knowing our team might not possess the granular understanding to maintain or evolve them without significant AI assistance? This could lead to overly simplistic designs to match a perceived lower skill floor. We might end up with dangerously complex AI stitched systems that are brittle and opaque.
The atrophy of problem solving and domain expertise: The true Tailbone
The evolutionary dead-end we risk isn’t the loss of raw coding ability. It’s the atrophy of deep problem-solving skills and intimate domain knowledge. If we start to make AI the lead for translating problem to code, the human developer’s muscle for analytical thought, the breaking down of complex requirements into logical software structures, for anticipating edge cases beyond the AI’s training data, may weaken. I still haven’t seen any AI start with “well, it depends…”
Just ask yourself where did you write down why one pattern is strategically superior to another in a specific context, considering long-term trade-offs? How do we identify the unmet needs of the customer? When did we discover a flawed assumption? Where are the talks at the coffee machine documented?
So, how will an LLM learn any of this? This nuanced understanding of a complex business is learned and build through the struggle of translating its messy realities into clean code. I am of the opinion, now, that if that “struggle” is outsourced, the depth of understanding is also outsourced. And we all have worked with teams that were either nearsourced or outsourced. How did that shared understanding go?
Solving today’s problems with yesterday’s solutions
This brings me back to the “echo chamber”. If AI is trained on existing codebases and solutions, it excels at producing variations of what’s been done before.
And AI is trained on those code bases?
True innovation often comes from a deep understanding of a problem that allows one to see an entirely novel approach, not just a new implementation. If our primary tool for “solving” is an AI that reflects past shitty solutions, are we limiting ourselves to incremental improvements within existing paradigms?
Where does this leave us?
I am not advocating about rejecting AI tools. But I do think we need to be very clear on our relationship with them. The focus must remain laser-sharp on solving problems effectively for the long term. My argument is about the slippery slope and the potential future of these tools
I am of the opinion that we can use AI to augment our work. It can handle boilerplate, it can suggest alternatives, but the human must remain the strategic thinker, the domain expert, the one who takes ultimate responsibility for the solution’s integrity. We all need to encourage each other to question and validate AI outputs. Assume nothing. Our most valuable skill will be the ability to deeply analyze a problem, understand its domain, and architect a robust and maintainable solution.
Perhaps the real ‘lead developer’ and ‘software architect’ of the future will be defined not by how quickly they can prompt an AI to produce code, but by their understanding the problem so profoundly that they can guide anyone, human or AI, to a solution that stands the test of time. Anything less is just building shinier tailbones.
They Say Its a Masterpiece. I Say Its a Disaster-piece! – Waldorf (Probably)
They Say Its a Masterpiece. I Say Its a Disaster-piece! – Waldorf (Probably)
Giving Better Feedback
Martijn Veldkamp
“Strategic Technology Leader | Customer’s Virtual CTO | Salesforce Expert | Helping Businesses Drive Digital Transformation”
May 9, 2025
After my Muppet Show article I had some very fun conversations. Why did it struck such a nerve? I think, probably because fields like architecture often involve abstract concepts, processes, and terminology. Analogies, specially well known and loved characters like the Muppets, act as powerful simplifying agents. They help translate complex ideas into understandable terms, broadening accessibility and engagement beyond my niche expert circle on LinkedIn.
The Guide to Surviving Design Critiques (and Giving Better Feedback)
Ah, the design approval phase. That hallowed architectural ritual where bright ideas meet, ehhh, the cold, hard glare of scrutiny. I know it’s part of the process, a step where concepts are refined. But lets be honest, sometimes it feels less like a constructive dialogue and more like you’ve accidentally wandered onto the stage of The Muppet Show, right into the firing line of Statler and Waldorf.
The archetype
You know the feeling. You’ve poured your heart, soul into that design. You present it with a hopeful tremor, and then… the heckling begins This, my friends, is the Statler and Waldorf effect. Next to the sarcastic takedown, they will findi fault with absolutely everything, all while cackling at their own wit. They are the archetype of every cynical client, every change-resistant committee member and every jaded senior partner who has seen it all before.
Destructive, Not Constructive
Their specialty is pointing out what’s wrong, often in the most demoralizing way possible, without offering much in the way of alternatives, solutions or encouragement. Encountering this resistance can be incredibly frustrating, especially when you’re passionate about your work.
Your Balcony Defense Manual
So, you’re facing a Statler and Waldorf in your design review. Your concept is being compared to something Fozzie Bear coughed up. What do you do? Develop a thick skin or a really good poker face, just kidding.
Remember, their commentary is often more about them and their negativity than it is about you or your work. Try not to take it too personally. Listen because occasionally, buried deep beneath layers of sarcasm, there might be a legitimate concern. It’s like panning for gold in a river of *beep*. It’s tempting to get defensive or fire back with your own sarcasm. Resist. You wont win. They have decades of practice. A polite, thank you for your perspective, we’ll certainly consider that, can be surprisingly disarming. Seek clarity, if a criticism is particularly vague and cutting, like It just doesn’t feel right, you could ask for specifics. Could you elaborate on what aspects aren’t resonating? Be prepared for another sarcastic volley, but you might occasionally get something more tangible. Remember Your Allies. Hopefully, not everyone in the room is so jaded. Lean on the more constructive feedback from others. Take the time for a Post-Critique Autopsy. After the barrage, take a moment to sift through the comments. Discard the pure heckling. Discuss the potentially valid points with trusted colleagues. Sometimes, even a broken clock is right twice a day.
Giving Feedback That Actually Helps
The golden rule: critique unto others as you would have them critique unto you. (Thanks spell checker)
Be Specific: If you think something will not work, point that specific point out.Balance is Key: Balance your critique with the good things that you see.Focus on the Work, Not the PersonOffer Solutions, Not Just ProblemsAsk Questions: A probing question might lead to great discussion that help clear up the designRemember the Goal: What are they trying to solve forDon’t Think Old (Even if You Are): Avoid the trap of automatically dismissing new ideas simply because they’re different.
Closing off
By learning to filter their feedback, and by striving to offer more constructive criticism ourselves, we can make the whole process a little less painful and a lot more productive. Remember: at least they showed up. And who knows, maybe one day you’ll even get a It wasn’t half bad! And for Statler and Waldorf, thats practically a standing ovation.
Well, that article wasn’t as bad as I thought it would be. You’re right. It was worse! Doo-ho-ho-ho-ho!
Stolen from https://static.vecteezy.com/
Stolen from https://static.vecteezy.com/
From Blueprint to CTO
Martijn Veldkamp
“Strategic Technology Leader | Customer’s Virtual CTO | Salesforce Expert | Helping Businesses Drive Digital Transformation”
February 14, 2025
Remember those old cartoons where the architect with a rolled-up blueprint and a pencil behind their ear, stood stoically overseeing construction?
That image, while nostalgic, is as outdated as dial-up internet. The role of the architect has undergone a dramatic transformation, evolving from a technical specialist to a vital business strategist.
Beyond Blueprints
In todays fast-paced digital world, architects are no longer just drawing up technical plans. They’re navigating a complex application landscape of cloud computing, artificial intelligence, data analytics, and ever-shifting business needs.
The blueprint is still important, but its now just one piece of a much larger puzzle.
Think of it like this: Imagine building a house. Architects used to focus primarily on the structural integrity, ensuring the walls wouldn’t fall down. Now, you also need to consider energy efficiency, smart home integration, and how the house will adapt to the family’s changing needs over time. The modern architect is concerned with the entire ecosystem over time, not just the foundation.
Captain Sparrow fan art
Business-Savvy! As an architect you need to understand the business inside and out. How to translate business goals into technical solutions, and vice versa. You need to be fluent in the language of both the C-suite and the development team.
This means understanding market trends, competitive pressures, and how technology can drive innovation and create a competitive edge.
Its no longer enough to simply design elegant systems. The architect must also consider the business impact of their decisions. Will this architecture enable faster time to market? Will it reduce costs? Will it improve customer experience? These are the questions that keep CEOs awake at night, and architects need to have the answers.
The Architect as a Change Agent
And not a weapon of mass confusion
You are also playing a crucial role in driving digital transformation. Helping businesses adopt new Salesforce technologies, migrate away from their legacy systems, while embracing agile methodologies. This requires not only technical expertise, but also strong leadership, communication, and change management skills.
The architect is no longer just a technical expert; they are a change agent, helping organizations navigate the complexities of the digital age.
The Customer CTO
The days of the lone wolf architect working in isolation are long gone. Todays architect is a collaborator, working closely with developers, business analysts, security experts, and other stakeholders. You need to be able to build consensus, negotiate compromises, and foster a culture of collaboration.
The modern architect understands that the best solutions are often the result of diverse perspectives and shared knowledge.
That is why I think that CTO can mean much more then just Chief Technology Officer:
Collaborative Transformation Officer, Consulting Technology Orchestrator, Connector of Technology & Organizations, Catalyst for Technology & Operations
I wanted to be even more poetic but that is quite hard with just these letters. I also kinda like the following, but I’m ending the Friday with a beer and a blog, so bear with me:
Weaver of Technology & BusinessCurator of Technological FuturesInnovator of Technological Approaches
To state some open doors
The world of technology is constantly evolving. New technologies emerge, old technologies become obsolete, and best practices are continuously being redefined. You as an architect must be a continuous learner, always seeking to expand their knowledge and stay ahead of the curve.
This means attending conferences, reading industry publications, experimenting with new technologies, and engaging with the broader architectural community. Personally I mostly have several authors that I really like that help shape my thoughts. Martin Fowler has a nice group of people that use his platform to distribute interesting ideas.
To try and close the article. Organisations will need people that can act hybrid, blending technical expertise with business acumen, leadership skills, and a passion for innovation. They will be the CTOs of the future, shaping the digital landscape and driving business success.
What skills do you think are most important for the modern architect? Id love to hear your thoughts in the comments below. Also please find some more interesting finds on CTO!
On Autopilot in Your Architecture Decisions? Last Wednesday was a very foggy day to travel by car to the office. I noticed that a lot of people either where running all
On Autopilot in Your Architecture Decisions?
Martijn Veldkamp
“Strategic Technology Leader | Customer’s Virtual CTO | Salesforce Expert | Helping Businesses Drive Digital Transformation”
October 24, 2024
Last Wednesday was a very foggy day to travel by car to the office. I noticed that a lot of people either where running all their foglights or just their daytime lights making them nearly invisible.
Ever driven through “thick” fog, only to realise that your car’s daytime running lights are on, but your full headlights aren’t? It happens more often than you think. In today’s world of automation, many of us assume everything is taken care of, until we hit a foggy patch. The we discover we’re not as prepared as we thought. This unconscious reliance on automated systems can lull us into a false sense of security.
This is a lot like what happens in the world of enterprise architecture.
The Fog of Autopilot in Architecture
Just as drivers forget to turn on their headlights in the fog, we, too, sometimes find ourselves moving on autopilot in our architecture decisions. How often do we rely on processes that “just work” without stopping to verify if they’re the best approach for this situation? We fall into our favourite patterns, depending on the same tech stacks, the same vendors, or the same integration points, because they’ve worked before.
But in this application landscape where the unexpected happens regularly (new regulations, evolving customer needs, emerging technologies), running on autopilot can be risky. What happens when a critical decision needs to be made, and we realize we’ve left the headlights off?
Where Are You on Autopilot?
If you’re honest with yourself, where are you currently driving in “fog” mode? Is it in cloud adoption, choosing the best application for a certain workload, technical debt management, or returning to your favourite capability map? Perhaps it’s in your approach to security, assuming that what worked yesterday will work tomorrow.
I’ve seen and experienced how easy it is to coast along with what feels comfortable. But without stopping to switch on the right lights and thus gaining visibility into potential pitfalls or opportunities. We risk making critical oversights that could cost our organisations time, money, or worse, customer trust.
Call to Action
What parts of your architecture are you running on autopilot? I’d love to hear your thoughts in the comments. Let’s share examples and learn from each other where we might be forgetting to “turn on the lights” in our architectural decisions.
Architectural OCD A couple of week’s ago the Fridays Nonsense post by Karsten Scherer had an interesting topic that had me thinking about internal systems. He mentioned
Architectural OCD
Martijn Veldkamp
“Strategic Technology Leader | Customer’s Virtual CTO | Salesforce Expert | Helping Businesses Drive Digital Transformation”
March 8, 2024
A couple of week’s ago the Fridays Nonsense post by Karsten Scherer had an interesting topic that had me thinking about internal systems. He mentioned systems that we are not aware of, until they stop working. For example your inner ear balance.
That post kickstarted my thinking about switching between unconscious and conscious. Becoming aware of feeling uncomfortable. That something is not right, but something is off. What triggers it? Why is a picture on the wall hanging slightly skewed triggering my senses that I notice it immediately? With what framework and expectations am I viewing the world? Or the other way around. What damping and priority settings do I have to handle noise but still alert me when stuff is different?
For example when you walk in a house and you smell something different. “Do you smell that?”. Could be me burning todays dinner, could be the house on fire, could be my wife painting the wall yet another color or the neighbour burning their plastic garbage, again…
Anyway, it is something different. Different then expected. Different then the baseline that we all have. Different enough that it travels through the overload of other sensory input. And get’s priority to override.
Side note:Reacting to something smelling differently is probably a survivor trait. Unconscious response to danger.
Smells
Fresh Prince of Bel Air
To loop back a bit to my professional career. I read about code smells either in a book by Martin Fowler or Kent Beck somewhere in the end of the 90s. Both come to memory when using the phrase “code smells” and possible technical debt.
I think it is the same as seeing stones in a sidewalk not fitting with the rest of the pattern. It “feels wrong”. Like a class with too many responsibilities, very long methods, duplicated code or methods with oh so many parameters. Next to these coding warning signs or anti patterns. There are also governance, processes and architectural smells. Let’s focus on the last part, architectural smells.
Architecture smells
Architectural smells have many examples. Applying a design in an inappropriate context. Or mixing designs that lead to undesirable behaviors. Applying design at the wrong level of granularity. These smells are not always because certain choices were made at the beginning. What I see happening at a lot of my customers is that this iterative development apporoach of their core systems and applications in distributed teams eventually leads to the loss of coherence in their architectural elements.
The moment you as an architect cannot focus on fixing important parts of the design without having to deal with the whole thing all at once. That is a smell.
Types of architectural smells I’ve encountered:
Lack of Separation of Concerns
I see systems where a lot of responsibility and knowledge sits in one component. How to setup a secure connection, orchestrate multiple calls and handle all the translations, handle errors but also maps all the fields and resultsReusability, modifiability, and understandability are impacted. Now every component that wants to send messages need their own implementation of securing a connection, storing secrets, orchestration, etc. Refactoring is an answer, next to education and showing what goods looks like.
Copies are everywhere
Another great anti-pattern is the result of copy and paste. It’s when you see duplications of code addressing the same concerns. Could be due to many reasons. I have seen Salesforce Orgs that paid very low wages to their Salesforce Developers and code was duplicated everywhere. Refactoring is an answer, next to education and showing what goods looks like.
Genericity
It probably isn’t a word, but as a non native speaker I have given myself some leeway. What I mean is an over use of very generic interfaces. So not explicitly modeled out interactions. In Salesforce we have the glorious sObject. Which can be anything really. Case, Contact or Account? It is hard to do dependency analysis when all is sObject. Yes there is a search function in Visual Studio Code and no it is not a replacement.
Conclusion
Code smells help developers figure out when and where they need to tidy up their code. Similarly, architectural smells help architects know where they should tweak their architectural designs. These smells show up when the software breaks some basic rules of how it should be built, like keeping changes separate from each other. But they also give specific signs that can be easily spotted if you have that bit of OCD.
By paying attention to what makes you uncomfortable, you can filters these smells, and make small changes in different parts of your design that over time when added up, make the whole system work a whole lot better.
