I am done with the whole shift left storyline.

When being part of an enterprise, you will meet different architects on any given day. The first one introduces itself as a solution architect, the other calls itself the enterprise architect, and they both mention a domain architect. It might feel like different names for the same thing, and perhaps even a bigger question, do we even need all of these different architects? Should the team not be able to make all of these architectural decisions by themselves?

Talking about the added value of applying Agile Architecture in your organization, we see fewer and fewer “IT architects” in organizations. Is that because we do not need Architects anymore?  

While browsing the Netlify configuration site for my account (in a more or less panicky attempt to find some config item I’d lost track of), I stumbled on an option named split testing. I know this concept as A/B testing, where you try out different versions or options of a site and check analytics to find out which version yields the highest revenue. Netlify tags this option as beta, but at the time of writing I’m pretty happy with its performance. Below is a short introduction on how to use the split testing feature.

More…

Remember when we used to have a production, acceptance testing, integration and development version of a site? And that we struggled to get an extra environment from IT just so our customers could test our work?

Those days are over. Below I’ll show how to set up deploys for every branch. Or every commit. And how to have all of those versions available at the same time. The enabling technology is Netlify.

This post will show how to deploy a site on Netlify, based on a GitHub repository. And the killer feature: each single commit can be deployed to a unique URL with no extra effort at all. This facilitates fast and easy feedback from our clients on the products we build.

more…

Great landing, wrong airport

I read this phrase a while ago and it got to me. It fitted the projects I was working on. <Enter attentional bias>.  These organisations I was working with were building great solutions (technically). Unfortunately, not always what their customers were expecting. It confirmed for me that Systems Thinking is really important. Combined with some new insights from behavioural sciences, you will land at the right airport.

Small side confession: reading this phrase triggered two things in me.  

• A memory of that time I planned a fun getaway to Mallorca with a friend but ended up at the wrong ‘Weeze airport’. Which made me think of changing this title to “Great holiday plan, wrong airport”. 
• The realisation that this phrase beautifully articulates the million-dollar question: ‘Which problem are we actually solving with this solution?’  

Although the story of the first is – in hindsight – brilliant, I’ll focus on the second one in this post.  

A data-platform is nothing more than a normal (cloud) platform with some additional functionality on top to make it specific to the requirements of the data domain. Instead of the applications that run on a “normal” platform like (web)services and front-ends it runs ELTs/ETLs and data applications. 

Many organisations have a new ambition to become a data-driven organisation. In essence, this means the organisation wants to make better business decisions based on insights provided by data [4]. Data itself is not able to advise a business for better decision-making. Therefore these organisations introduce a new capability: Data & Analytics. 
This blog elaborates on how adopting DevOps principles can enhance business value creation for the world of Data & Analytics.

Team Topologies is the work of Matthew Skelton and Manuel Pais, and I use it as part of my job. From a sociotechnical perspective, a team-first approach is paramount for any organisation and helps to decrease the accidental complexity. As such, I’m often asked “How can we operate in DevOps?” or “How can I have a reliable service to deliver value to my customer?”.

There is a lot of buzz around the practice of Progressive Delivery lately. Rightfully so, as it’s a great addition to continuous delivery. By gradually exposing new versions to a subset of users, you’re further mitigating risks. As usual with new and shiny things, many of us are eager to try it out, learn about the tools and shift to this way of working. But as is also common, there are reasons to do it, reasons to not do it, and reasons you might not succeed at it. Let me save you some trouble by elaborating on a few of them.