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. Both apply deep learning technology to AI assistants, and are opening up their AIs and bots to other apps, bots, and cloud services. This richly connected fabric makes bots useful and AI assistants valuable by teaching them how to identify objects you're talking about as well as understand what you want done. The same applies at work. Making this happen requires a shift from the traditional definition of a platform to a fabric which makes it possible to connect people and the actionable objects they use, in context.
Juggling Plates
First of all, work is not all done in one place. The things that people talk about and use to get work done are scattered across a handful of silos and apps. For some people it's a scary, dark forest of silos and apps, but most people rely on a handful of places to get their daily work done - and are reluctant to venture outside the places they know.
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?
Actionable Work
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. I believe it's also valuable to make work actionable - by individuals, teams, apps, bots, and AIs. Think "actionable" in the sense of actionable intelligence: "information that can be acted upon, with the further implication that actions should be taken." Think "work" in the sense of "work product" like tasks, documents, CAD files, transactions in system of record, as well as the trail of actions taken and resources used by people, apps, or bots to get work done.
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. I'll call this actionable work since it expresses a desire to make what you or others have done, used or talked about in the past usable to get work done in the future. Effortlessly findable. Easily usable. It should fall readily to hand. How close can we come to the ideal? What's needed? What stands in the way?
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. He should approve it or get back with questions by Wednesday close of business". Could a bot do this? Even if you're not using a bot, could a request like "How're we doing on the Acme Products proposal?" give you a link to the relevant status and related activity rather than just a link to a document named Acme Proposal?
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. Although some objects of actionable work have human sensible names, few of these names are unique. Unique names are themselves unique in a context like names in your address book, names in corporate directory, or assigned names like invoice numbers and permalinks in a system of record. Many objects of actionable work don't have human sensible names, but become addressable when a click on a screen or command like "reply" enables a software system to identify the object you want to act on.
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. By "fall readily to hand" I mean easily accessible to human beings who talk about related objects of work. People, bots, and AIs need to understand what humans means when they say "Send this to Jordan and see if he agrees", or "Open a trouble report on this." Building on a term coined by Justin Rosenstein, l call this representation of related people, objects and trails of actions in context a work graph.
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. It doesn't matter if you use Facebook's mobile app or Facebook's web browser interface so long as both user interfaces show and use the same objects and content under the covers on the server side. You also want to: 1) identify yourself once, and use that identity consistently; 2) rely on web services to consistently grant or deny access and other permissions based on that identity; 3) rely on web services for actions, permission-aware search and navigation throughout an interoperable fabric.
We're close to this basic interoperability using nothing more than a web browser, web standards, and web addressable services. See the Internet Archive's 2016 Decentralized Web Summit and my two cents in Reinventing the Web II
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. With the advent of the web, service business like Salesforce, SAP, and others began opening up their cloud platforms to entice builders to add complementary capabilities that "work like Salesforce" etc.
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. Likewise Slack is building out its messaging platform, adding bot and message button extensions to use external services from within Slack, and connectors to enable sharing and other services to use Slack for messaging.
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. It's plate juggling time, even for organizations that try to stuff all of their work into the same box. Customers, partners, and employees find it's even easier to use their phones and favorite services to route around what's missing or awkward to use at work. The good news: market pressures are driving platform builders to compete on their ability to connect and interoperate with complementary or competing services.
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. A great conversational interface requires a good way to model context, whether the conversation is driven by text messages, voice, or a sequence of screens.
I believe what's needed is a fabric for actionable work that lives over traditional cloud platforms and services. Not one big box where all the work gets done, but a thin layer of pages, messages, and trails of activity using identity and a work graph to enable people, bots, and AIs to understand what people want to do, how to find the right objects, and how to do it.
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, Traction® 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. A simple browser plug-in or single JavaScript call planted on an application page can add a TeamPage discussion box (similar to Disqus) and tasks to web pages representing orders, CAD designs, and other objects in an external system of record.
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. Customers, partners and employees build a shared fabric of actionable work, relying on TeamPage to clip references to related work that's more private than they're permitted to see.
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. Hey Siri - how're we doing on the Acme Products proposal?
Related
From The Work Graph Model: TeamPage style
".
The upshot of the latter data structure is having all the information we need when we need it. Where the enterprise social graph requires blasting a whole team with messages like “Hey, has anyone started working on this yet?”, we can just query the work graph and efficiently find out exactly who’s working on that task and how much progress they’ve made. Where the enterprise social graph model depends on serendipity, the work graph model routes information with purpose: towards driving projects to conclusions." Justin Rosenstein, Wired 9 Oct 2013
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. This enables TeamPage to show activity feeds, dashboards and calendars of people, linked to the work they created or edited, as well as activity feeds, dashboards, and calendars for specific tasks, projects, and spaces where many people work together.
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. For example, an internal team discussion on a customer's question.
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. TeamPage makes it simple to set up granular access rules for spaces based on individual names, Active Directory, LDAP, or TeamPage group membership.
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. Just install TeamPage's Web browser plug-in extension for modern browsers including Internet Explorer, Chrome, Firefox, and Safari.
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. Comments are stored in TeamPage , and link back to the external Web page, which is treated as part of the TeamPage work graph.
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. A task or question on an internal purchase order page can tracked and used part of TeamPage's work graph without complicated or expensive custom integration.
For example, add a TeamPage comment box to an Purchase order page in a Web based ERP system by adding a JavaScript snippet, and see something like this:
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.
More
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. "It could be ML/
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. These are our sixth, seventh, and eighth senses."
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. The same principle applies when you want to link and work across widely diverse siloed systems of record and transactional databases.
Enterprise 2.0 and Observable Work (2010) Jim McGee wrote: "One unintended consequence of today's technology environment is to make the process of knowledge work less visible just when we need it to be more so. The end products of knowledge work are already highly refined abstractions; a financial analysis, project plan, consulting report, or article. Today, the evolution from germ of an idea through intermediate representations and false starts to finished product exists, if at all, as a series of morphing digital representations and ephemeral feedback interactions." We need to make work observable.
I18N ERROR: @tsiskin#footer_RSS_Feed