Thanks to my wife, I’ve been learning a little bit about systems engineering, a form of engineering that addresses the complex interactions of multiple systems. As she says, you need to consider systems engineering when the interrelationships between systems are as complicated as the systems themselves. For example, to reduce automotive traffic you need to research social behavior, road design, business, and the environment. To study ergonomics you need to study the human body, computer design, application design, and user efficiency needs. And don’t get me started on the U.S. healthcare system.
The very first step of systems engineering is to understand the full scope. Ground transportation isn’t about cars and trains, for example, but about the entire surface of the earth: population clusters, topography, climate, and distances. Taxonomy starts this way too, with facets like people, documentation types, product lines, and access levels.
Or at least it should. Sometimes it’s easier to look at a single component of your world and tabulate it in isolation — department offices, account records, HR data — and imagine someday expanding to something larger. But this doesn’t work, not in the long run.
I did some in-house taxonomy work for a client that had two completely different product lines, among others. One product line was based on people. One product line was based on homes. (For example, imagine a telecommunications company that sells mobile phones to individuals, but installs land lines into buildings.) Each product line was managed by smart people who understood the value of taxonomy; they knew just how badly their departments needed a taxonomy with controlled vocabularies. But it took an independent like me to see the real problem: the departments were completely unable to work together. Why? Because the unique identifiers for the people-based line used people-based IDs — like social security numbers — and the home-based line used street addresses. It was impossible to adequately study the calling behavior of individuals, for purposes of cross-selling and product research.
Not surprisingly, the systems engineering process is the same as the taxonomy process, from input collection and requirements analysis to database design and governance. And in fact, for systems to work together, they need a common language, whether it’s a coordinate system or a list of reserved keywords. As complexity grows, the demand for systems engineering and taxonomy grows too, and in our globalized (dare I say universal) space both are growing very fast these days. Investigation into ever-more-complicated systems is necessary for innovation, and our challenge as participants in this growth is to keep looking for the ever-more-encompassing big picture.
If a taxonomy is a tree, then an enterprise taxonomy is the forest, and you know what they say about seeing the forests despite the trees.
Filed under: Taxonomy Development |