>1. Cloud computing is not Saas which is not Web 2.0 which is not ASP etc.
>That's like saying records management is archiving is discovery is document
>management.  SaaS is more about the
>business model of how the application functionality is provided. 

<Snipped for brevity>

Everyone offering SaaS is attempting to bundle storage with it, because
that's where they see the long term money.  If you don't think they're the
same, fine...  but if you're in RIM as a practitioner or manager, the
vendors selling it are selling it as a "concept" and over the past year,
they come in pushing 'the cloud' as the carrot with SaaS as the stick. 
Spend some time around SNIA and try to convince them the smoke and mirrors
aren't there. 

>There is some risk to SaaS, CC, etc., just as there is risk to the
>traditional software model or to keeping everything in paper in the
>basement.

Not exactly... in fact, not at all. You can prevent against the risks of
records storage you manage because YOU manage it.  And if you think most
organization not using "SaaS, CC, etc." are storing paper in a basement, you
OBVIOUSLY haven't been practicing RIM.  No matter how well structured your
SLAs are, there are limits to the liability and when your data and
information that represent records to your organization go out of your
control, your risks go WAY up.


>Compare cloud services to the electricity grid. Nobody could imagine in 1900
>outsourcing all of their energy needs to "the electricity cloud" - what
>happens if it goes down? What happens if the "power line" is cut? What
>happens if they jack the prices way up? 

Apples and oranges.  Nobody (typically) runs their own power plants but they
generally DO have backup generators to ensure nothing is lost in the event
of a catastrophe prior to a controlled capture and shutdown.  Many people
have run their own data storage and still do, and many times when these
service organizations fail, they take their stuff back and do it again. 
Sure there are economies to be had by having others provide this as a
service to you, but the risks are pretty great as well.  It ain't like
power, or water, or other infrastructure items 


>are trying to provide is the information services grid. It's more robust
>than your internal solution. It doesn't go down - and when it does, as
>Google Gmail did this week, it's still more reliable than 99% of corporate
>email. 

Once again, the model used as an example is e-mail... ho-hum.  Many see it
as a lifeblood, and true, lots of business is transacted by e-mail but the
critical information assets are generally the pieces of data attached to the
e-mail. 

The 99% rule is the same rule a well-known information (paper and digital)
storage vendor uses when one of their facilities burns to the ground or they
lose tapes... but if you're the 1% you don't CARE about the other 99%.  And
again, I point to a regional disaster scenario... major earthquake, shifting
transmitters on building tops, no signals... loss of power, inability to
access your "aaS" no matter what your SLA guarantees. Major hurricane or
flood, hundreds of clients needing access simultaneously to commonly stored
data sets... and these aren't maybes, these are eventualities.  


><snip>
>The communications networks aren't proven to be robust enough to handle the
>traffic of a large number of major companies all attempting to access huge
>repositories of information simultaneously.  And A RAID, or SAN or NAS can
>only spin up so fast and can't access multiple sectors at the same
>time.</snip>
>
>Which leaves what? Optical, which is slower? Tape, which is worse? Paper? 
>In a disaster that crushes the digital infrastructure, what's the likely
>outcome for paper and film? In the event of a major earthquake, which is the
>storage model most likely to gain you access to your information if your
>building was near the epicenter? Post-Katrina, how quickly were those
>organizations whose data was stored locally back online?

Local is a relative term and most organizations don't rely on ONE source for
their data.  Obviously you haven't spent much time developing or
implementing disaster preparedness, prevention, recovery or vital records
programs. I have.  The Katrina example is a bad one... these people in many
cases were ignorant and unwilling to address the known risks.  They knew
what the range of a Cat 5 was and how frequently they occurred.  I can
guarantee you that the Strategic Petroleum Reserve, a DOE facility that is
run by a contractor which is placed directly in the path of numerous events
knows what to do so they don't skip a beat.  There were plenty of other
stories of properly prepared organizations that didn't go under... but there
were more that did.  

Disaster preparedness doesn't mean you place your backup data set "local"
unless you define local as being at a distance far enough away from the
primary operation that it couldn't be affected by the same event.  Here in
the SF Bay Area, local is defined as more than 40 miles away from known
active fault systems and your primary place of operations.

Yeah, other options may be 'slower' but would you rather be hampered by slow
access or complete loss of information?   And if you KNOW what is vital and
what you will potentially need access to nearly immediately for continuity
of operations, you will have taken steps to have THAT information available
in multiple locations and in multiple formats.  

>So sorry, but this is not just "another attempt for the IT vendor community 
>to try and prove "anything you can do we can do better"". It's a fairly
>radical change in technology architecture and approach that a lot of
>companies are exploring as means to give them more robustness and
>scalability at lower cost while still providing required compliance and
>security capabilities.

But it isn't mature enough for organizations to jump on. Exploring is one
thing, but colonizing is another. And be careful when you attempt to
convince people that "required compliance and security capabilities" exist
here.  Until these service providers can prove that to be the case, they
STILL aren't the ones who will be wearing orange jumpsuits when the data
they are charged with the responsibility to manage on behalf or a client is
lost.  

In every case where identities have been exposed due to the loss of PII in
the past, it's the party responsible for gathering the data that has their
name and reputation soiled, and they are the one held accountable for the
financial costs of years of reporting and protection for their clients, not
the service provider under contract to protect it that was DIRECTLY
responsible for it's loss.

> Records managers need to consider how to manage 
>these environments rather than simply rail against them.

Records Mangers don't write the contracts and they aren't approached when
the vendors selling the services come on campus. And the services aren't
sold with full disclosure about potential problems and risks.  They're sold
as you indicated above... less costly, more compliant, reduced staff and
equipment costs, just like other used cars.

Rome wasn't built in a day, but moving into a partially constructed Rome
didn't mean there was a risk that you wouldn't have a roof over your head as
it improved.  And as Rome was nearing completion, its ruination was
beginning... it became too big to support, and it failed to support the
"small to medium sized" patrons first.

Larry

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]