How to Create Business Value with Semantic Tech
I recently tweeted that we build ontologies to create business value. I meant that we build Semantic Technology-based software to empower our customers to create business value (or to create it for them). In reply, a few people said they’d like to hear more.
What is business value?
As Coda Hale put it, business value is anything that makes it more likely that someone will give us their money. That’s what business value means to us at C&P. But we usually provide software (or services) to (or for) our customers, in which case we’re interested in creating business value for them.
Generally, business value is anything we do or build that lowers our customers’ costs, increases their revenues, or increases their profit margins.
Information technology (IT) is conventionally thought to be tied to business value by way of worker productivity. (Read Hal Varian’s Economics of Information Technology—I’m just stealing bits from it.) That is, IT increases unit of economic output per unit of labor input. There are variants and corner cases; for example, using IT to identify new, high-value customers. But all of those cases can be (or so I’m assuming) expressed as productivity gains.
So my tweet the other day comes down to this:
We use semantic technologies to lower our customers’ operational costs and raise their productivity. That directly creates business value for them, which indirectly creates it for us.
Semantic technology and business value
I suggest four reasons why semantic technology increases business value. In other words, semantic technology’s value proposition is based on (at least) these four competitive advantages.
Cooperation without coordination
Coordination costs are non-trivial in IT: there are a lot of fiddley details that have to be right or stuff just doesn’t work. Programmers complain about this all the time, but it hurts everyone in IT. You either know and are pissed about this; or you don’t know it, in which case, I don’t have much to say to you…
Semantic technology lowers IT costs because it enables cooperation without explicit, synchronous coordination. (I owe “cooperation without coordination” to David Wood; I’m deeply peeved that he said this before I did!)
There’s a hierarchy of costs: explicit, synchronous coordination is the most expensive; implicit, asynchronous is the least expensive. Packing “exchangable smarts” into the data—which is, more or less, all Semantic Technology does—pushes IT work down the hierarchy of cost.
Programmers like to pretend no other type of IT work (Q&A, testing, design, management, etc.) is as valuable as software development. More sympathetic with them, I could not be! But it’s still a fantasy: those other IT jobs matter, too. This is relevant here because pushing smarts into code tends to alienate, confuse, or silence non-programmers.
Pushing smarts into the data empowers everyone equally (or, more equally), since everyone is (or should be) a data stakeholder.
Appropriate abstractions
Another aspect of “exchangable smarts” to drive down IT costs is the standardized use of appropriate abstractions. Put the other way ‘round, inappropriate abstractions increase IT costs.
What is an appropriate abstraction? Some core, key abstractions in Semantic Technology include: the URI, URL, URN jumble of identification-naming-etc technologies; HTTP (especially when used restfully); and metadata as first-class entity. I won’t rehearse this story, since it’s been told a lot, but this chunk of tech is appropriately abstract from low-level, often physical and other implementational details that should be hidden from others as much as possible.
Abstractions are key to cost control in IT since, when done right, they act as firebreaks: a mechanism to manage chaotic, third party action. In other words, appropriate abstractions prevent third party changes from rippling through entire informational ecosystems. Those ripples are expensive; if we can avoid some or even many of them, we drive down the costs of otherwise unavoidable changes, which don’t necessarily increase business value.
In other words, appropriately abstract, that is, loosely coupled systems beat tightly coupled systems over large scales and long distances, largely by isolating consumers and producers from unnecessary changes.
Declarative is better than imperative
Same song, different verse…Declarative beats imperative because, in the end, it is often a more appropriate abstraction. Software build systems are declarative because who cares? Who wants to spend their life telling computers what to do, when it’s possible to build better systems by describing domains of interest using machine-understandable little languages, DSLs, ontologies, rules, etc.
Semantic Technology is all about declarativeness as evolutionarily superior to imperativeness.
Correctness when it matters; sloppiness when it doesn’t
This is the humane, pragmatic form of the eternal debate between so-called neats and scruffies. It just means that sometimes stuff has to be exactly right and, other times, it doesn’t.
The canonical example of the former is medical diagnosis systems. You don’t want those things to be…sloppy. You want them to be crisp and provably correct. On the flip side, some other use cases admit of a certain sloppiness, for a variety of reasons. The primary reason is that—as Google keeps demonstrating—if you have enough data, signal always beats noise (eh, you know what I mean).
Some Sem Tech peeps want to leverage their sacred cows by arguing that the other part of the spectrum is rubbish. My point is and has always been, simply, that only Semantic Technology spans the entire scruffy-neat spectrum, running from the Linked Data Web to hard-core, formal OWL ontologies, respectively. Only Sem Tech lets you roll, naturally, from no schema, to some schema, to super, hard-core formal schema—all in the same, compatible family of languages.
This flexible complexity is the semantic juice; the people who keep trying to shorten this spectrum should…just stop doing that. It’s a boneheaded strategery! Live and let live and we will all win.
Conclusion
That’s the basic argument in general form. Next week I’ll post another article with details and examples from the C&P technology stack.
Feedback: Comments Toggle Comments –>
