All Posts in Technology

|In: App Dev Methodologies|Last Updated:

I’m giving myself a Memorial Day break. I didn’t post anything yesterday, and today is a re-run, from, as the Beatles might have sung, 20 years ago today.

It’s a bit esoteric, but even more relevant today than when I first wrote it.

Take a look and let me know what you think about it.

– Bob

# # #

If there’s one certainty in our business, it’s that useful, lightweight frameworks turn into bloated, productivity-destroying methodologies.

And so it was with considerable trepidation last week that I suggested we need another methodology, to do for Content Management Systems (CMSs — the technologies we use to manage unstructured information) what normalization and related techniques do for relational database management systems (“Unstructured data design — the missing methodology,” KJR, 5/17/2010).

But we do. As evidence, I offer many of the comments and e-mails I received suggesting we don’t: Most pointed to the existence of well-developed tools that allow us to attach metadata to “unstructured content objects” (documents, spreadsheets, presentations, digital photos, videos and such, which we might as well acronymize now and have done with it: For our purposes they’re now officially “UCOs”).

And many more pointing out that search obviates the need for categorization.

Let’s handle search first, because it’s easier: Search is Google listing 16,345,321,568 UCOs that might have what you’re looking for. It’s also what leads to (for example) searches for “globe,” “sphere,” “orb,” and “ball” yielding entirely different results.

Search is what you do when you don’t have useful categories.

And then there’s metadata — the subject that proves we don’t have what we need. Because while we have the ability to attach metadata to UCOs, we have only ad hoc methods for deciding what that metadata should be.

Some readers suggested this might be a solved problem. Books are UCOs, and librarians have been categorizing them for centuries. Between the Dewey Decimal System and the Library of Congress Classification, surely there’s a sound basis on which to build.

Maybe there is. I’m skeptical but not knowledgeable enough to state with confidence they won’t work. I’m skeptical because their primary purpose is to place books in known locations in the library so they can be readily found, which means they’re probably similar to the single folder trees we need to move beyond.

What we need, that is, is the ability to place one UCO in as many different locations as anyone might logically expect to find it. To use one of my own books as an example, Leading IT: The Toughest Job in the World would fit in at least these categories: Leadership, Information Technology, Staffing, Decision-making, Motivation, Culture change, and Communication skills.

The official name for the discipline of defining knowledge domains … what we’re trying to do … is ontology. It’s an active area of development, including the creation of standards (such as OWL, which puzzlingly stands for “Web Ontology Language” instead of “Ontology Web Language,” but let it pass).

From what I’ve been able to determine, though, it appears everything being developed thus far falls under the heading of tools, with a useful methodology nowhere in sight. This is, perhaps, unsurprising as it appears philosophers have been discussing the subject at least since Aristotle first introduced it 2,350 years ago or so, without yet arriving at a consensus.

It could be awhile.

Of course, philosophers are obliged to develop systems so universal they apply, not only to our universe, but to all possible universes. Such is the nature of universal truth.

We don’t need to be quite so ambitious. We merely need to categorize information about our businesses. To get the ball rolling, I’ll offer up the framework we’ve synthesized at IT Catalysts. It enumerates ten topics that together completely describe any business — five internal and five external. They are:

Internal

  • People: The individual human beings who staff a business.
  • Processes: How people do their work.
  • Technologies: The tools people use to perform the roles they play in business processes.
  • Structure: Organizational structures, facilities, governance, accounting, and compensation — how the business is put together and interconnected.
  • Culture: The learned behavior people exhibit in response to their environment, and the shared attitudes that underlie it.

External

  • Products: Whatever the business sells to generate profitable revenue.
  • Customers: Whoever makes or influences buying decisions about the products a business sells.
  • Pricing: What the business charges for its products, terms and conditions of purchase, and the underlying principles that lead to them.
  • Marketplace: The business “ecosystem” in which the company exists, including customer groupings, competitors, partners, and suppliers.
  • Messages: How and what the business communicates with its marketplace.

There you go — a free gift, if you’ll forgive the redundancy. Just break these topics down into sub-topics and sub-sub-topics. The result should be a workable classification scheme.

Let me know when you’re done.

Comments

|In: Strategy and Tactics|Last Updated:

Is Chronodebt ever a good idea?

Chronodebt is the accumulated cost of remediating all IT assets that aren’t what engineering standards say they should be.

It’s what most of us have been calling “technical debt,” and I would too except that Ward Cunningham and his fellows at the Agile Aliance have already claimed it to mean “the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.”

Anyway, the short answer is yes. Taking on Chronodebt is, in many circumstances, exactly the right choice. The conundrum preceded the advent of business computing by at least a century, when, during construction of the transcontinental railroad, the Southern Pacific Railroad, was faced with a shortage of hardwood railroad ties.

And so, instead of waiting for enough hardwood ties to continue construction, it took on massive Chronodebt in the form of ties made of cheaper and plentiful cottonwood (“Cottonwood now or hardwood too late?“, KJR, 4/28/2003).

The cottonwood ties would only last a few years, but with them the company could generate enough revenue to replace them. Without them it would never have completed enough track to sell a single ticket.

The significant difference between this and most modern companies’ Chronodebt is that the Southern Pacific Railroad paid its Chronodebt off.

Chronodebt, like most other forms of debt, is neither good nor bad as an absolute. As with most other decisions, context matters. In the case of Chronodebt it all depend on what stage of concept development you’re in.

Imagine your “concept” barely deserves the term — it’s really more of a notion. You think it has promise, but you don’t have much in the way of supporting evidence to support it.

It’s time to bet the farm!

And it is, but only if you’re betting someone else’s farm, “someone else” is someone whose friendship you don’t value very much, and you’ve checked with your lawyers to confirm you aren’t at risk when someone else finds themselves farmless.

If it’s your kids’ college fund it’s time to launch Excel, or maybe Access, or an ISP’s generic eCommerce development kit.

If it isn’t all about you … if we’re talking about a corporate setting and it’s a proposal to try something new and different for which there isn’t and can’t be much data to bring to bear on the decision … then it’s still time for Excel, or maybe Access. Or, because it’s a corporation, perhaps SharePoint, or some SaaS product whose licensing terms aren’t too expensive and onerous.

It’s time, that is, for Chronodebt, because doing things the so-called “right way” probably means missing the opportunity altogether. And in fact we might not be talking about Chronodebt at all. Chronodebt in this situation comes from the danger of success, because it only has to be paid off if the idea pans out. Success is, to push the metaphor to the breaking point, the usurious interest rate charged for underinvestment, which wasn’t underinvestment until success happened.

Chronodebt is a good idea during the exploratory phase of innovation management. It’s a bad idea when innovations start to prove out. That’s when it’s time to replace the kludges and prototypes you built the new concept on with more robust and scalable alternatives … time, that is, to pay down the debt, which means investing in sustainability.

That isn’t the whole story, though.

There are times when a company’s whole business model starts to approach its use-by date. Imagine, for example, you’re CEO of a metropolitan daily newspaper and your presses are a major source of corporate Chronodebt. Time to pay it off by replacing them with something more modern?

Probably not. Like it or not (I don’t), newspaper print circulation has been steadily declining for decades and the more important metric — advertising revenue — is in even sharper decline. The best and most advanced presses money can buy won’t sell a single additional newspaper, or, more importantly, attract more advertisers.

As CEO, you tell the god Chronos to take a hike.

If, on the other hand, your on-line news site or mobile app are Chronodebt-bound, that’s another story entirely.

None of this is particularly complicated. And yet, especially in IT circles, we do have a tendency to consider engineering excellence to be an unalloyed and immutable good.

Sometimes, prototypes and kludges are exactly what the situation calls for.

And sometimes the right answer, although painful, is limping along on your ancient legacy systems until they crumble into dust.

Comments