Theme Zero: Data Sovereignty

Possession is nine tenths of the law

In a little over a decade, software as a service, otherwise known as the cloud, has mushroomed. For a number of very good reasons, a hosted service, sold by subscription, is rapidly becoming the de facto method of providing business and professional software. However:

• Some data will always be too sensitive to share outside the four walls of the organization,
• Some operations over an organization's data, sensitive or otherwise, will always be too idiosyncratic to be accommodated efficiently by any platform.

While incredibly convenient and easy to get into, cloud software companies are extremely conspicuous hacking targets; they are liable to outages, bankruptcy, or acquisition by (your) competitors; they are profligate data miners, and on average they are, often by design, difficult to sever relations with.

The idea of data sovereignty is, for customers of these services, to establish strategies for improving one's bargaining position, where the extreme solution is running the service yourself. For providers, it's about designing products and services where privacy, customizability, and exportability are principal differentiators. A growing number of organizations fit both of these descriptions at the same time.

Theme One: The ABCs of Content-Driven Systems

Decoupling Access control from Branding and Content

Digital designers of all kinds talk endlessly about the importance of separating content from presentation, but I argue there is a third consideration, and that’s who gets to see what. Overwhelmingly, access control is coupled to the application, and this makes it hard to provision, extend and integrate. The net effect is that to get through their day, people need a zillion different usernames and passwords in a hodgepodge of systems that do not interact with one another. The goal here is to figure out design patterns for (primarily Web-based) infrastructure software (CMS/ERP/CRM) that fully decouple the access control functionality from the content and the presentation. The result is simpler, more secure systems that work better for users. ABC:

• Access control (i.e., authentication and authorization),
• Branding (along with the rest of the presentation layer),
• Content (including data and business logic).

Theme Two: Documents Make Lousy Documentation

Disencumbering organizational reference material

Documents—deliberately-prepared, edited, curated, formatted, sequences of content—are great for telling stories. They're great for conveying arguments. However, if you already buy the argument and you're just looking for facts, documents have a number of characteristics that, when compared to newer—as in invented sometime in the last few decades—technology, simply get in the way.

We are 30 years into the Web, meaning we are 30 years into a robust and mature global hypermedia system. Why, then, are we still so preoccupied with documents? Why do Word, Excel, and Powerpoint (and their Google and PDF-taxidermied counterparts) still dominate? Why, when we need to locate some intraorganizational reference material, do we still have to slog through simulated paper where the information we want is buried in superfluous exposition? Especially now, in the burgeoning era of design systems, which are inherently hypertextual?

The best kinds of references are the ones that get you in and out with the information you need with the least overhead lost to searching and scanning. It is also important to be able to filter, aggregate, reformat, and ultimately repurpose said information, so merely indexing your documents for full-text search doesn't finish the job. What it means is hypertext. There are two obvious targets under this theme:

1. How to go into an organization and dissolve a corpus of documents into a tight hypermedia reference,
2. How (e.g.) an agency could package and deliver such an asset to a client.

Theme Three: Cool URIs Don't Change

How much value gets lost to broken links?

21 years ago, the inventor of the Web wrote a memo. Its title, infamous in some circles, is the same as this segment. Its message was simple: there is no excuse for broken links, at least within the confines of a given website. Two decades on, this problem has still not been solved—or perhaps more accurately, the problem has been solved, it's just that the solution is not evenly distributed.

In raw technical terms, stable addresses and unbreakable links are not that big of a challenge: I have been running 404-free websites on a shoestring for well over a decade, ever since Sir Tim's memo first came on my radar. While I have developed some techniques over the years, I have yet to make them work past my own idiosyncratic process and infrastructure.

Deploying this technique is at least as big a design problem—and a organizational problem—as it is a technical one. First, somebody has to care, and caring about unbreaking links has to be somebody's official responsibility—that is to say content governance. Next, development processes have to be changed—in my opinion only slightly—to accommodate the policy. Finally, the technical infrastructure needs to be modified, which can be a small job or a prohibitive one, depending on the particular products in use.

The benefit of exploring this theme is archive-grade reliability for information resources. It's a problem you solve exactly once for your organization, and your users will never again trip on a 404, as long there is an internet.