FinOps starts with architecture, not accounting – TechTarget
From workload design to unit economics, CIOs need to make cloud costs an architectural requirement alongside performance, security and resilience.
For years, cloud cost management was treated like something that happened after the real work was done. Architects designed the systems. Developers built them. Operations kept them alive. Then, a few weeks later, finance showed up with a cloud bill that looked like it had been assembled by a slot machine.
That was usually when the panic began.
I’ve been in those meetings. Someone from finance would ask why a storage bill doubled. Someone from engineering would explain that the data was needed for testing, analytics, compliance or “just in case.” Someone from leadership would ask who approved it. Then everyone would stare at each other because, technically, nobody did.
Accounting can tell you what you spent. It cannot redesign the architecture that caused the spend.
The architecture allowed it, the cloud platform happily provisioned it, and the invoice simply reported what had already happened.
That is why I keep saying FinOps cannot live primarily in accounting. Accounting can tell you what you spent. It cannot redesign the architecture that caused the spend.
FinOps now belongs in architecture because cloud cost is no longer just a financial outcome. It is an architectural characteristic, right alongside performance, security, resilience and scalability.
In traditional data centers, many infrastructure costs were hidden behind procurement cycles and capacity planning. You bought hardware, depreciated it, and argued about utilization later. With cloud, every bad design decision has a meter attached to it.
Overprovision a database, and the bill knows. Move data constantly between regions, and the bill knows. Choose the wrong storage tier, and the bill knows. Build chatty microservices across availability zones without understanding traffic patterns, and the bill absolutely knows.
I once worked with an enterprise that was proud of its cloud migration because the project had finished mostly on time. That pride lasted until the first full quarter of operating costs landed.
The applications worked, but they had been lifted and shifted into an environment where inefficiency was now charged by the hour. Servers that used to sit quietly underutilized in a data center became expensive virtual machines running all month. Old batch jobs moved huge amounts of data through expensive paths. Test environments stayed on because nobody owned the shutdown process.
Finance saw a cost problem. Architecture saw, or should have seen, a design problem.
That distinction matters. If the only response to cloud overspending is “cut 10%,” you get panic-driven optimization. Teams turn things off, delay projects, fight over budgets and sometimes create new risks. If the response is architectural, you ask better questions. Why does this workload run this way? Why does this data move so often? Why are we using this service tier? Why is this environment always on? Why did we design for peak capacity instead of elasticity?
Those are architecture questions, not accounting questions.
Rising cloud costs don’t necessarily signal inefficiency. CIOs should consider:
• Growing demand: More customers or transactions can justify higher spending.
• Improving efficiency: Total costs may rise even as the cost per transaction falls.
• Business value: Better performance, resilience or new capabilities may justify the expense.
Compare spending growth with changes in usage, unit costs and business outcomes before deciding whether to cut costs or redesign a workload.
One of the best shifts I’ve seen in mature cloud organizations is the move from total-cost thinking to unit-cost thinking. Total cost tells you the monthly bill. Unit cost tells you what it costs to serve a customer, process a claim, complete a transaction, train a model, stream a video or run a report.
That is where FinOps becomes useful to architects.
But if the cost per transaction rises as volume increases, something is wrong. The architecture is not scaling economically.
If a retail platform spends more during the holiday season, that may be fine if revenue scales with it. If a data platform costs more because more customers are using analytics features, that may be a good trade. But if the cost per transaction rises as volume increases, something is wrong. The architecture is not scaling economically.
I’ve seen this surprise teams that thought they had built scalable systems. Technically, they had. The systems could handle more demand. But financially, they scaled badly. Every new customer triggered more compute, more storage replication, more logging, more network transfer and more managed service consumption than anyone expected.
That is not a finance issue. That is architecture failing to understand the economic behavior of its own design.
Architects need to model cost the way they model latency or availability. If we choose this database, what happens when the workload is 10 times higher? If we retain logs for a year, what does that mean at future volume? If we put services in multiple regions, what is the cost of resilience? If we adopt a managed AI service, how does usage translate into spend?
Those questions belong at the whiteboard, not after deployment.
I have nothing against cost optimization projects. They can save real money. Rightsizing instances, deleting unused volumes, adjusting commitments, improving tagging and cleaning up zombie resources are all useful. But if that is your entire FinOps practice, you are basically running cloud janitorial services.
Important? Yes. Strategic? Not enough.
The real savings happen before the system is built.
They happen when an architect chooses an event-driven pattern instead of always-on polling. They happen when a team selects the right database for the access pattern instead of picking the fashionable one. They happen when data retention is designed around actual business and regulatory needs instead of infinite hoarding. They happen when environments are ephemeral by default. They happen when developers have paved roads that include cost guardrails from the beginning.
I once reviewed a cloud-native application that looked modern on paper. Containers, managed services, automation, the works. But the architecture generated massive amounts of telemetry, pushed it into expensive storage, replicated it broadly, and retained it far longer than needed. Everyone agreed observability was important, and it is. But nobody had asked what level of observability the business actually required for each environment.
The fix was not to tell finance to negotiate a better bill. The fix was to redesign the logging and monitoring architecture so it matched operational value. Keep the right signals. Reduce noise. Tier storage. Shorten retention where possible. Make debug-level data temporary.
Suddenly, FinOps looked a lot like good architecture. Because it was.
Every architecture review I run or advise should include cost as a first-class nonfunctional requirement. Not as a vague statement like “must be cost-effective,” which means almost nothing, but as something measurable.
What is the expected monthly operating range? What is the cost per unit of business value? What utilization assumptions are being made? What is the cost impact of failover? What happens if traffic doubles? What spend alerts and automated controls are in place? Who owns the cost of shared services?
These questions should sit next to availability targets, recovery objectives, latency requirements and security controls. If a system has an availability requirement, it should have an economic requirement. If it has a data architecture, it should have a data cost model. If it has a scaling strategy, it should have a scaling cost curve.
This does not mean architects need to become accountants. It means architects need to understand that design choices create financial consequences.
Accounting can report those consequences. Architecture determines them.
David Linthicum is a globally recognized thought leader, innovator and influencer in AI, cloud computing and cybersecurity. He has more than 30 years of experience in enterprise technology and, until early 2024, served as managing director and chief cloud strategy officer at Deloitte Consulting LLP.
For years, cloud cost management was treated like something that happened after the real work was done. Architects designed the systems. Developers built them. Operations kept them alive. Then, a few weeks later, finance showed up with a cloud bill that looked like it had been assembled by a slot machine.
That was usually when the panic began.
I’ve been in those meetings. Someone from finance would ask why a storage bill doubled. Someone from engineering would explain that the data was needed for testing, analytics, compliance or “just in case.” Someone from leadership would ask who approved it. Then everyone would stare at each other because, technically, nobody did.
The architecture allowed it, the cloud platform happily provisioned it, and the invoice simply reported what had already happened.
That is why I keep saying FinOps cannot live primarily in accounting. Accounting can tell you what you spent. It cannot redesign the architecture that caused the spend.
FinOps now belongs in architecture because cloud cost is no longer just a financial outcome. It is an architectural characteristic, right alongside performance, security, resilience and scalability.
In traditional data centers, many infrastructure costs were hidden behind procurement cycles and capacity planning. You bought hardware, depreciated it, and argued about utilization later. With cloud, every bad design decision has a meter attached to it.
Overprovision a database, and the bill knows. Move data constantly between regions, and the bill knows. Choose the wrong storage tier, and the bill knows. Build chatty microservices across availability zones without understanding traffic patterns, and the bill absolutely knows.
I once worked with an enterprise that was proud of its cloud migration because the project had finished mostly on time. That pride lasted until the first full quarter of operating costs landed.
The applications worked, but they had been lifted and shifted into an environment where inefficiency was now charged by the hour. Servers that used to sit quietly underutilized in a data center became expensive virtual machines running all month. Old batch jobs moved huge amounts of data through expensive paths. Test environments stayed on because nobody owned the shutdown process.
Finance saw a cost problem. Architecture saw, or should have seen, a design problem.
That distinction matters. If the only response to cloud overspending is “cut 10%,” you get panic-driven optimization. Teams turn things off, delay projects, fight over budgets and sometimes create new risks. If the response is architectural, you ask better questions. Why does this workload run this way? Why does this data move so often? Why are we using this service tier? Why is this environment always on? Why did we design for peak capacity instead of elasticity?
Those are architecture questions, not accounting questions.
One of the best shifts I’ve seen in mature cloud organizations is the move from total-cost thinking to unit-cost thinking. Total cost tells you the monthly bill. Unit cost tells you what it costs to serve a customer, process a claim, complete a transaction, train a model, stream a video or run a report.
That is where FinOps becomes useful to architects.
If a retail platform spends more during the holiday season, that may be fine if revenue scales with it. If a data platform costs more because more customers are using analytics features, that may be a good trade. But if the cost per transaction rises as volume increases, something is wrong. The architecture is not scaling economically.
I’ve seen this surprise teams that thought they had built scalable systems. Technically, they had. The systems could handle more demand. But financially, they scaled badly. Every new customer triggered more compute, more storage replication, more logging, more network transfer and more managed service consumption than anyone expected.
That is not a finance issue. That is architecture failing to understand the economic behavior of its own design.
Architects need to model cost the way they model latency or availability. If we choose this database, what happens when the workload is 10 times higher? If we retain logs for a year, what does that mean at future volume? If we put services in multiple regions, what is the cost of resilience? If we adopt a managed AI service, how does usage translate into spend?
Those questions belong at the whiteboard, not after deployment.
I have nothing against cost optimization projects. They can save real money. Rightsizing instances, deleting unused volumes, adjusting commitments, improving tagging and cleaning up zombie resources are all useful. But if that is your entire FinOps practice, you are basically running cloud janitorial services.
Important? Yes. Strategic? Not enough.
The real savings happen before the system is built.
They happen when an architect chooses an event-driven pattern instead of always-on polling. They happen when a team selects the right database for the access pattern instead of picking the fashionable one. They happen when data retention is designed around actual business and regulatory needs instead of infinite hoarding. They happen when environments are ephemeral by default. They happen when developers have paved roads that include cost guardrails from the beginning.
I once reviewed a cloud-native application that looked modern on paper. Containers, managed services, automation, the works. But the architecture generated massive amounts of telemetry, pushed it into expensive storage, replicated it broadly, and retained it far longer than needed. Everyone agreed observability was important, and it is. But nobody had asked what level of observability the business actually required for each environment.
The fix was not to tell finance to negotiate a better bill. The fix was to redesign the logging and monitoring architecture so it matched operational value. Keep the right signals. Reduce noise. Tier storage. Shorten retention where possible. Make debug-level data temporary.
Suddenly, FinOps looked a lot like good architecture. Because it was.
Even when architecture contributes to cloud overspending, redesigning a workload isn’t automatically the best response. Before committing to major changes, consider:
• The size of the problem: Is the expense substantial and recurring, or would a smaller operational adjustment address it?
• The cost of the fix: Will the expected savings outweigh engineering time, testing, migration expenses and potential disruption?
• The tradeoffs: Could lower operating costs compromise performance, resilience, security or business requirements?
• The decision-makers: Have architecture, operations, finance and business stakeholders agreed on what constitutes an acceptable outcome?
Every architecture review I run or advise should include cost as a first-class nonfunctional requirement. Not as a vague statement like “must be cost-effective,” which means almost nothing, but as something measurable.
What is the expected monthly operating range? What is the cost per unit of business value? What utilization assumptions are being made? What is the cost impact of failover? What happens if traffic doubles? What spend alerts and automated controls are in place? Who owns the cost of shared services?
These questions should sit next to availability targets, recovery objectives, latency requirements and security controls. If a system has an availability requirement, it should have an economic requirement. If it has a data architecture, it should have a data cost model. If it has a scaling strategy, it should have a scaling cost curve.
This does not mean architects need to become accountants. It means architects need to understand that design choices create financial consequences.
Accounting can report those consequences. Architecture determines them.
David Linthicum is a globally recognized thought leader, innovator and influencer in AI, cloud computing and cybersecurity. He has more than 30 years of experience in enterprise technology and, until early 2024, served as managing director and chief cloud strategy officer at Deloitte Consulting LLP.
YOU MUST AGREE TO OUR TERMS OF USE AND PRIVACY POLICY.
Already a subscriber? Sign in with your email above.
Get the free newsletter read by industry experts
Keep up with the story. Subscribe to the free TechTarget CIO newsletter
Subscribe to TechTarget for top news, trends & analysis
Get the free newsletter read by industry experts
The free newsletter covering the top industry headlines
source
This is a newsfeed from leading technology publications. No additional editorial review has been performed before posting.
