Wednesday, September 19, 2007

"Big T" Technology vs technology

It's certainly no news flash that new technologies get hyped, witness Object Oriented Programming, "Write Once, Run Everywhere" Java, and the Iridium satellite phone system (launched November 1, 1998, went into bankruptcy August 13, 1999). While all of these particular technologies are now in use, what's expected of them has all been severely cut back to realistic levels.

When technologists and developers fall in love with a technology, what they're really getting enamored of is a "Big T" Technology, which encompasses their vision of what a technology can provide and how it can change the world. And not surprisingly the passion of this attachment can both blind its promoter and, while perhaps admitting a surface awareness that not everything about the Technology is perfect, be utterly convinced that it can change and result in a perfect marriage.

(I don't want to convey the impression that all big-T Technologies are overwrought and destined for disappointment, the World Wide Web is certainly such a Technology, and it has changed the world.)

In the POET framework, the 'T' that's being addressed is, if not a world-changing Technology, at least intended to be a business-changing one.

My concern about this is that the small-t technology that's the foundation of the big-T Technology gets insufficient attention paid to it.

As an illustration, business executives doing strategic planning may decide that they need to provide (big T) Web Services employing a Subscription Model for their customers' Mission Critical Data. There, now go work the Politics, Operations, and Economics. The tech'll be purchased off the shelf and we'll have their consultants work with our people to roll out the whole thing. Obviously without the "tech" none of this will work, and Joel Spolsky of Joel On Software provides some insight as to what it really takes to "roll out the whole thing". See also "The Price of Performance" in ACM Queue for another look at how an insufficiently broad view of technology would have had costly real-world business impacts to Google.

In these two references, insufficient awareness and addressing of low-level technical issues would have had significant business impacts. But you might argue that these were caught by the POE process, so everything worked out as it should. However, Joel Spolsky is a tech-savvy (note the small 't') CEO that still writes code for his company, and Google is, well, Google.

Other companies do their due diligence to find the right Technology to implement their business processes and system architectures and still wind up with Service and System failures because the software implementing the Technology is full of bugs.

The Technology aspect might be asserted to be "important", but it's still last in priority, meaning that to those working the project management's not important, and the result of this is that the technology gets treated as a commodity, to be selected primarily based on features and price (and marketing).

I'm not saying that a corporate VP needs to ask what programming language or networking protocol a given product is using (though it would certainly catch the vendor's attention if they did), but someone in the technology evaluation hierarchy should. Along with asking for a description of the vendor's development process, their QA (Quality Assurance) and CM (Configuration Management) practices, and their customer bug reporting and fixing process. It doesn't need to be CMMI or ISO certified, but it should certainly be coherent and plausibly capable of resulting in the production of good software.

It's more than getting past the marketing hype of Big-T Technology, most everyone tries to do that now. It's a matter of respecting, understanding, and acknowledging the criticality of the foundational technology that underlies the Technologies you're going to use, not treating it as a commodity, and feeding that into your decision making process.

And as I posted previously, I'm concerned about what's happening to the quality of the foundational technologies as they're continuing to evolve.

No comments: