| |||
![]()
|
![]() ![]() |
![]()
Data Migration Service Level Agreements for Data Centers Valeh Nazemoff is an international bestselling author and SVP of Acolyst, with a focus on data migration solutions for the Federal Data Center Consolidation Initiative and Act of 2013. Recently, I met with the Deputy CIO of an agency within the Department of Defense. The agency had just received an unpleasant report card from the Office of Management Budget (OMB), an organization that requires agencies and departments to routinely report to Congress on realized savings. As a result, the Deputy CIO was more convinced than ever of the urgent need to migrate data and consolidate data centers for a variety of reasons. In September 2014, the United States Government Accountability Office (GAO) issued report GAO-14-713, titled Data Center Consolidation – Reporting Can Be Improved to Reflect Substantial Planned Savings, covering data consolidation inventories from 24 departments and agencies. Only two agencies were reported to have achieved success with “realized savings and efficiencies from the migration to enterprise data centers.” Further, only one agency was reported to have successfully “instituted a culture of continuous process improvement to seek new, cost effective methods, tools, and solutions for data center migration.” Only one. Transforming Mindsets, Creating ChangeFederal agencies and departments must transform their mindsets in order to migrate data in ways that meet GAO and OMB’s shared initiative of data center consolidation. Many benefits will result – data that is more reliable, scalable, and high performing. Plus, data consistency, latency, and efficiency will be maintained and even improved. But, where should they start? In November 2014, a white paper issued by Acolyst – FalconStor Federal titled Consolidating Multi-Petabyte Data Centers: Breaking through the Data Migration Barrier suggested that the major reason for rework and delays in data consolidation comes from lack of proper planning. The white paper asserts that “proper assessment and documentation establishes the appropriate framework and effective lines of communications, and confirms the direction that the organization is heading.” Another major issue expressed by the aforementioned Deputy CIO was the agency’s difficulty identifying which applications housed the data that was most critical to be migrated. Internal lines of business within the organization were not effectively communicating with IT. This is why there is a need for both internal and external data migration service level agreements (SLAs). Most federal agencies and departments vehemently refuse to do internal SLAs. Why is that? Many have the mentality that SLAs are only for punitive and negative uses. What if there was a mind shift when it comes to SLAs? They can serve as an effective means to communicate and document a project’s framework, garner buy-in from all parties, and redirect teams toward a common goal. SLAs can be used to uncover inconsistencies in definitions and expectations, determine root cause, assess impacts, mitigate risk, and drive actionable activities. Further, SLAs uncover which applications and data are most important to the client when migrating and consolidating data centers. Formalizing the SLAs assures all business units that their strategic and tactical objectives will be met. The objective of the exercise of writing and documenting an internal SLA is to get into the right mindset and be aware of the various questions and information that must be collaboratively gathered and evaluated. A Clear View of Current ConditionsA clear picture of the current “as-is” state of the impacted data centers are crucial. Organizations often discover new sources of data that must be migrated during this discovery process. Continual questions must be asked and their answers documented in the SLAs, such as:
Additionally, questions about data center applications should be addressed in the SLA, including:
Implementing Consolidation StrategiesThe focused goals of the Federal Data Center Consolidation Initiative (FDCCI) as outlined by then Federal CIO, Vivek Kundra, in February 2010 were and still are:
Expectations and deadlines were also set about the then voluntary changes to data centers. Given that most agencies and departments did not meet these milestones, the initiative became law when the Senate passed the Federal Data Center Consolidation Act of 2013 on September 18, 2014, requiring agencies to perform inventories and implement consolidation strategies by firm dates. All affected agencies share the same target (their desired “to-be” state), which is to achieve the mandates laid out in the FDCCI. They must create individual strategy maps to meet their goals, while creating joint definitions of migration success and streamlined communication along the way. Key considerations include:
Monitor and Evaluate ProgressThe PortfolioStat Integrated Data Collection (IDC) Consolidated Cost Savings and Avoidance report established by OMB is now considered the official method for agencies to report on their data center consolidation and spending and energy consumption optimization. Use of this report will help agencies monitor and evaluate their progress of data migration efforts and give insight into what changes need to be made to make their processes and procedures more efficient. The secret to meeting FDCCI initiatives lies with a well-prepared and constantly evolving SLA to gain perspective into gaps between the insight (as-is) and the strategy (to-be), enabling agencies to understand their current state, determine where they need to be and develop plans to get there. By asking the right questions and taking strategic action, agencies can effectively report on inventories and implement consolidation strategies. Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library. |
|||||||||||||
![]() |
![]() |