Intro To A Research Series On Information Architecture

This is not really a new blog post. It's a relatively recent post that didn't manage to make it over from my independent blog. I wanted to be sure it made it to my Forrester blog because I will have lots of publications and posts on information architecture coming up and this was a post on my first piece in this series. So here's the original post:

In January, the lead-off piece that introduces my research thread on information architecture hit our web site. It’s called  Topic Overview: Information Architecture. Information architecture (IA) is a huge topic and a hugely important one, but IA is really the worst-performing domain of enterprise architecture. Sure, even fewer EA teams have a mature — or even active — business architecture practice, but somehow I’m inclined to give that domain a break. Many, if not most, organizations have just started with business architecture, and I have a feeling business architecture efforts will hit practical paydirt fairly quickly. I’m expecting to soon hear more and more stories of architects relating business strategy, goals, capabilities, and processes to application and technology strategies, tightly focusing their planning and implementation on areas of critical business value,  and ultimately finding their EA programs being recognized for having new relevance, all as a result of smart initial forays into business architecture in some form.

But information architecture will continue to languish, even though more EA teams have been working on this area for a longer time, and there’s a more direct connection between IA and EA’s traditional comfort zones of technology architecture and application architecture. IA is just very hard to do. It’s highly political, it can appear irrelevant to tactical business needs even more than other areas of architecture, it seems like a boil-the-ocean sized problem, and there is an increasingly dizzying array of technology and architecture options to consider. If you had a green field, it would be difficult to figure out what the best configuration of centralized, consolidated data warehouses and federated/virtualized information fabric to build. And no one has a green field. Not a big surprise that the IA domain lags (see the figure below).

 

Survey respondents' progress on various EA domains from Aug 2009 survey

On a recent consulting gig, where I interviewed a bunch of IT and business folks and made recommendations about where the organization should focus its EA efforts, I identified four areas that they should concentrate all their efforts on. One of them, the most important one, was to put an information strategy together for two important business units. Their CIO told me after my final presentation that she thought the advice was right on, and they were going to pursue those priorities right away. Except for that information strategy one — they’ll hold off on that one for now. A typical scenario!

Take a look at the technology areas that our survey respondents (all EAs) said would be important over the next two years (see the next figure). I’ve highlighted the ones that IT really can’t pursue effectively without a formal information architecture practice.

Technology trends areas requiring solid information architecture practices


 

So, IA is going to be hot this year, right? Probably not. Check out this last chart that shows IA as an also-ran in the list of EA priorities.

2010 EA priorities from our August 2009 survey: IA not near the top

In the published piece, I present some other data on things like the maturity of data governance practices and then I  discuss why IA is such a problem. I also present a high-level approach for addressing IA in general. I borrowed this approach from analyst Randy Heffner. Randy introduced the idea of “street-level strategy” to describe a non-big-bang approach to a large undertaking. It couldn’t be more appropriate for information architecture. It’s about having a vision for the kind of architecture you need but not acting like you’ll be able to stop normal day-to-day activities and dedicate resources to building out that architecture before once again resuming business as usual. It’s about being opportunistic about nudging every project that comes along in the direction identified by your vision. Anyway, after all this material, I get into all the typical stuff that a Forrester Topic Overview gets into — which is to break a big subject down into component parts, and point to the existing research we have on those parts (each of which is a fairly meaty topic on its own).

I just introduce the ideas in this piece. I plan on getting a lot more prescriptive in my following research docs. This quarter I’m writing up the fruits of the discussions I’ve had with analysts Mike Gilpin, Randy Heffner, and Noel Yuhanna on the role of IA in SOA and information-as-a-service initiatives. This is where I will begin to put some flesh on the bones of the street-level-strategy approach and get into how implementation considerations — both in terms of business requirements and technology complexity — can help guide a stepwise approach to such a big initiative as IA. Following that, I’ll be working with analysts Leslie Owens and Stephen Powers to lay out the organizational roles that need to be pulled into an information architecture initiative, with some best practices guidance for coordinating such a political cross-silo program. Please get in touch if you have some thoughts about the kind of research on information architecture that you’d find particularly useful.

Comments

What kind of «IA» research I’d find find particularly useful?

First things first: Thanks for a very good article!
Then to what I’d like to see: Research on how EA professionals view/relate to APPLYING SEAMANTICS (…the kind that covers taxonomies, linked data and beyond, e.g. through means of RDF/OWL, ISO Topic Maps, Core Components and/or UML w/Profiles & MOF).

My experience is that there are at least two major fields where this is beginning to come into play:
(1) Process/energy industries (primarily petroleum)
and (2) Defense (read: armed forces)

While category (1) shows limited deployments of ISO 15926 (with or without iRING), players within (2) are adjusting the latest releases of major architectural frameworks -- DoDAF and MoDAF respectively (both in v2) -- to be better fit to use semantics.

Just my two cents of opinion :-D)

Bst rgds, André T. in Norway (http://no.linkedin.com/in/torkveen)

Research on Applying Semantics

Thanks a lot for your comments, Andre. I currently have the general topic of looking into what people are doing with semantic capabilities on my list for research later this year, but I had not fleshed it out much beyond the general topic. Your comments will help point me in a couple directions likely to yield results. Thanks again!