If there's hope for humanity it's in software

Services, Goads and Interfaces

Figure 0: Smart Web Services Architecture, a standards-based model upon which the Sun ONE initiative is based (Click image to enlarge).

The Sun ONE (Open Network Environment) architecture is meant to express the essence of that dream. Services, subscription-based, commodity, and even free, will be the lexicon of those who were once software marketeers, and we'll all consume those services by increasingly smaller, more powerful, more malleable, more better-connected gadgets of all kinds. Our purpose here is clear:

1. Provide services where once we sold software (and hardware)
2. Provide new services using innovative network-based approaches
3. Use existing interfaces where they make sense
4. Invent new interfaces when needed
5. Open is better than proprietary

Or is it really that simple?

We are constrained even as we are enabled by legacy infrastructure on the one hand and Network Age opportunities on the other. As we approach this idea of "purpose" in software design, examining both legacy and opportunity will prove to be useful.

Goads
But first a discussion of "goads," if we can call them that. These tendencies, which we deign to call laws in a descriptive sense, are the meat of Opportunity's entree. Some of the driving forces that we acknowledge in our industry are expressed by one of Sun Microsystems' themes: the Net Effect. The forces alluded to in the marketing guise of the "Net Effect" are the exponential phenomena we characterize as Moore's Law, Metcalfe's Law and Gilder's Law, to wit:

o Moore's Law: periodic (12-24 month) doubling of processor speed
due to shrinking transistors.

o Gilder's Law: periodic (6-12 month) doubling of global
telecommunications bandwidth. (ave. Mb/n-s)

o Metcalfe's Law: the potential value of any network is the square
of the available nodes on the network. V = n^2

These three "laws" and the implications and corollaries to these observations will help us to describe a "fitness landscape" in which the software we create must "make a living." The external forces (called "goads" below) that these laws represent will come into play from a teleological perspective, as goads and drivers for software development. (A goad is a sharp stick used for prodding animals - it also means a stimulus, or stimulation to action).

Interfaces
The currency of software design is the rich set of legacy interfaces we've accumulated over the decades. Now that XML has arrived with the promise of self-describing data everywhere, legacy interfaces become less problematic and more valuable, ensuring a high demand for legacy data for years to come.

Recall Eric Raymond's metaphor of the software noosphere. Once a piece of the noosphere has been successfully "homesteaded," whether via an open-source project, or a large corporate development team, that nugget of innovation has now become part of the legacy. Recall too Kaufman's notion of the "adjacent possible." This can metaphorically describes the innovation space nearest the legacy. While "innovation" isn't exactly the flip-side of "legacy," for the sake of this portrait we'll position them as such. From a software development perspective, there are generally many legacy interface issues. The extent to which legacy issues can be ignored is a measure of how much innovation potential an unexplored section of the noosphere may offer. If we imagine legacy software (interfaces) to be a series of interconnected pieces, the interfaces form the surface of a growing balloon, as in Figure 1. Legacy grows to consume Innovation over time as we imagine the balloon growing outward.

An example of a high legacy dependency project might be a software endeavor tasked with exposing existing automated internal business practices to a down-stream vendor via a trusted, secure Internet server. This sort of software development would need to pay particular attention to existing interfaces, as the adaption and adoption of those interfaces to broader network-service needs is the purpose of the project.

For an example of a project that is less dependent on legacy interfaces and freer to explore innovation, at least in terms of software interfaces, we might consider software for a new device which, while connected to the network (and thus utilizing a vast legacy of interfaces), nevertheless requires a class of service for which there are no existing APIs - say, for instance, a generic heart monitor/pace-maker for humans with Internet-based regular adjustments, alarms and possible services, ("And an ambulance shows up before you even know you need it!") made available on a subscription basis, despite the fact that standardized interfaces for wireless cardio-telemetry are TBD.

Figure 1: The Legacy Balloon Grows Over time (Click image to enlarge).

On the Y axis, also growing in time, are machine-to-machine interfaces and communications, beneath a legacy sphere of machine-to-human interfaces and communications. Clearly growing legacy interfaces provide a growing array of considerations for software developers. It is also important to note other drivers and goads that move the legacy toward innovation. This is where we layer in the goads described above.