This is something I spend a lot of time thinking about. That means I’ve developed some opinions!

Andrew Godwin and Matthew Blair asked me to write a bit of a manifesto that explains what I think we should be thinking about. Read the posts below in any order, but this one first.

I’ll add a disclaimer too. These are my opinions, not BVN policies!

Data is a huge subject. It’s also something that, traditionally, architects aren’t trained to deal with or understand[1. The obvious question (to Barry, I didn’t think of it) is who does feel comfortable with lots of data? Lots of professions need to deal with data: Psychologists, business people, statisticians, bookies, dog breeders, advertising, marketing, stock market traders… and more and more professions are being added to that list as a quantitative understanding of the world becomes a core of their business]. The main thrust of this manifesto is that we should be bold, responsible and flexible.

What do I mean when I talk about data in this series? I’m talking about the things that go into the people and project pages and into timesheets. There are lots of other ways that we make data, and these are all important but I’ll deal with them later on.

Bold in that we should do brave things. We should be as open as possible with our data[1. this is a post, but it’s still internal. I might post it one day]. We should set precedents by defining and controlling the API for our company and our industry.

Responsible by having no admins and taking control over your own data. And by realising that it’s all part of a pipeline.

Flexible by having fluid categories, and having no forced values.

This adds up to an attitude towards data that makes it work for us . Makes it deliver value to us . Not a world where we are its servants.

These are just my ideas. By sharing them I’m hoping that I can mix them with your ideas to turn them into really good ideas that are our ideas! Comment prolifically on all the posts.


There are footnotes throughout. Some are me rambling in a way that would otherwise break the flow. Others are technical points that are there to add weight to the argument but are too technical for the main body of the text.