Perhaps everyone in the Cloud Native industry underscores the value of the Cloud Native Compute Foundation (CNCF) for their projects, their excellent communities, and the great technologies they adopt. These organizations push the concept of Cloud Native-based solutions everywhere in the world. Fewer people know that they also created the Cloud Native Maturity Model. It consists of the following major categories: people, process, policy, and technology. Another interesting category speaks out: the business outcomes. Without the so-called business-IT alignment, the other categories are not as powerful as they might be. In this article, I will highlight why the focus on business outcomes is extremely important. Cloud Native Maturity Model – your business outcomes matter.
Buy-in from the business
Developer and other technology-savvy enthusiasts might disagree with you if you state that your business buy-in is as critical as their work: coding infrastructure and software applications. However, nothing can happen if there is no budget for those activities. You require the support of (external) stakeholders that allocate time, resources, and budget to fund it all.
Your application can only survive in their program management spreadsheets if it’s able to prove its value to their business challenges. And beyond that: it needs to evolve and grow to stay relevant in the future. Therefore you need the buy-in from the business representatives. These business goals are a driver for the other categories that play a role in the Cloud Native Maturity Model.
Business outcomes matter here for a number of reasons which include:
- Being able to meet future demand in terms of supporting a large number of customers.
- Respond to external changes faster (become more agile but also more resilient).
- The improved customer experience (less downtime, higher levels of user satisfaction in terms of service delivery).
It does not matter which of these business factors are most important. The fact that you consider the potential business outcomes is required to assess your organization from a business perspective.
Just like the other categories that are mentioned, the business outcomes can be ranked into five stages or levels.
- Having a baseline of the Cloud Native implementation and running an application in pre-production (Build – level 1).
- Moving to production based on a solid foundation (Operate – level 2).
- Scale the existing processes (Scale – level 3).
- Constant improvement of everything you do, think of governance, policies, and security (Improve – level 4).
- Monitor and Optimize your applications and infrastructure to revisit earlier decisions (Optimize – level 5).
You can use these levels to define where an application (or group of application components) would score during various phases of its lifecycle. Therefore it does not matter if you have just started to brainstorm the conceptual ideas or if your application is running in production already for a couple of years.
These concepts and different angles make it a powerful Maturity Model which fits well into every organization that builds software applications.
Not every company has a clear view of its true business goals. Sometimes it’s difficult to answer the questions like “where do you want to be next year”, “in which market/segment do we want to become a market leader” or “what is our short-term revenue target”. It’s even more difficult to translate this back to building applications and other (technical) systems that drive those business goals.
To make things a bit more practical, here are some business goals which are correlated to the development of Cloud Native applications:
- Reduce downtime of the top 10 applications by 50% to avoid broken transactions of paying customers.
- Faster shipping of User Stories and technical tasks to production by 25%.
- Decrease infrastructure-related costs by 60% (limit the scope to hardware and software licenses).
- Engage with tech talent to employ 10% more professionals by the end of the coming year. Cool and hip Cloud Native technologies play a vital role here.
- Transform and migrate legacy applications to cloud-native solutions to reduce costs of maintenance by 40%.
All of these are very powerful business goals that are extremely practical. They are not “vague” and difficult to understand. The best is to spread them into the organization so that everyone on every level understands them. It helps the workforce to think and act from a common perspective. Everyone is aligned and all share the same goals. Fewer misconceptions about what is important and whatnot.
Make it practical
But how does this translates to the actual implementation of the Cloud Native best practices? For this to understand, you need to have a brief overview of the five stages.
Build stage: level 1
In level 1 you just have conducted a successful Proof of Concept. It’s not just an idea you’re tinkering your mind with, it’s a piece of software that actually runs and you can demonstrate to your stakeholders. Your PoC shows something that sparks the mind of others in the organization. The following topics might be appealing to the ones higher up in the organization:
- No downtime when you upgrade an application from version 1 to version 2.
- Excellent monitoring of your application and only high priority alerts are generated for issues/incidents which can’t be solved by the application (infrastructure) itself.
- An application that uses less CPU / memory resources compared to other applications (which might act as the baseline).
While these are still a bit technical aspects, you can derive Key Performance Indicators (KPIs) from them. Don’t be mistaken by the well-known DevSecOps KPIs such as faster build times and deployment frequency. These still matter here, but it’s important to define the KPIs from a business perspective. Think of:
- Increased revenue per customer by 10% while the operational costs are kept the same.
- 10% fewer transactions that “miss the boat” so no manual intervention to restore them.
- Being able to handle audits 5 times faster than before since you have automated all compliance-related aspects.
Business stakeholders need to understand those aspects to support them and free budget to let you progress to the next level.
Operate: level 2
Operating your application in production is the focus of level 2. A set of running applications in production is the baseline for this stage. Your applications need to be built with Cloud Native technologies and best practices. When done so, this status helps to evaluate the outcomes of the migration and adoption of Cloud Native technical aspects.
The following observations/aspects are derived from this level:
- Business leaders are mentioned by your early successes. They might be getting more interested, but you constantly need to communicate the advantages and pinpoint the discussions towards the business benefits. However, good chance that there will be traction after your endless efforts.
- Other teams can build upon your achievements since patterns emerge. This is all based on standards, policies, and processes. More and more Product Owners see these aspects and they notice better software that is built faster.
But you’re not there yet. The most difficult aspect is not yet met: improved RoI since you’re still at the early stages of the Maturity Model. You still need to invest time, energy, and money into the solutions and think like tool selection, building up team skills, etc. Remember, you’re on the right track, but more is needed to keep the interest of the business leaders.
Scale: level 3
Small improvements need to grow to bigger successes. More people need to adopt whatever you have learned so far and the developer teams need to be more confident that they can do it. With this in mind, various competencies of the teams all around the organization grow efficiency, reliability, security, etc. Processes are designed around scale and you need to communicate the benefits of these scaling results.
This is easier said than done since you need to avoid “feelings” and focus on objectively measured results. Therefore, monitoring and logging are crucial to support your results and keep convincing the large business crowd. A good point of reference would be to start measuring the “old versus new” world. Think of:
- Measure the speed of deployment before and after the Cloud Native migration.
- Fewer security incidents (in production) since vulnerabilities and security misconfigurations are found and fixed earlier in the process.
- Re-usability is based on common patterns and solutions. Fewer teams re-invent the wheel over and over again. Establish common building blocks which are well maintained and offered in different versions to teams can adopt them at their own pace.
Ready for the next level?
Improve: level 4
Level 4 is all about improvements on various aspects which are related to the developer teams’ day-to-day activities. Examples of these are: controlling governance-related aspects such as access control, follow-ups on security-related aspects, and Policy plus Compliance as Code. Improved and better-supported APIs that reduce the communications overhead to other teams and departments.
In short, teams can focus more on business-related aspects than infrastructure and other less valuable activities. Perhaps one can also state that team sprints have fewer “tasks” and more “User Stories” to deliver business features. Since there is less focus on infrastructure-related aspects, the business gets a louder voice in what’s being developed and brought to production. This also fuels the expectations of the business outcomes. More focus on the realization of KPIs (remember level 1?) and more reporting to the (senior) management about compliance, security (business risks), and costs.
Keep in mind the business targets, it’s now time to optimize the applications to focus more and more on these goals and also demonstrate it during sprint reviews. Technical aspects vanish bit by bit and business areas get more attention. This would even attract business leaders higher in the organization so your team is put in the spotlight (again).
And this further accelerates other teams so they will also change their applications according to your best practices. In the meantime, you will be ready to further optimize a lot of other aspects.
Optimize: level 5
This is the last level of the Maturity Model. Perhaps you might think there is nothing left to do here. But there is always room for improvement.
Consider the following topics to further optimize everything you already did:
- Raise the bar for the KPIs you already achieved: even less downtime, even more paying customers (conversion), and even faster shipment to production.
- Try to reduce costs even more by automating the complicated tasks which were not optimized before.
- Further, reduce human errors by enabling tools to auto-remediate security issues and test your applications against them.
- Constantly measure your application performance, perhaps even in production to generate even more revenue.
As you can see there are still many aspects which can be improved which you might not notice yet. As a matter of fact, it’s time to show your results to the CEO and CFO or the board of your organization. It’s important to get top business buy-in so new (strategic) goals can be established. When your application reaches this stage, you’ve done very well and you can be proud of yourself and the team.
The CNCF works on a Cloud-Native Maturity Model. Besides the common categories such as people, processes, and technology, it’s also focused on Business Outcomes. In this article, I picked this category to deepen the topic and help people understand the interplay of Business and IT here. It’s vital for everyone in the organization to understand the business goals to transform and optimize their (Cloud Native) applications in such a way that KPIs help to measure the true business benefits. I hope this inspired you to implement your next features and to further grow the organization you’re working in.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to email@example.com.