No, I didn't get lost somewhere in the IT buzzword dictionary.
I've started to use the phrase to capture some basic concepts around one of the most mundane (yet) important tasks in IT -- migrations.
And I'd like to offer some thought as to why we might be thinking of this differently in the near future, if not today.
It's Moving Day!
I bet many of you have moved your residence at least once in your life, and maybe more often.
Me, I've moved about a half-dozen times since I graduated from school.
My approach has defintely evolved a bit over the years.
I seem to remember simply shovelling everything into boxes, loading them up, and disgorging them all at my new abode. It was a lot of work, and I ended up breaking a few things every time, but the worst part is that I still lived in a messy environment.
I had simply moved an awful mess from one place to another.
Later on, my wife helped me gain a new appreciation of the opportunity associated with a move.
Rather that just moving my mess from one place to another, start ahead of time and prune out all the stuff that shouldn't be coming with you.
Throw stuff away. Sell it off. Give it away. Make a pile on the roadway with a sign "free" on it. My wife convinced me that a little effort up front made a big difference at the other end. She was right.
When you're moving, think process. Put stuff in labelled boxes. Think in terms of sequence.
And, at the other end, give some thought as to building organizers, shelves, cabinets, etc. before all the stuff shows up, rather than just piling it in the basement, where it will simply rot.
Don't just think about moving stuff, think about improving your situation in the process.
And Now, Back To IT ...
IT guys (especially bigger shops) are always moving stuff around.
I joke that, in large shops, IT is perpetually in one of three phases:
- getting ready to move to something new
- moving to something new
- recovering from moving to something new
Sometimes it's simply to get something from one place to another. Take what was running here, and put it there. Don't change a thing. Don't try to improve functionality, or operations, or anything else.
I call these "technology migrations".
All you want is a low-risk, low-cost, minimal-effort way to get stuff from place A to place B.
A lot of EMC's business is storage, and these "tech migrations" are a staple of our business.
Two Views of Storage Technology Migrations
There are parts of the storage industry that become obsessed with products, and technology migrations are no exception. As an example, one of the more visible benefits for storage virtualization is non-disruptive migrations.
That's fine, but storage virtualization isn't the only way to do a non-disruptive migration. And not all migrations need to be non-disruptive. Matter-of-fact, many of them are cheaper and easier done non-disruptively.
Sometimes, I think it's almost like calling a moving company and they go on and one saying they've got the perfect truck, or the perfect packing materials for your move -- but they forget to ask you what you're moving, or why.
EMC's view of technology migrations is more of a moving professional. You interview the client and figure out what they need to move, and why. You understand what's important, what's sensitive and so on.
And then you go back to your proven portfolio of moving trucks, packing materials and moving specialists, and plan the move: low cost, low risk, and minimal effort.
BTW, the last time I counted, we had about 22 products in our own portfolio (and we work with at least a dozen non-EMC migration enablers) to help with technology migrations. We've also got over a thousand people who do this routinely, with many thousands of technology migrations under our belt.
Or, if you're so inclined, here's the tools and some instructions on how best to use them. Your choice.
But, all of this is winding up to an even bigger idea that I think gets left behind in the discussion ...
Operational Transformation
Big word, simple idea.
How'd you like to run things better after the move, rather than run them as you did before?
To do this, it isn't just products -- it's the "layers 8, 9 and 10 of the protocol stack": people, process and politics.
Using a storage example, would you like a refreshed storage architecture? Re-lay-out your SAN, LUNs and groups? Maybe do some tiering in the process? How about better operational procedures for provisioning, or problem management?
There's a lot that can be done other than just copying your LUNs from the old stuff to the new stuff.
Or, let's take server virtualization. I've blogged extensively that VMware is more than just a server thing. Yes, you can get at some of the benefits by just spinning up ESX on your servers. But there's much more out there, if you're up for it.
My favorite "can of worms" example is data center migrations, something we do a lot of. There's a thorny question of how much do you invest in improving the operational state of affairs during the move, and how much you simply shove in boxes and send over.
There's similar examples in file virtualization. Or information security. Or next-gen, model-based resource management.
You get the picture.
One Thing Leads To Another, Doesn't It?
OK, it's a fun discussion to have, but there's a natural tendency for scope creep, and all of the sudden you're solving world hunger when you just wanted a quick snack.
And I don't know if I can come up with useful, yet generic, guidelines when to shut down this line of discussion, and just get on with it.
But -- I would offer -- the topic should at least be considered. As IT improves their technology portfolio, they also should be looking at improving their operational capability.
And sometimes, the opportunity to do both shows up at the same time. More work to do, yes, but a unique opportunity to clean up the mess, and start fresh.
Kind of like moving your house.
Comments