Opinion
Conway’s law has an evil corollary that goes unnoticed in the dev world but wrecks your data org.
“You think it’s a hack, but all you’re hacking apart is the value of your data.” (the author)
Melvin Conway, a brilliant computer scientist who also invented the notion of a coroutine, has become pretty famous in the last 20 years for a law named after him:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
Turns out this is very important as we move towards the world of domain-driven design and micro-service architectures. The law is also actionable with something called the “Inverse Conway Maneuver”. But his law also has consequences for the world of data, which tend to be no fun.
Let’s back up a bit…
Conway’s Law implies Conway’s Corollary
Recently I observed something that comes as an implication of this law. I like to call it “Conway’s Corollary”, even though I’m pretty sure it’s a very common thing.
Simply put, if your dev department provides people with a tool to name song lists, but does not provide them with a way for adding labels/categories, people will start using the name to do things common in their “real world” domain. They will use the name “X-my-song-list” to mark outdated lists and “JAZZ-my-song-list” to indicate categories, and so on and so on.
To put it into more general terms…
“People will adapt the explicit systems they got to fit the implicit real-world business concepts.”
That sounds like a trivial thing, something like a workaround. But these “implicit concepts” have terrible consequences for the data orgs of this world. These implicit concepts are completely fine, as long as they are not important. But when they become important, the data world comes crashing down…
Why Conways Corollary is so bad for data orgs
The problem is, that the value of data lies in the business domain, not in the technical domain. In our song list example, some typical data applications are a recommendation engine for song lists, or data inside a bi tool to evaluate the feature adoption.
So what will happen? The data people will likely recreate the business concept of “labels/categorization” and extract it from the names. The recommendation engine will need it to exclude archived lists, the BI system will need it to group by categories.
Worse, in this case, two entities will implement this logic.
The problem is, if this context is important in the business world, the “cramping” is gonna grow; With every reuse of the song list concept, the two data teams will have to adapt their understanding of this “implicit business context”.
What do we do about it? We create the context!
The solution is really simple, you either create a new bounded context or put it into one you already got. Technically it’s also pretty easy to do, you just gotta put up a “wrapper” somewhere and fake something till you get it.
In our example, whoever is responsible for the song/song list domain thus creates a little stub, which on basis of the naming exposes two simple labels:
- The category based on the first word,
- and an archive flag based on a leading X.
And that’s it. Sometime in the future, this domain team can then implement actual labels, and make a simple and non-breaking change behind the wrapper while both the recommendation engines as well as the BI system keep on working.
The problem? This is out of the scope of the data org
First of all, this stuff happens all the time. Especially when development teams reuse technical concepts, they sometimes forget the implicit concepts which will be cramped into the technical concepts. And that leads to a dilemma:
- for the development team, this is “just a technical concept”, not actually meant to be a business concept,
- but for the data world, it becomes a business concept, because of Conway’s Corollary.
There’s no easy way to solve this dilemma except to be aware. Architects should be on the lookout for these things. It’s always a good idea to create wrappers in this case which at least encapsulate the concept. Data teams can also create such a wrapper on their side to at least make the problem transparent.
And finally, in my mind, the simplest way out of the dilemma is to have mindful product managers. Because if a new feature/product starts with the question “why do I want to do this? And how do I know I’m moving in the right direction?”, the answer will almost always involve data and the right contexts.