IA Summit 2015 Main Conference Talk
Topic(s): content modeling, content strategy, and cross/omni channel
Digital content experiences emerging in the next decade will look, feel, and be consumed very differently from those of today. As today’s “app and page” consumption paradigm gradually recedes, replaced by a much more immediate, fragmented, and continuous core experience, content management organizations face a point of consequence.
The demands of emerging digital experiences threaten to strain traditional enterprise content management approaches to the breaking point. Enterprise IA organizations will be forced to evolve to meet the complexity of this challenge by becoming increasingly granular in their content and information modeling. This shift will place heavy emphasis on the development of flexible information models containing rich secondary data to describe increasingly small, interoperable, and portable units of content.
About the speaker(s)
Toiling behind the presentation layer since before the Web, Bram Wessel is the co-founder of Factor, a Seattle-based IA firm specializing in enterprise information modeling.
Long before it became a chic corporate catchphrase, Bram has always believed that technology should serve humans, not the other way around.
An avid oenophile and fly angler, Bram is passionate about terroir and tight loops. With stolen time, he cultivates Hood Canal oysters, and makes Yakima Valley wine.
Bram Wessel: Let’s have a show of hands. How many of you have started reading, or 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 that’s probably almost everyone.
Keep your hand up, if you’ve never had any problems doing this. That means you’ve never lost your place, or had to scroll, or scrub, or reload, or relaunch anything at all on a second device ever.
Bram: I’m shocked at this point if anyone still has their hand up, and that’s because they’re widely promised. These experiences don’t yet work as reliably, as we think they ought to. This experience is much simpler, than any other experience we’re going to be talking about today.
The promises brands are making about experiences that we should expect in the near future sound like they’re going to be fiendishly complex by comparison. By futuristic experiences, I’m not talking about toilets that tweet.
Bram: Even though, somehow, that’s already a thing, apparently.
Bram: Some guy actually re-tweeted that, which is amazing to me.
Bram: So, what I’m talking about are experiences that traverse environments or, more precisely, context. Whether they involve time shifting, place shifting, device shifting, multiple devices at once. The one thing they have in common is multiple context.
What do we mean by context? In his brilliant new book, “Understanding Context,” which you may have heard of, 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 by nature.
As these digital agents evolve, a network effect is in play, and digital contexts are proliferating. Much to the chagrin of Fred Armisen in “Portlandia,” when he got in a terrible feedback loop trying to switch between devices.
At the same time, experiences are becoming more immediate, fragmented, and continuous. This means the potential for contextual disruption is increasing exponentially.
I’m here to tell you that contexts are not going to stop proliferating anytime 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 that US adults now average more time on the Internet using mobile devices than PCs. 84 percent of people say they use a smartphone or a tablet to multitask.
In Skynet news, we’ve crossed an important threshold. As of October of 2014, there are now more devices than people in the world.
The bottom line is it’s impossible to predict what contexts users will want content in next. Unfortunately, the world view that most content organizations have lags pretty far behind how actual humans are consuming and using content. We can see this in the way that brands tend to describe the world, as a series of not tubes but channels.
You’ve probably had a client or a colleague 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. Here lies the problem, with our least favorite buzz word, 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 discreet, and it’s virtuous to maintain consistency across these channels, often at the expense of coherence.
This is a theme that’s been emerging this week, so far. 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 that’s just not how organic experiences usually work.
When it comes to experiences that involve multiple contacts, where users are in control, this notion of an array of channels seems inadequate. There’s a bigger problem, which is that contexts aren’t actually discreet. They overlap. Often they occlude, and sometimes they collide.
Of course it’s a big problem, if you’re communication gets out of sync. 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 the critical tipping point, for organizations that manage enterprise content. 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. When it does, it’s likely to be a gateway drug for other ones.
Then suddenly brands and enterprises will be scrambling to adjust to yet another new paradigm, just as they were with the web, social media, and mobile. The biggest challenge that posses, is for those of us who create and manage enterprise content.
Now as Karen McGrane, and Ethan Marcotte, and other people have been warning us for a while now, it’s impossible to predict where content is going to need to go next. It’s going to be impossible to predict all the permutations of what content users will demand, in this proliferating context.
As contexts proliferate, units of content that organizations must manage to target all 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 pretty big ass store on the logos up there, so I should maybe be asking who hasn’t. Has anybody gotten a coupon with your receipt at the grocery store? Not as many as I thought. 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 micro content for 31,000 food, drug, and convenience stores in just the US alone. You too are at a major point of consequence, because your clients are starting realize that they and their suppliers can all benefit from new forms of experiences that are just now becoming possible.
Coupon provider’s 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. How would we define micro content?
Let’s examine the recent history of content. In the early days of the web, the unit of management was the page, right? It took almost no time for people to realize that this content management model wasn’t going to be sustainable, and the first content management systems started showing up. As CMSs 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, or an amalgamation of systems. But as people have been pointing out since the first edition of Lou and Peter’s Polar Bear book, the great challenge has always been how to chunk content so it can be managed more efficiently.
As this chunking gets more and more atomic, we start to see asymmetry of production versus management. It is now a lot more challenging for organizations to manage content than it is to create it in the first place. By the way, this is my copy of the first edition of Polar Bear. I went out for a 5K with Peter Morville just this morning, and I’m still waiting for my signature too.
Bram: We’ve gone from something like this, to something more like this within which we find something like this.
Bram: 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 context by the appropriate means.
Thanks to Kristina Halvorson and a host of others, we’ve realized that the content blob, you know what I mean, that unlimited free text body field in every CMS where most of our content ends up. That blob 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 are better managed individually.
Is micro content just small chunks of content which we’ve known about since the dawn of our discipline? 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 “blobby ass blobs” are what got us into trouble in the first place.
I work with taxonomists all day, and I love that the first word this poster uses to describe the blob is “indescribable.”
Bram: Wow. You got a taxonomist joke. Awesome. I’m with my people.
Bram: A better description of what we mean by micro content would be disaggregated, one might say “atomized” units of content constructed so they can travel independently across contexts, and be reaggregated into coherent experiences, which brings us back to the coupon. A coupon provider’s business model involves lots and lots of micro content widely distributed in various states of aggregation.
Their core service is not a content destination, and it never has been. It doesn’t just rely on a content management system. It relies on dozens of internal systems that manage different types of data that describes content. And when I say “data,” I do not 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 really great example of the scale that they’re talking about.
The screen printer in this photo is owned and maintained by a company called Catalina. You can see their name on the face plate. The slide of all those retailers that I showed you before, the 31,000, those are Catalina’s clients. That means Catalina is involved in 300 million retail transactions per week. That’s about 15 and half billion transactions per year.
The amount of data, the level of infrastructure, the sheer 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 screen printer at checkout is really 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 have evolved over the years it’s usually still just a piece of paper. You thought print was dead, again, right? A coupon seems simple. It’s usually composed of minimal amounts of chunks, including an image, usually a product shot, some copy, and often a barcode. In some cases this amounts to no more than four 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 it and then retrieve it in a highly contextualized moment 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 of content in a lot of different ways. But how often do we think of content as actual currency? This means a coupon provider is basically an ancillary transaction service that simply augments transactions by attaching small units of value to them through the distribution of micro content. 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.
Questions like, “What items are being purchased? Where are they being purchased? What partners of the coupon provider might be involved in a transaction? Are there offers or campaigns related to any of the items being purchased?” These are the basics that drive the algorithms used to decide what, if anything, comes out of that screen 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 basically everybody in the value chain.
To provide this service, a coupon has always been a unit of content that traverses contexts, which couldn’t be more different from the content consumption paradigm that we’re used to where there’s 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, 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 so thoroughly embedded into the traditional coupon provider business model that they get paid completely on the distribution side.
As you can see the business context loop in the coupon provider’s traditional world is quite simple in concept, but it’s quite complex in execution. To demonstrate this, I’m going to use techniques that we all should be familiar with, personas and scenarios.
This is Andrea. She’s in her mid-30s. She’s married with two children. The economy’s been rough recently but through it all Andrea’s held down a part-time job in the accounting department of a sewing equipment manufacturer. Given her experience with accounting, Andrea handles the home finances for her family. She’s adept at comparison shopping and finding the best deals for the things that her family needs.
Andrea shops at Target. Yay, Minneapolis. She also shops at Fred Meyer, where she’s a loyalty club member and it’s generally slightly more inexpensive. Sorry, I’m just going for realism. She also clips coupons to use in her shopping, like these and she uses a shopping list app on her smartphone, which is able to scan barcodes 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. Normally, once Andrea’s gathered all the items for a given session she just proceeds right 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 two are recorded, also with a scanner.
Also at some point Andrea is asked for her loyalty card information. Sometimes she dips her card in the card reader, but if she doesn’t have it with her she can use her phone number. Only when all other elements of the transaction are prepared does Andrea usually pay for her transaction, usually with another card reader dip. Andrea almost never pays with cash, because she’s got a mileage card. It doesn’t make a lot of sense to her. She’s got an accounting background, after all.
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 she really doesn’t give it much thought.
As you can see, the coupon figures into two steps of this typical retail transaction. In order to be redeemed, it 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.
That’s the happy path. But remember earlier we talked about how coupon providers are at a point of consequence. Why is this? 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. They’re competitors. Increasingly people like Andrea are being offered the option of paying by phone. Soon they’ll 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, all that stuff. The promise of the future is that you’ll be able to complete a transaction in one gesture like a tap.
Where does this 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 hands with your bag, 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 screen 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 or 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, these days a coupon is becoming much more than just 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 of transfer is increasingly becoming digitized.
Apple, for instance, has announced support for coupons in its 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’s 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 undertaking in an entirely digital ecosystem, the value a coupon provider delivers is still quite important to the value chain.
Getting rid of those printers also means getting rid of the physical coupon, potentially. That would fundamentally change 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 that 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.
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 that 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.
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? That’s what we call service evidence.
When that notification happens, how is it going to be perceived by the customer? Is it going to perceived as value, as currency, or as something more like notification spam?
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? If so, what would be the method of digital distribution?
Remember, a coupon provider hasn’t traditionally had the visibility or level of access to the consumer that will allow them to insert themselves into this scenario. Let’s remodel the coupon experience.
Back to Andrea. By the way, the quality of the stock photography that’s available these days for personas is unbelievable. I’m shocked. Now, we’re going to project her 18 to 36 months in the future.
She has a newer smartphone which is equipped with near field communications, NFC, which you might have heard of. She uses a digital payment system. She pays for groceries with her smartphone.
One day, she’s heading out to Fred Meyer. She opens up her shopping list app and gets notification for of a new feature that will plot the most efficient route through the store to get all the items on her list. That 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 her route.
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. When she gets to the item before that in her list, her app prompts her with alternatives to the cereal that she usually buys that are in stock today.
She notices that one item has a coupon available for it, so she taps that item. Up pops a coupon for a dollar off. This brand of cereal usually costs about the same as the one she buys. So, she’s grateful to save a little money.
A couple of items later, she arrives and discovers that there’s yet another coupon available for a brand of dish soap that she usually buys. Great, even more savings.
As she heads to the next item, which is 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 has never 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. At the receipt screen, she gets a list of all the coupon and loyalty program savings, she accumulated during this shopping session. She saved about $8.75, which lowers her total purchase from about $82 down to just over $73. That’s not bad.
At that point, a notification appears on her screen for another coupon for the allergy medicine, she just bought. Even better!
What happened here? 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.
It was so pleasant that apparently she dreams about it when she is perched over Vince Vaughn’s at work the next day.
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 its 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.
Let’s not forget about users. They’re going to need some meaningful incentives to participate or they’re just going to default back to the way they’ve always shopped for groceries before and ignore all these newfangled stuff.
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 the 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 with an infrared scanner.
In order to entice a consumer to use it, it must also have marketing copy. For example, a call to action or 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.
Digitization means that 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 a broader range of moments in a given customer’s journey.
This doesn’t necessarily reflect 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. 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 our 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? 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 another 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 medication she wanted. Not so happy path. It’s a lose-lose for everyone in the value chain.
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 microcontent 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 environment’s 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’ll 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 these services to be delivered asynchronously to avoid latency.
As context 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, for example, 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 app and the grocery retailer environment.
If you’re an enterprise taxonomist or information architect, whose job is to manage enterprise content, I bet this seems like an enormous amount of work. I might even say a shit ton. Well, there’s a precedent for this style of architecture, which might reduce some of the 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’ve come up with a set of principles that they recognize as hallmarks of the style, and I think it’s worth pointing out that this is not prescriptive. They have hit upon these services by watching the microservices style evolve, so it’s not a rigid formulaic prescriptive description of a style. It’s what they see happening in the development world.
Now, before everybody freaks out, I’m not going to suggest that we force fit yet another agile methodology onto our information architecture work because as a discipline, we’ve tried that before, and it usually doesn’t end well. Also, this isn’t the time or place for a thorough explication of all the concepts behind microservices.
I will suggest that certain architectural principles of the microservices style may be useful for designing microcontent services, and I’d like to try to suggest which of those principles might benefit information architects as we think about how to model microcontent.
First, I want to take about a one-slide detour and talk a little bit about content APIs. In her excellent book “Content Everywhere,” Sara W-B, as some of you may know, describes a content API by comparing it to a well-known data API. Just like the Google Maps’ API allows Google content to be used on lots of non-Google websites, she writes, a content-driven API stores data in a central place, where other services can access it and use it.
OK, now onto the principles. You’ll see how this ties back together.
Principle one. 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 not likely at the level of granularity, inner operability, or freedom from latency necessary for our grocery store experience.
In a services-driven architectural approach, services are independently deployable once they are defined. These services are reaggregated 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 two. Business driven. These independently deployable services are organized around business capabilities. Our coupon provider doesn’t need to model every possible technical scenario that a coupon might encounter. It just needs to expose its core business cases, acquisition, retention, and AOV, and its content in itemized form at a services level, described at just enough detail for digital agent to interpret.
Principle three. 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 typically or traditionally structured content API.
Here’s where the notion of microcontent becomes critical. A digital agent can now reaggregate that microcontent into a coherent bundle to accommodate a vast array of highly contextualized scenarios.
Principle four. Services, not projects. The problem with projects is that they have an endpoint, and this doesn’t really reflect reality. How many content projects have you heard of that don’t require some form of governance or maintenance once they’re completed, right?
Shifting our thinking to architecting and providing content services will help us keep these services evolving and adapting as context proliferate. I personally think we have little choice but to start getting into a services-oriented mindset now.
Principle five. Decentralized governance. Focusing on content services instead of projects affords decentralized governance. You publish the content, you govern it. It’s kind of like you build it, you run it, which is what they practice at Amazon, so that people keep maintaining their code and don’t just leave it out there to degrade and fall apart. This distributes responsibilities for governance across an organization and across all the organizations participating in a given value chain.
I bet all this distributedness sounds like it will create its own management headaches, right? Well, to be sure, there’s going to be a high level of organizational alignment and readiness required to accomplish such a shift, so this is going to have to evolve incrementally. There might be a solution for this, too, which is 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 into 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 microcontent services architecture. In cross-context land, as Andy also pointed out, we have to avoid reinventing our information models on a case-by-case basis.
An enterprise information model has to be flexible enough in its own architecture. Parts of it may be instantiated within various systems, but it must, itself, be abstracted from them, so it can span business context. 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 that dynamic feedback loops that ecosystems thrive on can flourish.
I want to wind down with this thought. It’s not about an ontology for context. It’s about building contextual ontologies. 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 expecting today’s CMSs and content APIs to eventually do.
In my view, it’s time to acknowledge that contexts are going to continue to proliferate. We must build contextual or context-enabled ontologies that can evolve durably and sustainably, unburdened by monolithic centralized systems.
These ontologies must be loosely coupled to enterprise information models that can tie them together, but only when and where it matters. I, for one, believe that information architecture is uniquely suited to this challenge because as a core discipline practiced in enterprise environments and ecosystems, good old fashioned IAs are our best hope to adapt to an itemized environment.