- by Paul Murphy -
Just recently the Canadian Federal Government had to significantly revise their November, 2004, monthly trade figures. Here's how Toronto's national newspaper, the Globe and Mail described the problem:
Underscoring the volatility of monthly trade data, Statscan last week issued a startling $1.9-billion downward revision to November's trade surplus, citing a computer glitch at the Canada Border Services Agency that caused a massive understatement of imports....
Despite monthly figures being subject to noise, currency traders pay close attention to the data. When the November figures were first reported, they helped lift the Canadian dollar more than a cent against the U.S. greenback.
Apparently controls were a little weak -but, of course, Sarbanes-Oxley doesn't apply to the Canadian government, and computers are notoriously unreliable; I mean, what can you do. Right?
If you work in IT, there are actually quite a few things you can do, but the one I want to talk about today is both obvious and radical: think of your organization's information and communications technologies, skills, and ownership as a portfolio, and reduce overall risks by intentionally diversifying all three.
The general strategy of choosing one systems architecture and sticking with it everywhere was popularized in the late seventies and early eighties mainly by consultants working for professional data processing groups in big organizations. Their core arguments were that wrestling control of mini-computer based applications like job shop scheduling, document processing, or inventory control from user management in order to give it to data processing would reduce overall duplication, reduce the cost of maintaining diverse skills, allow greater utilization of the central computing resource, and lead to enhanced user services.
It didn't generally work out that way, with user resentment against the costs, failures, and administrative demands of centralized data processing eventually leading many of them to leverage data processing's corporate loyalties to IBM to bring in thousands of IBM PCs -while using their own budgets to buy software and support for them from anybody except IBM.
Centralization didn't fail because the basic arguments were wrong, it failed because the only thing data processing has in common with computing support is the use of computers. As a result virtually every ERP centralization project failed to meet its cost/benefit targets but the idea that IT management should control and standardize the corporate information architecture became so deeply entrenched in the common wisdom of the profession that it still shows up in everything from Microsoft licensing practices to In Flight magazines.
Unfortunately today's monotheistic Microsoft architectures seem to be about as effective as those earlier consolidation projects - and cost control technigues like the use of desktop lockdowns, out-sourced help desks, and server based processing are replicating the conditions that led to the organizational failures and user rebellions of the eighties and early ninties
Thus the Canadian national accounts embarrasment looks like a classic controls failure, but the control that failed wasn't one of the usual suspects. It wasn't that no one knew; it was that the people who knew the update had failed saw that as an IT problem, not as their problem.
That's the fundamental control failure risked by most of the IT cost management methods generally considered best practices in the Microsoft client-server world. Fundamentally, if users don't own it, most won't take action when it fails and a few will quietly rejoice in the embarrasment caused IT when the fans and the brown stuff collide.
So what's the long term answer? Take the advice implicit in the bromide about those who fail to remember history being doomed to repeat it. Change direction now, while you still have the clout to do it. Remember: things change; the ideas and certainties that got you where you are, also guarantee you a role as tomorrow's fossil unless you change too.
If you're deeply committed to the Microsoft client-server architecture and its organizational consequences, the best thing you can do for your organization right now is to start rolling back the concentration of control and technologies underlying user alienation.
In reality the hardware used to deliver services isn't terribly revelant to control issues but most people think it is. As a result your choices, in terms of the hardware component in a decentralization strategy, are either to make the hardware disappear from view or hand control of it, along with software and staffing, to users.
I'll do a later column on using Solaris and Sunrays to give users more freedom and control while disappearing the infrastructure, but it's the control consequences of sticking with the more traditional client-server architecture that's on the agenda today.
Diversifying the control component, and therefore the hardware, software, and staffing components, of your IT portfolio will be popular with divisional management but can be a particularly tough sell both within IT and to a senior executive habituated to discounting claims of cost cutting through centralization and standardization. To win, what you need to do is build an action plan around opportunities to bring divergent technologies and opinion in under user control and then sell that to senior management under the Sarbanes-Oxley label.
The core argument is as simple and disarming as the simplification and centralization argument was in the late seventies and early eighties. Leverage what people understand: the role diversification plays in portfolio risk management, to build support among each stakeholder group. Thus you get some of your own colleagues in IT on board by giving them a more business focussed role and reminding them of the increased employability that goes with a wider skill set. You talk to senior management about getting line managers to "own their productivity" and talk to everyone about the value of technology diversification in reducing processing continuity, cost escalation, and failure risks.
Get down to specifics on that and the argument is dead simple: get half your file and print servers on Linux, and the next Microsoft worm won't shut down processing. Get half your power Office users on Macintosh, and you won't be timing the next round of upgrades to avoid risks during the quarterly report preparation period. Get some serious open source applications running in a line division or two and the organization will build the knowledge and confidence to shrug off the next mega-merger or collapse in the software industry.
Most importantly, however, you talk to senior and divisional management about the relationship between ownership and commitment. Remind them that people care most about the things the perceive as theirs. People who own the system will force a correction when a critical file transfer fails, or a stored procedure bug causes the monthly report to go increasingly off-track -and making sure that user commitment's in place is the most fundamental Sarbanes-Oxley control of all.