What is a domain knowledge? Domain knowledge implies a knowing of a specific area of knowledge, like plumber knows plumbing. It's quite easy to picture that everyone, or should say every profession, is a its own domain, thus has its own knowledge, which in true, in the same sense that goes by a Chinese saying, 隔行如隔山.
However, if we take it broadly, I would argue everything, every person, has a domain knowledge of a sort that is unique only to that person. Watching those "10 coolest hand-made toys" youtube videos make you wonder how creative this person is, how much time s/he has at hand, and deep down you also know that your brain is not up that, even given you as much time — you two are simply, different. Thus, wouldn't it be fair to say that his/her domain knowledge is different from yours then!? I think so. No two people are alike, which not only means that no two people look identically, but also emphasizes their knowledge repository, the structure of how they think, how they perceive, how they process information and derive conclusion, and how they reason → in short, their domains are just different, thus their domain knowledge will be different.
But "different" is itself a broad concept. It's another always-true statement that people are just different ← the counter argument will be to find a black swan so to prove this statement is wrong. But this type of always-true statement is not refutable. It has positioned the question in such a way that it is simply futile to search for a counter example. Rather, I would challenge the original argument and its definition in order to narrow down the scope of it. Once it becomes more concrete ("being different" is quite an abstract concept, but narrowing it down to "how are they different? they have different colors." Well, that is refutable now, if we further define what is color, and so on...), it becomes actioinable ← we can either prove it right, or wrong.
The reason I am talking about domain knowledge, is that at work I have constantly run into ideas and projects, my own moonlight POCs included, that when presenting to another audience to so called discussions, there are always two tyes of reactions — some find it exciting and like it, and some put out a few concerns and counter example, not to plainly shoot down the idea, but to bring in caution and further discussions → these are all good point. But my question is — how do you distinguish yourself from an existing competitor!?
We recognize a "problem", and think we have a good idea to "fix it". We even wrote some code to POC its feasibility and are hoping to show its value. But the hard question is always, why you!? why yours!? I used to draw this discussion eventually to domain knowledge, that ours is, should be, better, because we have a better domain knowledge, than competitors'. And if there is a work lagging, I would think that they have not done their homework right to discover, consolidate, and benefit from their domain knowledge. This sounds quite alright. But with the arguments I have presented at the beginning of this article, wouldn't it now sound fishy that using this ambiguous term is nothing but to make myself sound smart which, by being an always-true statement, giving others no chance to prove me wrong!?
This is terrible. But I don't want to yet give up its use. Here is why. Take this hardware management tool for example. On one hand there are opensource projects, free of charge; on the other company develops a product. How to make the company one stand out then!? I mean, we will lose to opensource simply by the sheer number of developers, don't you think!? And in nowadays' tech stack, toolsets are increasingly converging, meaning that if I were a front-end developer and am asked to draw a line graph, there are only a few libraries come to mind — they all look alike, regardless how well I can tweak them. And with that we also know that value is not at the line graph even, it is what that graph can tell me, and what I can do with that info, really matters. So how to achieve these two!? Domain knowledge.
I firmly believe this is your only chance to stand out, and should be the only criteria — fundamentally it is information asymmetry. I have already said before that power lies in this, so that's where the power to win over competition lies. There is no other way. Vendor doesn't even need to intentionally build that barrier by using something like a trade secret or patent, which lead to another lengthy debate of moral sense of knowledge. Let's keep an open book. I always argue that when was the last time you were willing to look at someone's code, and could actually understand what it was saying!? or, take any Physics text book, the laws are written down, figured out! Yet, did you ever read them? and fewer understands them even!
Therefore, domain knowledge is not secret, but a theory or practice that is hard to replicate because of its complexity, not of its secrecy. Vendor is naturally positioned in the front row of this race, because they created that product at the first place — naturally, he knows more of it than anyone else ← here, I want to emphasize again that competing on just sheer data point level is going to be a losing battle — collect and display the same data point, CPU, temperature, raid controller models... these are essential, but these are the starting line every racer is at. Your advantage as a vendor should display in the domain knowledge of what those numbers mean, and what we could do with them — CPU goes up 100%, is this good? bad? When upgrading firmware, wouldn't vendor's tool, however ugly it may be, still holds an edge over an opensource approach, simply because we think vendor knows better of that level of operation, and firmware is so fundamental that getting it wrong will just kill your thousand dollar equipment!? These, is what I will call domain knowledge — an edge over others not because we keep information from others. On the contrary, we just know more, know better, and are fully willing to share. But these knowledge, really we should call them experience, like a personal experience, is so hard to transfer, that it makes you, unique, thus valuable.
For these data driven applications, I think we can view them in three layers:
- Do I have data points that others don't have? → protocol, or sheer openness.
- Do I know a scenario of these data points that others don't have? → support cases is a wealthy mine of real world experience.
- When taking an action, can I keep the system stable and healthy better than others can?
I feel we have focuses too much on #1, which leads to competition of cosmetic, user experience, and at most, convenience. However, none of these will give you an edge:
cosmetics: I have already said that toolsets are converging. Your line graph will not be that much different from ours. And even it's pleasing to look at, one quickly gets bored of it, and will ask the question — what does this line mean?
UX: this is an endless discussion, and let's leave it to people who have passion of, humans.
convenience: do you realize that this actually implies that customer knows the same as you do!? They are already doing it, but you think you have a better way. Then of course, the question is, how much better is yours? Well, this is like proving yourself worth being loved this girl, and we all know that's just pointless — she loves, or not, has nothing to do with how good a person you actually are.
Instead, point #2 is a info repo vendor natually has, but simply will not be accessible by the public, and don't we all know how creative and bizarre the real world can be!? This gives you information that is exclusive, and that leads to advantage!
Point #3 should come out of #2, and one failed at this, one should fail to distinguish oneself, because this is where the gold is, this is the domain knowledge. Getting to this is hard, but that's how it should be done.
So this lengthy, ambiguous, argument, is what I think about domain knowledge. Confusing, isn't it!?
— by Feng Xia