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

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.

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