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.