Lion van Koppenhagen

About

About this site
This blog — sometimes known as my "Braindump" — is my platform for experimentation and community interaction. It is a way of offloading thoughts.

In almost all industries designers use standard parts. These have been extensively tested and have proven in practice that they do not have hidden defects. This is still not the case when designing software. Design based on components is still stuck in its infancy. There are plenty of standards, but the blocks do not fit together well. This post explores an approach forward using the Lego Analogy.

The Lego Analogy

Lego is a great analogy for understanding the importance of standards. Lego have been making bricks (Lego calls them elements) since the late 40s. It took them a little while to perfect their designs. But since 1958 they’ve been manufacturing bricks in the same way, to the same basic standard. This means that you can take any brick that’s been manufactured over the last 62 years and they’ll fit together.

A commitment to standards maximises the utility of all of the bricks that the company has ever produced.

If you look across all of the different sets that Lego have produced, you can see that some basic pieces are used very frequently. If you ask a Master Lego Builder for a list of their favourite pieces, you’ll discover the same.

Now if we would do the same for software development, what would be the list of elements our Master Software Builder would always need? What do we have to design?

Design still happens

Moving away from Big Design Up Front (BDUF) to Agile does not mean letting go of design all together. We need context or guardrails as some might call them. When less is more, we need insights into definition, features and benefits of minimalism applied to basic elements.

In this post we embrace the new IT and take a generic microservices architecture as the starting point. APIs are an incredibly valuable tool – they unlock data, increase agility, encourage innovation and speed up time-to-value.

This brings us to our first element, the API Catalog. Even though we can develop and reuse without a catalog, developers might create the same or similar APIs multiple times because it was not known that there is already an implementation existing. And that’s just the inside perspective. What about somebody from outside your organization looking for a smart way to integrate and connect with your business? Who to call, where to search, where to ask a question? Usually, this leads to people going to different places in order to solve their requirements.

Our first element, The API Catalog, is the Master Builders list of basic elements.

Which are the basic elements?

This is a question I cannot answer for you. The collection of basic elements is defined by the needs of your organization. This is why a strategic approach to APIs is vitally important to your business. It’s not up to me to decide what should be in your toolbox.

Think about creating a pool of resources generic enough that they can be applied to different projects. Reusing capacity improves efficiency and effectiveness, all the while reducing costs and increasing the potential return from projects.

Principles that should lead you to the elements essential to be in the catalog are:

  • Security by design
  • Privacy by design
  • Telemetry by design
  • Testing by design
  • Scalability by design

Failing to take any of these principles into account will lead to high refactoring cost in the future. Using these principles you can land and expand. Always keeping the big picture in mind but build for immediate use. Build simple blocks and have the teams decide which next block would add the most value.

This article is part of a series of articles themed Legolizing software development. I will post more on my site lion.nu, follow me on linkedin or facebook if you like to read more.

Isn’t it time to move from hindsight to insights?

In the era of the smartwatch we find it normal to know about ourselves with literally a flick of the wrist, we call it quantified self. Isn’t it time to really move towards the quantified organization, to Fitbit your organization?

Buzzwords

We read about big data, data driven decision making and business intelligence everywhere, buzzwords enough, but when it comes to reality we only use it in hindsight.

These days, if I walk into an office, I get an immediate answer when I ask a manager about sleeping patterns or heart rate. However, if I ask about the performance of the main value streams or delays in those value streams, I’m usually directed to the BI-team. If I ask an SMB owner about cash flow, I’m directed to his accountant. Maybe you feel comfortable driving your car without a realtime dashboard but you shouldn’t and the same goes for managing your organization big or small.

Insights, the path to success

When driving you usually at least watch the speedometer on your dashboard, you don’t go to the garage to ask at what speed you have been driving. Why should managing an organization be any different?

While sometimes it’s okay to follow your instincts, the vast majority of your business-based decisions should be backed by metrics, facts, or figures related to your goals.
By leveraging the wealth of data available into insights, it’s possible to make more informed decisions that will lead to commercial growth, evolution, and an increased bottom line. Those insights should be available in now, not later. What’s holding us back?

Scattered data, high complexity

We have so much data but it’s scattered in silos, or using it is to complex, or our IT organization expects us to use BI-Tools when all we want is insights.

About 10 years ago I was asked to come and drink a cup of coffee at a multi-national sales organization. The sales people where send on a Microsoft training SQL Server Reporting Services so they could create the insights they needed themselves. Imagine the panic. I was asked if we could design a simple solution, we could and we did and it became the most used unofficial application in the company.

So how did we do it and how can you do it?

Land and expand

We followed a simple agile path. Think Big start Small. Always keep the big picture in mind but build for immediate use. We didn’t start off building a complete solution. We build simple blocks named in the language of the users that allowed them to correlate data from various sources into reports, without the need to know the source or how to get there. The salesforce decided which next block would add the most value. All reports were based on data in near real time.

You can do the same for/with your organization. By implementing the right reporting tools block by block, you will be able to make the kind of data driven decisions that will drive your organization forward. It isn’t hard and it should not be costly. Just do it!

This article is an introduction to a series of articles themed telemetry by design. I will post more on my site lion.nu, follow me on linkedin or facebook if you like to read more.

“Software development is a serious business, but it is also seriously fun. To put it stronger: If it does not remind you of playing with LEGO when you were still a kid, you are doing it wrong.”

Maurits van der Schee

I have been involved in software development and organizational processes since I was 15 years old. Common sense and laziness have always been the most important guideline for me. Just think about what you want to achieve and do it so that you don’t have to do it again.

In my career, LEGO has always been a source of inspiration in solving issues. Probably because I played with it for hours as a child and learned to solve every challenge by doing it brick by brick.

As a fan of Lego, with a keen interest in science, the feature image is a creation from designer Andrew Carol Senior Engineer at Apple. In case you don’t recognise it, it is a rebuild of what is claimed to be the world’s oldest known computer.  The mechanism is known as the Antikythera Mechanism, part of an astronomical computer built around 150 BC to calculate the movements of celestial bodies.

The image and the quote seemed a good introduction to my article series legolizing software development.

This article is part of a series of articles themed Legolizing software development. I will post more on my site lion.nu, follow me on linkedin or facebook if you like to read more.