- Solutions
- Overview
- Rapid Response Cloud Cost Rescue
- Cloud Internal Cost Management (FinOps) Assessment
- Cloud Supplier Cost Management (FinOps) Assessment
- Cloud Cost Saving
- Cloud Cost Avoidance
- Cloud Billing, Cross Charging & Contract Management
- FinOps Enablement
- FinOps Training & Learning
- FinOps Tool Selection & Implementation
- Service Models
- Ways of Working
- Resources
- About
- Contact Us
The Importance of a Financial Architecture
08/04/2021
The Importance of a Financial Architecture for Cloud FinOps
There is a lot of conversation about ‘getting engineers to own Cloud Cost’. This means cloud engineers and finance departments need to work closer together and collaborate more. This should ensure good cloud financial management. Easier said than done, so are we not missing a trick?
Read the following steps for our recommended, different, approach. One that is more akin to how technical engineers are already used to working.
Create a Financial Architecture
Engineers are used to creating a Technical Architecture based on Technical Objectives such as Performance, Recoverability and Resilience. We recommend they also create a Financial Architecture. This is based on Financial Objectives such as Budget, Rates and Commitment Period. Similar to the Technical Architecture, this sets the standards and creates a reference point for build, test and deployment.
If you are not already doing that today, try and include it in your next project or change control item. See how it enables your engineers to understand the financial targets and deliver to them.
Create Financial Design Patterns and Principles
Now you’ve started to think about Financial Architecture as a logical approach. Akin to the Technical Architectures, you will realise that in addition to Technical Design Patterns and Technical Design Principles you also need to develop Financial Design Patterns and Financial Design Principles.
These Patterns and Principles represent the collective learning you go through as an organisation. It helps provide a level of pro-active Financial Governance. It also helps in educating the Engineering Teams on what is important and possible from a Cloud Cost Optimisation perspective.
So when you decide on your cross region and zone deployment, based on the Technical Recoverability Targets and Design Patterns, you can now supplement this with a choice for regions based on a Financial Budget Target and Regional Rate differences.
All of a sudden cloud cost optimisation just becomes another aspect of Good Engineering practice.
SLA Based Monitor, Alert and Resolution
Your Financial Targets are set using your Financial Architectures. So you can now establish a Threshold Monitoring and Alerting way of working. When Thresholds are exceeded, you generate service desk tickets for resolution.
Similar to a ticket as a result of a Performance Threshold being breached, a ticket for exceeding a Daily Budget Threshold can be raised. This now falls into your established processes and procedures to ensure your engineering teams execute identified actions.
Tickets are monitored by our Service Management process to ensure actions are understood and completed. Achievements are measured against SLAs. When breached, you investigate how to prevent this from happening in the future.
Breaches with a low value impact are raised as a P3, while breaches with a high monetary impact can be escalated to a P1 or P2 for more imminent resolution.
The importance of Financial Architecture is that it enables Cloud Financial Management using established Engineering Processes.
As always, we are interested in your thoughts. Email us on [email protected] or [email protected]. And if this topic is of interest to you, why not follow us on LinkedIn ?