+1
Jon
> From: [email protected]
> To: [email protected]
> Subject: RE: [NTSysADM] On premise vs. hosted service
> Date: Wed, 23 Jul 2014 17:27:17 +0000
>
> NOTE: I'm changing the subject, since this thread has forked a couple of
> times from the original topic.
>
> Ken,
>
> Your point that we really have to fully recognize all costs and try to
> compare apples and apples is well taken. But I fear that over-simplifying
> the costs happens on both sides.
>
> It may not cost much to spin up another VM, once you have the infrastructure
> in place, but the true cost of that VM should include part of that overhead
> (including staff time/expertise). I agree.
>
> The big issue I have with outsourcing is that we don't recognize the overhead
> or hidden costs there, either. IT services are FAR more complex a
> "commodity" than electricity or water, and even something like legal services
> or bookkeeping. The latter tend to have a large human component built in
> that can smooth out the 'special circumstances'; most outsourced IT solutions
> don't do that so well (and those that do are often noteworthy for their
> customer support).
>
> Most people grok printing services. Almost anyone can become reasonably
> proficient working with Kinkos, and there are people engaged in the
> transaction who can exercise what little judgment is required. With IT
> services you're not talking an employee turning on a faucet or inserting a
> plug in an outlet. You're talking someone using a web app to submit an
> expense report, complete benefit selection, or submit a purchase requisition.
> Those are all complex activities, and you have to provide something that
> will meet the requirements, including whatever flexibility for unusual/little
> used variation you require. (The poorer it does that, the better the
> customer support should be, to supply that human component.)
>
> If you're working in an organization that's fairly good at detailing what
> they need from a service (and we on this list should know how many ways
> things can go wrong), then the probability of making a good TECHNICAL
> decision is fair. And if you can do that, you're PROBABLY able to quantify
> the total costs of various hosting options to make a good financial decision,
> as well. But in my experience so far, the quality of the technical decision
> (i.e. are we identifying ALL our requirements, and how well the alternatives
> stack up in meeting them) is fair to poor. In that case, you're more likely
> to recognize more of the cost of the on-prem solution than the hosted one.
> I'll generalize, and say that IMO it's USUALLY easier to fix oversights and
> omissions in on-prem solutions. So the hosted solution looks like a lower
> TCO, except you're forgetting some of the things you need/want it to do.
>
> In addition, you won't outsource all your labor costs when you outsource IT
> services. Someone (maybe no longer an IT 'body') will still need to know
> something about the requirements and how to get the solution to implement
> them. Perhaps the 'departmental experts' famous for installing rogue
> systems, who can now install 'officially blessed' external service agreements.
>
> And you'll have to manage your supplier. Exercise due diligence to know that
> they'll provide reliable service and stay in business. I've had one painful
> experience with a supplier who was happy to take our money until something
> failed, then said "I can't afford to fix it for what you're paying - wanna
> give me more?" And before you say we should have checked, let me note that
> the company had changed hands about 4 times in 3 years. What looked
> perfectly reasonable at the beginning of the contract looked terrible in
> hindsight. Good luck getting a service contract that says "If your company
> changes hands, customer has the right to opt out." Not saying it isn't
> possible, just unlikely you'd think to ask unless you'd lived it once or
> twice.
>
> The other place where there are often large unrecognized costs are
> integration. The industry has gone through much controversy over "best of
> breed" vs. "suite" solutions. Better a system that's delivered fully
> integrated that meets 80-90% of my needs, than 6 systems that meet 100% but
> don't talk to one another. Been there, too. Some internal customers are
> unhappy with the results no matter which way you go. It's tough enough to
> stitch together disparate systems when they're on-prem. Even tougher when
> you have to do that across a public network. And, BTW, "if you want to do
> that, you have to go with our 'dedicated hosted', rather than 'multi-tenant'
> solution". Oops. Monthly cost just doubled - but you just signed the 3 year
> contract and didn't realize that would be a problem.
>
> And on the subject of due diligence, how many think to ask how they get their
> data back when they end the hosting relationship? I asked that of one hosted
> app vendor and their response was "We've retained 90+% of all our customers,
> and we never delete your data." Hmmm. What good is it to me if you keep it?
> And what if I don't WANT you to? But I'm IT. I brought it up. If the
> SMEs/decision makers who were present didn't pursue that issue or think it
> important enough to influence their decision, there's little more I can do.
>
> Oh, and want to synch identity so we don't need another set of creds for some
> hosted app? You might need an on-prem server for THAT (I say as I'm in the
> process of building one of those for the afore-mentioned solution).
>
> Is more hosted/cloud coming? Yes. Good reasons? Yes. Straightforward/easy
> to do? Not so much. And a real pain when management starts by looking at
> the cost first, and the requirements second.
>
> Maybe it's not that we're dinosaurs who can't change. Maybe it's 25 or 30
> years of experience saying "Wait a minute, you're not looking at the whole
> problem."
>
> Frank Ress
>
> P.S. <my turn to rant>Would someone please tell the dinosaurs who keep
> creating case-sensitive #@%& that we DON'T need that any more. Only
> passwords should be case-sensitive.</rant> ;-)
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Ken Schaefer
> Sent: Wednesday, July 23, 2014 1:57 AM
> To: [email protected]
> Subject: RE: [NTSysADM] I'm sure you've heard already...
>
> OK - fair enough:
>
> A service can be anything - electricity, water, a shop front, through to IT&T
> services - some very fundamental IT&T services would be application hosting,
> storage, printing, landline, email/mailbox. You can have more fancy "business
> IT services" like transaction processing or similar.
>
> Buy vs. lease is a common question that gets asked when you "buy a service" -
> do you buy or lease a property to provide a shop-front? Some companies buy
> and develop their own land. I'm guessing most small businesses choose the
> lease option. Even with utility services like electricity, there'd be some
> organisations that that choose to provide electricity using their own
> equipment, rather than outsourcing it to a utilities company. I'm guessing
> most are quite large, but there's also instances of very remote sites
> utilising their own solar or wind generation.
>
> So, what criteria does one use to determine whether to buy vs. lease? What
> criteria do you use when deciding when to have an internal capability vs.
> using an external provider? There's a whole bunch of other questions with
> their criteria as well - depending on what framework you want to use (have
> sent you the ITIL service strategy doc offline).
>
> There's nothing specific to it that I've come across that makes procuring an
> "IT service" or capability any different to any other type of service. You
> could buy a printing capability, or you can lease it. You can do it
> internally, or you can outsource it to a print house. You can buy a server,
> or lease it. You can manage it internally, or outsource it. And so on, and so
> forth.
>
> That decision (and in a larger org, you'd have a whole sourcing strategy to
> provide guidance on when to choose each option) is something the business
> should look at first. Way before any implementation details. This is what I
> call "hard question" - as opposed to your example (who has the encryption
> keys?), which I would call and details/implementation question. It's just my
> personal experience, but from what I've seen, a lot of orgs seem to struggle
> to generate good data to justify their sourcing decisions.
>
> The previous post from J-P is a classic example (IMHO) of not understanding
> the cost of providing an IT service. If providing a service was as simple and
> cheap as "adding another VM", then it would cost just as much to run 1 VM, as
> it does to run 100,000 VMs. And that certainly isn't true. The tricky part is
> working out how much an incremental VM actually costs (which means
> assigning/apportioning actual costs to services delivered). Then a meaningful
> analysis can be done on whether it should be hosted internally, or put
> somewhere else.
>
> Cheers
> Ken
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Susan Bradley
> Sent: Wednesday, 23 July 2014 4:09 PM
> To: [email protected]
> Subject: Re: [NTSysADM] I'm sure you've heard already...
>
> You use the phrase "how I want to buy a service" which is what I'm
> struggling over. I don't have departments in my firm and thus don't
> consider employing someone to do a task as "buying" the service which is I
> think where the misunderstanding is starting out from.
>
> For some items, like utilities, where it doesn't have a confidentiality
> issue, I buy the service in the manner that it's given to me and think
> nothing of it. For others, like legal services, in my firm we hire the
> Attorney and his reputation and sign an engagement letter. I'm not
> always "buying a service" in my mind. I engage another human being that
> I trust. It's not a commodity, it's still a relationship.
>
> In my personal space "how you want to buy a service" isn't the question I
> start with (and apologies as I that's what I'm stumbling over). For some
> small businesses the question is how cheap they can get a service
> for. For others, like mine, it's more of this fuzzy "am I comfortable
> in hiring someone that I don't have direct control over". It's not
> necessarily 'how to buy' but 'do we hire'?
>
> Neither one of us is talking rubbish, we just are coming with different
> backgrounds (and hopefully providing useful links or food for thought along
> the way).
>
>
> P.S. regarding the other point made in a different comment and provide a geek
> comment... If a vendor says they are SAS 70 certified, I'd ask them what it
> got replaced with because SAS 70 is the old wording
>
> http://www.csoonline.com/article/2126003/compliance/sas-70-replacement--ssae-16.html
>
>
>
>
>
> ________________________________
>
> This communication is for the use of the intended recipient only. It may
> contain information that is privileged and confidential. If you are not the
> intended recipient of this communication, the disclosure, copying,
> distribution or use hereof is prohibited. If you have received this
> communication in error, please advise me by return e-mail or by telephone and
> then delete it immediately.
>
>
