Initial Rant...
Generating a "winning team" attitude
Team = Product. This is the premise that Jim and Michelle McCarthy propose in their teachings (follow this link for more info on them. It will be worth your time). Their theory explains (and in practice shows) that the attributes of a team are directly traced to the attributes of the product and viceversa.
In our case, the product was a data center set up at the hosting facility that could carry our day-to-day activities and maintain the same service level that we had in our previous facility. We needed to become a team with those attributes if we wanted to succeed. Our core team was made up of 11 individuals with skills in Project Management, Networking and Server Administration, Database Administration, Quality Assurance and Enterprise Software Architecture Development. At first, there were several differences and egos that needed to be leveled and dealt with. It took a few weeks to work through that but we got there. There were several times when my colleagues helped me get motivated to keep pushing and in other cases I was able to provide motivation and encouragement. It was not easy but it was worth it. This core group was fortunate enough to count with the help of many other colleagues in those same areas listed above.
In our case, the product was a data center set up at the hosting facility that could carry our day-to-day activities and maintain the same service level that we had in our previous facility. We needed to become a team with those attributes if we wanted to succeed. Our core team was made up of 11 individuals with skills in Project Management, Networking and Server Administration, Database Administration, Quality Assurance and Enterprise Software Architecture Development. At first, there were several differences and egos that needed to be leveled and dealt with. It took a few weeks to work through that but we got there. There were several times when my colleagues helped me get motivated to keep pushing and in other cases I was able to provide motivation and encouragement. It was not easy but it was worth it. This core group was fortunate enough to count with the help of many other colleagues in those same areas listed above.
Organization of the Project (SharePoint helped quite a bit!)
Fortunately for me, I had been working with a tool called SharePoint (Microsoft's version of a Content Management tool). I am by no means an "expert" on SharePoint but at the time I knew enough to be dangerous with it. The first thing we set up was a site to keep track of the "usual suspects": Calendar, Document Library, Discussion Board, List of "Common Links", list of "Servers to Migrate", list of "Steps to Carry out the migration", and a "how-to" wiki page for the project. The last three artifacts were the most utilized and helped save our necks (many times) and keep the project on track.
Obtaining Trust: This was the most important clean up activity. I had to trust me team mates. They had to trust me. Equally important was for upper management to trust the team and the team to trust them. Again, some times that was not easy but we had to keep pushing!
Clear Objectives: For our software to work properly at the new location we had to make a list of all the services that made up our suite of applications: Database layer, business layer, services layer, communications layer, presentation layer. We made sure we accounted for all the servers that were running pertinent software and cataloged the physical and logical characteristics of each machine. We qualified each machine as being DEV, QA, PROD or DR (disaster recovery). Also, we qualified each machine based on the main purpose of the software that ran on it. We also cataloged physical characteristics of the machine like old name, new name, new DR name, IP addresses (old and new), Operating System, memory, CPU, etc. We created a long master list of the hardware and we used our Content Management system to present that list using different perspectives (or views): The PROD view, the DR site view, the Database servers view, etc. Having this list available (on-line) during meetings was crucial for the team to remain on "the same page."
Flexible Architecture: Our software provided a very flexible architecture. It was based on many configurable components (that's as deep as I can get on that topic). Layered architectures are going to fair much better in a data center migration project. If you think you may be changing data centers in the future I encourage you to take a long, hard look at your infrastructure and score it for how easy or difficult it will be to reconfigure especially when you are forced to change names of the servers that run your enterprise apps.
To be continued in Part 2
No comments:
Post a Comment