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
