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. 

Introduction

In the current day and age, technology is becoming part of the core business of many organizations. The software landscape is increasing in size rapidly, and the complexity of the systems grows. When applications, services, or even the entire IT landscape become unavailable, this will have a severe impact on the continuity of the business. 
Many companies rely heavily on third parties to run and support their systems; this ranges from integrations with SaaS services to building upon the services of a hosting party who run the software and maintain the hardware. Without these parties, it is impossible to run your software; however, what if they suddenly can not deliver anymore? 
If integrations with third-party software stop working, then your application will lose some functionality. Worst case scenario your application stops functioning altogether. The same issue presents itself if your hosting party suddenly can not deliver anymore. If your software is not running, then you are unavailable as well. This blog discusses how to prepare and handle such issues.

Mapping the current situation

The first thing that you need to do is to make sure that you have an accurate mapping of your existing software landscape. With an accurate representation of the landscape, you can create an overview of all third-party integrations, making sure you do not miss any. Using this overview, you can determine which integrations are responsible for which part of each of your functionalities. Order these from most important to least important, and you know exactly which third party software is most important to you, allowing you to prioritize properly. 

Ask a statement about their continuity

If you have not done this already, then now is the best time to do it. Once you have a good overview of your current situation, you can start to contact your third-party providers and ask them about their continuity. They will probably have a statement at the ready for you, which you can use to determine if it is enough to meet your demands. If they do not have such a statement, then that is already something to take note of. Why do they not have such a statement, are they prepared to keep the company going even in tough times? In the future, you should ask these questions upfront, before you start using a third-party service if you did not do this already.
Of course, there is still a chance that the company fails to comply with the statement, if that is the case, you will have to make sure that you are ready to handle the issues that arise because of this. Below a number of solutions for these issues have been stated. 

Integrating with third-party software

If your application integrates with third-party services, then you need to check if they have an Escrow agreement. An Escrow agreement allows you to take over the companies source code in case of the company going bankrupt or if something else goes fatally wrong. This allows you to start running the software for yourself until another solution has been found. Preventing you from being unable to use that service. 
Of course, this is a temporary solution. You do not have any employees that can maintain this solution, and you also had a reason for buying this software instead of writing it yourself. The code of these companies is often complicated for you to maintain and expand upon as well, so if this happens, you immediately have to start thinking about new solutions. Finding a replacement for this software is the most natural solution. Another solution is to revise the decision to buy the software and decide to start writing it yourself. However, just keeping the software as you received it will inevitably end up causing problems, such as security issues.

 
Conclusion

Software solutions tend to rely more and more on external factors that you can not influence as a customer. Therefore it is important to be aware of the risk these external factors bring and what happens when they become unavailable. Your company needs to have a clear idea of which preventive actions to take and how to handle it when a third party becomes unavailable. This blog discussed a number of preventive measures that you can take to make sure the unavailability of third parties will not affect your own business continuity. 

Multi Products Scrum teams are in reality observed often. One team serving different stakeholders and customer segments. Both would like to use the same people to work on their improvements.

In most organizations there tend to be more products than teams. While scaling frameworks give solutions on how to cope with a big Product and orchestrating value delivery among multiple teams. But how to deal with many products and a few Scrum teams?

Read more →