Jacqui Wilson
FinOps Lead | IT Operations Manager at Old Mutual South Africa
By Jacqui Wilson, a FinOps Practitioner
At Old Mutual, a premium African financial services group, we have a handful of mandatory (provisioning and lifecycle controlled with compliance reporting) tags within our single payer and all linked accounts. This tagging data combined with some of the data captured (and not easily maintained) in our ServiceNow CMDB are the basis of the cost allocation data. We then have CUBEs logics which are the business rules which are applied to the data. This includes fixed and variable proportion logic of splitting up shared costs and exception rules are applied to certain linked accounts.
Other sources of cost that we need to account for can include the following.
AWS Marketplace procurements
Additionally, we have AWS Marketplace procurements which will need to be paid directly to one profit loss center and recovered by one or multiple linked accounts (with one or more profit centers). We then also add in credit allocations (where applicable) our foreign exchange rate applied as well as our tax added on. All this is populated into the General Ledger template for recovery to be processed and a bulk account payable file for the payments to be made.
Today, we do this manually by applying the written rules into formulas and running calculations in Microsoft Excel.
Addressing commitment-based discounts, savings plans, and spot
We have looked at the choice of DIY (Do it Yourself) or Buy. We are only in the Compute Savings Plans for compute services, not SPOT / RI’s yet, however some teams are starting to consider. We currently have limited containers, so creating the chargeback is easy.
The general ledgers are governance policy control. We cannot abruptly run the recovery/chargeback rules on top of these accounts to do the cost allocation. It usually goes through the workflow to get necessary approvals from Chartered Accounts to ensure cost allocation accuracy. Finally, the cost allocation data gets manually captured to create a chargeback file.
Implementing levels of chargeback
There are multiple Chargeback levels (e.g.level 1, 2, 3, etc.). For example, once the Chargeback is applied to a business unit, the 2nd level is to distribute the Chargeback to different workgroups like account/enterprise/team owner under that business unit, and the Chargeback is identified through tags.
There are internal cost centers where these chargebacks are applied. The chargeback data sent by the centralized team is divided into multiple chunks to have a 1:1 relationship between these cost centers.
Addressing timing
One of the problems is that the cost allocation is done in the middle of the next month, where the team never allocated the budget for it if there was an overrun in the previous month. Once the chargeback data is available, the credit allocation process with discounts will be initiated. The centralized team makes the payment to the external cloud provider.
Additionally, for our hosted SaaS (e.g., Sql, IBM, Kafka, DataBricks, etc.) BYOL (bring your own license) to AWS, we have Chargeback models applied monthly without using AWS-CUR data. We have a License solution: Xupervisor. It enables us to track pay as you consume against the entitlement we procured.
For Microsoft Azure Chargeback, we extract the billing data into Microsoft Excel and use our lookup of account and profit loss center. We only have a small footprint, making both showback and chargeback far less complicated. We have no savings plans to allocate. Each account with all subscriptions is recovered from.
The benefits of better tagging (and compliance)
We follow best practices that contribute to better tagging and benefits cost allocation. We have tags from the provisioning phase, and they are mandatory. We have five mandatory tags, but we expect 15. Some of the tags that we use internally are AppID, AppName, Cost/BudgetCenter, Map-migrated, OwnerAssignmentGroupEmail, HoursOfOperations, BackUp, Environment and AMSPatchGroup.
In AWS, we are 100% covered with auto-tagging; while provisioning, we proactively apply tags, but in Azure, we are not there yet. So, we use reactive methods to apply the tags once the resources are deployed. Once the resource is provisioned, the data gets stored in ServiceNow based on the CMDB discovery.
In AWS, we use a compliance tool, but ServiceNow has the CMDB to run the scan. The compliance tool runs per account not only to identify tagging compliance but also for CI changes. We can check the health of the tags across accounts and individual accounts. This tool helps a lot compared to the native way to identify the tags because it’s an overhead to create a custom query to identify compliance by accessing individual accounts, as we need to gain roles and permission to access numerous linked accounts.
We send the tagging compliance report to the account owners, but we create an incident ticket and assign it to the owners (best practice). Also, creating a compliance report dashboard with the project hierarchy that indicates the teams that did not follow the standards and bringing a wall of shame and fame dashboard contributes to gamification, which helps the teams act on the compliance report with due diligence.
Some additional inputs on the Showback Reports. For Showback reports, we ingest AWS-CUR data and enrich it with business logic such as ownership hierarchy, so Executives to Product Owners can get a quick self-service view of spend trends. It is done using Microsoft PowerBI. We have enabled the Cost Intelligence Dashboards within AWS QuickSight; however, these don’t fully meet the Product and Engineering community needs. We also have looked at the choice of DIY or Buy.
After the Cost Allocation is completed, we need to help better forecast and budget tracking for Optimization. We have a data model built in the Alteryx tool that enables us to run the ingestion of aws-trusted advisor, aws-compute optimizer, and aws-cur.The outputs produce segment views for action per the linked account team.