Chapter 25. Connectivity to Other Frameworks

Unless your company was born in the cloud and spends most of its technology budget there, FinOps likely won’t exist in a vacuum, and it will probably not be the only IT management discipline your organization practices.

Most large organizations use a variety of different IT management disciplines to define how they will deliver technology services, to understand the value of the spending associated with them, to accelerate the adoption or delivery curve, and to keep the organization safe from a wide variety of risks.

This chapter lays out a starting path for how to work with the teams in your organization using other IT and technology spending-related frameworks. The focus will be less about the technical intersections between the methodologies (that’s more detail than we have room for here) and more about the ways to work with teams/people who do them. The goal is to work with these other frameworks and disciplines successfully, to complement them instead of overlapping or competing with them. Too often we’ve seen friction between disciplines or offices emerge as each tries to establish power over the other or create influence within the organization. FinOps is not meant to be a panacea to all IT spending problems, but to help enable all disciplines in the organization—including other IT management functions and teams—to manage cloud use and cost effectively.

The exhaustive list of IT-related frameworks is long and—for many of us—confusing. They cover a wide range of IT management areas, such as assets, licenses, financial management, security, development practices, architectural processes, and more.

Here are some of the common frameworks we see alongside FinOps. They typically interact with FinOps in the following ways:

IT Management disciplines

FinOps can share details like what things are running within cloud environments, how cloud resources are configured, and in which locations/regions they are running. Items covered in Chapter 12, including cost allocation, account hierarchies, and tags, are important here.

  • IT Service Management (ITSM)

  • IT Infrastructure Library (ITIL)

  • Configuration Management (CM)

IT Financial disciplines

FinOps can help classify the different types and classes of cloud usage seen within the cloud bill. The needed classifications may also drive your tagging approach. Tracking license usage across cloud environments and the lifecycle of assets are important concepts. They focus on matching the deep data of cloud billing with the existing categories of IT costs provided by other finance frameworks.

  • IT Financial Management (ITFM)

  • Technology Business Management (TBM)

  • Software Asset Management (SAM)

  • IT Asset Management (ITAM)

Information Security / Cybersecurity
FinOps often shares anomaly detection data that may help alert security teams to areas of concern. Tagging standards can help security teams identify the ownership and intended purpose of cloud resources quickly when flagged for review by security processes.
GreenOps
This is covered in detail in Chapter 19.

These methodologies, disciplines, and practices may have been functioning within your organization for many years to help govern specific aspects of IT delivery prior to your use of public cloud. A common a-ha moment is the idea that these other disciplines are not actually equipped to deal with the self-service, on-demand, and massively variable nature of cloud, nor with the sheer volume of billing data it puts out. FinOps isn’t meant to replace these but rather to help deliver the same general outcome: the maximum value for every technology dollar spent, but with a deep domain focus on cloud.

Your organization may be adopting or using one of the many implementations of Agile or DevOps frameworks to help accelerate and coordinate your IT value delivery. Your organization may have enterprise architecture teams leveraging one of the many architecture frameworks to drive how you develop and implement your IT solutions. You may already have a Cloud Center of Excellence (CCoE) or cloud platform team using one of the Cloud Adoption Frameworks or Well-Architected Frameworks from the cloud service providers you use. And you certainly have an information security team focused on ensuring that every product and engineering team maintains a keen focus on cybersecurity requirements and risk.

Tip

Security is a phenomenal parallel to the FinOps team: the security team is not solely responsible for ensuring secure practices around the organization but rather for providing guidance, centralized best practices, and acceleration to the line of business teams.

Not every company will have all of these other groups. In established organizations, the FinOps team may well be the newest of many groups to arrive on the scene (save for GreenOps, discussed in Chapter 19) to help change the culture of the organization and sharpen the value that IT can bring the organization as a whole.

Total Cost of Ownership

Because FinOps is particularly focused on the cloud, you’ll need to engage other teams in the organization to get the total cost of ownership (TCO) for an application or portfolio that exists partly in cloud and partly on premises. All those other costs that you don’t buy through the cloud bill—rent, labor, contracts, and some licenses—and as a result don’t typically end up in your FinOps reporting, are all part of your TCO. Understanding TCO is critical to determining the value from your technology purchases and enabling the nirvana state of data-driven decision making that we discuss in Chapter 26.

There are peculiarities to the cloud that make FinOps necessary—the huge volume of data you’re dealing with, the speed with which it’s coming to you, and the unlimited availability that creates the opportunities for overspending—and that FinOps is uniquely equipped to handle. If your finance team is already managing those monthly or fixed costs of IT, the FinOps team can blend in the cloud costs in a usable format to give the organization a full picture of spend by application, by business unit, by product, etc. The FinOps team can go deeper to provide not only the allocation of that spend but the story of why it is what it is, and unlock potential optimizations that require finer-grained visibility than many traditional IT management disciplines can do, which they need to continue to make IT spending more effective overall.

Working with Other Methodologies and Frameworks

There are a number of steps you should take as you develop FinOps to avoid conflict with other methodologies or frameworks that are already established.

Tip

Over time, as the cloud becomes the majority of IT spend for most companies, some of these existing frameworks may be consolidated to operate as one. Recognize this in the beginning and be on the lookout for opportunities to combine efforts so that your organization gets the most benefit in the long run. Focus on the outcomes that each framework is designed to achieve.

Find Out Who’s Out There

It is not uncommon for a FinOps team to begin their work and then sometime later discover that there are other teams operating other IT frameworks. This can lead to a perception between the teams that each is conflicting with what they are trying to achieve or duplicating efforts. Ideally, you identify who is running which frameworks and functions early on in the process of implementing FinOps. Seek first to understand what each team does and what value they are delivering for the business. Go talk to them, find out what they are trying to accomplish and who is their executive sponsor, and, above all else, begin to build a working relationship.

Make Friends and Share Goals

Create a shared understanding that there is not a competition to see who does the best job. Having an us versus them attitude (discussed in relation to engineering teams in Chapter 24) will only lead to both sides being less willing to collaborate, in the same way it does when FinOps and other teams like engineering or finance see themselves as having opposing goals. The perception is that the success of one can often come at the expense of the other. However, the shared goal should be the success of the organization’s mission.

Overlapping goals between the teams are expected, so clearly defining those will enable a shared roadmap to avoid duplication or, even worse, conflict between them.

Some areas to explore for overlapping goals include the following:

  • Who is supplying the data needed to make timely decisions and how that data allows the business to measure trade-offs designed to maximize business value

  • Which team is responsible for each portion of the IT spend and usage management

  • How IT spend is to be controlled/governed and who defines it

  • How the data, reports, and dashboards each methodology provides will be generated and distributed

Tip

FinOps doesn’t do it all—and it’s not intended to—nor does any other framework. Identifying each framework’s strengths and weaknesses will enable you to identify where you can help each other with the larger organizational goal, with the outputs of one framework solving weaknesses for the other. Drawing up a responsibility chart can help the entire organization understand how each team works together.

Here are some areas where FinOps is often different than other frameworks:

Scope
Other frameworks are often aimed at all IT-related spending, such as staff costs, consulting contracts, license management, and data center operations, whereas FinOps has a specific focus on public cloud and SaaS providers with variable spend costs specifically.
Scale of inputs
Other frameworks often work with a large number of source inputs, each of lower scale but varying in complexity and consistency. FinOps relies upon a limited number of source inputs containing extremely large and complex datasets.
Speed
Other frameworks work best with traditional cost elements that operate on longer business cycles (monthly, quarterly). FinOps is designed to be executed in an action cycle as quickly as possible (hourly, daily) to react to the variability of cloud usage.

A solid combination of frameworks can create a T-shaped approach to technology value delivery. In other words, together they deliver broad visibility via frameworks like ITFM with a wide (but less granular) scope as well as granular domain abilities via frameworks like FinOps with a deep (but less wide) scope.

Share Influence, Terminology, and Processes

Existing framework teams are likely to already have influence over the same personas you will need to influence with the introduction of FinOps, or the growing interest from your organization to introduce FinOps may offer an opportunity for existing framework teams to amplify their impact, as in Ashley’s story about interacting with the SAM team. Teams that have existing relationships across the organization can help introduce FinOps and shorten the process of FinOps becoming a known practice within the organization. Aligning on the common messaging across the frameworks means you end up with a shared voice.

All of you are doing things that:

  • Are not the core business of the organization, i.e., the time and effort spent implementing these frameworks is time and effort not spent building the products that your organization is selling

  • Require work and collaboration on the part of many people throughout the company

  • Are critical to the success of the organization, i.e., without these frameworks the organization will have challenges that will negatively impact its success

Aim to build a shared influence across your company that both expresses the importance of each relevant framework and helps support why both are required for the organization’s success.

To implement any of these frameworks, there are datasets, reports, and education of domain-specific terminology required. Before implementing a new policy or standard upon your organization, you should identify existing policies and standards that can be reused or repurposed. Need a tagging plan? An existing framework team like ITFM, TBM, ITAM, DevOps, or your CCoE may already have some allocation rules defined. Leaning on existing processes and knowledge in the organization will make things simpler and speed up the process of building a mature practice. Perhaps more important, adopting terminology and definitions that are well known inside your company is much easier than trying to create new—and potentially conflicting—uses of similar terms.

Share Infrastructure

Remember the concept of putting data in the path of each persona, covered in Chapter 8. Existing frameworks are likely to have existing reports and dashboards that engineers, finance, and leadership are already using. Instead of making new reports and dashboards, you should align with the teams who own these existing reports and add the FinOps messaging. If ITFM reports are already a part of your executive reporting processes, aim to add deeper cloud data via your FinOps practice to those reports. Don’t try to reinvent the wheel. Sharing existing reports and dashboards both reduces effort in establishing FinOps reporting and avoids extra effort being required by the relevant personas across your organization.

Share Knowledge

FinOps is an integrative discipline that ties together the work of many other disciplines in your organizations, so there are several key disciplines that have key similarities to FinOps. Oftentimes practitioners of these disciplines describe FinOps as “my discipline, but for cloud.” But there are important differences in cloud, which is why FinOps needs its own focus in most organizations.

Tip

Without understanding the strengths and weaknesses of existing frameworks that we discussed in sharing goals, it’s easy to trivialize what each is and what it can achieve for your organization. For FinOps, it is a mistake to think that existing frameworks have nothing to offer. Plenty of the activities they already perform will be delivering value that can be leveraged by FinOps. Sharing education programs, outreach, and evangelism builds a common understanding of each other’s frameworks; this will enable all teams to have a shared appreciation for the others’ frameworks.

Conclusion

FinOps is about building bridges, not walls. All IT management methodologies have a common goal of helping the business get the most value out of IT spending, but they approach it from different angles, and some are specialized to target certain types of IT spending.

To summarize:

  • Seek to identify teams inside your organization that are operating other frameworks.

  • Aim to align and complement teams in your organization managing other frameworks. You all have something to learn from each other and will find areas where you can support each other.

  • Work together to both avoid duplication and empower each other’s goals.

  • Decide which team will be responsible for each component of overlapping responsibility.

  • Build consistency in your messaging inside your organization around cloud spend and business value decisions.

Now you have an understanding of how to build relationships and truly collaborate with engineers, finance, and the many other groups your FinOps team will work with. Now it’s time to make those relationships pay dividends.

This brings you to what we like to call FinOps nirvana. The penultimate chapter will encapsulate everything we’ve discussed so far that enables you to achieve the ultimate goal: enabling data-driven decision making.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset