Oliver Assad · 2026-10-22 #domain:manage#intersecting-disciplines#governance
Why?I see many posts about cross-functional forums, Cloud Centers of Excellence, and "shift-left FinOps". The idea is interesting. A group with engineering, security, finance, and procurement should make cloud decisions faster. But I doubt it. Does a meeting really remove the cost of 1:1 messages? And who decides when many disciplines sit together?Intersecting Disciplines is the FinOps Framework capability that coordinates FinOps with related disciplines, called allied personas, that manage technology responsibilities.1 Examples are IT asset management (ITAM), IT financial management (ITFM), sustainability, and security. The capability does not tell FinOps how to do their jobs. It tells FinOps how to work with them. For example, before FinOps proposes bring-your-own-licence (BYOL) for a database, it asks the software asset management (SAM) team. The publisher contract may change.1I call the cost of 1:1 asynchronous messages the Ping Tax. An architect asks Security in one thread, and FinOps asks about the same design in another. Each answer stays in its thread, so the next team repeats the debate, and the decision arrives late.noteTL;DR 1. How do we hold all the experts at one table, so every decision gets advice from every discipline, without burying people in one-to-one asynchronous messages? 2. Can we adjust the processes we already have, such as tickets and architecture reviews, to carry issues to that table? Can they turn those issues into recorded decisions?
The StructureHow do we build a structure that holds all the experts at one table? The answer is not a new thing to invent. The answer is simple: bring all the experts to one table for a quick discussion, instead of sending asynchronous messages. Other fields already do this, and each form teaches something.The TOGAF Architecture Board teaches the executive sponsor and the small group. That is the TOGAF 7 text (The Open Group, 1999), and newer versions may differ. The SAP LeanIX wiki describes a review board of architects plus security, compliance, and business members, so non-architects belong at the table. The AWS Well-Architected review teaches the tone: blame-free, hours not days, and a conversation, not an audit. A guild teaches that a community can be voluntary and cross teams.A Cloud Center of Excellence (CCoE) is a group that leads cloud adoption, migration, and operation, and AWS lists cost optimization among its duties.2 Microsoft's roundabout image teaches guardrails, which are rules teams self-serve under, over gates, which make each request wait.3 Sources disagree on where FinOps sits, so the table can sit inside or next to a CCoE.4 Sources also warn of three failures, mostly as opinion: a bottleneck, bureaucracy, and part-time staffing.Who sits at the table? The Foundation's personas page names Procurement as a core persona. It does not list Enterprise Architecture or Platform as allied personas.Still, one cloud decision can touch ITAM, ITFM, security, sustainability, architecture, platform, procurement, finance, and product. Each seat asks one question about the same decision. That is an inference from each mandate, not a published rule. FinOps answers with cost data and estimates.Overload is the risk. A table with every discipline at every meeting would waste time. So the standing group stays small, and other experts take a seat only when an item needs their discipline. The coordinator decides who joins.So what do we conclude from the structure? Use a community of experts, which is a standing group that meets on a fixed rhythm. Attach it to the setup the company already has, such as an architecture board or a CCoE meeting. Create a fresh community only if none exists. Then widen its seats, so FinOps and the other disciplines are in.
The Communication ChannelWhat can we borrow from the processes we already have? IT service management (ITSM) and its tickets are the inspiration. A request enters one queue and moves through states, so everyone sees where it stands.If the company already has an ITSM workflow, add one step in the middle. The ticket then grows in three parts as it moves. The requester states the business goal, with no technology. The architect adds the design, and FinOps prices the alternatives. The round table adds the resolution, and this three-part form is a proposal.The ticket goes to the coordinator, who leads the community, for example an enterprise architect. The coordinator checks that the parts are complete. Then the coordinator triages the ticket by importance, assigns the roles that must join, prepares the agenda, and sets the dates. The next round table then discusses the ticket.The minutes record the decision, and the action points go back into the ticket flow for execution. If no ITSM workflow exists, a simple shared board does the same job.Not every problem has a money value, so there is no money threshold. The coordinator decides: a small, standard request that needs no discussion goes straight on without the table.The minutes follow the idea of an Architecture Decision Record: a status, a confidence level, and no edits to an accepted record. A changed decision gets a new record. Microsoft advises this for decisions that affect structure or quality or are hard to reverse. The minutes also name the owners and a review date.The round table lasts one hour and decides only. The pre-read goes out the day before, and the coordinator cancels the meeting when nothing is pending. Each expert answers for their own discipline with yes, yes with conditions, or no. The coordinator does not vote. If two disciplines still disagree, the coordinator escalates to the executive sponsor, because the Framework names Leadership as the final escalation point.1The AWS sample CCoE charter shows weekly governance meetings.2 Microsoft says to minimize dedicated meetings as a CCoE matures.3 No source tests decisions-only meetings or pre-reads, so these are a proposal.In short, the channel reuses the processes already in place, with one extra step.
In PracticeA team can set a tagging strategy, buy a tool, or write AI rules on its own, without the round table. But when the team is unsure, or needs the opinion of more than one party, it brings the case through this structure. It contacts the coordinator, the chair of the community, and the coordinator organizes the parties for the discussion. The rule of thumb: if you need an opinion from more than one party, use this structure.Three generic cases show the path. Onboarding a New Tool: A team wants a tool and is unsure whether to buy, reuse an existing tool or alternative, or build. The requester raises a ticket and presents the case to the round table. The coordinator invites ITAM, Procurement, Engineering or Platform, and FinOps. ITAM checks existing licences, and Procurement covers vendor terms and renewal dates. Engineering or Platform says whether the platform already covers the need. FinOps compares the cost of build and buy. It also notes that a marketplace purchase may or may not draw down the cloud commitment, so check each cloud's rules.5 The round table decides to reuse, buy, or build, and the minutes name the owner. The ticket then goes to the next round table for security clearance before purchase. Agreeing on AI Governance: The AI owner, such as the CCoE, wants two or three AI rules, for example on data, vendors, and cost limits. It first wants input from the others. So it brings a draft of a few rules, not a complete rule set, and asks for opinions. The coordinator invites Engineering, Security for data, Legal for licences and IP, Procurement for model vendors, Finance, and FinOps. Each gives a view on the draft rules. FinOps adds the unit cost per request or token, and notes that GPU capacity is scarce, according to the Foundation's AI paper. The group adjusts and agrees the rules. The minutes record them with an owner, and later AI cases are checked against them. Setting a Tagging Strategy: The platform or FinOps lead needs a tagging strategy that many disciplines read, but is unsure which keys each wants. The lead presents a proposed key set to the round table. The coordinator invites Security, Compliance, architects, Platform, Finance, and ITAM. Each asks for the keys it needs: a cost center, a data classification, an owner for scripts, and perhaps a licence key. The licence key is a proposal, because no source names one. One trap matters: never put personal data in tags, because tags reach billing.6 The group agrees the mandatory keys, one owner per key, and enforcement at creation. It starts small, and the minutes list each key with its owner.Each case follows the same path: ticket, coordinator, round table, minutes.
ConclusionThe first question asks for a structure. The answer is a community of experts. It attaches to an existing setup, such as an architecture board or a CCoE, and it has seats for FinOps and the other disciplines.The second question asks for a channel. The answer is the ticket flow the company already has, with one extra step. The coordinator comes first, then a one-hour round table, then minutes and action points. Together they answer the Ping Tax with one table, one queue, and one record.The design has limits. A table that approves every change becomes a bottleneck, and weekly meetings tire experts, so the cancel rule matters. A small company can reuse an existing forum, as the Foundation advises.4 No source tests this exact design, and none measures its benefit.Here is my own view. I believe this helps most where a decision crosses three or more disciplines and a wrong call is costly. This is not a new invention. It extends well-proven concepts, such as architecture boards, CCoEs, tickets, and decision records, and it has no rigid rules. Principles give the structure and the process for collaboration between disciplines. In the end, that is what FinOps brings: a culture that bridges communication between different communities.