Category: Innovation

Posted on

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.

Posted on

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.

Posted on

Having fun with Banano Nano

Having fun with Banano Nano

Stop waiting for “Perfect Data”!

Martijn Veldkamp

“Strategic Technology Leader | Customer’s Virtual CTO | Salesforce Expert | Helping Businesses Drive Digital Transformation”

November 21, 2025

It’s never getting off the couch! The single greatest killer of innovation is not bad preparation but poor administration. Innovation projects are uniquely vulnerable to this because they are not simple IT upgrades, they are fundamental changes to business processes.

The Hype Trap: The 95% of failures are often “hype experiments.” They start with a some flashy tool (like a generic AI chatbot) and go in search of a problem. Rather than the other way around. They stall because they have no clear owner, no defined ROI, and no integration into the actual workflows where you know, actual people do their jobs.The 5% Success: The 5% that get traction ignore the marketing hype. They are the unglamorous, high-return areas like back-office automation. They succeed because they are domain-specific (e.g., an AI that only reads lease agreements) and deeply integrated into a specific workflow.

Just do it!

There’s a common belief that AI initiatives require perfectly clean, structured and in-shape data before you can even begin. This is a form of procrastination. Let’s start tomorrow! Data is the ultimate couch potato, it will never get in shape on its own.

Waiting for Perfect: Companies that wait for a perfect, company-wide data strategy will be waiting forever. As one report on why AI projects fail notes, Garbage in, Garbage out is still a primary obstacle, leading to projects getting stuck in endless data-wrangling phases.The Start Now approach: Successful teams, adopt a pragmatic approach. They don’t wait. One manufacturing project, for example, saw a double-digit accuracy jump not from a better model, but by simply constraining the first version to SKUs that had at least 18 months of (imperfect) historical data. They started with the data they had, proving value, and built momentum from there.

Innovation fails not from bad prep, but from hype and hesitation. Start with a real workflow, use the messy data you already have, and build momentum. The unsexy projects are the ones that will actually drive benefits.

Posted on

Be very sure on what you want ! But that goes for more things in life. No matter how good the tech is, you have to think of the use-case. You have to see it. You have t

A computer lets you make more mistakes faster than any invention in human history, with the possible exceptions of handguns and tequila by Mitch Ratcl

Automation Without Purpose: Now With 10x More Useless Reports

Martijn Veldkamp

“Strategic Technology Leader | Customer’s Virtual CTO | Salesforce Expert | Helping Businesses Drive Digital Transformation”

September 19, 2025

I spend a lot of my time not just building systems but designing the flows of work that ripple through entire organizations, not just Salesforce. For every elegant customer journey we try to automate, there’s a parallel process demanding “evidence” and “compliance” or “alignment”. This lack of trust is everywhere. It leads to mandatory fields nobody reads. Reports that exist only to justify more reports. Or even beautiful dashboards that are never refreshed.

I had some beers with an old colleague of mine and Salesforce, like any enterprise platform, is often the staging ground for bureaucratic theater. Performance red tape. The ultimate of organised distrust.

Duplicate approvals because one team doesn’t trust another’s process.Mandatory checkboxes that serve no analytical purpose.Endless “alignment” decks uploaded to your DMS of choice, then instantly forgotten.

Traditionally, these frictions had limits: human bandwidth, cost of labor, and outright resistance. Nobody wants to spend hours building dashboards that nobody reads. Even consultants eventually roll their eyes.

But AI erases those limits. Ever had ChatGPT say no to you? I asked my son to have ChatGPT help him come with a plan to stick a fly up his nose. Two prompts later and we have an action plan.

The guardrails are gone. Here’s where the mindset of a Salesforce architect diverges from the hype. My job isn’t just to implement AI. It’s to design friction intentionally. Why? Because constraints create meaning. Without them, we risk endless regression of workflows that look important but achieve nothing. Management by AI checkbox.

An architect must ask:

Does this automation reduce a real human pain point, or just accelerate a bureaucratic one?Who will read this dashboard? What decision will it actually influence?What’s the minimum viable process that satisfies compliance without spawning digital theater?Can we design AI to say no? To push back on pointless work instead of scaling it?

The danger isn’t AI itself. It’s AI without governance, AI without discernment, AI unmoored from business outcomes.

Posted on

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.

Posted on

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!

Posted on

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!