Posted by Gene Leganza on March 24, 2010
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).
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.
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.
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.