The Meta Dilemma

After more than a half year of blog entries perhaps it’s time to take stock, see what we might have learned.  Partly this is because we have covered more than two dozen subjects, partly because we will be taking a summer break.  There will be no more entries for a while.

The topics have been diverse, from cloud computing and risk management to mobile computing, embedded systems, and new Web-based applications.  From long term storage and big data to inter-enterprise IT and PR for IT organizations.  Each one has posed some sort of dilemma for CIOs.

But there must be a bigger pattern here, some overriding dilemma for CIOs.  Some choice that will determine for a long time to come the success of IT within their organizations and the success of their careers.

I think I see it.  Each of the blog entries discusses a new technology, practice, or usage trend.  Sometimes we draw on some of CRITOs cutting edge academic research.  But most of the challenges posed by the dilemmas we discussed seem ageless.  Strategizing on ways to influence business units, cajoling end user departments into sharing resources, finding “organizational will” to get done what needs to be done.

I think the CIO’s “meta” dilemma is embodied in the tension between the need to master technology – fast moving, ever-changing – and the need to master the persuasion of others, which is as old fashioned as a Dale Carnegie “How to Win Friends and Influence People” class (http://en.wikipedia.org/wiki/How_to_Win_Friends_and_Influence_People).

The problem is, the technology is incredibly alluring.  I have been saying for five years now – even during the economic depths of 2008 and 2009 – that we are in the middle of a great technology renaissance.   Only the third one since mainframes entered businesses en masse in the 1960s.  Each era has had a boom-bust cycle that starts with about five years of technology introduction and “irrational exuberance,” followed by a sharp high tech stock market collapse, and followed by a long, steady period of growth.  The second era, that of the PC, ended when the Worldwide Web came on the scene in the mid 1990s.  We are living now in that Internet era growth period 12 years after the bust.

So, success will require new technology, and CIOs will be responsible for helping their organizations make the most out of it.  In fact, there has never been a better time for using technology to competitive advantage.  But as in the past eras, the CIO’s responsibility for the success of new technology deployments may put him or her in a position counter to the business.  It can mean putting on the brakes, bringing order to chaos.  The organization doesn’t always know what’s best for it.

Mastering the new technology is a necessary-but-not-sufficient condition for success.  Winning friends and influencing people will be even more important going forward as the consumerization of IT continues.  You need to mirror the whole organization in your own approach.  Salesperson some of the time, marketing expert some of the time, finance wizard some of the time, and operations some of the time.  It’s a multifaceted role unique to IT.

Over the years I’ve had the honor of judging a number of “CIO of the Year” awards, in China, Europe, and the U.S.  The successful CIOs I’ve come in contact with all seem to have not only knowledge of the most up-to-date technology, but also a deep understanding of how their own organizations work.  They enlist allies in the business units and keep the CEO in the loop, and they think of themselves as business people first, technologists second.  They are personable, impressive, engaged and engaging.

Some of these CIOs seem like they come by these traits innately.  But others have to work at it, which gives us all hope.  We don’t have to be salesperson of the year to influence others.  We can each make our case our own way.

There is a final condition to being a successful CIO and that is attention to the team.  An IT department must have the same multifaceted personalities working within it as the CIO has within him or her.  The CIO is CEO of this department.  You need to deal with a mix of egos, talents, and operating styles.  You need to help them deal with adversity – end user departments blaming IT for their own mistakes, vendor shortcomings, external business conditions – and win their own friends and influence their own people.

I know this advice is platitudinous.  But while the success of so much in the enterprise depends on IT, the success if IT depends even more on the rest of the enterprise.  It’s your job to help the enterprise fulfill its role in your success.

Signing off, your colleague, John

From Ten Years Out: Aftermath of the Apps Plague

We should have seen it coming, back in the early 2010s, don’t you think?  The signs were there.  Consumers downloading dozens, then scores, then hundreds of apps for their smart phones, and, in some cases, writing their own.  Then more apps for their tablets.  By 2015, apps for their laptops, in-car systems, home music systems, and home automation.

Then, bringing them all to work.  Sales forces with tablet computers of all make, manner, and operating system (once the Apple iPad was overtaken by open source tablets); marketing departments developing their own Web 2.0 apps for customer smart phones; even security professionals downloading patches, updates, and specialized security software by the chunk.  Hundreds, then thousands of vendors, millions of discrete apps.

There was no way to keep track, of course.  IT departments tried device crawlers for a while to understand what apps were actually running in the enterprises, but the data bases were hopelessly out of date.  App suites sold by the big vendors were easily infiltrated by apps plugged in from other vendors.  It was a mess.

But if we did see it coming, we turned a blind eye, didn’t we?  We were getting so many quick, easy hits with these short little specialized programs, that it felt good.  No more six months to develop even a modest IT application.  Just find and deploy an app.  The business units loved it!  After all, what did they care about software maintenance a few years down the road? It would be someone else, not they, who would have to deal with consequences seen and unforeseen.

In retrospect, this reminds me of the early days of Powersoft’s PowerBuilder, which brought enterprise application into the mainstream of point-and-click development even before Visual Basic.  I remember sitting in a focus group of CIOs in the mid 1980s talking about their use of PowerBuilder (see history at http://pbdj.sys-con.com/node/124571) and learning about the dark side of this new way to develop programs.  Lack of documentation, half-baked testing, integration issues kicked down the road, and bad and potentially unsecure code papered over with a nice GUI.

What was ironic was how all these apps simply swarmed over the “cloud.”  Remember that once hot buzz word?  Look how fast it joined other lost phrases like distributed data processing (DDP), web services, and application service providers (ASPs).

Just as departmental minicomputers destroyed the timesharing industry in the early 1980s, apps continually moved functionality to the end device and obviated the cloud as a processing source.  As we used to say in the 1990s, “on-prem” always wins.  Centralized solutions always lose out to software in the hands of users.   Sure, you could store information in the cloud, and you could get your app from the cloud, but the app was your software to use.  The cloud became merely the Walmart of apps.

In fact, the cloud made the problem worse.  Apps could be updated by their vendors too easily, sometimes as often as twice a day.  Talk about version control.  This worked OK in the consumer world, but wreaked havoc when enterprise departments started developing their own.  No sooner would the IT department integrate a sales department app with a finance department app than the sales department would make it obsolete with another update.  There was no master plan for development, no common architectural standards, and, over time, no love lost between IT and the user departments.

So here we are, in the 2020s, in the throes of the app plague – looking back with 2020 hindsight (pun intended) and hoping to learn enough to get ourselves out of this mess.  App certification and standards boards are a start, but they only work with publicly sold apps.  Some companies are instituting their own certification and app standards boards, but the industry-specific boards that purport to link enterprise app standards together have bogged down in politics.  Most IT departments are hunkered down just walling off their main mission-critical server-based applications from all but carefully developed client apps, and letting the rest of the organization deal with the cacophony outside those walls.

It looks to me like that’s the way we’ll have to go.  Secure the enterprise’s main applications, and then carefully allow immigration of approved and certified apps into the pool of those we integrate with the major systems.  But if we tighten down too much we negate the investment and utility of all those other apps. What a waste!

I have looked and I have yet to find an app to deal with this particular CIO dilemma.

The Dilemma:   The author envisions a future a decade out in which the apps so freely downloaded to today’s tablets and smart phones become a plague when developed willy-nilly within the enterprise.  The dilemma is the integration of certain apps – but not others – with enterprise systems without creating such strict barriers to integration that the investment and utility of all other apps is wasted.

What Might Work:  Jump early on the need to inventory and vet apps used on devices in the enterprise, or that integrate with enterprise apps.  By all means pick favorites.  And pick the brains of other CIOs going through the same thing.

The Architecture Dilemma

What are we going to do?  We have been working on enterprise architecture standards for years, honing the concept of a single overall approach to enterprise systems development, application interfaces, process management, and infrastructure deployment.  And all our vendors are locked into hardware and software architectures they have been developing for years, often enshrining within them architectures from long-gone, decades-old products.

You see, it will all have to change.  If not as soon as the end of the Mayan calendar on December 21, 2012 (notwithstanding reports of bad math in the calculations) – pretty soon after that.

Here’s why.  Most current computer system architectures and data center architectures are built on the client-server model (after a painstaking migration from the mainframe-terminal model), which basically calls for an asymmetrical flow of information in file and record formats from servers to the clients.  Not much different from the batch processing of yore.

But that traffic flow – from the center of the network to the edge – is changing fast.

I know, I’ve done the calculations.  Nearly 10 years ago I began using IDC forecasts of networked devices and estimates of the bandwidth they would consume and multiplying the figures out.  I wanted to forecast future bandwidth demand.  I also came up with percentage estimates of how much transmitted content was delivered in file-and-record format and how much was what communications types call “bursty,” meaning it came in unpredictable sizes at unpredictable times.

What I found was disturbing.  Back then, about 85% of the bandwidth was delivered to client devices in standard file-and-record format.  But the emerging of smart phones and embedded systems is changing that.  Within five years that polarity will have reversed, with 75% of the traffic flowing either around the edge of the network or from the network edge to the center.  Most of it will be bursty.

(As a fact check you can refer to the study of Internet traffic conducted in 2004 and update in 2005 by CacheLogic, Ltd, which found that 62% of Internet traffic came from peer-to-peer communications, including a lot of Bit Torrent traffic (http://torrentfreak.com/bittorrent-the-one-third-of-all-internet-traffic-myth/.)

Here’s what this means.  Internal system communications based on file and record calls will have to change, or be hopelessly inefficient.  Embedded systems will drive not only more edge-to-center traffic, but more real-time, bursty traffic.  So will social networking.  Normal IT will either be interrupted a lot more, or separate systems and architectures will have to be maintained.  Mushrooming virtualization software will struggle with new traffic and data types.  Traffic queuing and capacity management algorithms will be stretched beyond design goals.  And so on.  This will all happen even as the amount of information on networks grows at better than 50% a year (see my blog entry of April 18 on unstructured data (http://ciodilemma.wordpress.com/2011/04/18/what-lurks-in-your-unstructured-data/). Not quite a Mayan end-of-days, but certainly challenges for vendors and CIOs.

We can already see manifestations of this architecture change.  Consider Apache’s Hadoop, a software framework designed to deal with massive amounts of distributed data.  It’s used by organizations as diverse as Amazon, Yahoo, and Booz Allen Hamilton.

But don’t you already have software that does some of this? Data warehouse software?  Home grown systems?  If you are leading edge you may find a way to tie your existing data warehouses into new Hadoop systems culling data from social network feeds or other large unstructured data pools.  Or maybe not.  At the moment there aren’t a lot of data integration tools available to connected existing systems with Hadoop.

And after Hadoop, what?  Data warehouse and Zigbee interconnections to tie your normal analytics into real time automation feeds?  Intercompany connections?

So, in answer to the question posed at the beginning of this entry, as time goes on and more and more products will evolve to handle the changing data and traffic environment – and we will be stuck with the task of integrating them with of legacy systems, like transaction data bases, customer support data bases, and so on.  All this using computers still built around the 8-bit byte.

This is a long term dilemma.  I picture today’s legacy systems being increasingly surrounded by new, differently-architected systems in a cluster of home grown confusing interfaces, connectors, and bridges.  Eventually the whole shebang will have to be re-architected with career-threatening consequences.  The question is, whose career?  Yours or the next CIO?

The Dilemma:   Rapidly changing data flows and character will stress conventional IT and product architectures, creating demand for new ones.  But these will require integration with the old, and IT departments will have to guide their organizations through this thicket.

What Might Work:  By all means deploy your Hadoop and other systems, but pay attention in the design phase to integration with existing systems.  Carefully test integration products from new vendors, and send some programmers to school.

Virtual Systems, Physical Headaches

We are in the age of virtualization.  Last year more virtual servers shipped than real servers for the first time.  By the end of the year there will be 50 million servers in use in the world, 18 million of them made of software only.

Yeah, more resources, right?

Maybe, maybe not.  This is not the first age of virtualization.  We had one before.  This was the age of virtual mainframes, heralded by the introduction of the Burroughs 1700 more than 35 years ago and followed up by IBM with its VM 370.  And who can forget Nanodata – or rather, who can remember it? – the start-up from Buffalo, New York, that spent a decade designing a machine that could emulate multiple mainframes?  It could be an IBM 370 one minute, a Sperry Univac 1110 the next.

Virtualization has been around since the dawn of computer industry time.  It’s all about using software to share hardware resources and to emulate other software.  So today we have virtual software that emulates itself in multiple copies on the same physical device.

But the problems of ancient virtual machines have descendants in today’s versions.

Remember thrashing?  That was when a CPU spent so much time bringing data into and out of main memory from disk storage that it never got around to processing that data.   This was what killed Ovation, a start-up that was the darling of the venture capital community in 1984 that planned to launch an integrated word processing, spreadsheet, graphics, and data base application for $795.  It could never solve the thrashing problem and sank from view.  Nanodata’s problem was that its emulations weren’t line-by-code-line perfect, making them more or less useless (that and the lack of customers willing to visit Buffalo in the winter).

These problems could be classified as “technical complexities of resource sharing,” where the sharing inhibits performance of the resource.

Won’t that happen today?  Aren’t you going to have to have software to manage the software that manages the hardware?  Maybe a few layers of it?  And isn’t the management software from one vendor likely to be incompatible with software from another vendor?  Google “problems with virtual machines” and you get all sorts of blog entries about issues that crop up, from individual virtual PCs that get kicked off network domains and machines that have issues restarting after automatic shutdowns to trouble shooting hypervisor glitches.

So there will be “technical complexities of resource sharing” for today’s IT departments as we race to the 100 million virtual server mark (2016).   Good luck finding the right management software, skilled employees, and budget to deal with all these ethereal bits of software.

But I think you will need even more luck dealing with the “NON-technical complexities of resource sharing.”   I talked about this back in my blog entry of January 25, The Perils of Private Clouds (http://ciodilemma.wordpress.com/2011/01/24/the-perils-of-private-clouds/).  Not everyone in the organization will want to share resources.

For instance, about five years ago IDC researched large enterprise resource planning (ERP) implementations for success factors.  The researchers found that the implementations that failed generally did so because of interdepartmental issues, like sharing customer lists, coming up with common data base formats, and allocating budget and management responsibility.  Silos are silos for a reason.

The care and feeding of virtual systems will be radically different from the care and feeding of physical systems.  Board and module swaps will give way to software patches, reinstalls, and even more staff specialization.  Your dilemma is this: even as you scramble to keep up with this rapid migration to visualization – this decade’s version – you will still face age-old organizational issues.   You will need a split personality – (software) rocket scientist on the one hand and mother hen on the other – to be successful.

The Dilemma:   As virtualization drives more software into the IT infrastructure, it will change the nature of IT system deployment and support, creating challenges in staffing, procurement, and budgeting.  At the same time it exacerbates organizational squabbles over resource sharing.

What Might Work:  You are probably doing this already, but develop a strategy for dealing with departments that want to opt out of virtualization projects, which means enlisting the help of senior management.  And increase your staff training and recruitment budget.

Infectious Supply Chains

Remember the song “Dem Bones”?  Of course not, at least if you are under 50 or not from the U.S.  It’s an old spiritual that is basically an anatomy lesson: “toe bone connected to your foot bone, foot bone connected to your ankle bone ….” and so on up to the head bone (http://en.wikipedia.org/wiki/Dem_Bones).  And while it may not be strictly anatomically correct, to me it makes a cautionary point about modern supply chains and multi-enterprise IT in an era of ever more real-time, build-to-order manufacturing.  Or patient care, electricity delivery, retailing, etc.  And in an era when it’s getting easier for user departments to set up their own multi-enterprise IT.

Supply chain hiccoughs are pretty well understood – a fire destroys a warehouse in South Korea and laptop production slows because of a battery shortage (http://www.zdnet.com/news/dell-hp-confronting-laptop-battery-shortage/194260); an earthquake severs fiber optic cables off Taiwan and the “supply” of Internet services to Asia is diminished for months (http://www.wired.com/threatlevel/2008/01/fiber-optic-cab/); a tsunami hits Japan and GM has to halt production in two US plants and lay off workers (http://www.autoblog.com/2011/03/22/report-another-gm-plant-halted-by-parts-shortage-workers-layed/). Hey, the great London Dock Strike of 1889 illustrated what happens when a supply chain is disrupted.  Goods rot in transit and the economy suffers (http://www.portcities.org.uk/london/server/show/ConNarrative.77/chapterId/1868/The-Great-Dock-Strike-of-1889.html).

But what about the IT systems that knit these supply and value chains together?  The electronic tendrils that go from one organization to another, often treating employees of one company as if they were employees of another?

Our CRITO colleagues have studied these interorganizational systems in context.  In The Impact of Internal and Interorganizational Information Systems, published last year in the Journal of Information Systems (http://pcic.merage.uci.edu/papers/2010/ImpactsofInternal.pdf), Jason Dedrick of Syracuse University and  Kenneth L. Kraemer of UC Irvine compare the economic impact of internal systems (which can make an organization more efficient) with interorganizational systems (which can make outsourcing more efficient).

In general they found that more intense use of internal IT did not have an impact on the level of manufacturing outsourcing, but the level of supplier use of interorganizational systems did.  And the two types of systems competed with one another (more of one meant less of the other).

Here’s the rub.  With more and more firms using all aspects of IT to interconnect – Internet, EDI, custom Intranets, email, and social networking – the impact of multi-enterprise systems on internal IT will increase.  Didn’t I mention in a previous blog entry that the number of enterprise to customer interactions will grow fourfold in three years?   (See It and the Brand http://ciodilemma.wordpress.com/2011/06/06/it-and-the-brand-the-good-the-bad-and-the-ugly/).  And did you know that enterprise volume purchasing in the world surpassed $8 trillion in the last 12 months and is growing at 25% a year?

So, more and more of our IT systems will be interfacing with those of other enterprises and with more and more of their employees.  And these may include IT systems we barely think of as such – wikis, online communities, private social networks, etc., both internally and externally hosted.

I wouldn’t go so far as to call this a disaster in the making, but I do see it as a challenge.

We know about the security issues – these have been worries for years.  In general, the security of a multi-enterprise network will be only as good as that of the weakest enterprise.  A LoveBug-like virus running through one company’s internal system can infect a business partner’s in minutes.  But there are other worries, as well.  Response time slowdowns at one company in the value chain affect customer response times and satisfaction in another – e.g., a denial of service attack at an ISP or an outage at a cloud provider.  Not to mention glitches in outsourcer systems (think customer support automated response systems that drop or misroute calls) that affect your customers directly.

The CIO’s dilemma is this: these multi-enterprise systems are a fact of life, and, working well, can be a competitive advantage.   But that means that IT problems, crashes, outages, and vulnerabilities are multi-enterprise as well.  CIO’s have some ability to influence decisions and strategies in partner companies, but not that much.  There is only so much in the way of inoculation against problems created by others in the chain.

But let me pull one gem from the Dedrick/Kraemer study that might help.  It was a quote from one of the PC companies the researchers interviewed.  It was just one line about the decision to outsource to suppliers:  “IT is a big factor.  A supplier’s management capabilities are reflected in their IT [emphasis added] … We do go out to bid and change suppliers, but only after we examine their IT capabilities.”

My advice: when evaluating the IT capabilities of a potential partner in a multi-enterprise network, also evaluate their management capabilities.  They better both be top notch.

The Dilemma:   More and more information access and processing will take place over multi-enterprise networks, over which CIOs have only partial control.  Yet problems on the network created elsewhere can affect your own organization’s IT performance.

What Might Work:  You probably already have several of these networks in place,  perhaps order processing or customer support.  Examine the best of them and develop internal guidelines and roll-out cookbooks for user departments setting up their own such systems.

Mission-Critical Mobile Applications – Yipes!

In one day I can use my iPhone to deposit a check, board a Delta flight, navigate in my rental car, pay for my latte at Starbucks, read a credit card, and access my online medical records.  I can also use it to play the latest free version of Angry Birds, Tweet my 10 chapter Tweet novel, and, if I am not careful, drop it (the phone, not the novel) in the toilet.

IDC’s current forecast is for nearly 500 million smart phones to ship worldwide this year, more than 600 million next year.   By the end of the year there will be nearly a billion of these devils in use.  They are like tribbles (http://www.startrek.com/database_article/trouble-with-tribbles-the) – attractive by themselves but a menace in the aggregate.  We could be talking about a trillion accesses to enterprise information systems a year.

Are you ready?  Each of IDC’s six vertical market practices – from energy to banking – talks of mobile applications as a next frontier.  Patient monitoring, fleet management, smart grid, funds transfer, point-of-sale, emergency services, and so on.  Each has a unique set of challenges.

For instance, if you are a bank, do you offer online banking through a Web site or an app?  How do you keep the app updated and backward compatible?  How many devices does it work on?  How do you handle tech support?  Do you charge for the app and service?  What do you do when you have to introduce multifactor authentication?

If you are a health care provider, how do you support the doctors and health care professionals clamoring to use their mobile devices to track patient progress and access and update medical records – given the security and management issues?   Vendors are starting to offer bidirectional access to electronic medical records and point-of-care mobile devices, but which vendor do you chose?  Will they be around in five years?  Meanwhile, early returns show improved patient outcomes from real-time access to patient data from mobile devices, so the impetus for adoption is there.

We have talked about the problems with mobile devices before (see my March 7 post The Commingled Data Tangle and May 23’s The IPad: Tabula Rasa or Tabula Cura) – security, management, personal versus business use, ownership, and so on.  But the use in mission-critical applications – ones smack dab in the middle of the value chain – adds an order of magnitude to the penalties for badly managed implementations.

Yet, in a study IDC conducted for Unisys last year (http://www.unisys.com/unisys/ri/topic/researchtopicdetail.jsp?id=700004) on the consumerization of IT, we found that already more than 10% of information workers used smart phones to access enterprise applications, with younger workers coming in at twice that.  Between the 500 million smart phones and another 50 million iPad-like devices shipping this year that percent will hit better than 25% this year.  That’s your employees and your customers.

The dilemma here is subtle.  You need to support these new applications – the user departments will drag you to them if you don’t lead the way – but you need to do it in an orderly fashion.  We are just exiting the phase where mobile devices are used for traditional tethered applications – except they are mobile – and entering the phase where they do things that can’t be done without being mobile.  An iPhone can do what an in-dash GPS system can do, but you can’t rip the in-dash system out to use when you are in your spouse’s car.

Supporting this next level of mobile usage isn’t just a matter of cranking down on security, device management, and application support because your traditional applications now need to support these scary devices.  It means choosing and developing whole new applications, delivering them in a new way, integrating them with enterprise information architectures, and thinking out the policy and legal issues long before deployment.  It may also mean working with a lot of new and untested companies.

In fact, if the number of smart phones and tablets in your organization doubles this year, the number of ways they will need to interface with your mission-critical functions will quadruple, and the time you need to spend dealing with them will more than quadruple.  Bet on it.

By the way, I am told that if you drop your iPhone in the toilet the old practice of leaving it in a bowl of rice overnight might not work.  It might take three days.

The Dilemma:   User organizations will soon be clamoring to use mobile devices and tablets in ways central to the organization’s mission, and IT will need to both enthusiastically support them and yet also create an orderly process for implementation and support.

What Might Work:  Go to the heart of the matter.  With your business colleagues, investigate at least one mission critical mobile application – patient point-of-care, fleet management, mobile payments, and so on depending on your industry.  Test it with a small group of motivated users.  Once you are in test mode you can slow down and roll-out full implementation much more slowly.

 

The 100-Year Problem

That’s what the movie industry calls it, the 100-year problem.  Storage for information that preserves quality and allows for ready access many years hence.  The movie industry thinks of Charlie Chaplin and Buster Keaton celluloid moldering in forgotten vaults.  I think of the reel-to-reel tape of my long gone father talking to a neighbor’s kid.  It’s my only recording of him, and it’s sitting in my storage unit bereft of any way to play it. You might think of your Wang 8-inch floppy disks sitting in legal department cartons with files on them that may someday be subpoenaed.

In 2007 the Academy of Motion Pictures Arts and Sciences published what might be the definitive treatise on the subject, The Digital Dilemma (http://www.oscars.org/science-technology/council/projects/digitaldilemma/ ).  What one learns from reading the report is this:

One.  Storage of digital information is more costly than analog storage. Systems need to be on constantly, serviced, and upgraded.  There has to be an infrastructure to support the data.

Two.  Digital content mushrooms in a way analog doesn’t – endless versions, back-ups of back-ups, and so on.  There is no cutting room floor in the digital world.

Three.  Digital media degrades faster, from wear and tear, material breakdown, or obsolescence.

Four.  No one knows what content will be valued years in the future.   Like Rembrandts in the attic or cigarette ads in old Life magazines, what’s of value tomorrow may not be of interest today.

There are strategies being developed today for long term data storage, some of which may be found in the study my CRITO colleague, Vijay Gurbaxani, helped create for the Blue Ribbon Task Force on Sustainable Information Digital Preservation and Access (BRTF) (http://brtf.sdsc.edu/biblio/BRTF_Final_Report.pdf). (In a minor way, I also supported the project – see page 10!)

And while the strategies developed by the BRTF are aimed mostly at digital information for education and research, the challenges to long term information access and storage the report lists sounds like an enterprise CIO’s lament.  Think of:

Long time horizons.

Diffused stakeholders.

Misaligned or weak incentives.

Lack of clarity about roles and responsibilities of stakeholders.

I think of the BRTF as having been written by the best for the best – the National Science Foundation talking to the Library of Congress, university professors to the Smithsonian.   If the environment discussed by the BRTF depicts a long term storage environment somewhere between a challenge and a mess, imagine the environment for the average enterprise.  It’s somewhere between a mess and a catastrophe-in-the-making.

Here’s the CIO’s dilemma.  In the digital world, it will be IT departments that actually run the servers and storage systems that preserve and provide access to the information.  But all the important decisions will be made by, well, as the report says, a diffused set of stakeholders with weak or misaligned incentives working with, in the business context, an unimaginable time horizon.

I wouldn’t be surprised if most CIO’s focus on the technical issues of long-term storage – classifying, tagging, archiving, vaulting, refreshing and reformatting, and so on.  But those are necessary but not sufficient conditions for long term success.  More important will be the wrangling of those stakeholders until the need for long term preservation is well understood and the organization will to fund it is in place.

For CIO’s, perhaps the best first step to this wrangling can be found in the first of three imperatives listed in the Executive Summary (page 1): Articulation a compelling value proposition. Without this you might as well not go on to the next two imperatives (incentives and roles).  This is why I have been harping on IT’s need to blow its own horn and integrate with business units in my last three blog entries.

OK, as the study points out, you don’t have to solve the long term preservation issue for all time in one fell swoop, but you do need an ongoing, funded and adaptable process.  And, oh yeah, one of the things the motion picture industry does when it makes digital movies is to convert one copy to analog film and store it the old fashioned way – just in case.

The Dilemma:   IT organizations manage the systems that provide long term preservation and access of digital information, yet the success of (and funding for) long term preservation will depend on multiple enterprise constituencies, least of all IT.

What Might Work:  Review the BTRF report, see what might apply to your organization, and begin (if you haven’t already) to draw up a longer term plan for long term preservation.  Then start shopping it around the organization.  Look for a strong business unit partner – perhaps the legal department?