One debate that has threaded its way through all of collaborative history is whether collaboration is about communication or organization. When COVID-19 hit and created the work-from-home culture, the focus was on making the communications piece work when people couldn’t meet physically. That’s necessary, but not sufficient. We’re now seeing things like Teams and Slack that include more project management and work organization features, but I still wonder whether there might be a better overall model.
I’ll try to be transformational here. Let’s suppose that we had a snippet—call it a “token”—that represented everything in a project. Think of it as a recipe, or a “digital twin.” It would have a name, it would identify who was responsible for managing the project, what workers were involved, and what its schedule for completion was, both for steps and the project as a whole. So far, it’s similar to what project management tools offer.
Now let’s extend that idea. Our token might contain the links to resources needed to perform each task in the project, including credentials that would allow the responsible worker to access the resources. It could also include links to the communications channels to be used for meetings or ad hoc conversations, in addition to notes taken by everyone involved. That way, past events could be analyzed to catch up or to figure out how something went wrong.
All of this would be controlled by the final piece of the token, the policies. Policies would determine what a given worker was allowed to do, what happens if something isn’t marked complete when it should be, who to contact if someone responsible for a task is unavailable when to kick things to a higher management level, and so forth.
In effect, this sort of token makes the abstract concept of a digital workplace into something we could realize. Because the token represents everything about a project, including its data, workers, and connections, it could be inserted in a “token-reader” to create everything a worker would need to be a part of the activity it represents, no matter where they were. You could even envision a kind of “token-reader requirements” section in the token’s policies that would either disable some activities or simply refuse to load a token if the reader couldn’t provide all the necessary links, security, etc.
A project manager would likely author the tokens, using a tool designed for that purpose. The sequence of steps to be expected, the place where a parallel operation was allowed, and the related points where results from parallel paths had to be collected, would each be specified. The project manager would launch the project by launching the token, and it would then pass along the defined workflow, separating into pieces at parallel-process points and reassembling when those tasks are completed. When step one is complete, the token would be queued in the “token in-box” for the next step, the next worker.
In this model, meetings and group activities would include specific steps that involve multiple people. The token description of these activities would include who expects to be involved and even provide a link to schedule the meeting or join it. You could even have a token-link refer to a generic something like “video call,” and have some middleware sort out what specific mechanism of fulfillment was best given the combination of capabilities available among users.
Tokens don’t have to be monolithic or confined to a single enterprise. You could nest tokens to reflect complex project structures, and define ones that represented prospect/customer relationships, partner relationships, and even regulatory and auditing relationships. A digital workplace then becomes a digital enterprise.
This sort of thing isn’t a pipe dream. At a high level, this sort of token usage could be developed out of the “digital twin” concept, which builds a model of a real-world system to facilitate the management of the system through the model. The
Object Management Group (OMG) has a project in the space, but it’s still in the explore-the-concept phase and isn’t directed specifically at collaboration or portable digital workplaces.
Blockchain technology could also be a pathway to our token-driven work. Blockchain would make the token secure and tamper-proof, and it could form the basis for a whole token system. There’s a company-and-community startup (Blockchain Labs for Open Collaboration or BLOC) that does this sort of thing on a professional services basis. Could they decide to create something more generic? IT vendors may also be candidates for early progress. For example, IBM has long listed blockchain as one of its strategic technologies, and yet it has failed to garner the revenue boost that was hoped for. Perhaps a token-driven digital workplace would change their luck.
Finally, the cloud itself may be a driver. Token-driven is also a form of data-driven or model-driven, and many (including me) believe that in order for any distributed process to scale and be resilient, meaning cloud-compatible, it will have to be managed through a data model or token. The Organization for the Advancement of Structured Information Standards (OASIS) has projects in many areas; its Topology and Orchestration Specification for Cloud Applications (TOSCA) model is becoming very popular in defining cloud application deployments, and they have a half-dozen projects related to the workplace. It would be a small step for them to propose an approach to building a token-hosted recipe for project work overall.
Original thinking is required here because there’s a risk of our automating the way we do things now instead of the way things should be done in a distributed, digital, world. This concept could fix that.
