Analysis (Services and Self)

Koan Bremner's view on life as a database and data warehouse professional / addict and non-genetic woman

Thursday, November 18, 2004

Sacred cow #1: "You need good vertical market knowledge to write good vertical market software"

I confess, I've always thought this was true. Until today, that is.

When I used to teach (particularly, when I used to teach data warehousing and OLAP) I always opined that understanding the business was key to deploying those technologies well. It seemed self-evident; if you don't understand the business problem, how can you possibly hope to design, build and deploy a software solution to solve the problem? Or, stating the case optimistically, if you don't understand the business opportunity, how can you possibly hope to design, build and deploy software to exploit that opportunity?

You know, I think I was wrong; at least, I hadn't grasped the fundamental pitfall of that position. Which is (I think) that the more immersed in "how things are done" you are, the less able you are to think "how things *could* be done", "why some things that are being done should no longer be done" and "what isn't being done that *should* be done?"

A case in point from today; talking with a colleague on the subject of some technology I'm developing, which he claims to not completely understand (not yet, at least, but he will!) I've designed it one way, because (from the technology point of view) it's the "right" way. He, however, says that the majority of people who would use that technology in our customers might have difficulty exploiting it; if only users could do it another way (which he then proceeded to explain) the majority of them would find it much easier to exploit. The beautiful part is, with virtually no additional effort I can include the alternate approach. Net result; we enable both power users and occasional users to get what they need, in a way that suits them both.

The thing is, if I had had more in-depth knowledge of how our customers currently work, I would probably have arrived at the second approach first; and maybe not have arrived at the first approach at all. But the interaction of two people (one a technology specialist, who hasn't yet developed a deep appreciation of the business nuances of our customers in this particular vertical market, the other a technologist who understands those business nuances intimately but is a relative newcomer to this particular technology) created arguably a better solution; certainly, a more complete solution.

So I'm wondering if this particular episode is an isolated exception, or maybe (as I suspect) indicative of a more subtle truth; that not only can two minds be better than one, but that by trying to be a generalist (as I used to) you actually run the risk of missing things that two specialists *who share a common vocabulary, and who aren't afraid to ask questions of the other that stem from a lack of knowledge, not a lack of intelligence* will uncover.


This blog has been migrated to new software on a different server ( and comments on this post on *this* blog are now closed. All existing comments have been copied to the equivalent post on the new blog. If you still wish to comment on this post, please use the equivalent post at:


<< Home