Technological Perfecta 2

Following my post on Technological Perfecta on my SOA blog, Tim Bass and Opher Etzion have continued the discussion on Orthogonal Blogging at the SOA Horse Races. Tim writes:

"End users rarely build “SOAs” “EDAs” or CEPs”. End users have IT budgets to solve business problems with the most cost effective technology they can find; and they do not care (if they have a clue) what cute three letter acronyms have been created by analysts to describe momentum in the software market."

Tim's argument here is not about SOA or any other TLA (three letter acronym), but about software innovation in general.

But is anybody asking end-users to build SOAs? To my mind, it is the vendors that are building SOA; they are hoping that their customers will use SOA and related technologies to solve business problems.

But why would anyone want to use new technologies, if the old technologies were adequate? Underlying Tim's post are some fairly fundamental challenges about software innovation.

1. Why should anyone innovate? In particular, why should any individual or organization adopt new software technologies or otherwise change the way they use software to solve business problems?

2. Who should innovate? Should the adoption of new software technologies be visible to developers and end-users, or should it managed by a specialist team of technical architects (either in the organization or in some external supplier) who make sure that everything is transparently efficient and effective for everyone else.

3. When should people innovate? Does it make sense to get in early, or should people emulate the Japanese businessman quoted by Tim: "What we care about are mature technologies with solid reference clients and proven implementations."

4. How should people innovate? Small incremental steps, one technology at a time? Or sweeping changes, adopting an entirely new development paradigm in a single leap? How many simultaneous innovations can an organization cope with, and can (should) this capacity for change be increased?

5. And finally, given that there are so many new technologies to choose from: Which innovations, in which combinations?

To my mind, a strategy for software innovation is not about choosing specific software products, or even classes of software product - it is about managing these five critical questions over time. Specific TLAs will come and go, and software industry analysts will try to create meaningful maps of a complicated and constantly shifting TLA landscape, but there will always be a need for innovation. Won't there?