The worst mistake we can make in IT is to become so embedded in firefighting or triage activities that we lose the ability to pull back and see the “big picture”. This is most likely to happen in a situation where there’s no encompassing strategy.

A strategy shouldn’t be about having a fine level of granularity, and often it’s the perceived need for fine detail that prevents the strategy from being developed.

However, strategy really is all about the big picture rather than the miniscule details. The miniscule details are actually important, but if you stop to focus on them in the strategy, you lose the high level overview and again become mired in the mundane.

In short, the details are the purdue of the projects that come as a result of having a well defined strategy. Indeed, to quote Oxford Dictionaries Online, a strategy is:

a plan of action designed to achieve a long-term or overall aim

No business actually succeeds without a strategy. (That’s why fancy management consultants are paid anywhere from thousands to millions of dollars to come up with mission statements and other such slogans. These in themselves may not necessarily be a statement of strategy, but the best ones will actually align with long-term strategy.) Similarly, no subset of a business will function to its full potential without a strategy.

Like so much of backup, the big problem in developing strategy within IT is that it’s not (solely) an IT function to define the strategy. When developed in isolation from the actual business strategy, SLAs and other functional requirements, an IT strategy is about as useful as a partition on a disk mirrored to another partition on the same disk. So it might loosely be a mirror, when you just look at the partition level – data that’s written to that partition is also written to another partition, but ultimately all it does is slow down the actual work, not fulfil its actual function, and fail to protect the data.

IT without a strategy is arguably better than IT with a strategy that isn’t coordinated with the business. Without a strategy at all, it’s pure reactionary, meaning IT is at least responding to of-the-moment business needs. With a strategy, but one that doesn’t align to the business needs, the IT group is:

  • Potentially spending money on unnecessary items;
  • Using staff unproductively;
  • Draining resources from work the business actually does need.

To a degree, IT strategy is a core responsibility of the CIO (or the equivalent role in a smaller company); it comes from senior management in IT liaising with the rest of the business to determine business requirements, and then liaising with staff in IT to create a targeted strategy that sees suitable staff and systems development in such a way that the business benefits. That’s not to say that the CIO has to do this in isolation. It’s also not to say that it can only be achieved as an internal discussion. Indeed, there are often benefits to involving external sources in the discussion.

Let me give you a much simpler example: in IT, I think we’ve all worked on a problem, or an issue, for an extended period of time, to the point where we finally ‘give in’, and get someone to offer their thoughts. With a fresh perspective, and not mired in the day to day aspects of the issue, it’s quite common in those situations for the person to almost instantly (or seemingly instantly) offer a clear and coherent solution. The same applies practically anywhere: look at just about any field, and if someone is stuck, the best way to find a solution is to get a bit of advice from someone who isn’t personally waist or neck deep in the issue.

I’m not saying that getting consultants in to advise on IT strategy is a magic bullet. In fact, if you take that attitude you’re just going to be milked – a consultant can’t advise blind on strategy, and any consultant who says he or she can is a flim-flam artist. Instead, clear strategy development comes from all three sections – IT, business and an external agent – working together:

Developing a StrategyThe order of the above diagram is actually important. The strategy must be driven by the business needs, which means it sits at the top of the process – if the business doesn’t drive the generation of the IT strategy, then the IT strategy isn’t effective. Both IT and the external advisor(s) will play a role of course, but they’re effectively supporting roles – they provide input to the process. IT provides input in terms of what can be done, what will require budget, what already exists, etc. The external source provides input in terms of what is best practice, what needs to be changed in terms of current processes and systems, and what needs to be removed.

When the three agents work together, true IT strategy is achieved.

So what should be the goals of an IT strategy? There’s actually only one goal:

  1. To enable the business to achieve its strategy.

Any IT strategy that doesn’t have the above as a root goal is not going to help the business. Once this is established as a goal, it’s worthwhile to consider that goals relating to say, staff development etc., are actually business goals rather than goals that should belong to any individual group.

 

Who manages the backups at your site? I.e., who has primary duties for administering and maintaining the backup system?

I’m not a gambling person, but odds are if your organisation is “average” based on my experience, it’ll be the most junior person in the responsible team. That’s how I started in backups, by the way – I joined a system administration team in 1996, and was told to start managing the backups.

I’m all for giving junior people experience in complex and important systems – hands on experience significantly outweighs formal training or certification programmes in my estimate. But there’s a vast gulf of difference between hands on experience and manages.

Let’s compare backup to a few other realms to see what I mean.

  • When you consider an insurance company, do you take into consideration how long they’ve been in the industry?
  • When you take your car to a mechanic, do you hope it’ll be serviced by the apprentice, or the actual mechanic?
  • When you go to the doctors, do you want to get seen by a fully qualified doctor or someone doing their first placement after 6-12 months through their university degree?
  • When you get tradespeople in to do work, do you want the apprentice that started last week doing the work, or the experienced tradesperson?
  • If you call the police, do you want to see a rookie turn up, or an officer with real experience?

I’m willing to assume that in the majority of instances, regardless of whether it’s in health, repairs, trades, insurance, etc., most people will want to be looked after by someone with real experience. If there’s a “junior” involved, you want them supervised and their work double-checked.

Yet many companies time and time again push backups down to the lowest rung in the administration team. It just doesn’t sit well with reality. It’s not how we want to deal with people and situations in real life, and yet because it’s supposedly not a glamorous job, it gets assigned to juniors.

I have a great friend who is a paramedic. He is, quite literally, a hero, though he denies it. He’s saved peoples lives, he’s given people hope, he’s dealt with people at their very best, and at their very worst, and all done it as part of his job. For some time he worked with students who were studying to become paramedics themselves, as an instructor. They’d be teamed up with him, and he’d do his call-outs with the student. The student would be forced to learn, but he’d be a safety net – not only for the student but equally, if not more so, for the patient.

I think a lot of companies forget the safety net when they assign backups to the most junior person in the administration team. Sure, in many instances, the senior staff will pitch in and participate during a critical recovery, but that’s not a safety net, it’s an umbrella in a hail storm. A safety net, in backup systems, would be where the senior person is there monitoring, watching and assisting not only in the recovery processes, but also in the configuration and ongoing checking of the backup system.

(Another example: EMC have a “Disaster Recovery Guide” for NetWorker. The worst mistake a backup administrator can make is read this for the first time when they need to do a disaster recovery. It should actually be read well in advance of a recovery situation, as it gives important information pertaining to getting backups that are useful in disaster recovery situations.)

By all means have your junior staff teethe on a backup system – they’ll rarely get a better cross platform and cross system exposure to your environment than by working with backup. But equally, remember where and when you want to see inexperienced or junior people working on your health, your car, your house repairs, etc., and make sure you deploy an appropriate safety net.

If you don’t … well, have a nice fall.

 

In March this year, I ran a NetWorker Usage Survey to gauge the lay of the land in terms of how and on what NetWorker is deployed within the user community. As a result of that, hundreds of people downloaded the March 2010 NetWorker Usage Survey Report.

It’s time to revisit that survey; I’ve adjusted the questions a little based on some of the responses from the previous survey results, and I’m keen for as many answers as possible to make this a worthwhile report. (Don’t forget, the report will be free to download.)

I’ll be aiming to keep the survey running until the end of November, and publish the results early in December. So please, fill out the survey below and have your say!

~

The survey has now closed. The report will be posted soon.

 

Consulting isn’t the glamour job that a lot of people think it is. Sure, you may get to travel and learn new things, but as anyone who travels a lot will tell you, it can be a bit wearing after a while, and you find yourself suddenly hankering for the most basic of simple meals after weeks at a time of hotel or restaurant food.

Nor do you do consulting for the fame. Sure, good consultants will get reputations in their fields, but we’re hardly household names (except maybe in particularly niche/geeky households). Undoubtedly I think the best consultants start with a passion for their field and a desire to learn as much as possible, but this will only get you so far. There needs to be something else to prevent burn out and to allow for personal growth.

I’ve been extraordinarily lucky to develop and keep long term customer relationships, carrying customers between my last company (which collapsed) and my current company, and equally having customers carry those relationships with me from one company to the next. At one level, they remain customers – but at another, as you’ve been working with certain customers year in, year out, you realise that the true value of consulting is the people you’re doing the consulting for. It’s not about being able to solve problems and challenges for companies that you deal with, it’s about being able to solve problems and challenges for the individual people you deal with. The first just pays the bills; the second one is what gives you the job satisfaction.

In the past couple of weeks I’ve had a few people I’ve been working with for years advise me that they’re moving on to other endeavours. It’s always at this time that I pause to think about the core reason I do this job: to help people.

 

This is my blog entry about the SNIA blogfest on 4 November that I attended, but it’s not what I originally intended to be my blog entry. I was intending just to do a slightly more structured dump of all the details I took down during the meetings with the four vendors, but I don’t think this would be fair to my readers.

At the same time, I’m not a storage expert like the other bloggers who were at the event. In particular, Rodney Haywood and Justin Warren have been dedicating their blogs to strong amounts of information of the details discussed by the vendors. Ben Di Qual tweeted a huge amount during the session as well, and he tweeted towards the end of the day that maybe it’s time for him to launch a blog as well. I’m presuming Graeme Elliott will post something as well (maybe here?)

Perhaps the delays I’ve experienced in finding time to blog about the event have been useful, because it’s made me realise I want to summarise my experience in a different way.

For that, I need an illustration. Having met with the four vendors, and heard their “how we do things” story, I can now visualise each vendor as a tower. And to me, here’s what they look like:

IBM Tower

EMC Tower

HDS Tower

NetApp Tower

I don’t want to talk about the speeds and feeds of any of the products of any of the vendors. To me, that’s the boring side of storage – though I still recognise its importance. I don’t really care how many IOPs a storage system can do for instance, so long as it can do enough for the purposes of the business that’s deploying it. Though I will say that a common message from vendors was that while companies buy storage initially for capacity, they’ll end up replacing it for performance. (This certainly mirrors what I’ve seen over the years.)

When I got my book published, the first lesson was that it wasn’t so to speak a technical book, but an IT management book. Having learnt that lesson, it subsequently reminded me that my passion in IT is about management, processes and holistic strategies. This is partly why backup is my forté, I think; backup is something that touches on everything within an environment, and needs a total business strategy as opposed to an IT policy.

So the message I got out of the vendors was business strategy, not storage options. This is equally as important a message though – in fact, it’s arguably far more in-depth a message than a single storage message.

I’m hoping the diagrams help to explain the business strategy message I got from the four vendors.

EMC and IBM to me presented the most comprehensive business strategy of the four vendors. This was a mix of what they presented and prior understanding of their overall product range. If I were to rate the actual on-the-day presentations, IBM certainly were the best at communicating their “total business strategy”. IBM though also said that they didn’t quite know what information to present, so they just went for the big picture overview of as much as anything. Whether EMC, as a more active social media company were treating the event as a literal “storage” event, or just through a lack of (foresight? time taken to prepare?), concentrated just on storage. But I still know much of the EMC story. To be fair to IBM, too, they’ve been doing it for a lot, lot longer than any of the other storage companies – so they’re pretty good communicators.

Neither IBM nor EMC provide a total strategy; they both have gaps, of course – I wouldn’t claim that any vendor out there today provides a total strategy. IBM and EMC though are closer to that full picture than either of the other two vendors we met with on that day.

But what about HDS and NetApp?

I don’t believe HDS have a total business strategy story to tell. They want to; they try to, but the message comes out all jumbled and patch-work. They contribute disks and some storage systems themselves, and try to contribute a unifying management layer, and then add an assortment of diverse and not necessarily compatible products into the mix. To be fair: they’re trying to provide a total business strategy, but if I were to put an “IT Manager” hat on, I’m not convinced I’d be happy with their story – as an IT manager I may very well choose to buy one or two products from them, but their total strategy is so piecemeal that there’s no technology reason to try to source everything from them.

For what it’s worth, their “universal management” interface message is as patchy as their product set. It started with (paraphrasing only!) “we provide a unifying management system” and boiled down to “our goal is to provide a unifying management system, when we can”.

To me, that’s not a unified management system.

I should note at this point that I’m working on the blog entry now on battery power, as all of Bunbury appears to have lost power tonight. (Let me speak another time of the appalling lack of redundancy built into Australian power distribution systems.)

On to NetApp. NetApp try to present a total business strategy story. They speak of unified storage where you don’t need to buy product A for function X, product B for function Y and product C for function Z – instead, you just buy über product A that will handle X, Y and Z.

But what about functions P, Q and R? Coming at the process from a “I’m not into storage”, the first thing that jars me with NetApp is the “old backup is dead [edit: John Martin has rightly corrected me - he said 'backup is evil']” story. NetApp focus incredibly hard on trying to point out that you never need to backup again so long as you have the right snapshot configuration.

Like IBM’s “incrementals forever are really cool” story, NetApp’s “with snapshot you never need to backup again” strikes me as being almost at 90 degree angles to reality.

(Aside: Of course I’m interested in hearing counter arguments from IBM, and I’ve actually requested trial access to their TSM FastBack product, since I am interested in what it may be able to do – but being told that it doesn’t matter how many incremental backups you’ve done because (paraphrasing!) “a relational database ensures that the recovery is really fast by tracking the backups” isn’t something that convinces me.)

NetApp’s “you never need to backup again” story is at times, from my conservative approach to data protection, a bit like The Wizard of Oz: “Pay no attention to that man behind the curtain!” Yet having a company repeatedly insist that X is true because X is true doesn’t make me for one moment believe that X is true: and so, I remain unconvinced that “snapshots forever = backups never” is a valid business strategy except in the most extreme of cases.

Or to put it another way: HDS trotted out an example about achieving only a 4% saving by doing dedupe against 350 virtual machines. I’d call this trying to use an extreme example as a generic one: I’m sure they did encounter a situation where they only got a 4% storage saving by applying dedupe against 350 virtual machines; but I’m equally sure that one example can’t be used as proof that you can’t dedupe against virtual machines.

Likewise, I call shenanigans on NetApp’s bid to declare traditional backup dead [edit: evil]. Sure the biggest of the big companies with the biggest of budgets might be able to do a mix of snapshots and replication and … etc., but very, very few companies can completely eliminate traditional backup. They may of course reduce their need for it in all situations. As soon as you’ve got snapshot capable storage, particularly in the NAS market, you can let users recover data from snaps and then focus backups on longer term protection etc. But that’s not eliminating traditional backup altogether.

[Edit: Following on from correction; I'd like to see NetApp's "how backup fits into our picture" strategy in better detail, and based on John's comments, I'm sure he'll assist!]

So in that sense, we have four vendors who each try, in their own way, to provide a total business strategy. IBM and EMC are the ones that get closest to that strategy, and both NetApp and HDS in their own way were unable to convince me they’re able to do that.

That doesn’t mean to say they should be ignored, of course – but they’re clearly the underdogs in terms of complete offerings. They both clearly have a more complete story to tell than say, one of the niche storage vendors (e.g., Xiotech or Compellent), but their stories are no where near as complete as the vendors who aim for the total vertical.

It was a fascinating day, and I’d like to thank all those involved: Paul Talbut and Simon Sharwood from SNIA; Clive Gold and Mark Oakey from EMC; John Martin from NetApp; Adrian De Luca from HDS; and Craig McKenna, Anna Wells and Joe Cho from IBM. (There were others from IBM, but I’m sorry to say I’ve forgotten their names). Of course, big thanks must also go to my fellow storage bloggers/tweeters – Rodney Haywood, Justin Warren, Ben Di Qual and Graeme Elliott. Without any of those people, the day could not have been as useful or interesting as it was.

And there you have it.

Now for the disclosures:

  1. EMC bought us coffee.
  2. EMC gave us folios with a pad and paper. I took one. The folio will end up in my cupboard with a bunch of other vendor provided folios from over the years.
  3. IBM gave us “leftover” neoprene laptop bags from a conference, that had a small pen and pad in it. My boyfriend claimed the neoprene bag.
  4. IBM bought us coffee.
  5. IBM provided lunch.
  6. HDS provided afternoon tea.
  7. HDS provided drip-filter coffee. I did not however in any way let the drip filter coffee colour my experience on-site. (Remember, I’m a coffee snob.)
  8. NetApp provided beer and wine. I had another engagement to get to that night, and did not partake in any.
 

Just to let you folks know that I’m currently just “mostly missing in action” rather than “missing in action”.

It’s been a hectic few weeks for me, both personally and work-wise, and as my role adjusts to some changes I’ll be doing more travel again which will mean getting used to doing posts on the run.

I’m currently in (not so) sunny Western Australia – specifically, Bunbury, doing some work for a long-term customer, and flying back on Friday. That’ll give me Saturday and Sunday to recharge my batteries and get some Greek coffee into my system. (Maybe, if my friendly tattoo artist will help out, maybe Sunday will also see me getting some new ink. Though maybe that won’t happen if I don’t remember to email her – hmmm…)

Next article: Last week I attended the SNIA AU/NZ first storage blogfest – where myself and a group of other bloggers/tweeters were taken to EMC, IBM, HDS and NetApp for some discussions and technology direction overviews. I had hoped to blog about it by now – but instead I’m aiming to have blogged about it by the time I leave WA – that’ll mean either tonight, or tomorrow night.

Stay tuned – I’m not MIA, just MMIA.

© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha