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 – FinOps is NOT a special persona
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 does not understand that any firm using AWS, or any other cloud is a technology company which is vastly different from the companies present in the 19th century. In other words, while he may have heard that there is a new thing called the public cloud, he fails to understand that it fundamentally changes the corporate structure and culture.
Instead of adjusting the entire firm Storment introduces a new corporate persona, FinOps, and 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.
Notice in the below chart that Storment’s FinOps persona is of equivalent weight as C-suite, Business or Technology or Finance!
He explicitly states that the engineering team should not consider cost optimization, even though his book is built upon very few widely known concepts anybody can and should understand. It’s unclear how anybody can use AWS or any other cloud without understanding the consequences of their choices – would you allow your employees flying supersonic fighter jets without any training whatsoever and instead, you would set up a committee to review the jet crashes after the crashes themselves? He fails to understand that to make 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 roles, artificial work and artificial problems which would have never existed if the engineering itself were cost-aware.
Failure #2 – FinOps is NOT the principal business driver
The book views the FinOps domain as the principal business driver (“the role of FinOps it to make money” ?!?), 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.
In fact, the entire book and FinOps Foundation are obsessed about corporate power and the design of such corporate structures which ensure Storment’s FinOps Teams are the ultimate decision makers.
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.
All referred concepts are covered at the most basic level, if at all, providing no insight whatsoever into if, when, how and in concert with what they would be applicable.
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 #6 – Likely Intellectual Property Breaches
The book frequently quotes messages from the FinOps Foundation’s internal (i.e., not public) Slack, community members’ presentations and other materials, sometimes without proper attribution.
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 #7 – 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?
See the FinOps Foundation Premier Member Conditions:
There is no annual report which would explain the revenues, expenses, salaries to mitigate at least partially the conflict of interests. Has FinOps Foundation joined the Linux Foundation to avoid the legal requirements for publishing annual reports?
Summary
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, implicitly sells them FinOps Foundation’s sponsors’ services they do not need 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.
Storment addresses the complexity of the cloud by increasing it even further by creating unneeded organizational structures which, for some time, hide the actual problems. The real solution to complexity is simplification.
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.
