Atomizer—Microcontent and the Future of IA
Atomizer – Microcontent and the Future of IA from Bram Wessel
Let’s have a show of hands:
How many of you have started reading, watching, or listening to something on one device, then tried to pick up where you left off — on another device?
In this audience, I’m guessing almost everyone.
Keep your hand up if you have NEVER had any problems doing this. That means never lost your place or had to scroll or scrub or reload or relaunch, anything on a second device? Ever?
I’m shocked if anyone still has their hand up. That’s because though widely promised, this experience doesn’t yet work as reliably we think it should.
And this experience is much simpler than any other experience we’re going to be talking about today. The promises brands are making about the experiences we should expect in the near future sound fiendishly complex by comparison.
And by new experiences, I’m not talking about toilets that Tweet, even though somehow that is already a thing.
What I’m talking about are experiences that traverse environments, or more precisely, contexts. Whether they involve time-shifting, place-shifting, device-shifting, or multiple devices at once, the one thing they have in common is multiple contexts.
What do we mean by context?
In his brilliant new book “Understanding Context,” Andrew Hinton defines context in terms of how an agent interacts with an environment. An agent in this case can be a human, or it can be a digital agent, like an app or a service that’s acting on behalf of a human or other entity. This is how we end up with digital contexts, which are abstract.
As these digital agents evolve, a network effect is in play, and digital contexts are proliferating.
At the same time, experiences are becoming more immediate, fragmented, and continuous.
This means the potential for contextual disruption is increasing exponentially.
And I’m here to tell you that contexts are not going to stop proliferating any time soon. This trend is here to stay, in fact, it’s accelerating.
By now it’s obvious that most people own a smartphone.
That means US adults now average more time on the Internet using mobile devices than PC’s. 84% of people say they use a smartphone or a tablet to multitask. And as of October 2014 we crossed a big threshold, there are now more devices than people in the world.
So the bottom line is that it’s impossible to predict what contexts users will want content in next.
Unfortunately the worldview that most content organizations have lags pretty far behind how actual humans are consuming and using content.
We see this in the way brands have tended to describe the world as a series of… channels. You’ve probably heard a colleague or client say something like “If only we can manage our content so we can distribute it across all of our channels, then we’ll be able to: [INSERT YOUR FAVORITE BUSINESS GOAL IN THE BLANK].”
And herein lies the problem with our least-favorite buzzword, “Omni-Channel.” As a conceptual model for experience, Omni-channel implies user intent to open channels of interaction with companies or organizations. It also implies that these channels are discrete, and that it’s virtuous to maintain consistency across these channels, often at the expense of coherence.
This likely stems from this idea’s marketing origins in the early days of broadcast media, when it was possible to build a business on the illusion that brands had a one-way conversation with their customers.
As Information Architects, you and I know that’s just not how organic experiences usually work. When it comes to experiences that involve multiple contexts, where users are in control, this notion of an array of channels seems kinda inadequate.
And there’s a bigger problem, which is that contexts aren’t actually discrete. They overlap. Often, they occlude. Sometimes, they collide.
So of course it’s a problem if your communication gets out of sync. But consistency for its own sake also fails to accommodate contextual subtleties that can completely undermine the cohesion of an experience.
This is all leading up to a critical tipping point for organizations that manage enterprise content. And it’s about to get a lot crazier.
Should they become widely adopted, wearables will only accelerate this shift. Just as with smartphones, eventually a wearable device, like the one that launched quietly yesterday, will catch on. And when it does, it’s likely to be a gateway drug for others.
Then, suddenly, brands and enterprises will be scrambling to adjust to the new paradigm, just as they were with the Web, social media, and mobile.
The biggest challenge this poses is for those of us who create and manage enterprise content.
As Karen McGrane, Ethan Marcotte and others have been warning us for awhile now, it’s impossible to predict where content is going to need to go next. And it’s going to be impossible to predict all the permutations of what content users will demand in these proliferating contexts.
As contexts proliferate, units of content that organizations must manage to target all of these contexts will become increasingly atomic.
To illustrate what I mean, I’m going to talk about an experience that almost everyone has, but most of us don’t think a whole lot about.
I bet most of you have shopped at one of these stores. (That’s a big-ass storm of logos up there, so maybe I should be asking, who hasn’t?)
Anybody gotten a coupon with your receipt at a grocery store?
Let me tell you a little something about how that happens.
Let’s say you’re a company that provides coupons for these retailers. You do this by means of a device like this.
This is called a string printer. It’s connected to the Point of Sale system in these stores, and it’s also connected to a data center.
When a transaction takes place, the string printer device queries this remote data center to determine whether or not to issue a coupon, and, if so, what coupon to issue.
That means if you’re this coupon company, your job is to provide highly targeted microcontent for thirty-one thousand Food, Drug, and Convenience stores in the US.
So you too are at a point of major consequence because your clients are starting to realize that they, and their suppliers, and their customers can all benefit from new forms of experiences that are just now becoming possible. Coupon providers’ traditional delivery system, consisting of string printers at checkout, is slowly being replaced by devices consumers control.
This has huge implications for how these companies manage their enterprise content. And the nature of their business means that this content must be managed at a very atomic level. This is what I mean by micro-content.
So how would we define micro-content? Well, let’s examine the recent history of content. In the early days of the Web, the unit of management was the page. It took almost no time for people to realize that this content management model wasn’t sustainable, and the first content management systems started showing up. As CMS’s evolved, they began to rely on metadata to help drive this dynamic generation of pages. Eventually the CMS reached the point where an organization’s entire digital presence is managed by some form of CMS.
But as people have been pointing out since the first edition of Lou and Pete’s Polar Bear book, the great challenge has always been how to chunk content so that it can be managed more efficiently.
And as this chunking gets more and more atomic, we start to see an asymmetry of production vs. management.
It’s now a lot more challenging for organizations to manage content than it is to create it in the first place.
We’ve gone from macro-content elements with a little bit of metadata to micro-content elements each with a LOT of data. This includes many sets of metadata about content itself, and many related sets of data, all with (if you’re lucky) only slightly different taxonomic structures. All of which must be integrated with the data a CMS needs to distribute content to the appropriate contexts by the appropriate means.
Thanks to Kristina Halvorson, and a host of others, we’ve realized that the content blob — that unlimited free-text body field in every CMS where most of our content ends up — is bad practice, and within the blob there are actually all kinds of content elements that should be structured themselves.
Those structural units have always been there, but the difference is that now, due to the proliferation of contexts, they’re better managed individually.
So is micro-content just small chunks of content, which we’ve known about basically since the dawn of our discipline?
Well, not exactly. Chunking is one of the most basic principles of Content Modeling, and chunking enables better management of micro-content, but units of micro-content don’t necessarily consist of single chunks. Remember? Those blobs are what got us in trouble in the first place.
No, a better description of what we mean by micro-content would be disaggregated (one might even say “atomized”) units of content, constructed so that they can travel independently across contexts and be re-aggregated into coherent experiences.
Which brings us back to the coupon. A coupon provider’s business model involves lots of micro-content, widely distributed, in various states of aggregation. Their core service is not a content destination and it never has been. And it doesn’t just rely on a content management system, it relies on dozens of internal systems that manage different types of data that describe content.
And when I say data, I don’t mean datum. This is data in the most pluralistic sense. When you hear people talking about Big Data, the data that a coupon provider manages is a great example of the scale they’re talking about.
The string printer in this photo is owned and maintained by a company called Catalina. The slide of all those retailers I showed you before? Those stores are Catalina’s clients. That means Catalina is involved in over 300 million retail transactions per week. That’s about 15 & ½ billion transactions per year.
The amount of data, the level of infrastructure, the scale of Information Architecture involved in aggregating the most effective micro-content for both the retailer and the consumer to spit out of that little string printer at checkout is kinda staggering.
The grocery store coupon is an instructive example of a type of micro-content. It’s been around forever, and though the means of distribution evolved over the years, it’s still usually a piece of paper. And you thought print was dead!
A coupon seems simple. It’s usually composed of a minimal amount of chunks, including an image (usually a product shot), some copy and often a bar code. In some cases, this amounts to no more than 4 lines of text.
A coupon has to be minimal, because of the way it’s used. It must be portable so a user can easily acquire and store it in a highly contextualized moment — when it’s distributed at a point of sale. And it must be easily retrievable when the appropriate context arises to redeem it.
Another interesting thing about coupons is that they are content, but they have actual monetary value. In their traditional life cycle, they are born AND die as part of a monetary transaction.
They effectively operate as currency.
As Information Architects we think about content in a lot of different ways, but how often do we think about content as actual currency?
So this means a coupon provider is an ancillary transaction service that simply augments transactions by attaching small units of value to them through the distribution of microcontent.
To provide this service, coupon providers ask questions of their vast stores of information to determine what offers can be paired with what products within a transaction. These are the basics that drive the algorithms used to decide what, if anything, comes out of the string printer.
This is how coupon providers deliver value. Consumers are happy when they receive a discount. Retailers are happy when consumers come back. Manufacturers are happy when consumers switch to or buy more of their products. It’s a win-win for everyone in the value chain.
A coupon has always been a unit of content that traverses contexts. Which couldn’t be more different from the content consumption paradigm we’re used to, where there is usually a sender and a receiver, or a screen and a viewer.
Instead, the broad contexts a coupon traverses are called distribution and redemption.
In a distribution context, the business goal in granting a coupon will sound familiar to marketing folks; Acquisition, Retention and increasing AOV. Common biz goals, right?
Also in the distribution context, a coupon provider’s interests are aligned with consumers — consumers want discounts and coupons provide them.
Since the incentive is much higher in distribution, a lot more information goes into it than redemption. The redemption context is much less managed. It’s intended to create a positive feedback loop by hopefully triggering another distribution.
In fact, this imbalance is embedded so thoroughly into the traditional coupon provider business model that they get paid completely on the distribution side.
So as you can see, the business context loop in the coupon provider’s traditional world is quite simple in concept. But it’s more complex in execution…
To demonstrate this, I’m going to use techniques we’re all familiar with — Personas and Scenarios.
Meet Andrea. She’s in her mid-30’s, married, with two children. The economy has been tough recently, but through it all, Andrea has held down a part time job in the accounting department of a sewing equipment maker.
Given her experience with accounting, Andrea handles the home finances for her family. She is adept at comparison shopping and finding the best deals for the things her family needs.
Andrea shops at Target, but mostly she shops at Fred Meyer, where she’s a loyalty club member and where it is generally slightly more inexpensive.
Andrea also clips coupons to use in her shopping.
Andrea uses a Shopping List app on her smartphone, which is able to scan bar-codes to help her manage her list and comparison shop.
In her routine trips to Fred Meyer, Andrea has her route through the aisles mostly planned out in her head, because she’s familiar with the store’s layout.
So normally, once Andrea has gathered all the items on her list for a given session, she proceeds to checkout. The checkout clerk records all the items for that transaction with the infrared scanner, and there are at least three other prompts during this transaction flow. At some point, the clerk asks Andrea if she has any coupons, at which point, those too are recorded (also with the scanner).
Also at some point, Andrea is asked for her loyalty card information. Sometimes she dips her card, but if she doesn’t have it with her, she can use her phone number.
Only when all other elements of a transaction are prepared does Andrea pay for her transaction, usually with another card reader dip. (Andrea almost never pays with cash, because she has a mileage credit card.)
Finally, once Andrea’s transaction is completed successfully, a receipt and sometimes a coupon are presented to her as she leaves checkout. When she’s using a self-serve kiosk, she doesn’t always wait to see if a coupon prints, and doesn’t give it much thought.
As you can see, the coupon figures in two steps of this typical retail transaction. In order to be redeemed, a coupon must be distributed at some point before the payment step. Then if a transaction meets certain criteria one or more coupons is presented for a future visit after the payment step.
So that’s the happy path. But remember earlier we talked about how coupon providers are at a point of consequence? Why is this?
Well, something new is starting to happen in retail stores these days. The traditional checkout scenario is getting disrupted. I’m sure you’ve heard of Google Wallet, Apple Pay and their competitors. Increasingly, people like Andrea are being offered the option of paying by phone. Soon, they will be able to pay by watch, or even some other wearable.
What’s driving this paradigm shift is convenience. Quite frankly, the way we’ve gotten used to doing things is kind of a pain in the ass. It’s inconvenient to carry around a purse or a wallet full of credit cards, debit cards, loyalty cards, paper coupons, etc. The promise of the future is that you’ll be able to complete a transaction in one gesture, like a tap.
So where does that leave a coupon provider? If you’re blithely traipsing through checkout, tapping and whistling on your merry way, are you going to want to stop, switch your bag to your other arm and make sure to snatch that coupon out of the printer?
This paradigm shift has the potential to disrupt both coupon scenarios — distribution and redemption. And not just because the string printer seems like an antiquated and inconvenient peripheral to the point of sale. If you can store coupons digitally the same way you can store credit and loyalty cards, they can be digitally bundled into the payment step. That means more coupons could be distributed and potentially redeemed, which is good for everyone in the value chain.
Of course, a coupon these days is becoming more than a slip of paper. As we described above, that paper object is a token for a transfer of value, much like paper money is. As with other currency, this value transfer is increasingly becoming digitized.
Apple has announced support for coupons in it’s Passbook application, and Andrea’s Shopping List app is owned by a company called coupons.com.
There’s quite a bit of incentive aligned behind such a shift. For one thing, we’re pretty sure companies like our friends at Catalina would welcome the opportunity to get rid of those string printers.
After all, there is a cost associated with distributing and maintaining them. For a coupon provider, the real work is in getting the appropriate unit of value into the appropriate hands in the appropriate context. If this transaction is undertaken in an entirely digital ecosystem, the value a coupon provider delivers is still quite important to the value chain.
But getting rid of those printers means also getting rid of the physical coupon. And that fundamentally changes the way coupons operate as a value interaction. Our cultural assumptions about coupons are driven by decades of behavior that has evolved very slowly. One of the key aspects of coupons that makes their use successful is the perception of value that accompanies the physical object. It conforms to a mental model we have for paper money, it feels like currency, and to a large extent it behaves like currency.
So what happens to a coupon when it becomes a digital entity? How does that change the perception of its value? How does that change how it gets distributed?
Traditionally distribution has occurred in proximity to receipt printing. Should this scenario persist in digital contexts?
That’s probably going to depend on which entities are involved in the transaction flow. In an all-digital transaction flow, a coupon provider can’t insert themselves into the process in the same way they traditionally have with a string printer. But they still have to insert the coupon itself.
The other thing that happens if the string printer is removed from the equation is that the invisible operation the string printer provides — the data center query which is so critical to the coupon provider’s business — must somehow be replaced. Even though digital payment services will provide a facility for coupons to be managed, there will be a shift in consumer expectations that accompanies this shift in context.
So what happens in a digital context? If the receipt is going to be digitally distributed, will it even be possible for the coupon to be distributed in proximity to the receipt? If not, how will a consumer be notified that a coupon has been distributed? And when that notification happens, how is it going to be perceived by the customer? As value? As currency? Or as notification spam?
Well, now the good news for the coupon provider — if distribution is going to be de-coupled from the receipt, that also presents other opportunities for distribution to occur. For example, could distribution be introduced before the point of sale? If the goal of issuing coupons is to influence purchasing behavior with a marginal transfer of value, couldn’t that give-to-get happen further up the consideration funnel?
And if so, what’s the method of digital distribution? Remember, a coupon provider hasn’t traditionally had the visibility or level of access to the consumer that would allow them to insert themselves into this scenario.
So, let’s remodel the coupon experience.
Now we’re going to project Andrea about 18-36 months into the future.
She has a newer smartphone which is equipped with NFC. She uses a digital payment system so she pays for groceries with her phone.
One day when she’s heading out to Fred Meyer, she opens up her Shopping List App and gets notified of a new feature that will plot the most efficient route through the store to get all the items on her list. Sounds convenient, so she taps a prompt to accept this feature, and agrees to allow her grocery retailer to share her shopping history from its loyalty program with her Shopping List app.
When she gets to the grocery store, she opens up her app and it prompts her to confirm which store she is shopping at. Using location information from her phone, the app locates the specific store number where she’s shopping, loads a floor plan and plots a route for her.
As she traverses her route, at each point there’s an icon indicating whether or not the item on her list is in stock. Everything is in stock except Breakfast Cereal, so when she gets to the previous item, her app prompts her with alternatives to the cereal she usually buys, that ARE in stock. She notices that one item has a coupon available for it, so she taps that item. Up pops a coupon for $1.00 off. This brand of cereal usually costs about the same as the brand she buys, so she’s grateful to save a little money.
A couple of items later, she arrives and discovers that that there’s yet another coupon available for a brand of dish soap that she usually buys. Even more savings.
As she heads to the next item, toothpaste, she notices that there’s another coupon available. She taps the icon for that and is presented with a digital coupon for a brand she’s heard of, but hasn’t ever tried. Since the coupon makes this cheaper than her usual brand, she tries the new brand this time.
When she gets to checkout, she taps her phone to use the digital payment service, and at the receipt screen, she gets a list of all the coupon and loyalty program savings she accumulated during this shopping session. She’s saved about 8.75, which lowers her total purchase from about $82 down to just over $73. Alright, that’s not bad.
At that point, a notification appears on her screen for another coupon for the allergy medicine she just bought. OK, even better!
So what happened here? Well, from Andrea’s perspective, one of her routine tasks was augmented in a pleasant, yet minimally-disruptive way. She was able to use an app she chose, on a device she controls, to make her trip to the grocery store she usually shops at, more convenient and save a meaningful amount of money.
What happened behind the scenes reflects the new reality retailers, manufacturers, and coupon providers soon must accommodate. These experiences will change the nature of the relationship between a coupon provider and it’s constituents, both brands and retailers.
These experiences will also require a level of integration that most enterprise content management organizations simply aren’t prepared for. You’ll notice that no single entity controlled this experience end-to-end. It required cooperation from an app maker, a digital payment service, a retailer, manufacturers, and the coupon provider.
And let’s not forget about users! They will need meaningful incentives to participate, or they’ll just ignore all the technology and keep shopping for groceries the way they always have.
Let’s shift back to the perspective of the coupon provider. How do they need to structure their enterprise content to be able to participate in this scenario?
To begin with, they need to model their microcontent to be more portable than it is today. A string-printed coupon is a unit of microcontent that’s not going to operate as successfully in the new cross-context experience I just described.
Here again is a typical string-printed coupon. In order for it to operate as a unit of value, certain components must be aggregated together. It must signal what it is, that’s the value and qualifier copy. It must provide terms and conditions, that’s the legal copy. It must furnish a bar-code, that’s how it can be redeemed. In order to entice a consumer to use it, it must also have marketing copy (e.g. a Call to Action) and an image.
What you’ll notice about this model is that the format dictates a lot of what is presented, and that won’t hold true for a digital coupon. As we’ve learned since the smartphone revolution began, there are now infinite viewports through which content will be consumed.
And digitization means there are limitless ways a digital coupon could be chunked for presentation. It’s not necessary to present all of these items at once – they can be disaggregated or atomized. Some of them may be required for the point of sale, others may be required when a customer is at a shelf, deciding between two products.
Our coupon provider can now no longer think of a “coupon” as a unit of content. They are forced to re-conceive a coupon as a distributed content experience that traverses contexts — digital AND physical — and features in a broader range of moments in a given customer’s journey.
This doesn’t necessarily fit the monolithic architecture that the coupon provider has operated with thus far. The traditional model of looking up a transaction history at the point of sale won’t be feasible or efficient. The context of a list-driven shopping session is more immediate and will demand instantaneous response or well-choreographed integration. It will require something that could be thought of as a microcontent service. And this service will have to be flexible enough that it can be integrated into a myriad of potential contexts.
This suggests an architectural shift in how a coupon provider structures its data and content. Instead of comparing a transaction history to a list of offers, they must have the offers themselves tailored for context. They need to ask themselves what offers are appropriate for what contexts?
How are they going to be able to do this?
Well, they’re going to have to map out their contexts much more thoroughly than they have thus far. They’re going to have to define the characteristics and attributes of these contexts.
Essentially, they’re going to have to create contextual, or context-enabled ontologies that are flexible enough to accommodate ambiguous, dynamic situations, not specific controlled task flows.
To see what I mean, let’s examine a common grocery scenario. Say the coupon provider wants customers to get distributed a coupon for an alternate to something that’s out of stock. In the traditional model, that scenario would simply be impossible. The coupon provider would have no way of determining that an item would have been purchased had it been in stock.
Even if there were a campaign in market on behalf of the out of stock item to encourage consumers to switch to their brand, the absence of that item in the transaction would mean a missed opportunity to trigger a coupon for that shopping session. As for Andrea, she might walk out of the retailer annoyed that she couldn’t get the allergy medicine she wanted there. Not so happy path. A lose-lose for everyone.
So what’s the new information model for this interaction? It’s not any more feasible for the coupon provider to have real-time inventory information for every location of the 31,000 retailers they support. This would add Petabytes to their already massive data store and introduce even more latency.
A better architecture might be a distributed microcontent services model. In such an architecture, using our example, the coupon provider makes microcontent available to the retailer and the shopping list app maker via digital services, and affords a range of possible uses for the micro-content based on business rules that integrate the interests of all the participants.
That means the coupon provider is going to have to define the relevant characteristics of certain types of contexts to afford environments highly contextualized sensitivity to the digital agents that are interacting with them, and vice versa.
In this formulation, a Shopping List app is a digital agent operated by a shopper. A store is a digital agent operating on behalf of a retailer or manufacturer. A coupon provider’s microcontent services can integrate at multiple points.
The shopping list app needs to understand that it will interact with things called stores, and each store will provide information about itself. For instance, a store might provide location-specific information such as a floor plan. Or it might provide inventory information. Or transaction history information from its loyalty program.
Pushing taxonomic structure out to the edges will allow business logic to be embedded within microcontent services. It can also allow most of these services to be delivered asynchronously, to avoid latency.
As contexts proliferate, microcontent services will need to be more distributed because current monolithic CMS architectures may not prove flexible enough when content is disaggregated, and not targeted at a specific destination.
In a microcontent services architecture, the data AND THE CONTENT, are embedded at DISTRIBUTED points in the ecosystem. In Andrea’s shopping experience, coupon content is embedded in the Shopping List App or Digital Payment service, and the distribution of a coupon is triggered by lightweight communication between the app and the grocery retailer environment.
So if you’re an enterprise taxonomist, or an information architect whose job it is to manage enterprise content, I bet this seems like an enormous amount of work!
Well, there’s a precedent for this style of architecture which can reduce some of this effort and hopefully complexity. It’s called the micro-services architectural style, and it’s inspired by agile and object-oriented methodologies.
Martin Fowler, one of the pioneers of the Agile movement, and his colleagues James Lewis and Sam Newman, have written about it. They have come up with a set of principles that they recognize as hallmarks of the style.
Now, before everybody freaks out, I’m not going to suggest that we force-fit yet another Agile methodology on to Information Architecture work. As a discipline, we’ve tried that before and it usually doesn’t end well.
And this isn’t the time or place for a thorough explication all of the concepts behind micro-services.
But I will suggest that certain architectural principles of the micro-services style may be useful for designing microcontent services, and I’d like to suggest which of these principles might benefit IA’s as we think about modeling microcontent.
But first, I want to talk about Content APIs
In her excellent book “Content Everywhere,” Sarah Wachter-Boettcher describes a Content API by comparing it to a well-known data API. She says “Just like the Google Maps API allows Google content to be used on lots of non-Google websites, a content-driven API stores data in a central place where other services can access and use it.”
Now, onto the principles.
Principle 1: Evolution From Monolithic to Decentralized
A Content API structured in the manner of the previous Google Maps example may be available at a very high level of service, but likely not at the level of granularity, interoperability, or freedom from latency necessary for our grocery store experience.
In a services-driven architectural approach, services are “independently deployable” once they are defined. So these services are re-aggregated at a much more ad-hoc, immediate, and local level, which places a greater burden on the digital agents at the endpoints rather than centralized content storehouses.
Principle 2: Business-Driven
These independently-deployable services are organized around business capabilities.
Our coupon provider doesn’t need to model every possible technical scenario a coupon might encounter. It just needs to expose its core business cases, Acquisition, Retention, and AOV, and its content, in atomized form, at a services level, described at just enough detail for a digital agent to interpret.
Principle 3: Smart Endpoints and Dumb Pipes
Microcontent services will need to be architected for a high degree of portability. Relying on intelligent digital agents affords the ability to embed necessary contextual logic into the endpoints of an experience instead of managing them centrally. This will take the architecture beyond the capabilities of a typical Content API.
Here’s where the notion of microcontent becomes critical. A digital agent can now re-aggregate that microcontent into a coherent bundle to accommodate a vast array of highly contextualized scenarios.
Principle 4: Services not Projects
The problem with projects is that they have an end-point. This doesn’t really reflect reality — how many content projects have you heard of that don’t require some form of governance and maintenance once they’re completed?
Shifting our thinking to architecting and providing content services will help us keep these services evolving and adapting as contexts proliferate. I personally think we have no choice but to start getting into a services oriented mindset now.
Principle 5: Decentralized Governance
Focusing on content services instead of projects affords decentralized governance — you publish the content, you govern it. This distributes responsibilities for governance across an organization, AND across all of the organizations participating in a given value chain.
So I bet all this distribution sounds like it will create its own management headaches, doesn’t it? To be sure, there will be a high level of organizational alignment and readiness required to accomplish such a shift, so it’s going to have to evolve incrementally.
But there might be a solution for this too, something we like to call an Enterprise Information Model.
An Enterprise Information Model is the logical structure that defines and describes how information is handled across the systems that interoperate with each other in a given enterprise. It’s where the principles of contextual modeling, ontological structure, relationships between taxonomies, change procedures, and content and data governance, can be defined and to the degree necessary, managed.
As Andy Fitzgerald said yesterday in this room in his Desiring Ecologies talk, information models “provide a central point of cohesion.”
An Enterprise Information Model can be a key unifying information asset for a microcontent services architecture.
But in cross-context land, as Andy also pointed out, “we have to avoid re-inventing our information models on a case-by-case basis.” So an Enterprise Information Model has to be flexible enough in it’s own architecture. Parts of it may be instantiated within various systems, but it must itself be abstracted from them, so it can span business contexts. And it has to allow for context-enabled ontologies to be governed somewhat independently. It must strike a balance between bottom up and top-down flexibility so the dynamic feedback loops that ecosystems thrive on can flourish.
So I want to wind down with this thought.
Clearly it would be impossible to build a universal ontology that’s capable of describing all contexts that may emerge. But that’s kind of what we’re asking today’s CMS’s and Content API’s to do.
In my view, it’s time to acknowledge that contexts will continue to proliferate. We must build contextual or context-enabled ontologies that can evolve durably, and sustainably, unburdened by monolithic centralized systems. And these ontologies must be loosely coupled to Enterprise Information Models that can tie them together but only where and when it matters.
I for one, believe Information Architecture is uniquely suited to this challenge. Because as a core discipline practiced in enterprise environments and ecosystems, good old fashioned IA is our best hope to adapt to an Atomized environment.
