A Fabric, not a Platform
Apple and Google are competing to build a fabric that connects everything you own and use, working outward from the globally meshed supercomputer you carry in your pocket.
First of all, work is not all done in one place.
This isn't a bad thing:
- Nothing is ever done in one place; work is intrinsically intertwingled.
People will use their own smart phones and apps to route around omissions and ugly bumps that IT provides.
- Trying to stuff all work into one big box is much, much worse: I remember the global bank whose Lotus Notes repositories spent almost all of their cycles synchronizing with each other.
- In a competitive marketplace, progress is made in fits and starts.
New apps, platforms and services are far better, cheaper and more fun to use than apps fossilized by IT for a small captive, internal audience, written and maintained by the lowest-cost outsourced bidder.
- It's an opportunity for companies like Salesforce and others to build big service platforms to create cozy places for familiar activities, lowering friction and adding guardrails for guidance.
- Sharing platforms like Box, Dropbox, and Google also aspire to become platforms for work, trying to convince customers and developers to choose their platform to build cozy places for specific activities.
- But having a multitude of channels repeats the plate juggling problem if you have too many places to look when you try to get organized, see Group Chat Doesn't Suck.
The Way We're Using It Sucks
How can we make work actionable?
I hope you all agree that one way to make life easier for people trying to get work done together is to make their work observable.
In an ideal world, the information you want, things you need to work with, and people who you should talk with should be just a click - or a "Hey Siri" - away.
Objects - Documents, pages, messages, tasks, discussions, and transactions need to be findable, addressable, and usable as objects of action verbs, whether than verb is an action taken using a click, API call, message to a bot, or request to an assistant like Siri.
Context - To make work actionable, you need to implicitly or explicitly identify the context of an action's reference; context itself becomes an object of actionable work.
Although this sounds like something that only a programmer would say, think about how you reference objects in a conversation: "How are we doing on the Acme Products proposal?" A human being you work with either has a pretty good idea of what you mean in some shared context, or will ask you a question to clarify.
A good reply might be "We're waiting for Chris.
Software objects have addresses or names that can identify that object in the context of some open domain like the web or a closed domain like a database.
Work Graph - Whether shown on a screen or mentioned in a relevant context, context makes objects of actionable work findable, usable, and fall readily to hand.
Work like the web - You don't need to get into arguments about the world of apps versus the work of the web so long as the underlying objects you use are addressable and usable with standard W3C protocols.
We're close to this basic interoperability using nothing more than a web browser, web standards, and web addressable services.
A Fabric, Not a Platform
Traditionally, "platform" refers to a software product with APIs used to construct or extend applications and services, like the original version of Lotus Notes.
Sharing services like Box and Dropbox began opening up their platforms to enable apps as well as people to share documents and handle closely related activities.
Platform wars - The fact that all of these services are available via the cloud makes a basic level of W3C-based interoperability possible, if not exactly easy or pleasant.
At the same time, the shift to mobile first drives adoption of bot and AI conversational interfaces since: 1) there's no room to show a long list of results or screens that look like an old fashion airplane cockpit on a mobile screen; 2) people aren't willing to put up with the clutter; 3) people feel comfortable with a conversational interface that reliably understands what they want done and asks for clarification or confirmation when appropriate.
I believe what's needed is a fabric for actionable work that lives over traditional cloud platforms and services.
Transactional and other work done inside a system of record or a selected service platform will still be done using that platform, linked from the actionable objects in the work graph using standard W3C links or vendor API services.
For example, TeamPage offers social enterprise web capabilities (summarized below) that automatically index the content of any external web reference, and make that page an actionable object which can be discussed, tasked, tagged, and searched from within TeamPage.
TeamPage permissions make it easy to define who can see and use actionable objects, expressed in the context of a business activity like Quality Management.
The work graph and its actionable objects are the right resources for bots and AI's to learn how to make what you care about effortlessly findable, easily usable, and accessible to bots and AI's you trust.
The upshot of the latter data structure is having all the information we need when we need it.
TeamPage Work Graph
TeamPage watches what you do, and automatically maintains two-way links and relationships as you edit, keeping an accurate version history of everything so you can easily see what changed, when, and who did what.
TeamPage's work graph automatically connects articles, comments, status messages, tasks, milestones, projects, links, shared references, and relationships stored in TeamPage to the TeamPage profile of the person who created, edited or tagged the work, along with a time stamp for the action.
This concept of a work graph is helpful in describing what TeamPage automatically creates and maintains as you work.
But what counts is how TeamPage uses its work graph model to cut clutter, make it much easier to work with people anywhere inside or outside your organization, and make files and records already in IT systems easily accessible to get work done.
The same work graph information is organized and presented two different ways: by person, or by unit of work.
Working with external and internal teams - use permission rules to clip what the work graph lets you see
TeamPage's work graph model includes permissioned access that automatically clips content to show just those work items, relationships, and search results each person is allowed to read.
This makes it simple to use TeamPage for work that can cross boundaries, linking customers, suppliers, partners and internal teams with different permissions to different business activities on the same TeamPage server.
TeamPages' work graph model allows you to put a private comment (or task) in a more private space where it's only visible to a smaller group.
Typically each external client has a private space (like separate clients of a law firm), and internal team members have a birds eye view across all clients and most or all internal spaces.
Extending the work graph to content on the public Web, Intranet pages, and siloed systems of record.
TeamPage's Social Enterprise Web enables you to share, tag, task or comment on any page your browser can see on the public Web or on your private intranet.
The Social Enterprise Web also lets you add a TeamPage share button (like Facebook or Google+ share buttons) or comment box (like Disqus) to any public or intranet Web page your organization controls.
As a bonus, the content of a page linked to TeamPage with the browser plug-in, share button, or comment box is automatically indexed for TeamPage search and drill down navigation.
The Social Enterprise Web makes pages on the public Web or your organization's intranet simple to see, share, find and connect to TeamPage tasks.
You can then search, share, task, tag or comment on any work item in these external systems, making live external transactions part of your TeamPage work graph, including integrated TeamPage and external content analysis, search and navigation.
Reinventing the Web II (2014) Why isn't the Web a reliable and useful long term store for the links and content people independently create? What can we do to fix that? Who benefits from creating spaces with stable, permanently addressable content? Who pays? What incentives can make Web scale permanent, stable content with reliable bidirectional links and other goodies as common and useful as Web search over the entire flakey, decentralized and wildly successful Web? Includes links to the 2016 Internet Archive Decentralized Web Summit and other resources.
Continuity and Intertwingled Work (2014) A level above an Internet of Things: Apple aims to deliver a seamless fabric spanning what's in your phone, tablet, car, and home, for you, your family, and trusted services at work.
Google::Apple is the new Microsoft::Apple (2016) A two player race between the most valuable and capable enterprises on earth.
Contextual Computing At Work (2013) Peter Morrison argues that the future or work isn't mobile, it's contextual: "Always-present computers, able to sense the objective and subjective aspects of a given situation, will augment our ability to perceive and act in the moment based on where we are, who we’re with, and our past experiences.
Intertwingled Work (2010) No one Web service or collection of Web servers contain everything people need, but we get along using search and creative services that link content across wildly different sources.