At the first Internet of Things and Distributed Ledgers Hackathon, Barclays Rise Hackspace, Notting Hill, London, 7 November 2015.
Archive for the ‘Spimes’ Category
A data architecture for spimes
Thinking some more about spimes, those product entities that exist individually in space and time. I can see they could lead to major changes in the way in which marketing data is collected, collated, stored, analyzed, and used. Clearly, individual spimes and their wranglers will generate a lot of data as they interact with the world and report back (eg, via RFID and GPS), and that data could usefully form the basis for marketing knowledge and marketing action. But the web changes everything. Spime wranglers, being intelligent human beings and companies, could comment and reflect on their interactions; the social web allows them to meet each other, across space and across time, in the same way that a houseowner can “meet” the previous or future occupants of his house. Likewise, intelligent spimes could also reflect on their interactions, and even wrangle less-intelligent spimes.
What software architecture is appropriate for this mass of data? Clearly, we’d want to store all the data, regardless of its format, in databases. My question is pitched at a higher level of abstraction than that of the databases. We desire that multiple, independent agents (both people and devices) are able to access the data, to read it and contribute to it, and maybe to over-write it (assuming they have the appropriate authorizations). Moreover, we want to be able to combine and reason-across the data generated by one spime, say a particular motor vehicle, with that of other spimes — say, other vehicles of the same model, or other vehicles owned by the same person, or other vehicles purchased in the same year, etc. We’d also like to combine and reason-across the data generated by spimes in different product categories — all the durables purchased by the Smith family in their life, for instance, or all the products purchased in Main Street, Anytown, last week.
An obvious data architecture for multiple, independent reading- and writing-entities is a blackboard. A blackboard architecture is a shared memory space which enables agents sending and receiving messages to be decoupled from one another, both spatially and temporally. Exactly as a blackboard does, messages left on the blackboard are stored until they are erased, and so the long-dead can communicate to the living, who can in turn communicate to the not-yet-born. Tuple spaces and the associated Linda language are an example of a blackboard architecture (implemented in Java as Java Spaces). We could imagine that each spime has its own tuple space, partitioned into secure sub-spaces for different spime-wranglers, from manufacturers, through each spime owner or carer, to after-sales service providers and disposal agencies. Access to spaces will need to be controlled, so that only authorized agents may write, read and erase data in their allocated partition. Here we could use something called Law-Governed Linda, an enhancement of Linda designed to add security features, although this may be too rigid for products whose uses cannot be readily predicted in advance. An architecture allowing access to a tuple space following an appropriate dialogue between the relevant agents may be more flexible.
So far, so good for the data storage and access. But spimes and spime wranglers will generate enormous quantities of data, and analyzing all this data will require some effort. Better then, to plan for this effort and automate as much of the data collation, aggregation, processing and analysis. Here, I suggest we should use so-called Tuple Centres, which are intelligent Tuple Spaces, able to reason over the data they hold. Because we will want to combine and analyze data arising from different spimes, these tuple centres will need to communicate with one another, and agree (or not) to allow their data to be aggregated. A multi-agent system (MAS) with agents representing each spime-space (ie, the tuple space of each spime), and, for many spimes, each partition of each spime-space, seems the most effective architecture. This is because the interests of the relevant stakeholders (spime-wranglers, marketing departments, manufacturers and service providers, data protection agencies, the state, the law) will vary and a MAS is the most effective way to formally represent and accommodate these diverse interests in a software system.
There are many details still be worked for this architecture. But even at this level, it is clear that the traditional marketing data warehouse architecture is not sophisticated enough for what is needed for spimes. Hence, my statement above that spimes could lead to major changes in the way in which marketing data is collected, collated, stored and analyzed. Use of spime data I will leave for another post.
TuCSon, developed at the University of Bologna, Italy, is a platform which enables fast implementation of tuple centre applications.
The resonance of spimes
In 2004, Bruce Sterling coined the term “spime” for an object which tracked its own history and its own interactions with the world (using, for example, technologies such as RFID and GPS). In Sterling’s words, spimes
“are precisely located in space and time. They have histories. They are recorded, tracked, inventoried, and always associated with a story.
Spimes have identities, they are protagonists of a documented process.”
Spime wranglers are people willing to invest time and effort in managing the meta-data and narratives of their spimes. The always-interesting Russell Davies has been exploring the consequences of this idea for designers of commercial products.
Several thoughts have occured to me:
As with all new technologies, the future is unevenly distributed, and there have been spime wranglers for some artefacts for a very long time — for instance, for early industrial manufacturing technologies (eg, the 1785 Boulton and Watt steam engine (a diagram of which is above), in use for 102 years, and then immediately shipped by an alert wrangler to a museum in Australia in 1888) and for Stradivarius violins. The service log books of motor vehicles, legally required in most western countries, are a pre-computer version of the metadata and narrative which a spime and its wranglers can generate.
Secondly, spime wranglers, like lead-users, become co-designers and co-marketers of the product, because they help to vest the product with meaning-in-the-world. Grant McCracken has written on the trend to greater democratization of meaning-creation in marketing. (Note: I’ll try to find a specific post of Grant’s on this topic.)
Finally, it strikes me that the best way to conceive of the narrative and metadata generated and collated by a spime and, working with it, by the spime’s wranglers is through Rupert Sheldrake’s powerful (and sadly neglected) idea of morphic fields. I hope to explore this idea, and its implications for quantitative marketing, in a future post.