Intro To A Research Series On Information Architecture

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).

Information architecture lags all domains except business architecture

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.

Important technology decision areas for 2010 & 2011

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: IA is 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.

A Note About Forrester’s Policy Of Free Access To Topic Overview Documents

Topic Overviews are typically relatively light on new content. They mostly introduce and rationalize a body of work on an important topic. As such, Forrester doesn’t charge its by-the-drink price for this type of document. Topic Overviews point to a lot of other research, all of which is only available for a fee or to Forrester subscribers. This creates a rather ironic scenario — Forrester doesn’t charge as by-the-drink buyers would be disappointed and angered by the lack of original research in the document itself if they had to pay for it. Makes sense; but because they are free, a lot of non-clients access Topic Overviews, and then if the document makes a compelling argument to read further, every click on a link of interest leads to an abstract and a notice that access is only for a fee. This can also anger readers who then perceive the free access to the Topic Overview as a cheesy marketing ploy. It’s a bit of a no-win situation. For my IA Topic Overview, I included as much primary research via interviews and survey data as I typically would for a document of this length, with the hope of avoiding the frustration scenario while still serving as a consolidator of related research by other analysts. Did it work? As of this writing, 11 people rated my document, with an average score of 8 out of 10 (this is actually a lot of ratings — typically docs get read a couple thousand times with 0-2 people rating them). I’ve seen the scores come in as they were entered and the 8 is the average of ten nines and one zero. The zero-scorer did not bother to leave a comment about what he or she objected to; that indicates the standard free/fee frustration scenario. Oh well!

Forrester’s EA Forum – The Panel Discussions

Wow, I really dropped the ball on this blogging thing. I haven’t written an entry since the end of October ! I guess our annual Q4 frenzy got to me and I reverted to old habits — drop everything except what’s due next. And to think that despite my lack of social media activity, I managed to nab the coveted 233rd slot in Technobabble’s list of top analyst blogs! Imagine what might have been possible if I had kept up. Blew my big chance for fame; or, at least, a shot at a 22x ranking. Oh, well. I have resolved to do a more consistent job of fitting social media into my workflow. I’ll make up for some lost ground over the next couple weeks once Forrester’s EA Forum in San Diego (February 11 & 12) and London (March 2 & 3) convene — I plan on tweeting and blogging frantically to keep up with the flow of ideas that those events produce.

The flood of ideas comes from the constant interaction with practitioners, from the pre-conference program for the EA community members (Forrester Leadership Board/EA, aka the EA Council), the one-on-ones that are scheduled for any time slot an analyst has a free 20 minutes, the questions and discussions during and after formal sessions, and just all the random encounters that happen when a lot of people are in the same place at the same time.

An added plus this year will be the presence of Brenda Michelson in the role of official external blogger. She’ll be wandering around, attending sessions, commenting through her blog and Twitter, and, I hope, acting as a stimulus for discussions at the conference as well as in the blogo- and twittersphere. This should prove much different from just inviting the press.

This year, besides a vanilla stand-and-deliver session, I’m also doing three panel discussions. Now, panel discussions can be fun, stimulating, and illuminating, but they can also be extremely ho-hum. It’s challenging enough to say something meaningful in a 45-60 minute session without breaking the time up into smaller chunks to rotate through panel members’ comments — you can easily wind up with a series of truisms being trotted out to the nods of the audience with no real value added beyond general encouragement to keep on doing what we all know to do.

But I’m psyched about these panels because I’ve lined up questions I think will dig out the nuggets of advanced knowledge that my esteemed panelists have in their heads. I’m not going to go so far as to take on the persona of an obnoxious talk show host, but I will use the panelists’ answers to questions as the jumping-off point to really dig into what made them successful, or exactly how to go about implementing a new approach to architecture.

I’m doing a panels on: 1) Best Practices Of Successful EA Teams (a keynote session), 2) Next-gen EA, and 3) Business Design As The Key To Information Architecture. What would you want to ask successful EA leaders about the obstacles you are facing? What about a bunch of supposed experts on EA 2.0, or whatever we’re calling this phase of the evolution of EA? How about that most difficult of places — the intersection of application development, business architecture, and information management? What would you ask of experts who say they know how to best juggle the demand for tactical results with strategic needs? Here is a sampling of the questions I have lined up. Feel free to comment and suggest approaches. If I use your question, I’ll be sure to blog about the answers here.

Panel: Architecture Guides IT ’s Delivery To Business—Key Practices From Three Firms

Questions:

How do you deal with the tradeoff between the value of keeping to standards and being “responsive to the business” by allowing for non-standard technology implementations?

How do you deal with prioritizing your resources around the right issues? If your answer is to go where the heat is, how to you ensure that you don’t get too tactical?

How do you ensure that EA influences business and/or IT decision-making? How do you know that the architecture is being considered when people are making decisions? What is your governance model and how do you know it’s working?

Would you characterize EA as an IT function whose charter is to help IT plan better and to guide technology strategy, or as a business function whose overall goal is to help the business meet its goals? If the former, is all this “EA 2.0” talk about being closer to the business just a lot of hot air? And if the latter, should EA report into the business instead of IT?

Panel: Next-Generation Enterprise Architecture

Questions:

We’ve heard a lot about “EA 2.0,” “next-gen EA.” Why do we need a new approach? Is it because the old approach isn’t working? Will the new approach “work” better? Is next-gen EA a change in what EA is trying to do or how it’s going to go about doing it?

If, in the new scenario we keep hearing about, EA is closer to the business, is it farther from technology? Does EA leave its responsibilities for technology strategy and technology governance behind? If not, then this is additive, isn’t it? So this means EA teams will get bigger? Or do EA teams teach IT technology subject matter experts to add architecture-related tasks to their day jobs, thereby making the technology-related responsibilities of EA more virtualized?

Will EAs be involved in forming business strategy? Or will EA be, at most, “shaping demand,” whatever that means? Or, will EA be doing all these new things just to do a better job of setting the technology strategy?

How can an organization tell if they’re ready to make the move to next-gen EA? What are the indicators that an organization is ready? Or, conversely, what are the indicators that an organization is not ready to attempt a change? Are there some types of organizations that will be better positioned for this move? Is it sector-related? Size-related? Related to any kind of maturity model?

What comes after this? Two years from now, what will we be describing as the next next-gen EA program? Is EA 3.0 completely virtualized with architects absorbed into the business?

Panel: Briding the Silos: Business Design As A Guide To Information Architecture

Questions:

Are there good reasons to be pursuing a service-oriented architecture or creating data services and not establishing a canonical information model? When is it OK and when is it not OK? How can it be a good idea to pursue IaaS without establishing a canonical information model? What is the downside to not engaging in formal IA activities?

About half the people I’ve surveyed who say there have a formal IA practice say they have a predominately bottom-up approach. This means that the primary trigger for internal IA research will be an application project. Now, it’s good that there is a driver for pursuing IA but it’s problematic to impose a project’s timeline on that sort of strategic  activity. What approach to IA can best accommodate the need to do some IA “archeological digs” in the context of projects?

IaaS, MDM, ETL, BI, data federation, data virtualization, semantic technologies, etc. etc.: Are these all different approaches to different problems that just happen to be about information, or are they connected? Would it be crazy to expect to be able to build a strategy that uses each of these information-related technologies in a complimentary way? And what about BPM? Where does that fit in? Are there any shops out there with information strategies that present a coherent view of the use of these technologies to achieve business goals?

How do you connect “business design” and business architecture to a coherent set of strategies for all the related information architecture and information management areas?

People have had enough trouble doing IA because it’s highly political and the technology requires an architect-and-high-priest-level of understanding of some pretty esoteric areas. Now we’re telling everyone to add in a major business architecture component to drive and focus the whole set of initiatives. Is there a pragmatic approach to this?

Your turn!
What questions would you ask the experts on these panels?

Bridging The Silos: Business Design As A Guide To Information Architecture

Q & A From Next-Gen EA Teleconference Oct 09

Jeff Scott and I presented a teleconference entitled “Next-Generation Enterprise Architecture” last week (available here). It was a lively session with a lot of material on our side and a lot of questions from attendees. We focused on the questions over the phone in the live session and decided it was best to handle the written questions that came in via the Webex chat in a blog post.

Two closely related questions kicked things off:

“How are enterprise IT organizations rationalizing EA’s role in Demand Management with ‘traditional’ Customer Relationship Management?”

“Traditionally, aligning IT strategy to business strategy is typically the job of Head of Application or Application Client Relationship Manager.  EA was more a technical advisor.  Are you advocating the marriage of these positions?”

Response

Traditional IT customer relationship management has been handled by application managers or dedicated client relationship managers. Unfortunately, this arrangement has perpetuated a business unit silo approach down into the IT organization. Demand mangers have done just that: managed the demand their business clients present them with adding little if any enterprise perspective to leverage existing resources or collaborate on new solutions. Relationship managers have done a good job collecting all of the requests, prioritizing them, and sequencing them into the solutions delivery workflow. What is needed is more demand “shaping” and less demand “management.” And this is where EA s can help. Using business architecture tools and techniques, EAs can help ensure investments are being optimized across the business unit silos.

Forrester is seeing leading edge EAs working with business leaders at a conceptual/strategic level to determine what needs to be done with an enterprise perspective, rationalize the needs at the enterprise level, and then help translate the needs into business unit aligned initiatives that can be managed by the traditional demand managers. This shift does require that EA move from being technical advisors to strategy advisors.

EA's Value To The Top CIO Priorities

Next question:

“Given a mixed environment of legacy, COTS, and custom solutions, supporting a changing business environment and delivering precision IT says EA has to not only cover business/process architecture, but also the information architecture. Where / how do you see information architecture coming together?”

Response

Now that’s a big question and its generally the main subject of my (Gene’s) research agenda for the next year or so. In the distant past, organizations attempted to pursue information architecture and wound up mired in a boil-the-ocean initiative that never ended and always seemed far from producing value. The failure of these initiatives made people very cautious about starting them up again. But all the attention on business processes brought about by the popularity of BPM suites as well as decomposing processes into services to pursue SOA has brought information architecture front and center. All processes act on data and focusing on process without getting the data right just doesn’t work (and there are other forces at work also raising the priority of information architecture). The only way for information architecture to come together is through ownership and conscious effort. We’re strong advocates for the EA team to lead the charge, but what matters most is that someone own the overall effort and then engages the appropriate IT and business subject matter experts  to develop the information architecture and then govern it. The real trick is to scope the program in increments to be able to deliver near-term benefits in the context of projects that deliver business value while working on the strategic goal. But by no means should an organization treat the whole issue of rationalizing data sources casually in an ad hoc manner. Look for upcoming research from us to provide more details on this issue.

EA's Value To The Core IT Processes

We’ll take the last three questions together as they’re all about tools to support EA:

“EA teams struggle to justify the cost of tools to support them. There is rarely any quantified ROI of investing in EA solutions.  How are they to overcome this?”

“Can you address the role of collaboration tools in EA teams?”

“Is it idealistic or too far out to consider that automating many related aspects of EA through tool integration is possible. For example, from the information architecture viewpoint you structure your data classifications and categories; from a technology viewpoint you capture the maturity of your products (i.e., those strategic ones to re-use, those to contain/retire, etc.); and for solutions architecture you capture business requirements. Is there a way to use the tools associated with one space in the other?”

Response

Most EA teams just use diagramming tools such as Visio either because, up to now, that’s all they really needed or because they could justify neither the cost of the more elaborate EA tool offerings nor the time investment needed to master them and train everyone they’d want to use them. That picture is starting to change as EA teams become more federated and find themselves needing to tie a growing multitude of SMEs into a cohesive EA effort. The trend towards business architecture will also help move this along as a key focus area for this discipline is relating medium-detail-level business architecture components, such as capabilities, to their corresponding IT components, such as services or applications. Analyzing dependencies in complex environments and building detailed strategies will increasingly require a repository, modeling standards, and a variety of models. The gold will be in analyzing the interrelationships between business capabilities and technology’s capabilities, and the ability to look at the layers separately and together will become increasingly important. And even if this kind of analysis can be achieved manually with great effort as a one-off project using simple Office tools, it will be impossible to maintain manual models in complex environments, and the value in the effort will be quickly lost as the info gets out of date. On top of that, as the second question hints at, the growing network of architects will make some sort of collaboration tools a requirement.

However, while I feel confident the need for EA tools is growing dramatically, that doesn’t mean that it will be much easier to justify the investment in one. It’s still difficult to communicate the value of EA efforts to folks who focus intensely on near-term solutions within organizational silos (that is, most people in most organizations). But if the EA function exists, then somebody in a management role in your organization must believe in its value. Start there to explain what you would do with a tool. Be specific. Generalizations about how a tool would be a great asset clearly won’t fly. But the ideal of pinning tool value to a specific ROI may be elusive. You could use the tool to analyze, for example, your application and infrastructure software portfolio and identify all the redundancies, claiming all the cost savings that would result from consolidation as tool ROI. But you could probably do that, albeit with more labor, without a tool, and many consolidation projects don’t get past the drawing board.

So I don’t think that linking to a specific project’s ROI is the way to justify investment in an EA tool. I think the value in an EA tool is strongly related to the value of the EA program, which is both fuzzy and powerful. Fuzzy is bad when you’re trying to get someone to write a check, but EA can provide significant value and an EA tool can enable analysis and visualization in important ways.

Back to starting with your local EA advocate in management – for many your CIO – and being specific about what you’d do with an EA tool. To do that, you have to understand the available tools’ capabilities and think through how you might use them in your EA program. You will have to show specifics about how the tool will either save a significant amount of time and labor, or, better, enable analysis that would otherwise be impossible manually. That means you’ll have to research the tools, find case studies of how they’ve provided value, and determine which features and functions you would make best use of. Then write the story of what great things you would do if you had the right tool, and start pitching. No shortcuts here, I’m afraid.

And about that question about tools to promote architect collaboration – once you’ve created a short list of tools, see if there is a related feature available. If you can get some of that functionality in a package that you can roll out to your network of architects and SMEs, great. But there are probably collaboration tools already in your shop (that you may have helped to standardize) that you can look to  to foster collaboration. Internal blogs, Wikis and Sharepoint sites can be relatively simple things but provide the functionality you need to get architects talking to one another, even across a widely distributed organization. It doesn’t have to be fancy – all you really need is a place to post discussions (with appropriate tagging/search/archiving functionality) and a way to message your architect community in real time.

Good Order-taking Is Not Good Enough

I’m currently dealing with a client whose IT department is pretty good at being an order-taker. But the business folks are dissatisfied. An LOB exec told me “when we told IT we wanted [a particular solution] they should have probed for what the real issues were and then come up with a better solution than what we asked for. They should have pushed back.” I don’t know about you, but I find this remarkable.

For years IT has struggled to be the best possible order-taker. Back in 2006, Forrester defined three archetypes of IT: The Solid Utility, the Trusted  Supplier, and the Partner Player (see  the first figure). These archetypes are progressive: you can’t be a Trusted Supplier without also being

IT Archetypes

a Solid Utility, etc. It took a lot of work to be a solid utility by providing cost-effective dial-tone reliability with transparent, constantly declining costs. And then it took a lot of organizational maturity to attain Trusted Supplier status by nailing projects and consistently delivering on-time, on-budget, and to spec. So when we talk about being a Partner Player, being at the proverbial table and helping to move the business forward, it really sounds like IT management nirvana — we’re going beyond technical execution into the strategic realm.

Of course, EA programs can help at each phase (see the next figure). EA can help by defining

EA Enables IT Archetypes

and governing to the standards and technology strategy that make IT cost-effective to run and support, and by baking these standards into application patterns that take a significant amount of risk out of development projects. And by pursuing business architecture, EA can begin to have the strategic discussions that will lead to being perceived as a Partner Player.

But back to the IT department I mentioned at the beginning of this post. These folks are crying out for architect-led interactions at the brainstorming stage, but their organizational culture and their processes currently prevent the whole “dream with me” stage described by Eric Hendrickson in his comment to a previous post. Making those interactions happen and formalizing them into regular occurrences is the way to nail the alignment problem and move into strategic discussions. But for this organization it’s not a nice-to-have — it’s as big a black eye as failing to provide a sound infrastructure or always being late with projects.

If this is generalizable to the industry at large, then getting to be a Partner Player is no longer an aspiration that would be nice to achieve but a no-big-deal-if-we-don’t-nail-it-this-year sort of thing. Being a Partner Player is  just meeting expectations. It’s just what the business perceives as necessary to utilize technology in a way that will enable them to survive, compete, and excel. And my take on this client so far is that they are a relatively conservative organization, so if their business folks have this expectation of IT, many others do also.

That means the bar has been raised. IT organizations must evaluate themselves and see if they’re headed in this direction soon. If not, it’s time to change something: change your organizational design, change your processes, change your strategy, change whatever you need to change to make this happen. And since I’m an EA guy, I have to say my view is that the EA effort is where to place your bets.

Comments welcome and encouraged, of course. Take another 30 seconds and take this quick poll — how would you characterize your organization?

Babies, Bath Water, And Enterprise Architecture Maturity Models

Recently I took a look at an EA-maturity-model-cum-roadmap from Leo de Sousa, Manager of Business Application Services and Enterprise Architecture at the British Columbia Institute of Technology (click to read Leo’s blog on EA CMM). To my surprise, I liked it. Why was I surprised?

I have never liked EA maturity models. Yes, tracking progress is important. And yes, there should be a consensus about what characterizes a mature EA practice. But I don’t like how they would ostensibly be used to compare one enterprise with another, a la benchmarks. Perhaps I was soured on them by seeing them used as a governance technique in US federal agencies.

The Office of Management and Budget (OMB) required agencies to assess themselves against a standardized maturity model, with progressive hurdles in successive years. Federal agencies, accustomed as they are to all sorts of oversight and compliance mandates, know how to pass compliance audits. Did you ever wonder how (then) Popkin System Architect got so popular  in the federal government? An EA tool was required to demonstrate a certain level of EA maturity and System Architect was the lowest-cost offering at the time (I’m sure there are other reasons as well). Behavior was around letter-of-the-law compliance, and it seldom catalyzed getting with the spirit. Even when Dick Burk at OMB introduced a clever workaround in a second version of the model — you could leapfrog to a level 4 if you showed actual business benefits, regardless of what other checklist items you missed — agencies simply marched through the maturity level checklists getting the requisite items done. The scores were good, but in my opinion they overstated the degree to which EA was ingrained in the culture of the agencies.

And then there’s the notion of a single number representing an enterprise. In most reasonably large organizations, there is some degree of federation of the EA effort. Some business units might have very advanced practices, while others have virtually none, and the enterprise-wide practice may have an entirely different agenda. What does one do, rate all units and average the number? That would be a pretty meaningless metric.

Source: Leo de Sousa, Manager, Business Application Services and Enterprise Architecture, British Columbia Institute of Technology

So, I’m afraid because  of all this I threw the proverbial baby out with the bath water regarding EA maturity models. But I like Leo’s. He took some fairly standard criteria and modified them to fit his organizational goals and processes. They still resemble other CMMI-like level criteria, so his 3 would be similar to someone else’s 3, but that’s not the main point. The point is to create a roadmap for where he wants his EA practice to go, and then rate and report actual against plan. This approach is about creating a tailored roadmap to consciously mature your EA practice; it is not about scoring maturity of implemented architectures.

No big deal, you say? I tweeted about this and a couple of wise EA folks who usually respond to my tweets essentially said “of course, you have to make it your own, what else would you do?” making me wonder if I’ve been missing the boat all along.  But I don’t think this is a prevalent attitude about EA maturity models. I think the general idea is to rate one’s org against where it ought to be, by some industry-standard scale. I don’t find that worth much. I think an organization should understand where they are and where they want to be, figure out how to get there, and track their progress. If someone else’s model of how EA can improve your org helps you describe your goal or your path, great. But generic doesn’t work — for any generic goal statement, you must edit it into terms specific to your enterprise. And don’t set any goals without including the statement “as measured by ___.” You can use the Goal-Question-Metric technique for filling in the blank, but that’s a topic for another day.

To really manage your EA agenda, I’d recommend taking the maturity model as a roadmap a step further and also populate it with goals that don’t fit the standard CMMI scale language.  For example, if you have an incipient information architecture or business architecture practice, place goals and milestones related to expanding and formalizing those efforts on the roadmap. I’ve been interviewing people about their information architecture initiatives and working with Forrester analyst Jeff Scott on approaches to business architecture that can be broken down into a cookbook-like  sequence, so watch this space for more on phased approaches to these aspects of architecture initiatives.

How do you all measure EA progress in your shops? Do you use a maturity model? And/or have you created concrete custom goals with associated metrics and measure against them? Take the quick poll below and we’ll all get to see!

Will Business Architecture Initiatives Put A Permanent End To Business-IT Alignment Problems?

An early 2009 Forrester interview with the CIO of a retail firm produced a great quote: “Our business execs have two views of IT: a big budget blob or their BlackBerry.” Now, maybe those retail business execs think of IT as a strategic budget blob, but it’s more likely that’s a shop with alignment issues. If that CIO’s business execs don’t see technology as enabling anything more than mobile email, then they really don’t get the power of technology and they’re not going to see the value in the IT department.

But alignment issues are not limited to shops where business execs don’t see value in technology. The whole IT-to-BT transition is about how the business is enthusiastically embracing technology – they’re just not bothering to go through the IT department to find it, deploy it, or use it. Today’s alignment problem is more about the gap between the business’s valuation of technology’s potential and their valuation of the IT department’s ability to deliver on that potential.

Enterprise architecture (EA) has always had the capability to bridge that gap. Now, I certainly can’t claim that all or even most organizations that implemented an EA practice have solved all their alignment problems. But the simplest explanation of how an EA program is supposed to work would stand in for a perfect formula for aligning any enterprise: Map out the current and future states of your organization’s business, information, application, and infrastructure architectures, create the detailed roadmaps that spell out how to go from where you are to that desired future state and bingo! Business execs would know exactly what IT was up to and why they were doing it. They’d be cheering and carrying their IT and EA pals on their shoulders on the way to the next stockholders’ meeting.

What? Hasn’t happened to you yet? What could possibly be wrong? Perhaps it’s that most EA programs haven’t exactly executed the classic formula. Perhaps EA has focused almost entirely on technology and applications and the business has perceived EA – if it has indeed been perceptible at all to the business – as just another thing IT was doing that didn’t matter much to them. Maybe until very recently, for most organizations the business architecture piece has been missing in action (and let’s talk about information architecture another day). No business architecture, no relevance to the business community.

But all that is changing. Suddenly it seems business architecture is the hottest topic in EA circles. When I spoke to clients at Forrester’s IT Forum in May and our EA Forum back in February, business architecture was practically all anyone in the EA role was talking about, whether their EA practice was 10 years or 10 days old. A variety of forces have conspired to make technology-only architecture initiatives seem only marginally worth pursuing. These forces include a relentless drive for value – which implies an accompanying drive for transparency – and a continuing breakdown of the insularity of the IT organization.

But for whatever the reasons, business architecture programs are taking off, and I think that wherever they get traction they will finally put an end to business-IT alignment problems for good. Why? Because whatever the form of the business architecture program, business and IT will interact regularly and work together on addressing business problems and attaining business goals. Business execs will become invested in the connection between implementing the to-be business architecture and the rest of the enterprise architecture domains, at least in terms of the dependencies. And of course, IT will recognize the opportunity to communicate meaningfully with their business partners to ensure complete transparency and to relate all IT resource expenditures to business goals.

But wait a minute, back up – did he say “whatever the form of the business architecture program”? Isn’t there a cookbook of best practices that everyone can follow? The fact is that best practices are evolving, but at this point there are many approaches to business architecture initiatives. Jeff Scott and I have written a series of case studies on business-focused architecture to showcase the different approaches and provide a context for the value they are producing. We also presented a webinar on August 5 that discussed three of the case studies briefly and presented Forrester’s approach to starting business architecture initiatives. We touched on a number of issues, either through the planned agenda or the lively Q&A, including the role of business architecture in the context of the larger EA program and recommendations for the right business architecture artifacts. Regarding the latter point, I discussed a capability map from one of the case studies (see below) and Jeff talked about this type of representation as the “Rosetta stone” for business-IT alignment, which got some traction in the Twittersphere.

In the concurrent chat session embedded in the webinar, we covered a number of very interesting questions, but, given the circumstances, we really just touched on them lightly. Some of these issues clearly warrant further analysis and discussion, such as:

How would we reconcile the two opposing views presented in the case studies, where IT management was intimately involved with business architecture discussions in one case and locked out of the room in another in order to avoid biasing the discussion with current system constraints?

What are the best tools for creating business architecture artifacts? How important are the more elaborate EA tools?

How might capability maps work in organizations that have advanced ITIL/ITSM practices? Or that have successful APM/PPM efforts? Wouldn’t this form of business architecture artifact work well in analyzing IT as a business?

I invite anyone who attended the session or accesses the archived version to post comments here on the above questions – or any related issues for that matter. There are plenty of best practices to be surfaced as this area is still evolving.

There is actually a lot you can accomplish with business architecture, from finding efficiencies to launching new business capabilities to transforming the business. Important as it is, attaining business/IT alignment, the subject of the webinar and this blog post, can seem like just a beneficial side effect when you consider the high-impact possibilities.