Apologies for the length of this post but I certainly don't think this is OT
- I think this is a very important discussion for RMers to have as the trend
continues to accelerate. 


<snip>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. </snip>
JW: 1. Re storage: So? 
2. They categorically are not the same. The infrastructure is different, the
functionality is different, the end state is different, the approach is
different - other than that.... Kind of like my example about archives vs.
DM vs. RM. (Yes, I know there is a difference! But so too is there in my
example.) I can't speak to SNIA as I have no idea what their position is. 

<snip>
>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.
</snip>
JW: 1. How about the risk of a database corrupting? How about the risk of
tapes not backing up correctly? How about the risks of selecting a hardware
or software solution that is acquired and no longer supported next week? I
stand by my position that everything has a risk associated with it - and a
cost. 
2. No, I certainly don't think everyone not using CC is keeping paper in the
basement. It's an example, not a categorical. I'll decline to address the ad
hominem. 
3. Absolutely. Same issues that you run into with offsite storage but I
don't see any categorical admonishments NOT to do that, but rather
recommendations on HOW to do that to minimize the associated risk. 

<snip>
>Compare cloud services to the electricity grid. Nobody could imagine in
1900
>outsourcing all of their energy needs to "the electricity cloud" 
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 </snip>
JW: 1. Heh. Many buildings have backup generators - and many of them do not.
And most organizations don't know how to do a good shutdown. And most users'
PCs aren't connected to the UPS and backup generators to shut down
gracefully. Etc. Etc. Etc. The folks you work with may have spent the money
and have the infrastructure in place to do that. The 600,000+ or so small
and medium-size businesses that exist in the US don't. 
2. It absolutely is an infrastructure issue and I think this will become
increasingly apparent as we move forward into the model you describes with
the reciprocal agreements. 

<snip>
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>
JW: 1. You're missing the point about the 99% I cite up there. What is the
percentage of organizations whose downtime for email, or SAP, or any other
mission-critical service, including both planned and unplanned, was less
than an hour? I'm almost certain it is far lower than 1%. And those
organizations are the ones that can spend millions of dollars on robust
clustering, mirroring, hotsites, and the like. The other 99+% of
organizations that can't could conceivably get better robustness and
reliability from a cloud or SaaS solution than they could from their own IT
and at a significantly reduced cost. 
2. Major hurricanes and floods knock out significant capabilities across a
broad area of the country. If you have no network access and no power than
local vs. cloud makes no difference. If you do, Google and Amazon are much
more likely to have service online than your IT staff. They are much more
likely to be able to provide access to hundreds of clients simultaneously.
They are definitely more able to provide access to the data that would
otherwise have been stored locally in the powerless and networkless
datacenter at corporate HQ in New Orleans. Or Tower 1. Or the epicenter of
the earthquake. 

<snip>Local is a relative term and most organizations don't rely on ONE
source for
their data.</snip>  
JW: Really? Where do organizations with one location keep their data? Where
is all an organization's email? SAP data? Customer records? I submit that
you describe the exception rather than the rule - and I don't think you can
disagree with that in an environment where we still see Fortune 500
companies without a formal records program. 

<snip>Obviously you haven't spent much time developing or implementing
disaster preparedness, prevention, recovery or vital records programs. I
have.  </snip>
JW: Nope but this is a non sequitur with little relation to the original
point of the article which was the increasing use of cloud, SaaS, utility
computing and the like and which can actually complement disaster recovery
and business continuity operations. Not instead of, perhaps in addition to.

<snip>
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.</snip>
JW: By your organization. I'm not going to tell you how many organizations
had their operations in Tower 1 and their offsite backups in Tower 2 because
there was considered to be almost no risk in Manhattan of two buildings that
size being totally lost - until it happened. See also 500-year floods, the
NE US/Canada power grid outage, etc. 

<snip>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.</snip>
JW: Which makes my point precisely. If your stuff is stored in Google, the
likelihood of complete loss of information is not very high today, and as
cloud computing takes over and there are more agreements and federation of
the "information grid" in place the likelihood will continue to drop. What's
easier to make available in multiple locations and formats than something
available through a browser?

<snip>
>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. </snip> 
JW: I agree completely. 

<snip>
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.</snip>
JW: That's a due diligence issue and a RM-IT-legal-business issue, not a
cloud- or SaaS-specific issue. How is this different from litigation support
services, offsite storage, use of a service bureau for imaging, or any other
introduction of a third party?

<snip>
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</snip>
JW: I agree and would simply note that most of your prior objections,
relating to offsite backup 40 miles away, redundant servers (by
implication), etc. are far less available to SMEs than they are to larger
enterprises for reasons of cost, complexity, management, etc., making cloud
and SaaS *more* applicable to them, not less. 

R/S, 

jesse

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]