Reduce System Implementation By Emphasizing Design Over Build.
Many years of designing, executing, and remediating complex technology projects have taught me a valuable lesson: Document BEFORE you build.
Most people have it backwards. They'll do a little planning, then start building everything, then revise the plan as they build stuff, and then they'll update the documentation later.
Yeah, right. "Later" never happens...and suddenly you have incorrect/incomplete/outdated documentation that doesn't match what was built. That costs time. Time costs money.
"...but there's always time to do it over." My experiences have led me to believe that each hour of planning and documentation performed up front saves at least 8-10 hours of labor later on in the project. Some of my clients have told me I'm being too conservative, and that each hour spent on planning/documentation saves more like 12-16 hours of labor later.
It's faster and cheaper to do the due diligence up front. This means collecting information such as IP addresses and setting up naming standards. Documenting who the project manager and all of the team members are. Setting up spreadsheets and Visio documents delineating what needs to be built. Reviewing all of that documentation with the project team and project stakeholders.
Let's face it; it's a lot easier to rework a Visio diagram than it is to rip apart and rewire a densely-cabled VMware cluster. (If it isn't, hire yourself a 12-year-old to work Visio for you. Just make sure you don't violate any child labor laws.)
When planning first, second pays off. I once had a client that contacted us in an emergency situation. They were moving their data center, and the vendor that had contracted to move their VMware cluster had flaked out and resigned from the project three weeks prior to Moving Day because they had no resources available.
I was sent across the country to the client (who turned out to have a bunch of incredibly nice and easy to work with employees) just two weeks before Moving Day...for a project which had been inked out as taking FIVE weeks.
The VMware "cluster" was actually several unrelated VMware hosts, none of which had matching hardware, all of which were using a combination of local storage and a single very old SAN. It was clear that the old VMware systems would not survive being shut down and moved.
The client did have a new set of VMware hosts and SANs ready to go at their new site...but how to migrate from the old, horrible VMware hosts to the new beautiful hosts with no connectivity between the two sites?
I spent two days documenting what the new VMware cluster needed to look like, creating an intricate spreadsheet showing every connection to every host and every switch port.
On the third day, I had the client move one of the new VMware hosts and one of the new SAN units back to the old site. It took two days to build a new VMware "mini-cluster" consisting of one host plus one SAN, connecting everything to the old network. On the fourth night, I migrated all of the client's production systems from the old VMware hosts to the new mini-cluster. Just one of the new VMware hosts was several times more powerful than all of the old VMware hosts combined, so this wasn't a big deal.
The following week was spent at the new site, building out the rest of the two new VMware clusters, leaving space in the rack for the missing host and SAN. Everything else was loaded, configured, and cabled.
On Moving Day, the client had a special team in place to move the new VMware mini-cluster from the old to the new site right away. I met the team at the new site, and hooked up the mini-cluster to the other new hosts to form the final production cluster.
Early in the morning on Day 1 At The New Site, all production systems were up and running...two days ahead of the original schedule.
Such is the power of documenting first, building second.
Many years of designing, executing, and remediating complex technology projects have taught me a valuable lesson: Document BEFORE you build.
Most people have it backwards. They'll do a little planning, then start building everything, then revise the plan as they build stuff, and then they'll update the documentation later.
Yeah, right. "Later" never happens...and suddenly you have incorrect/incomplete/outdated documentation that doesn't match what was built. That costs time. Time costs money.
"...but there's always time to do it over." My experiences have led me to believe that each hour of planning and documentation performed up front saves at least 8-10 hours of labor later on in the project. Some of my clients have told me I'm being too conservative, and that each hour spent on planning/documentation saves more like 12-16 hours of labor later.
It's faster and cheaper to do the due diligence up front. This means collecting information such as IP addresses and setting up naming standards. Documenting who the project manager and all of the team members are. Setting up spreadsheets and Visio documents delineating what needs to be built. Reviewing all of that documentation with the project team and project stakeholders.
Let's face it; it's a lot easier to rework a Visio diagram than it is to rip apart and rewire a densely-cabled VMware cluster. (If it isn't, hire yourself a 12-year-old to work Visio for you. Just make sure you don't violate any child labor laws.)
When planning first, second pays off. I once had a client that contacted us in an emergency situation. They were moving their data center, and the vendor that had contracted to move their VMware cluster had flaked out and resigned from the project three weeks prior to Moving Day because they had no resources available.
I was sent across the country to the client (who turned out to have a bunch of incredibly nice and easy to work with employees) just two weeks before Moving Day...for a project which had been inked out as taking FIVE weeks.
The VMware "cluster" was actually several unrelated VMware hosts, none of which had matching hardware, all of which were using a combination of local storage and a single very old SAN. It was clear that the old VMware systems would not survive being shut down and moved.
The client did have a new set of VMware hosts and SANs ready to go at their new site...but how to migrate from the old, horrible VMware hosts to the new beautiful hosts with no connectivity between the two sites?
I spent two days documenting what the new VMware cluster needed to look like, creating an intricate spreadsheet showing every connection to every host and every switch port.
On the third day, I had the client move one of the new VMware hosts and one of the new SAN units back to the old site. It took two days to build a new VMware "mini-cluster" consisting of one host plus one SAN, connecting everything to the old network. On the fourth night, I migrated all of the client's production systems from the old VMware hosts to the new mini-cluster. Just one of the new VMware hosts was several times more powerful than all of the old VMware hosts combined, so this wasn't a big deal.
The following week was spent at the new site, building out the rest of the two new VMware clusters, leaving space in the rack for the missing host and SAN. Everything else was loaded, configured, and cabled.
On Moving Day, the client had a special team in place to move the new VMware mini-cluster from the old to the new site right away. I met the team at the new site, and hooked up the mini-cluster to the other new hosts to form the final production cluster.
Early in the morning on Day 1 At The New Site, all production systems were up and running...two days ahead of the original schedule.
Such is the power of documenting first, building second.
RSS Feed