If you're like most people I know, you've never heard of ISACA, the recall-resistent initials of the Information Systems Audit and Control Association. And, if you're like many (perhaps most) Linux Journal readers, chances are ISACA is older than you are.
ISACA was born in 1969 as the EDP (electronic data processing, for you whippersnappers) Auditors Association. In 1976 it formed an education foundation "to undertake large-scale research efforts to expand the knowledge and value of the IT governance and control field". Two more decades would pass before Information Services, better known as Management Information Services (MIS), were re-brand IT. That happened when the publishing giant IDG decided a common two-letter pronoun was a better initialism than a common two-letter verb.
ISACA is nothing if not conservative, however; so its name persists, even though it has forked to include the IT Governance Institute (ITGI), which was formed in 1998 and serves to help Boards of Directors "extend governance to IT and provide the leadership, organizational structures and processes that ensure that the enterprise's IT sustains and extends the enterprise's strategies and objectives". The italics are theirs.
If you're not familiar with ISACA or ITGI, perhaps you've heard of COBIT, or Control Objectives for Information and Related Technologies (even though that's not what it spells). Says the ITGI,
COBIT, issued by the IT Governance Institute and now in its third edition, is increasingly internationally accepted as good practice for control over information, IT and related risks. Its guidance enables an enterprise to implement effective governance over the IT that is pervasive and intrinsic throughout the enterprise. In particular, COBIT's Management Guidelines component contains a framework responding to management's need for control and measurability of IT by providing tools to assess and measure the enterprise’s IT capability for the 34 COBIT IT processes.
COBIT and the concerns it addresses had their profiles raised overnight with the passage in 2002 of the Sarbanes-Oxley Act, which raised corporate accountability to unprecedented heights and spawned a whole new industrial category (along with vast new bureaucracies) devoted to compliance with the act's many requirements and provisions.
On 27-30 June, 2004, ISACA held its 32nd Annual Conference and Annual General Meeting of the Membership at the Hyatt Cambridge in Boston. Among the educational sessions were —
And, for Session 222 on Day 2, "The Realities of Open Source". That was the session I gave. It was, one attendee told me, the first time ISACA addressed open source as an issue.
The room, which held about eighty people, was a little more than half-full. The following session, "Wireless Hacking Exposed," was SRO. So much for open source box office.
Before and after I gave my talk, I sat in on a variety of other sessions. In every case I carried the only laptop in the room, other than the ones used by speakers to give PowerPoint presentations. When I pulled it out to take notes, or to work on my own talk, others looked at me like I was carrying a loaded weapon. Was I about to commit an act of wireless hacking, perhaps?
That would have been cool, of course, but not with this crowd. While open source is a grass roots phenomenon, growing into organizations from the bottom up, these guys were about as top-down as they come.
For me, it was a fun challenge. I had given talks to newbies before, but never to newbies that also happened to work in IT Governance. I felt like I was explaining free enterprise to the Politbureau in the old USSR. Or communism to the Cato Institute. The cultural distance verged on the absolute.
I opened with the two questions I already knew were on everybody's mind:
I answered by saying "We're not in Kansas any more" and proceeded to explain how many of the civilized graces we take for granted, from email and Web servers to Amazon and eBay, owed credit to open source developers, values and effects — all of which were as wild and uncontrollable as the next storm or earthquake.
That said, I went on to explain that open source was also about resourceful individuals and groups doing what needs to be done, that open source is an example of what happens when the demand side supplies itself, and that it can be understood as the DIY sector of the Information Systems construction and maintenance business.
I also said none of this was especially visible when you're busy looking down at it from the parapets of Fort Business, and demanding that it comply with approved strategies and tactics.
I showed the sizes of various open source conversations on the Web, which equaled or even exceeded those concerning Microsoft and other familiar names. I showed how much Linux and open source code was probably already running in attendees' companies, whether they knew it or not.
And I talked about common interests. For example, in the use value (rather than the sale value) of software. Also in low cost, availability, quality, integrity, efficiency, effectiveness, continuity, robust infrastructure, leveraged physical assets, problem solving and other virtues copied from the slides of other speakers.
In the Q&A we talked about SCO FUD and other predictable issues. One attendee demanded an explanation for why "they" (meaning open source advocates) had "such terrible manners". Later on a boat tour of Boston Harbor, she came up to me, waved a cigarette in my face, and insisted that open source people "have a good case, but they simply must change their behavior". But she couldn't give me an example of what she meant.
After my talk, several attendees told me they were, in fact, open source users and advocates inside their organizations, and that the prognosis for open source there, while good, was very long-term. The main thing at issue was "auditability". One attendee told me that open source stuff is, indeed, auditable; but that nobody was making that fact plain. Another said there was an enormous amount of work to do.
In my July 9 SuitWatch newsletter, I wrote about the cultural divide I witnessed at the conference, and its near-absolute contrast from Supernova, the conference where I spoke just a couple days before ISACA. The theme for Supernova was decentralization. If anything, ISACA's theme was the polar opposite.
Immediately an email came from Glen Campbell, a veteran of both cultures. Here it is, in its entirety:
I have always been acutely aware of the gap between the IT/IS industry and what I call the "high-tech" world, having straddled the edges of both of them for about 20 years now. What you encountered at the ISACA conference is a classic instance of this. One thing that open source advocates so often miss out (and I'm in the open-source community: see http://siteframe.org) is that the largest driving factor in most Fortune 2000 IT shops is risk mitigation.
An example: a year or so ago I worked as a contractor at a large bank in San Francisco. They have a thousand or more Sun servers doing their web serving: they are running essentially nothing except Apache. I mentioned to one of their IT directors that they could save tons of money by using whitebox servers running Linux and the same Apache code. His response? "Yeah, but then there wouldn't be anyone we could sue." He was deadly serious: the ability to pass along some of the risk is far more important than cost or implementation ease. In the open-source world, name one company that's large enough to assume some of the risk for a Fortune2000 firm: maybe IBM on some of their Linux implementations, but that's about it. And IBM doesn't create (or warrant) open-source software, they merely distribute it.
Likewise, the whole concept of DIY-IT is a complete anachronism to most IT shops. They did DIY-IT in the 60's, 70's, and 80's, and discovered that, no only is it less expensive to outsource their internal systems (to SAP, or Siebel, or EDS, or IBM), it also - tada! - reduces their risk in that there's another large corporation out there that they can sue if something goes wrong.
Name one open-source software provider that will sign a service level agreement that guarantees a specific amount of uptime (say, 99.998%) per year? Who's willing to pay real money when they can't achieve it? The open-source model fails on a business level like that. To be able to assume those levels of risk, there has to be some serious income on the front end. That's why Sun can change 10-50x for a server that runs Apache (which, by the way, is one of the very few open-soure packages that large companies have come to trust).
I have a number of friends here in Silicon Valley who are on the "high-tech" side of the world. They simply cannot understand why, when you encounter an IT problem, a company doesn't gray Perl or Python and write a script that solves it. The IT guys, on the other hand, look at this with horror; how in the world could this hold up to a Sarbanes-Oxley investigation, which requires the CEO to personally sign off on the sources and validity of the corporate data? How in the world is the CEO going to understand a Perl script? The CEO will happily pay a 100 grand to avoid going to jail because of this.
That said, there are a growing number of CIOs and CTOs who preside over organizations that welcome and nourish open source. Perhaps the best example is J.P. Rangaswami, Global CIO and Managing Director for Dresdner Kleinwort Wasserstein, a large international investment banking firm with more than six thousand employees. J.P. says he "went open" at DrKW in 1999, and considers the company's open source strategy a competitive advantage. Several years ago, DrKW made a bold move for a customer organization by open sourcing OpenAdaptor, a Java/XML platform for rapid business system integration. The move was strategic in a variety of ways, not the least of which was employee retention. "We attracted and retained talent", J.P. says. Not coincidentally, J.P. sat on a panel at Supernova, and was named Top CIO of the Year last December by Risk Waters Group.
So there are ways of bridging the cultural gap. But we also need to acknowledge that gap, and the challenges it presents. Because it's not going away any time soon.
Doc Searls is Senior Editor of Linux Journal. Linux for Suits is his monthly column here. He also writes SuitWatch, a bi-weekly Linux Journal newsletter. And he presides over Doc Searls' IT Garage, a sister site to Linux Journal on the Web.