Architecting Information and Engineering Content
February 21, 2010
Word visualization from the text of this blog up to this point in time.
From time to time, online discussions turn upon themselves to talk about their own organization and utility. These discussions thus turn into explorations of information and the patterns to which it can incline or perhaps to which it should be guided. As one example, a recent article appeared from Forrester Research on the topic of Information Architecture (IA) and its struggle to gain a foothold of initial credibility amid the main corridors of Information Technology (IT) management, together with the associated sub-specialties of Enterprise Architecture (EA) and Master Data Management (MDM).
Source: Visual Complexity
That Information Architecture has not made much progress in this struggle can be traced in part to its nascent state of maturity as a discipline. This immaturity is itself not too surprising given the magnitude and scope of its purview and the deeply inter-disciplinary nature of its work. One overview of Information Architecture that I find interesting is provided by Michael Cummings at Interaction-Design. Within this survey, the roots of Information Architecture are traced back to Richard Saul Wurman who coined the phrase back in 1975 and who saw the Information Architect as “someone who enables data to be transformed into understandable information”. This comment by Wurman is particularly useful because it highlights a key distinction – between the data from which information is fashioned and the information domain itself. This seems to be a distinction that has been lost in many discussions of Information Architecture – although it is a distinction I will endeavour to re-introduce.
As I have set out in previous posts, and in particular Managing Information and The Truth about Content, I have gone to some lengths to highlight the difference between potential information, which I term “content”, and the information itself, which I describe as being “transactional”. I go to these pains not to be difficult but rather because I contend that it is essential that we approach the problem of managing and optimizing information domains from two directions – from the outside-in, and from the inside-out.
To my mind, most of what we see in Information Architecture is grounded in seeing information from the outside looking in – focusing on how information transactions can be organized, discovered, presented, and used. This is a profoundly important endeavour. However, the success of this endeavour will be forever limited unless another perspective is invoked. This other perspective is what I have termed Content Engineering and it goes out of its way to see information transactions from the inside looking out – focusing on how information transactions are formed and adapted as the product of what is ideally a carefully designed, closely managed and efficiently automated environment. As information volumes expand, as they are at an accelerating rate, it is becoming increasingly important that we consider both sides of this equation – and this means, in most cases, new levels of attention being accorded to the content processes that underpin the more visible information processes.
In some ways, this discussion could be pursued as one that sketches out how Information Architecture could evolve to look more intently at what is inside the information transactions. While this may be an abundantly practical thing to do, perhaps simply to avoid spawning too many new disciplines, I would be tempted to maintain some measure of distinction between these two perspectives of outside-in and inside-out. Within actual projects, I actually do find that we leverage quite different strategies and tools when we are establishing the Information Architecture that dwells upon the surface as opposed to when we are engineering the content processes in the strata below.
This is not to suggest that the complexities manifest within the Information Architecture will be less than those seen within the content layers. In fact, the reverse is more commonly true as once we are looking at the domain of information transactions we are confronted with the universe of instantiations and with it the bewildering transactional volumes and multifaceted business implications. In the domain of the Content Engineering, we have the opportunity to apply selection and prioritization criteria, abstraction techniques and automated content processes so that information transactions can be expressly designed to address identified requirements. The requirements that Content Engineering sets out to address, it is important to highlight, are defined by the Information Architecture activity and the work of understanding what information is needed, by whom, and to what end in terms of supporting a task or satisfying a need. With the requirement declared, the Content Engineering activity can be pursued to establish the most effective and efficient way to address the requirement. Content Engineering is thus focused on process optimization and, once again, when we are dealing with phenomenal scales of information volumes it is critical that enterprises find the efficiencies that the optimization of content processes can introduce.
The Forrester Research report highlights the fact that Information Architecture has made scant progress at winning the respect and attention of the mainstream Information Technology (IT) management regimes. There are indications that the value of, and growing need for, Information Architecture is acknowledged but, as a discipline, Information Architecture still looks nebulous to those who inhabit more specialized, or entrenched, disciplines. If Information Architecture has not yet won its due recognition, then it must be conceded that the domain of Content Engineering is barely even visible. Despite the mountains of cash expended in the direction of information technology, in truth few organizations have endeavoured to think deeply about their information domains and therefore to consider seriously how they should practice the discipline of Information Architecture. Fewer enterprises still have studied their information challenges to the point where they see that they will need to systematically optimize their information performance by delving deeply into the content sources and processes behind their information – into the formative patterns that produce the information itself. However, this is all starting to change as the age of digitization picks up steam and the rate of information expansion fully outstrips our current abilities to cope. In general, the time has come for us to step up the pace with which the interrelated disciplines of Information Architecture and Content Engineering are advanced, adopted and applied.
I still feel unclear as to the IA vs CE distinction; would it make sense to say that IA *enables* the transformation of data into understandable information, and CE *transforms* the data according to requirements of the enterprise or institution?
Posted by: Milan Davidovic | February 21, 2010 at 01:16 PM
Yes, at times I feel a little like a medieval philosopher wrestling with inherited concepts even as I try to describe something new. I guess others would probably draw a different and perhaps less obscure analogy - perhaps to Seventeenth Century Philosphers. In this, content becomes my version of "substance". How obscure is that?
In the picture I was trying to paint, IA could be seen as setting out the design for the information transactions and the CE performs the bull work associated with fashioning the information transactions that fulfil that design. So there is definitely an intimate relationship between IA and CE, and I definitely see the latter supporting, and instantiating, the former. Perhaps this is not too far off your typification.
Posted by: Joe Gollner | March 07, 2010 at 12:49 PM
Wordles are wonderful, aren't they? I like them too.
I seem to be reading your blog in reverse chronological order, and time-lagged. Just a suggestion, you probably are familiar with it: you may like the work done at semi-academic site
http://www.visualcomplexity.com/vc/
as there is content pertaining to information architecture in the context of it being an attempt to "...[transform] data... into understandable information" using data visualization. Quote is from your entry above.
Visual Complexity's work is different in that many of the 700+ projects referenced there are more than a mere mapping of raw data to a visual image. While mappings are helpful, they remain not much more more than an infographic (and yes, I still enjoy infographics, even after innudation).
No, I have no affiliation with the Visual Complexity site. Just sharing.
Posted by: Curious Ellie | April 28, 2010 at 02:00 AM
Hi Ellie
This is the type of sharing that can never be exhausted. Thanks for the pointer. And I have - from time to time - looked at how better visualization can be leveraged in the realm of information management. In one of my whitepapers, called "XML Business Templates", I address using XML to frame out business processes in a way that can be both discussed and executed. In some projects, this has gone one step further to exploring how the process, and its execution, can be visualized.
Colleagues at the Intelligent Content 2010 conference (on which I have a post - http://www.gollner.ca/2010/03/intelligent-content-2010.html) demonstrated a metadata driven discovery interface for product information that was delightfully visual and interactive. They had, I observed, made "metadata sexy", an almost impossible feat. More to the point, the visualizations they had introduced was eagerly embraced by users - with many of them saying that they made their work more enjoyable and more enviable in the eyes of others. There seems to be more to visualizations, if I can say it this way, than meets the eye.
Posted by: Joe Gollner | April 28, 2010 at 04:10 AM