Think You’re Achieving Full Cloud Cost Savings With Tools? Think Again.

IT Benchmarking

How companies are partnering with a service for true end-to-end process support that brings full cloud cost savings

48% of enterprises plan to keep spending steadily on cloud, according to IDC research, making cloud costs a focus for IT leaders. And, the majority of organizations believe they’re overspending on cloud.

The first blog in this two-part series described how tools may provide an opportunity to reduce costs. But as many organizations are aware that they need to improve their cloud spending habits, the process that it takes to get there often seems exorbitant, causing them to instead disregard the changes needed to turn their cloud spending around. This blog intends to show that the time and resources involved in executing shouldn’t deter companies from making the necessary changes. 

From insights to process, these two companies found that hiring a partner to guide them through the work needed to transform their cloud costs, in ways that were custom to their needs, made all the difference in ensuring that they not only followed through on executing a plan of action but giving them a successful outcome. 

An international telecommunications company has migrated its entire infrastructure to the public cloud (AWS and Azure) and uses a broker towards AWS and Microsoft, performing contract management and basic security services. For both providers, a System Integrator (SI) has been contracted to provide managed services (IM and TAM) on top of the cloud providers.  

During the migration, cloud costs rose above the available budgets that had been set, based on advice by the SI’s. During migration, the SI’s focused on the project deadlines rather than optimizing and saving on what was already running in the cloud. The telecommunications company turned to IDC Metri for independent advice on cloud cost savings. 

IDC Metri has helped to improve tooling, and to define processes and ways of working, for this telecommunications company to analyze and manage cloud costs themselves. IT leaders can learn from their experience that recommendations from tools, including those from cloud providers, aren’t always realistic. They tend to be opportunistic, like suggesting that all instances should be reserved for three years, and that this will save over 50% of costs for those instances. That is the same as expecting your IT landscape to remain the same within that time – this is simply not true. 

PostNL has been one of the first listed companies in the Netherlands to go ‘all in’ to the public cloud, starting in 2012. Nowadays, PostNL is in the second stage transforming all of its bespoke applications from IaaS to PaaS solutions, like BI/Analytics platforms, container platforms and serverless computing. When compared to IaaS, price models for PaaS are more usage based than capacity based. Saving costs on usage-based priced services means optimizing the software, rather than the underlying infrastructure. 

Unlike the anonymous international telecommunications company in our example, PostNL doesn’t have SI’s in-between them and the cloud providers that offer managed services. The application teams, mainly DevOps based, are managing the cloud infrastructure themselves. Also here, cloud costs had an upward trend, from which PostNL has asked IDC Metri to bend it. 

IDC Metri has made recommendations, which were much less supported by tools, since these focus on IaaS, rather than PaaS. With the top 10 teams concerning costs, alignment has been done on savings, which has led to about 8% savings. A must know here is that large scale optimizations, such as applying savings plans, had already been done by PostNL itself. The savings IDC Metri helped to achieve were more on architecture and licenses. 

In conclusion, using tools that generate recommendations is only the starting point for achieving savings. First of all, the recommendations need to be taken with a grain of salt since they tend to be rather opportunistic. Furthermore, a list of recommendations is one thing, to actually achieve savings, hereby overcoming indifference or even resistance to save costs, is another thing. IDC Metri does support the full process, from analyzing costs through setting up processes to actually achieving savings. 

Can’t wait until the next blog is published to learn more about cutting cloud costs? Contact us to schedule a conversation. 

How Agile Development Teams Can Resolve Agile Measurement Challenges With Function Point Analysis

IT Benchmarking

Agile development empowers teams with many benefits but also presents challenges around managing and measuring its effectiveness. The way to resolve these is Function Point Analysis.

From business impediment to business enabler, IT development has come a long way since Agile has become the favored practice. Now empowered with speed and responsiveness, organizations have left the days of slow, cumbersome, inflexible, and unresponsive practices behind in the dust. Instead they’re able to support business needs and experience better alignment with changing business environments better than ever before. 

It’s easy to understand why Agile is experiencing a strong increase in adoption; as companies become more nimble to embrace the pressures they’re facing in digital transformation, IT development is able to respond aggressively to evolving competitors and exploit markets more easily. But these benefits rival the frustrations on the management side of Agile teams. The nature of Agile makes it so that IT has lost visibility and scope control while the business has lost predictability. While Agile might make teams fast and responsive, businesses don’t know when projects will be delivered, and quality of delivery is often poor. 

This is due to story points. Story points is a relative and subjective effort measurement that allows teams to estimate how much work of a certain item is required compared to a certain reference story with a fixed number of points. Story points can be used as an assessment method within a team. But how do these points happen? In an Agile Scrum environment, productivity is often associated with delivered story points, often expressed in Velocity as an estimation unit. The problem is that story points are not standardized, and productivity based on story points means nothing outside of a team itself. Even within a team, story point deflation is always lurking. 

Is it even possible to objectively measure productivity? This blog will show that using a ratio scale is the way to objectively measure productivity as proven by IDC Metri’s years of helping clients turn around this common challenge. Management information can be established through a ‘unit of measurement’, bringing answers to long-sought after questions such as which teams are performing well, which teams are not performing so well and when is which functionality ready at what cost? 

If you want to use productivity to compare teams, departments, organizations and/or suppliers, or the market, it’s a necessity to use a standard measure of output. Even when this data is about trends on your teams, this insight creates a unified and common view.  

For years IDC Metri has been offering function points to create this factual view to clients. Function point analysis was developed in the 1970s to determine the productivity of development teams when it was impossible to do this by counting lines of code. By making function point analysis independent of the technical implementation (programming language, architecture, etc.) and the development method (Waterfall, Agile, etc.), it’s also relevant today and fits into the solution that Agile teams and management need to resolve the challenges that story points create. In short function points are the de-facto standard to express the amount of functionality in a standardized size unit. 

Several manual standards are available and one international ISO standard is available for automated function point analysis: ‘Automated Function Points (AFP)’. IDC Metri prefers to use automated measuring of functional size but also employs certified analysts who can manually measure when automated measuring is not possible for whatever reason.  

To measure the size of the output of a team, it is also important to not only look at the added functionality but also at the changed and removed functionality. IDC Metri uses automated measuring of ‘Enhancement Function Points (EFP)’ to measure how much functionality has been added, changed and/or removed during a sprint, release or project. This gives the ‘Project Size’ in EFP, a standardized method to measure the output of a sprint or release. 

While Agile is hard to measure and manage for full value, the IDC Metri proven approach of using function points transforms a team-driven, fast-moving, rapid iteration process that evaluates progress on qualitative measures into something that can be quantified and predicted. 

Looking to learn more about Objective Measurement vs. Story Points? Download the IDC Metri eBook How to Measure Business Value for Agile Teams.

Contact Us

Interested in learning more about IDC Metri?