FinOps: 101

In our ever-changing techno-sphere, one unyielding fact must be kept at the top of mind (and this is a purely economic bias): nothing matters if it doesn't support the parent organization in keeping its promise to its client base. Our mental models and frameworks excavate the 'business diamond in the rough'. The models and frameworks are the maps and the technology/processes that implement the intent behind these frameworks are enablers.

FinOps is one such framework.

Who is responsible for FinOps?

Short answer: Everyone.

The longer answer is the CIO, the CTO, the Engineering Manager, the Product Analyst, the Data Architect, the Business Analyst and the list goes on.

The size of a business should not deter the adoption of FinOps frameworks, nor should the size of the team. FinOps practices should be implemented throughout an organization, albeit with appropriate tooling and processes at each level.

FinOps teams require Cloud expertise to build trust.

Since FinOps is used to determine resource allocation, it can become a contentious area for discussion. The 'suits', as business teams are sometimes pejoratively called, can be blamed for making decisions about technologies they have little to no experience in. Of course, the assumption here is that the 'suits' don't know or understand the world of Cloud Computing (and to be honest, this is not an unfair opinion). Therefore, a FinOps team MUST include cloud expertise and this can (will?) lead to more trust in their decisions.

FinOps teams MUST standardize semantics and language.

Language is undoubtedly the most potent tool in our arsenal. The right word, with the right meaning used at the right time, can lead to fabulous (and sometimes, unexpected) outcomes. Each team within an organization likely uses discipline-specific terms, views cloud billing data from a different perspective, and has separate motivators for what they want to achieve.

FinOps teams should have, at least, these 3 functional categories.

Category # 1: The technical teams who need infrastructure.

Category # 2: The analysts who assess the validity of the technical team's claims.

Category # 3: The communicators who evangelize and demonstrate the benefits of FinOps for the rest of the organization.

Category # 1: 'The Patient'

The Engineers: They are best situated to provide nuance and rationale to any architectural decisions made, their cost implications and how to best govern the changes to the infrastructure.

Category # 2: 'The Doctor'

FinOps Governance Analysts: They create the policy for FinOps, identify and confirm OKRs and KPIs, and are responsible for FinOps program governance.

Financial Analysts: They use their understanding of Finance and Accounting to pick out areas of cost overruns, develop more insightful cost models, and are the custodians of billing and spending trends/forecasts.

Category # 3: 'The Promoters'

Trainers and Change Managers: Any organizational change requires an announcement be made and additional support in the form of training materials and education will be developed.

For FinOps to be successful, all stakeholders (however removed they may be) should be open and willing to accept the FinOps mindset. Only then can one expect the confusion and ambiguity of this discipline to be mitigated.

I write to remember and if in the process, I can help someone learn about Containers, Orchestration (Docker Compose, Kubernetes), GitOps, DevSecOps, VR/AR, Architecture, and Data Management, that is just icing on the cake.