How has ReluTech adopted AWS’ “working backwards” philosophy?
In my last article, I mentioned the working backwards philosophy; a value creation method where the problem solver begins at the finish line and reverse engineers the process back to its original position. For AWS, this led to the creation of the enterprise public cloud platform and ultimately invented the consumption model for on-demand computing for Andy Jassy and Jeff Bezos. In this article, I’ll discuss how ReluTech has implemented this logic to improve the migration bubble’s financial constraints on the adoption of the public cloud.
In 2013 our Founder & CEO, Mark Metz, and I started a working session we would ultimately name the Migration Bubble Buster Strategy. This “think big” session was designed to begin as a customer’s workload was seeded on the AWS platform and be completed when the customer’s hardware assets were either consolidated or evacuated from the data center. We then identified the most significant barriers of entry to cloud adoption (as it relates to data center hardware) and how we could eliminate these considerations for the prospect and/or customer. As with almost all services led engagements, we ultimately needed to discover how to reduce the overall project timeline which, in turn, would lower overall project costs; solely focusing on the consolidation or evacuation of the data center assets.
Having more than twenty years of professional experience in the data center, I began to evaluate asset lifecycle management strategies of end users and their refresh cycles. Working backwards again, I identified specific segments in the hardware lifecycle that could prevent an end-user from decommissioning hardware and porting the workloads associated with that hardware to AWS. Below are the three key findings. As I move through this series, I will discuss in greater detail how to remediate these considerations from your journey to AWS.
IT Divesting
Investment in data centers leave companies with tremendous technical debt, with few options to reset their technology strategy, as asset values rapidly decline over short amounts of time. With average depreciation schedules averaging 5 years, CFO’s will often prevent transformation until all systems are fully depreciated. Monetizing these assets before a migration begins not only offers options to fund migrations but can also provide the ability to write down a portion of the book value.
OEM Refresh Avoidance
Hardware refreshes are almost certain to delay cloud adoption. Purchasing new equipment, only for it to be decommissioned in under 5 years, likely delays the financial advantages of moving to AWS. Exploring the secondary market as a procurement vehicle for enterprise data center infrastructure should be the goal. With identical configurations and parts, a single generation-old hardware device can offer a reduction from the OEM list price by greater than 75%.
Elastic Maintenance
Companies, on average, spend 15% of their total IT budget on break fix service contracts from the OEM’s. While this is a brilliant selling tactic from the equipment manufacturers, as it drives behaviors of end-users to buy new hardware with services contracts embedded in the purchase of that equipment, it’s certainly not an advantageous position for end users. These expensive annual maintenance agreements likely consume IT budgets that could be repurposed to AWS transformation. Third party support options not only allow customers to begin divorcing themselves from their OEM relationships, but they are offered at a fraction of the price while maintaining the exact same service levels.
