Tag Archives: Patterns


Experiences with Holacracy

There is a growing number of books on holacracy. One of the first on this subject without even coining the term was Eckart’s Notes. Also the ones on Semco (like Semco style and Maverick!) are gaining popularity. These all describe case studies, where Reinventing Organisations shows development stages in organization. These in turn are based on literature and case studies like the one that is described in Eckart’s Notes.

Since we are experimenting with holacracy at Bol.com I recently read Getting Teams Done. It gives a great introductions and offers a practical approach.

Holacracy cases

Recently there were some case studies and testimonials of the use of holacracy published at Medium.
Path to holacracy

The Dutch design company Concept7 has experimented with a number of ‘management styles’ over the years. Their objective has always been clear: to foster freedom and empowerment in their employees. The entire staff has been working with holacracy for a few years now. Lauren shares her story.

The founder of Voys, Mark Vetter, has always believed in self-organisation. He claims holacracy has brought us accountability, entrepreneurship, and faster evolution. Check Mark’s story on getting things done in a company. The Voys way is published in a book on the way they are organised.

The founders of the Dutch ‘user experience’ company Valsplat believe it is utmost important to bring your whole self to work, or even express or develop your talents. Nils claims holacracy has provided me with tools that help me focus. He states:

Holacracy helps us to become the best possible version of ourselves

Boek – Getting Teams Done – Spark

Getting Teams Done - SparkHet boek Getting Teams Done is een leuk introductie in Holacracy. Dit boek introduceert de methode waarmee leidinggevenden, teamleiders managers en zelfsturende professionals de teamproductiviteit naar een hoger niveau kunnen tillen. Holacracy wordt bijvoorbeeld ook gebruikt als organisatievorm bij Zappos (lees ook Delivering Happiness).

Getting Teams Done is geschreven in de stijl van Het Doel / The Goal en The Phoenix Project. De romanvorm wordt daarbij in dit geval afgewisseld met een non-fictie deel waarin wordt uitgelegd hoe Holacracy werkt en waar het een oplossing biedt. Daarnaast wordt in dat deel steeds het proces en de ondersteunende technieken uitgelegd.

Het boek Getting Teams Done is een aanrader voor iedereen die geinteresseerd is in Holacracy en zeker voor diegene die werkt voor een organisatie waar Holacracy of een variant als Spark ingevoerd wordt. Het invoeren van Holacracy of Spark vraag een zeer sterke discipline. Daarbij is het handig om hulp van buiten te hebben die buiten de inhoudelijke en andere discussies staat. Op die manier kan er sneller mee aan de slag gegaan worden en kunnen de resultaten eerder worden bereikt.

Velocity 2015 Amsterdam

Thursday was a very interesting day for me at Velocity 2015 Amsterdam, build resilient systems at scale. It is one of the best conferences I attended in the last years. Using some quote’s and bullets I’ll give a little insight.

On retro’s, post mortems, etc

Lindsay Holmwood showed that what goes wrong in retrospectives, post mortems and the like is mostly based on:

  • Confirmation bias – aka ignore alternatives
  • Hindsight bias – aka – alter memories to fit a narrative. Talk about events with the knowledge of the outcome.

To overcome these we could use techniques like: Take opposing viewpoints (on purpose, to investigate things), contrarian thinking, let people explain stuff in terms of foresight and all kinds of sharing information.
In short for this to work we need a safe environment where people can speak up. Starting from the believe that everyone did the best they could. And always keep in mind that there is a difference between work as imagined and works as done.

Optimizing teams in a distributed world – Conway’s 3 other laws

Conway’s Law stems fro the greater part from his 1967 paper: How do committees invent.
The slides and all references mentioned in the presentation.

  1. Whose structure is a copy of the organisation’s structures. To put it different: Communication dictates design. Also check The Mythical Man Month and Dunbar’s number. So manage communication between teams.
  2. – Doing it over – There is never enough time to do something right, but there is always enough time to do it over. Engineering and architecture are always about: Trade offs. Also check: Satisfying vs Sacrificing. So remember it is a continuous process.
  3. If you or your team cannot explain all the code in your release package your release is too large.

  4. Homomorphism – If you have 4 groups working on a compiler, you’ll get a 4-pass compiler. So organise teams in order to achieve what you want (around business capabilities).
  5. Disintegration – The bigger they are, the harder they fall. Time is against large projects and teams. Aim for a scope that supports a release cycle of two weeks or less. So keep your teams as small as necessary.

It is better to be too small than too big.

We are all DevOps

One of the best talks on DevOps in the Etsy world by Katherine Daniels.

On hiring:

It is easier to teach someone a new technology skill, than to teach someone not to be an asshole.

Continuous Delivery at bol.com

Last month two of our software engineers Mihaela Tunaru and Mary Gouseti were invited to give a presentation of how continuous delivery is done at bol.com. The presentation gives a good insight in the state of continuous delivery at bol.com from a software engineering perspective.

In case you want to know more from the operations perspective check Mayfly on GitHub and the presentation below. Maarten Dirkse gave a talk Docker your user stories using Mayfly.

Mayfly is a development platform built by bol.com. Mayfly speeds up your service development by wrapping your scrum user story code in containers, testing it in an isolated, production-like environment and automatically enforcing your Definition of Done.

Finding billion dollar startups in Europe

The WSJ billion dollar startup club

The Wall Street Journal and Dow Jones VentureSource are tracking venture-backed private companies valued at $1 billion or more. This group of companies is called the billion dollar club.

The infographic created by the WSJ can be used to track how the membership of this club evolves and what the valuation of these companies individual and as a group is. In line with the findings in the Digital Evolution Index there is a limited number of European companies in the club and their number and valuation aren’t growing as fast as Asia and USA ones.

In January 2014 only 2 of the 42 companies in the billion dollar club are from Europe. In September 2015 just 10 of the 118 are European based companies. Here is the list of billion dollar startups in Europe:

  • Spotify
  • Global Fashion Group
  • Delivery Hero
  • Powa
  • Adyen – Read: The unicorn of Amsterdam
  • BlaBlaCar
  • Klarna
  • Home24
  • Shazam
  • Farfetch
  • Funding Circle

Rocket Internet and Zalando exited the list in October 2014 because of their IPOs. All are located in the countries with the best internet infrastructure: United Kingdom (London), Sweden, Germany, The Netherlands, Luxembourg and France.

The TechCrunch billion dollar startup club

Besides WSJ and Dow Jones VentureSource TechCrunch also curates a list of Unicorns. A Unicorn being a private company with a post-money valuations of $1 billion or more. The TechCrunch Unicorn Leaderboard features one European company that isn’t listed at the WSJ’s list: Auto1 Group from Berlin, Germany.

The picture in both leader boards is the same: there is a relative low number of billion dollar European startups. It is the same in the emerging Unicorns list.

Does Europe fall behind?

Looking at both the WSJ and TechCrunch list of unicorns and the findings in the Digital Evolution Index it certainly looks like Europe is falling behind. If the EU wouldn’t agree why would they have bothered to start a digital agenda (a Europe 2020 initiative)?

Thomas Petersen has written Why is Europe failing to create more unicorns? Mainly stating that there is no true single European market, the EU doesn’t make it better for entrepreneurs (yet worse because of legislation and political sub optimisations), and there is geolocation where both money and technical knowledge gravitate to.

Besides those, there is a reason that al European unicorns are situated in the countries with the best internet infrastructure. Larger parts of Europe aren’t in that position yet.
Some of the European countries with unicorns are in the stall out group in the DESI index. Meaning that measures should be taken to get their momentum back because they run the risk of falling behind.
Again Europe should work really hard on creating a true single digital European market. Reducing the number of laws and trade barriers is key.

Presentatie op LAC congres – Agile architectuur presentatie

verleiding - Agile architectuur presentatieWoensdag 26 november en donderdag 27 november is het jaarlijkse LAC congres. Dit congres voor architecten in de wereld van organisatie en IT heeft dit jaar als thema: “Architectuur in Actie“.

Presentatie Afweging waarde van architectuur en time-to-market

Op donderdag zal ik een Agile architectuur presentatie geven in de track architecuur in actie: “Afweging waarde van architectuur en time-to-market

Zo’n beetje iedere architect of ontwikkelaar komt op het minst in de verleiding: een snellere time to market realiseren ten koste van de architectuur of de kwaliteit van de implementatie. Het komt voor in software-aanpassingen, maar ook meteen bij de introductie van nieuwe technologie. Aan de hand van voorbeelden uit de afgelopen twee jaar, laten we zien hoe we hier bij Bol.com mee omgaan. Bij een bewuste keuze kan architectuur of de architect wel eens de factor zijn die de versnelling kan realiseren.

Het complete programma van het LAC congres.

Service Bus definition

While preparing guidelines for the usage of the Oracle Service Bus (OSB) I was looking for a definition of a Service Bus. There wasn’t one on my blog yet (more posts on integration) so i decided to use the following and share them with you.

Forrester Service Bus definition

From 2009 Forrester has used this one:

An intermediary that provides core functions to makes a set of reusable services widely available, plus extended functions that simplify the use of the ESB in a real-world IT environment.

Erl Service Bus definition

Thomas Erl offers the following description of a Service Bus::

An enterprise service bus represents an environment designed to foster sophisticated interconnectivity between services. It establishes an intermediate layer of processing that can help overcome common problems associated with reliability, scalability, and communications disparity.

An Enterprise Service Bus is seen by Erl et al as a pattern. That is why it is even more important to share what that patterns is. Later on I’ll also shortly describe the VETRO pattern. Also a very useful pattern to use when comparing integration tools or developing guide lines.

Erl Enterprise Service Bus pattern

On the SOA patterns site we learn that an enterprise service bus represents an environment designed to foster sophisticated interconnectivity between services. The Enterprise Service Bus pattern is a composite pattern based on:

  • Asynchronous Queuing basically an intermediary buffer, allowing service and consumers to process messages independently by remaining temporally decoupled.
  • Service Broker composed of the following patterns
  • Data Model transformation to convert data between disparate schema structures.
  • Data Format transformation to dynamically translate one data format into another.
  • Protocol bridging to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.
  • Intermediate routing meaning message paths can be dynamically determined through the use of intermediary routing logic.
  • With optional the following patterns: Reliable Messaging, Policy Centralization, Rules Centralization, and Event-Driven Messaging. Also have a look at slide 12 etc of the SOA Symposium Service Bus presentation.

VETRO pattern for Service Bus

The VETRO pattern was introduced by David Chappell, writer of the 2004 book Enterprise Service Bus.

  • V – Validate: Validation of messages eg based on XSD or schematron.
  • E – Enrich: Adding data from applications the message doesn’t originate from.
  • T – Transform: Transform the data model, data format or the protocol used to send the message.
  • R – Routing: Determine at runtime where to send the message to.
  • E – Execute: You can see this as calling the implementation.

We also used this pattern to compare Oracle integration tools and infrastructure. It can be very well used while choosing the appropriate tools for a job and deciding on guidelines on how to use these tools.

Dis-economies of centralization

While in a previous post I was arguing that we should handle industry models with care, because of very inconvenient side effects. This week I’ll blog in a similar way on centralization. Among the effects of centralization are often overlooked or neglected dis-economies of scale.

Dis-economies of scale

One of the main reasons for centralization is to gain economies of scale. Less known are the dis-economies of scale. I’ll give some examples in the paragraphs below.

The cost of communication between the central group and the rest of the organization. Although there are lots of tools that make communication easier. Distance in the physical sense or within an organization can create boundaries. These have to be dealt with and there are costs incurred for that. Besides that it has to be clear who to communicate for what matters. This, in my experience, is not always the case. With a greater (organizational) distance more effort has to be put into this.

There is a large possibility that top heavy management in a centralized department becomes isolated from the effects of their decisions. In other words the feedback loop is broken. Because the communication loop is broken, decision become more and more dysfunctional. This due to the lack of real world knowledge that should be incorporated in these decisions.

Centralization can lead to reduced agility. On one hand standardization is a great asset. The larger part of architecture, whether it is enterprise architecture, process architecture or infrastructure architecture, is about standards and reducing the “solution space”. This has several advantages, among which the reduction of software- and systems entropy. The downside of a centralized body that maintains standards is that it probably will lead to inertia and unwillingness to change.

I’m a big fan of (open) standards. They simplify life! However we should not neglect that standardization comes at a cost. There are the costs for implementing, adapting to and maintaining standards in our organization. Say for example that we use a canonical (data) model. There is are maintenance costs (at least some effort) while adopting to change outside and within our organization. These costs of standardization tend to be hidden.

What to do?

Bring the effects described before into the business case for centralization. You did make sure that there was some sort of trade off when you decided to centralize a certain part of your organization didn’t you?

Take measures to prevent these risks. It goes without saying that these measures will take effort, time and possibly money. Now you know you’re going to take measures don’t you?

It is about how you use technology

You might have read here or on other blogs that SOA isn’t a purpose. It is a means to an end. The same goes for all the technologies that we use when implementing a SOA, or an architecture, or an application in general. So I wanted to share the next video with you since I think that it – in an even broader perspective – shows this point. Technology itself is not good or bad. It all boils down to how we as people use it.

Source: RSA.org 21th century alignment.

Using a Service Bus to connect the Supply Chain

So here is my presentation from the SOA Symposium 2010. Hope you enjoy it:

SOA Cloud 2011 Brazil

SOA Cloud Symposium 2011

The SOA Cloud Symposium 2011 logo has just been released. In 2011 the SOA Symposium will be held on April 27 and 28 in Brasilia the capital of Brasil.