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.
When I was searching for input to my first business architecture research report titled “Business Architecture’s Time Has Come” in October of 2008, I had a hard time finding true business architecture practitioners to participate in the study. To be sure, there were lots of EAs thinking about business architecture, but very few really doing business architecture.
Earlier that year I had facilitated a group discussion about the current state of business architecture at an EA conference. There were more than 30 people in the room, and the discussion was lively. Much of the first half hour focused on what business architecture really meant and how it should be applied. There were a wide array of positions and some very impassioned exchanges. To shift the discussion to more practical areas, I asked “Who has an active business architecture practice?” To my surprise not one person in the room raised their hand.
What a difference a year makes. Our 2010 research shows that 40% of organizations now have an established business architecture program. And most of the rest are working toward creating one. For a large majority of EA teams the question has shifted from “When should I start my business architecture effort?” to “How do I get business architecture moving?” Forrester’s 2010 EA Forum had a track dedicated to enterprise business architecture. I presented or facilitated three business architecture sessions that were all heavily attended with lots of active participation. Some of the interesting ideas that surfaced during forum discussions were:
I recently published a sample business capability map for insurance firms as a way to illustrate many aspects about the description and use of this business architecture methodology. One of the readers of this report commented “It seems the business capability maps provide value as a complement to existing methodologies” and referenced Strategy Maps and Business Process Modeling. This made me realize that I should explain more how Forrester sees capability maps as more than a complement – and why we, along with many of our clients are so ‘jazzed up’ about this methodology.
A bit of background: Forrester views capabilities as stable elements of a business model, where the dynamics of a firm are reflected in the business goals for the capability, and the processes, functions, information and other assets which are how a capability is delivered. A capability map describes all the capabilities, and the relationships between them, which an organization needs to have as part of their business model to achieve outcomes. Think of Sales as a simple example, where there are business goals and associated metrics for Sales, and processes, functions, information and people assets necessary for this capability to be delivered. And Sales has a relationship to Fulfillment, to Customer Service and to Marketing.
Forrester analysts have long been active bloggers about the roles and subject areas they cover. If you've been a prior visitor to the Forrester Blog For Enterprise Architecture, you've seen posts from Randy Heffner, Gene Leganza, Jeff Scott and myself. From these beginnings, we've learned a lot - and we've put these learnings into our new blog platform and network.
Here's an overview from Cliff Condon, the champion and project manager for this new platform:
Hey everyone. Here it is – Forrester’s new blog network. We made some change to improve the experience for readers and to encourage more analysts to blog. Feel free to poke around and let me know what you think.
There are a few things I’d like to point out to you:
* Everyone’s welcome here. Forrester analysts use blogs as an input into the research they produce, so having an open, ongoing dialogue with the marketplace is critical. Clients and non-clients can participate – so I encourage you to be part of the conversations on Forrester blogs.
* We still have team blogs focused on role professionals. Our role blogs, such as the CIO blog and the Interactive Marketing blog, are a rollup of all the posts from the analysts serving that specific role professional. By following a role team blog, you can participate in all the conversational threads affecting a role.
* And now we’ve added analyst blogs as well. If you prefer to engage directly with your favorite analyst, you can. Look on the right-hand rail of the team blog and you’ll see a list of the analyst blogs. Just click on their name to go to their blog. Or type their name into “Search”. An analyst blog is a place for the analyst to get reaction to their ideas and connect with others shaping the marketplace. You’ll find the blogs to be personal in tone and approach.