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.

Welcome to the third part in my series about legolizing software development. In this third part of the series I selected this essential (by design) element first because I, just like most of us working in the software industry, perceive it as an additional burden.

To prevent my own prejudice clouding the subject matter, I asked a friend from my college years, Tony Lemmers, Data Protection Officer, to join me as a co-writer exploring this topic.

Introduction

With the new global emphasis on privacy and the legal consequences of non-compliance, we do not have the option to fail fast, learn fast, we can’t get away with a number of 9s, because the penalty on failing might sink our business. In theses political uncertain times, defending privacy is paramount to the success of every enterprise. The threats and risks to data are no longer theoretical; they are apparent and menacing. Tech decision makers have to step in-front of the problem and respond to the challenge. Privacy by design is part of the high-level design of software systems, with emphasis on the system’s structure and the non-functional requirements it needs to meet.

Privacy by design (PbD) is a policy measure that guides software developers to apply inherent solutions to achieve better privacy protection. For PbD to be implemented successfully, it is important to understand developers’ perceptions, interpretation and practices as to informational privacy (or data protection).

We’d like to share our lessons learned about architecture, development environment, security considerations and privacy considerations with you. We will also explain some issues we stumbled over and what solutions we chose to solve them.

In the first part of our exploration on the subject, we start off outlining the two main elements in this exploration:

  • Cultural change
  • Non-functional requirements

Cultural Change

Analysis of the way of working in projects in the past revealed an interplay between several different forces affecting the way in which developers handle privacy concerns.

We discussed and analyzed the cognitive, organizational and behavioral factors that play a role in developers’ privacy decision making. We identified three key elements:

  • Our findings indicate that developers use the vocabulary of data security to approach privacy challenges. This vocabulary limits their perceptions of privacy mainly to third-party threats coming from outside of the organization;
  • that organizational privacy climate is a powerful means for organizations to guide developers toward particular practices of privacy;
  • that software architectural patterns frame privacy solutions that are used throughout the development process, possibly explain developers’ preference of policy-based solutions to architectural solutions.

Framing these findings leads us to the factors that can influence developers’ privacy practices and allows us to use them as a guide for working toward a more effective implementation of PbD.

Non-functional requirements

A Non-functional requirement (NFR) specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. The plan for implementing PbD NFRs needs to be detailed at the start of designing the basic system architecture, because they are architecturally significant requirements.

The general believe is that the GDPR forbids a lot of things. This is not the case. GDPR mainly requires us to think before acting. The same is the case for development. Here are some simple steps to aid in this process.

  • Do you need PII (Personal Identifiable Information)?
    If for example you need to know whether a user of your application is older than, let say, 18 years. You could ask for his/ her birthday but that is PII. Is is better and simpler to ask ’Are you older than 18 year?’
  • Which legal basis do you use to gather the PII?
    GDPR offers six possibilities here;
    – Performance of a contract,
    – Compliance for a legal obligation,
    – To protect the vital interest of the user,
    – Public interest,
    – Legitimate interest,
    – Consent
    In software development, performance of a contract or consent are the bases that are most used. Of these two consent is the weakest because it can be withdrawn at any moment and has to be presented in a clear and easily accessible way.
  • Only gather the PII you need and have a basis (see point 2) for.
    When you need someone’s address because you’re sending them something it’s not necessary to ask about gender. The package will get there without knowing the gender and you have minimized the PII you gather on someone. Also if you have less information on someone there is less to protect, store, etc. .
  • You can use the PII you gathered on someone only for the purpose for which you gathered it.
    There is an exemption on this, if a new purpose is similar to the original purpose, than it is allowed, otherwise this is one of those few things that are forbidden.
  • Take care that the PII you have is up-to-date.
    This is not only useful for yourself but also a requirement from the GDPR. So ask your users on a regular basis (once a year) if there data is correct. Not only to comply with GDPR but it is also good business.
  • PII is like money, so protect it the same (or better) way as you would protect your money.
    This protection should both be technical (separated databases for PII with better encryption and pseudonymization) but also organizational. This means the people should only have access to the PII they need access to and that there should be access controls in place. The first fine which was given in the Netherlands was for the lack of good access control by a hospital.

This concludes our introduction to PbD. Feel free to contact us if you feel we can be of help.

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.

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.