McKinsey ask: How strategic is our technology agenda?

McKinsey Quarterly poses this question in the latest issue with some case study information. The fundamental issue is an old one: the IT budget being spent on maintenance, with smart investment being what gets squeezed out. But the illustrations suggest ways to move forward. It’s not the old “Align IT with the business” mantra, which still starts from the assumption that IT somehow is outside and separate from “the business” and that the disconnect is IT’s problem.

This article admittedly starts by profiling a dysfunctional CIO who doesn’t understand the issue. But it looks at the issue from the whole business perspective – that is, the CEO’s. It shows how investment can be viewed, even when it’s core infrastructure that’s at issue; it talks about benchmarking capabilities against non-competitive industries, not just competitors; and highlights some of the perceived wisdom which can, sometimes, be plain wrong and a distraction from the real challenges.

How strategic is our technology agenda? McKinsey Quarterly, Oct 2011

Business with your partners: IT strategy

A colleague in LinkedIn posted a question about how you determine your business partners’ business requirements, so that you can determine technology strategy. It’s only been out there a couple of hours, and it’s got a string of answers already. I’d like to spawn a more general thread.

Almost all the answers assume, I think, that “business partner” means “someone you want to sell to”. But there are many other kinds of business partners. In pharmaceuticals, where I worked for a decade or so, partners might be a research organisation you’re working with, a peer enterprise with a co-marketing agreement, your regulator, your upstream partners (important, because the regulator can demand to see information they supply about the compound they’ve sold you), a service provider, an information source … and no doubt some I’ve missed. And a partner may turn up in more than one role: maybe IBM provides technology to American Express, and American Express provides outsourced travel services to IBM (it’s a hypothetical example: I don’t know).

So: there are some fundamentals.

First: you can’t determine your technology strategy according to what your partners are doing, because there are so many of them. Think the ongoing Lotus Notes versus Microsoft Exchange debate for a very pertinent example. Nor can you dictate strategy to them – they have exactly the same variety, unless they are so small and so closely tied to you that they can be seen as part of your organisation.

Second: therefore, individual business strategies with particular partners in particular roles can’t be allowed to determine your overall technology strategy. Even if you decide to have one of whatever your partners use, that’s a strategy; and it has a very specific consequence, which is that your own technology base must be capable of doing the integrating, in-house, to present a single picture (to your executive management, at the very least). More likely there will be specific partners who have the power to dictate how you inter-operate with them: Walmart, say, and your regulator; some who you can dictate to, if you so wish; and others with whom you must inter-operate using a variety of specific technologies with neither partner dictating. Heterogeneity is the rule; and true business partnering is about respecting each other’s decisions and strategies, not dominating them.

Third, and inescapably, therefore: strategies based on product decisions are doomed to failure. Bar none. Not even Microsoft Office; I would lay odds you have several versions active in your enterprise environment right now, and your partners will add several more. Every changeover means conversion filters, or constraining users to the previous version’s formats. And the latest release of Office changes everything more fundamentally than most, with its XML-based formats.

So you need your business partners’ business objectives, and a definition of the business requirements which you and your partners share. But it’s perilous to define an IT strategy on the basis of current requirements with the current set of partners. Take a step back, and use these to create a higher-level business and technology strategy for your own organisation. It must be stable enough and at a high enough level of abstraction to survive partnership changes, new regulations, mergers, acquisitions and divestments.

And this makes a very strong case for open standards as the basis for architecture (which is IT strategy anyway: see Jeanne Ross of MIT Sloan School on the subject): at least at the interface where your systems meet your partners’, directly or (via the Internet, for example) indirectly. “Open” in this case is probably fairly close to the Microsoft definition. Not necessarily publicly created, or even in the public domain: this may help, but it can slow development down. But published, open to licence, easily accessible, widely implemented, and evolving in a backward-compatible way.

So: know your business partners; figure out how to work with them; but remember you’re also figuring out how to work with the business partners you don’t know you’re going to have. It’s what you don’t know that you don’t know, that kills you!

Links:
• Jeanne Ross MIT Sloan online profile
You may be able to see:
• Enterprise Architecture as Strategy Video View, Jeanne Ross, Forrester Forum, 15 May 2007
• Enterprise Architecture as Strategy Presentation, Jeanne Ross, Forrester Forum, PDF file, 15 May 2007
(these are Forrester Research excerpts from the 2007 Architecture Forum, and may be available to clients only)