In the early stages of cloud technology, many organizations began to rely on Cloud Service Providers (CSP) for services like computing, storage, and disaster recovery. While these services were largely individual workload pilots in isolated environments, which kept CSP usage small, organizations nonetheless sought ways to monitor, optimize, and govern their enterprise cloud spend.
To meet this need, an ecosystem of Spend Optimizer Tools (SOT) arose, which were quickly incorporated as business and technical qualifications required for contract awards. These SOTs became a core component of most cloud engagements, regardless of size and scope. Although business models varied, a consensus developed that most SOTs would charge based on a percentage of the underlying CSP usage. For instance, a popular SOT platform within a Software as a Service (SaaS) offering was priced at 2% of the CSP monthly spend.
For organizations deploying a small workload—spending $10,000 per month, say, with a $200 SOT charge—this was considered good value and return on investment for the features and efficiency that were delivered. As CSP usage grew, however, the 2% charge for a SOT became unsustainable for many customers. Moreover, organizations soon realized that while some core features and functions proved extremely useful, others did not add enough value to justify their cost.
Making a Plan
We began by developing a value proposition for the ideal SOT, a tool that would allow its users to gain insight and visibility from an enterprise data view across multiple CSP platforms, enabling deeper understanding and better decision-making. We also sought a tool to measure governance policies and compliance to standards.
With these needs defined, we identified three potential routes to achieve the ideal SOT, each with its own advantages and pitfalls. First, we could continue to purchase the SOT, which would provide immediate utility, but at the expense of valuable margins. Second, we could hire a firm to develop the SOT, which would require an initial investment, as well as the opportunity cost of not funding sales expansion plans. Hiring an outside firm also risked vendor lock-in for operations and maintenance (O&M) and ongoing support. Third, we could build our own SOT, using internal staff during non-core hours and weekends. While this solution would not require an upfront investment, it also risked a lengthy time to market, impact to operations, and ongoing investment in product development.
Our team analyzed these three routes in a decision matrix, ranking each in terms of probability, impact, cost, and value. We tested and validated this model using internal and external data, including soliciting input from customers and other stakeholders. After completing this analysis, we opted for the third option, assembling a team of internal personnel with the personal drive and desire to build the SOT solution.
Crafting a Solution
To begin, our team created a roadmap focused only on core features and functions that we had identified as high-value in an SOT. These included:
- Real-time, multi-CSP metrics, including usage and billing data, in a centralized management portal dashboard
- Aggregation of enterprise-level visibility across multiple CSP platforms
- On-demand reporting, emails, and alerts to identify daily spend, spending trends, and anomalies
- Detailed billing reports, cost analysis functions, usage metrics, and ad-hoc business intelligence queries with real-time billing data
- Data export functions that work with any business intelligence service
- Full compliance for physical, sensory, and cognitive disability use
- Standard Identity and Access Management (IAM) platforms for integration into existing legacy environments
We also created a supporting schedule, milestone deliverables, cost investment model, and government and change management structure, all of which provided clear guidelines and a framework for the full lifecycle of the project.
By defining these parameters at the project’s outset, our team avoided an ongoing product development investment and undue distraction from our core business. To limit delay to market, we relied on the same Agile software and framework that we use for customer projects. Our team first focused on implementing basic core reporting requirements—the most important need, both internally and for our customers—after which we continued to build out the rest of the product. Ultimately, we were able to release the SOT on time and within budget, meeting all investment and market-value objectives.
Deploying the SOT
Once our team built out the core reporting requirements, we released the SOT to our customers. To offset functionality gaps, we did not charge customers for its use, thereby achieving an immediate price advantage in the market. This release allowed our customers to benefit from the most vital features right away, without incurring additional costs.
The SOT enabled ECS to eliminate third party tool costs and invest that funding to support our growth and expansion. We proposed the SOT in competitive bids, using its features and price advantages to win the largest cloud contract in our history—a customer that remains to this day.
Rather than creating a product to emulate our competitors, ECS designed a solution based on our needs and those of our customers. By defining success for all stakeholders, including customers, from the get-go, our team was able to build and deploy the ideal SOT within all time and budget constraints. The roadmap served as our true north when faced with unforeseen roadblocks and challenges, allowing us to adjust as necessary without sacrificing key success criteria.
Overall, this was a process of reviewing options, understanding costs and benefits, and mitigating risks within a framework that allowed for frequent testing, validation, and flexibility. ECS delivered our solution by relying on a dedicated team with a shared vision. This methodology now serves as our corporate model for innovation, as well as a primary driver for learning, transformation, and development within the company.
