Archive

Posts Tagged ‘alignment’

Good Order-taking Is Not Good Enough

October 19, 2009 Leave a comment

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

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

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?

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

August 21, 2009 3 comments

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.

DHL Capability Map

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.