Turn on, Tune in

In software engineering we spend a lot of time rethinking the ways in which we can make software available to users: applications, packages, components, services, apps, and so on. Each presents a slightly deployment model and commonly a radically different business model. Though many of these delivery 'paradigms' (for want of a better word) have similarities from an engineering standpoint, the different approaches have yielded productive energy and  technological creativity. With some trepidation, for I am usurping, at least in part, a marketing role, I intend to propose a new paradigm - software as channel. To make things easier think here of a TV channel.

Rather than viewing a software application as principally a static entity, intended to support specified tasks with occasional upgrades of features, the channel view regards software as a vehicle for a relationship between software developer and consumer, that is users. The channel delivers functional content to the consumer. Some of this functional content meets the core requirements of the consumer, by analogy evening news or a popular soap opera, subject to occasional changes and improvements but essentially stable. Others are intended to develop and deepen the relationship, extending the reach of the channel, by analogy new programming. Like TV channels some software channels are relatively narrow, specialist sports or home improvement channels, others are broad, offering a wide range of functional content that most consumers require.

The goals of the channel are straightforward: to increase it's reach by extending the number of consumers who subscribe to it, and to maintain the loyalty of existing subscribers. This delivers increased income either by way of advertising or subscription fees (there are other models). It achieves these goals by ensuring the 'mix' is correct between the old favourites and new material, that is in software terms between core capabilities and feature extensions. The assumption is consumers are fickle, they can can channel hop unless they are consistently engaged.

The idea of a channel is not so far from our experience of consumer oriented applications in which  automated updates are continually delivering new added features and fixes. The application in this context should never get stale and should grow with the user. At best it can stretch the user, presenting them with new opportunities - developing new needs and requirements that can then be satisfied through further updates and feature enhancements.

An important part of the channel model is, as I have suggested above, the existence of many mature business models - principally based on advertising or subscription but also including community sourced, donation based and many points in between. Consumers purchase individual channels but often buy 'packages' of channels that reflect their interest. Premium channels are often in packages with a range of secondary offerings.

So, what are the engineering implications of the channel paradigm? Truthfully, I am unsure. Clearly it changes the orientation from product or service delivery to a relational stance. In other words the goal of the engineer is to, on a continuing basis, engage and stimulate the consumer. The approach changes the nature of system requirements which are no longer one-shot, given by the user. Update and change cease to be a by-product of a development strategy but are rather the key to the ongoing business. The proposed approach entails building highly performant cloud-based services backed by highly-tuned user-focused client-side applications specific to the individual platforms and maintaining a seamless consistency of data and resources. This has architectural implications that will need to be worked out. Delivering continuous change may have implications for stability and integrity.

This idea is a sketch, but one I feel that is suggestive of new questions and new possibilities. I invite comment.