This is a review of the early version of the book available as of October 2022 – the final book is expected to be published in March 2023.
The book’s apparent aim is to persuade its readers that every single company needs a special, well-funded FinOps team following the FinOps Foundation’s FinOps Framework, comprising at best of the FinOps Foundation certified staff (overpriced) and the entire firm at best certified by the FinOps Foundation as following their vague and unrealistic framework (expensive and meaningless).
However, its messages fail to resonate for the following reasons:
Failure #1 – There are no clear-cut finance and engineering personas
The book is based upon a simplified view of the world where there are distinct, well-defined engineering personas, finance personas and other personas.
Storment focuses on the finance personas – he even produces sample headcounts for his FinOps teams! – who, in effect, are far more like engineering personas since they are supposed to vet cloud architectures of the engineering teams.
He fails to understand that to make the most of the cloud, the engineering itself must be cost-aware and must exhibit cloud-native mindset. See this article.
Storment’s FinOps is reactive, while one should always be pro-active. In other words, adopting Storment’s framework would lead to creating artificial work and problems which would have never existed if the engineering itself would be cost-aware.
Failure #2 – FinOps is NOT the principal business driver
The book views the FinOps domain as the principal business driver, rather than a small part of the cloud architecture field where it belongs to – this leads to the situations where Storment et al claim that choice of technologies should be made by the FinOps teams unaware of the context and the associated detailed reasoning. This usually always leads to suboptimal results.
If true, it would require extreme sophistication of the FinOps team which is unrealistic if Storment is even unable to clarify how FinOps forecasting should work, though his FinOps Foundation defines that for his framework’s most advanced stage the forecasting should be about “at least 90% accurate” without defining how he measures the accuracy.
On the other hand, we believe that
- Finance or FinOps should be understood as an enabler, not as the driver.
- FinOps is a small part of the general cloud architecture – the belief compatible with the AWS Well-Architected Framework.
Failure #3 – FinOps is NOT the ultimate universal discipline
Compare the scope of Storment’s term FinOps with the term Cloud Financial Management as used by, for example, AWS:
- Storment’s FinOps comprises all other disciplines, including security, and sustainability (it’s a separate chapter in his book). It’s unclear how Storment’s FinOps can dictate the firms’ environmental policies! For an unknown reason, he omits the RevOps (Revenue Ops). In other words, the scope of Storment’s FinOps is clearly out of proportions, and he is asking for excessive corporate power without bringing any value back.
- On the other hand, Cloud Financial Management’s ambitions are much smaller – Cloud Financial Management focuses entirely on ensuring your money is well spent and is very prescriptive.
Failure #4 – Inappropriately chosen contents of the book
The book completely fails at identifying the target audience, the level of the detail and the importance of each concept.
It starts with general strategies on how to persuade management to establish and generously fund FinOps teams (!). Then it goes into irrelevant details, like choice of colors for reports, but fails to advise what effective FinOps reports should contain.
The book explains the easy, well-known, and widely published general concepts, such as psychological biases (Anchoring Bias, Confirmation Bias, the Von Restorff Effect or Hick’s Law) at length but fails to deliver on how to apply these within the FinOps domain with realistic examples.
The book omits in full explaining the FinOps domain specific medium to hard concepts, at best it only briefly touches them. It mentions that data quality is a problem but omits any explanation of how to measure data quality or what strategies are best. It does not even include any reference to cloud optimization strategies.
Failure #5 – Lack of Actionable Knowledge
While Storment et al do stress the need for forecasting, unit costs and other noble concepts, the book itself, or even their FinOps Professional certification fail to teach any actionable knowledge.
They do not provide a single example of how to forecast costs or how to calculate unit costs.
This is, in fact, a problem with the entire FinOps Foundation – for example, for forecasting, the FinOps Professional certification’s curriculum outlines obsolete statistical methods used in the 1970s without any reference to how to apply them to real cloud data.
Failure #5 – Likely Intellectual Property Breaches
The book frequently quotes messages from the FinOps Foundation’s internal (i.e., not public) Slack.
The published messages border on or imply violations of confidentiality and / or intellectual property laws / contract clauses.
Therefore, anybody dealing with the FinOps Foundation should be conscious of the FinOps Foundation “strongly encouraging” sharing everyone’s intellectual property and re-publishing them.
Failure #6 – Business Model of the FinOps “Foundation”
While the FinOps Foundation claims:
The FinOps Foundation’s mission is to advance every individual who manages the value of cloud, wherever they are. This is through enriching community connections, advancement through training and education and empowering with best practices.
its relationships with vendors and the associated conflicts of interests, their FinOps Ambassadors programs, compensation of their staff, their certifications, the lack of fresh ideas and other activities raise the question of whether the foundation is actually a foundation.
For example, does the book intentionally omit certain critical concepts since Storment lacks the necessary insights or since they would harm the FinOps Foundation sponsors who are members of their Governing board (!)? Is the FinOps Foundation’s role to provide a marketplace for their sponsors, and offering them confidential intelligence on its members it gathers?
There is no annual report which would explain the revenues, expenses, salaries to mitigate at least partially the conflict of interests.
When assessing any potential future partner to cooperate with or an organization to join, one should assess the rigor they approach any topic and their critical thinking skills since one can usually project these reliably into the future.
This book targets an unsophisticated audience and lacks any specific and actionable information and would not help anybody in implementing FinOps or Cloud Financial Management.
Its messages are diversions from the real problems with the cloud which are caused by not optimal cloud architectures. One should solve the real causes of the problems, rather than their consequences and Storment failed to provide any evidence that he has any real solutions at all.
Consequently, the book fails in providing any substance necessary for persuading any executive to adopt the Storment’s FinOps.
Instead, we recommend focusing on the AWS Well-Architected Framework.