Embedding FinOps: Achieving a Continuous Authority to Operate (cATO)

Summary

The TL;DR is that to do FinOps right, we must begin with the end in mind by embedding FinOps processes upfront and in a continuous manner by assessing each stage of the Software Development Lifecycle (SDLC) in how your organisational processes and procedures can be tweaked to include these fundamental practices.

In an effort to achieve this, I propose that they are embedded into your organisation's own version of a continuous Authority to Operate (cATO) procedure which ensures we shift left as much organisational risk as possible and bake in the benefits that FinOps done well has to offer.

As always, none of my recommendations come easy, or fast, I remain resolute in ensuring we do FinOps right by building from the foundations up, and not just ticking a box, cutting a corner, or buying a shiny new tool.

Happy reading.

Introduction

In today's fast-paced digital landscape, organisations continue to push toward the cloud for a range of operational reasons whether that be to benefit from the agility and scalability available. Or in other cases, simply to follow the herd. Though in parallel to this explosion of organisations racing to the sky, it has become increasingly important for organisations to ensure their cloud applications are not only secure, and compliant, but are also cost-effective.

However, all of these important 'wants', from being secure and compliant to now cost-effective are due to the advent of significant data breaches, changing legislation and tougher economic times. Very rarely, in my personal experience, are they proactively baked in, planned upfront and embedded in the social & operational fabric of the organisation before or after moving to the cloud.

Meaning, in the same reactive rush to the sky with their cloud-first principles, they continue to 'bolt-on' rather than ensuring these processes and procedures are 'built-in' to actually give them a fighting chance of success.

The end product of organisations operated in this way is always the same. Steadily, over time, roles shift from being able to utilise their cerebrum to design, solve, and build a better working world. To one who spends most of their time-fighting fires because all these 'musts' were never baked in, leading to a domino effect of unknowns. At its core, this is what is known as hyperbolic discounting, organisations and individuals valuing immediate rewards over longer-term rewards because they need to get a win, as root causes are hard to find, and change is even harder.

But you came here for more than that, what can we do?

Enter the Authority to Operate (ATO), the original baked-in not bolted-on influencer.

Note: If the above sounds like your organisation, or potentially you, take a look at an article below that I wrote about getting to the root cause and solving problems with the end in mind before continuing on how we build evolutionary architecture in the form of FinOps processes.

Authority to Operate (ATO)

So first, what is an Authority to Operate? If you are aware, meet me down at The So What? For those of you who may not be familiar with this concept read on for a short and sweet.

Background

ATOs at their core are an assessment that aims to reduce risk and ensure compliance with a range of policies, better practices, legal requirements etc. They are most commonly undertaken in government, defence and national security organisations but have broad applicability to all industries.

ATOs essentially are formal permission granted by an organisation's allocated governing authority that allows the information system in question to operate in a specific environment i.e. it has been assessed to a particular standard to ensure it meets all controls, standards, policies and procedures related to infrastructure, security, networks, architectural design etc.

Systems that have ATOs issued must be routinely re-evaluated to ensure the system continues to meet the requirements. This reassessment is time-bound and/or can be triggered by subsequent changes to the system/architecture. ATOs processes routinely align with the NIST Risk Management Framework (RMF).

The governing authority mentioned above is normally delegated to an organisation's Information Technology Security Advisor (ITSA) who sits within a Security Architecture Practice and provides support and advice to senior management and staff on cyber-related matters.

continuous Authority to Operate (cATO)

A continuous Authority to Operate (cATO) on the other hand is a newer, more robust and certainly streamlined (time-wise) version of an ATO. Made possible through DevSecOps and CI/CD pipelines which involve continuous monitoring and assessment of the information system to ensure it remains secure and compliant.

A must in the world of cloud, Infrastructure as Code (IaC) and CI/CD which sees changes deployed rapidly and the ability to unintentionally leave the door open to cyber criminals.

The So What?

ATOs have always been about more than just security, they are one of the most rigorous and 'shifted left' opportunities an organisation has to 'get it right'. Good ATOs include various architectural practices and processes outside of just the full security assessment and should include, but are not limited to:

1. Configuration management: Ensuring accurate and up-to-date records of an application's software and hardware configurations. It ensures that any changes made to the system are tracked, evaluated, and tested for their potential impact on security and compliance.
2. Change management: This refers to the process of assessing and implementing changes to an application's code, infrastructure, or configuration. It involves identifying and mitigating potential risks associated with any proposed changes and testing the application to ensure that it remains secure and compliant after the changes have been made.
3. Integration and deployment: This involves integrating new features or changes into an application's codebase and deploying them into production. It includes testing and quality assurance practices to ensure that the application is always in a stable and secure state.
4. Monitoring and logging: This involves continuously monitoring an application's performance and security logs to identify and address any issues or security incidents in real time.
5. Disaster recovery and business continuity: This involves developing plans and procedures for recovering from unexpected events that may impact an application's availability or security, such as natural disasters, cyber-attacks, or system failures.

Now, it is acknowledged ATOs routinely miss the mark due to development teams not involving architecture post the initial sign-off due to most ATO processes being security-focused and cumbersome in nature, let alone the lack of resources available. That is a separate conversation for my architecture friends.

However, in a cATO model, which involves Continuous Integration and Deployment (CI/CD) at every step of your organisation's Software Development Lifecycle (SDLC) process. From design to development to testing, to integration and deployment and finally monitoring and logging, you have the ability to integrate FinOps practices.

By embedding FinOps practices into the cATO model your organisation can stop hoping, wishing, and dreaming of a better day and finally move to a proactive optimisation of the cloud which sees best practice architecture, and efficient and effective use of cloud resources. This, in turn, can help your organisation to reduce unnecessary expenditure, avoid waste, align spending with business objectives and deliver a more reliable technology outfit overall.

The How?

Each organisation will be different, some may not have an ATO/cATO process in existence now and some may and will be wondering where this all fits. Though I won't be able to cover all scenarios my hope is that in explaining the concept above and with some hints below, you will be able to craft your own version of continuous FinOps Practices - how you technically achieve it, is up to you!

Some thoughts to take away:

Define cost management policies and standards:

You must establish the boundaries of where FinOps must first be considered and how cloud costs be managed through the software development lifecycle. In my personal opinion, this starts at the point of design and business teams engaging architecture to look at solution design options and is inclusive of your BAU teams doing production support fixes and project teams doing upgrades.

It is time for cloud architects in your organisation to be cost-conscious, and as part of their architectural trade-offs include cost-based decisions in their Solution Overviews/High-Level Solution Designs (HLSD).

This is critical as most organisations have shifted from on-premises or are still running hybrid operations. As such, the incumbent architecture practice is set in its ways of not needing to cost hardware, licences, etc. and needs a shake-up. This may require you to find, beg, borrow, plead, and hire, and an architect which can provide this cost-conscious lens upfront. A journey that is worthwhile, if you so chose to take this road.

Integrate cost management into the development process:

This comes back to the number one challenge in organisations around getting engineers to take action. Again, these developers, have never had to care for costs. It came out of a large bucket of magical money that they never needed to care about, certainly when the on-premises hardware was already accounted for.

So outside of the massive step change required to upskill developers to be cloud cost-conscious and actually care about what their spaghetti code costs. There are some really simple ways to improve this:

• Code/design reviews by those who have already got FinOps knowledge and can do it justice by applying that critical thinking hat. This has the benefit of building internal capability over time.
• Gamification of your KPIs/OKRs and the variances in specific metrics to bring out that competitive spirit in your developers to improve over time. No one wants quick fixes here, everything I harp on about is gradual, measure twice cut once logic.
• Tools like Infra.io, are an absolute game changer for some organisations and developers to see in real-time what their code/IaC change could mean, leading to proactive rather than reactive FinOps practices.

Establish a culture of cost consciousness

Though this is applied above for our developer cohort, it is broader. FinOps permeates every aspect of your organisation - you just haven't found that out yet. Given such, by taking a tailored approach to the SDLC specifically, working with project management, change managers, testers, and the whole gamut of skilled professionals we can start to embed the importance of being cost conscious.

This is more than just saying, to be better, it's about providing them with the right resources, training, tools, experiences and information for them to learn and grow to be what's required. Change is hard, but this kind of change is worthwhile.

And there are many more, but this article is getting long and you get the point...

Conclusion

In conclusion, embedding FinOps practices into your organisation's own cATO, whether one exists now or not, is critical to ensure your organisation has a FinOps gatekeeper at each step of the software lifecycle as your software makes its way to the magical cloud.

It's this level of proactively managed cost consciousness that ensures organisations can do as they require to fulfil stakeholder needs. That may be to make money as a private entity or to provide public value in an effort to protect citizens as a government organisation.

Though in order to achieve a cATO process with embedded FinOps as suggested above will require a number of changes across people, process and technology. I hope you are up for it, good luck!

#cloud #finops #architecture #aws #cicd #iac

The views expressed in this article are my own and do not represent that of my employer.

See other articles I have written relating to FinOps here: