Is it worth doing it? Building a business case for Platform Engineering transition

# Modern Architecture

Is it worth doing it? Building a business case for Platform Engineering transition

19.06.2023

Platform Engineering transformation requires both faith and reason. We know that the benefits of Platform Engineering exceed the cost and efforts of this change. We believe this transition can be effectively planned, communicated, and executed.

The business case for Platform Engineering should take into account:

the problem organization is facing with the current software development process, including the information about the scale and missing business opportunities;
existing alternative solutions or scenarios;
the attributes of the chosen solution, including its benefits and risks;
implementation approach with critical points and circumstances of implementation.

Why do we start it? What do we expect?

Software development processes’ fundamental and most common problem is the lack of efficiency. It may cause many internal and external consequences, for example, employee turmoil and, in effect – lack of engagement and rotation.

What is platform engineering, and what is it not? Let’s recall its concept – to avoid building arguments for non-existing or false definitions.

A platform should fulfill the self-service model for developers, providing all necessary systems, tools, and workflows regarding the entire application’s lifecycle. A new team should also emerge, one dedicated solely to building and maintaining the platform and the interface developers’ teams may work on.

https://mindboxgroup.com/the-rise-of-platform-engineering/

The platform should also possess some key attributes:

act like an autonomous factory with established rules and assured integration, where Engineers are easily onboarded;
allow the developers to focus on important tasks and work in a modern environment which helps them improve their skills;
be customized. https://mindboxgroup.com/platform-engineering-of-high-expectations/

Is there an alternative solution? Many organizations are currently moving to the DevOps model, hoping to solve the basic problem of software development inefficiency. Some are “already there” and are stuck with the new-old concerns. DevOps teams are struggling with the fast-changing environment, deployment pipelines, configuration, and environment management, rising complexity, and toolsets variety. They can also not effectively manage teams mixed with over-skilled seniors and under-skilled juniors. DevOps environment configuration shouldn’t be a task for highly skilled developers – but on the other hand, it’s still too challenging for the less experienced ones. https://mindboxgroup.com/what-went-wrong-with-devops-revolution/

Depending on the harm it causes, organizations are becoming aware that they are reaching the decision point again. And now, as usual, there are three possible answers. Some decide they don’t change anything, “We endure DevOps.” Other organizations also react somehow predictably: “It hurts? — ok, let’s do even more DevOps”.

We address this article to those who are brave or determined enough to start the change and decide to adopt Platform Engineering.

Let’s start a business case for Platform Engineering

The problem may inspire you to look for a solution that already works – there are examples of those who do better with software development. Why not look up to AWS or other public cloud environments – the implementation of the idea of an ecosystem with standard components ready to be used, reused, arranged, and constantly optimized to meet specific needs case by case? This forms a perfect list of general benefits from the platform approach, and Platform Engineering is not an exception.

Integration by default. The ecosystem – the platform stores and serves a set of complementary elements that can be used and integrated into various sets. It’s a key benefit: you don’t need to worry about the integration anymore because those elements are natively integrated. The same as a properly built Platform should offer.

What do you gain? A properly operating platform instead of chaos management. Rather than intuitive but disorganized ways – there is a choice of elements and basic, ready-to-use, and growing templates repository. All of them can be applied almost automatically.

Continuously updated and optimized environment. This environment – if we follow the cloud ecosystem example again – should be set to evolve, optimize and develop to serve developers’ everyday work better. But it should also be adjusted to more strategic, long-term shifts in software products created with the aid of the platform. A bunch of people are responsible for this task, and an internal team is dedicated to continuously developing, testing, and optimizing this environment.

Measurement and monitoring of the process. How far can these analogies between PE and, for example, AWS go? Indeed, both environments allow monitoring, measuring, and improving the function and platform itself. We can monitor the efficiency of tools and templates and development teams’. You can also compare internal and external teams.

Transparency, awareness, and understanding. Platform Engineering gives us a new level of internal transparency. This transparency allows for supporting the standardization of requirements across the organization. And this, in turn, makes such internal processes as the onboarding of developers more efficient.

Developers empowerment – let them focus on the code. The above-mentioned standardization, integration, and transparency enable your developers to focus on their core activities – and that is a key benefit of the well-designed and deployed Platform Engineering.

Call it a black box, call it a cloud (like): it’s brilliant

Let us not go too far with the cloud analogy. Perhaps comparing Platform Engineering to a black box is easier and more appropriate, where the developer commits the code and the black box “does the rest”.

Between the code and the functioning application, there should be a black box – or a fog – from the developers’ perspective. They should confine in that black box that it is a set of integrated and proven tools easily combined into a process.

Black box wizards. Ones who know how to rule the platform

However, some team members in the Platform Engineering approach should be better informed of its nature. Platform Engineering requires that part of the development team should have end-to-end skills besides the group of platform developers dedicated to its creation and maintenance.

This role may be described as a platform architect who knows what is inside the black box and how it is integrated. It’s important thing to remember that we will have to grow this competence in our organization once we decide to turn to platform engineering. This illustrates well how the dualism of DevOps turns 180º: from serving developers’ needs approach to an adjust-to-standard process.

Scalability (and other benefits) are welcome

Platforms are, by definition, easy to scale – that’s one of the PE advantages that business and financial guys will welcome.

Let us stress that the organization’s KPIs are the same as those of the DevOps model: release early, release often, automate the process, reduce the cost of development, reduce the number of bugs, etc. There’s an alternative if your development process doesn’t meet those goals: hire more developers or change the approach. We recommend the second way and offer a recipe: platform approach.

The proper Engineering Platform should be Zero Touch operations. This enables scalability. The automated environment is constantly and continuously optimized but requires a new approach and a new style of work.

Besides: going platform doesn’t mean we expect you to do another revolution. Once again, we want to stress it: it is not the same scale of the event as a waterfall to agile overturn. It should be regarded rather as the evolution and reinvention of DevOps into a more effective model. However – still a relevant pivot, especially in more prominent organizations.

Last but not least: impact on cybersecurity. On the list of benefits, we shouldn’t underestimate cybersecurity. Yes, we will reach a higher level of security overall and security of software development flow. The new mode of production results in more robust, safe applications. Platform architects are responsible for the protection of the black box environment. Thus – with the Platform engineering approach, we have the power and tools to give the entire organization’s software products more security and resilience.

Risks in DevOps to PE Transformation

The catalog of risks consists of more categories than just human factors, but it is correlated with others.

The above-mentioned team members’ resistance to changing their work should be considered a natural phenomenon.

However, this resistance’s intensity may vary depending on technical factors. One should always consider that the limited functionality of the early version of the platform is also natural for the change project and an important issue.

It impacts the will of developers to be involved in the creation of the platform. This problem should be addressed quickly because we risk the rejection of the tool by the users.

Responsibility for the platform – must become the keystone of the Engineer’s mindset. We should be aware of it, establish this notion during the implementation phase, and cultivate it later.

It is worth stressing that Mindbox’s role in implementing platform engineering projects is to help choose and understand the scope of new parts. We help define the aims and range of skills, limits, and responsibilities. We are working hard with our partners on the pace of change. Although many of its elements need time to mature – all challenges should be addressed proactively. Otherwise, we risk that lagging in the change process results in incremental delays in current tasks and projects.

What we observe

We help many clients improve their platform engineering transformation.

They focus especially on transitioning to a new role in DevOps teams: from developers executing the process to creators of the process – platform developers. IT guys are accustomed to performing the functionalities the business ordered. Now, those who become platform developers and architects become creators and take responsibility for the solution’s functionality.

Most of our clients are convinced that Platform Engineering is the right way for them. But it is hard to plan and start transitioning to a platform model without support and understanding in the organization. Most of them have found that the involvement of high-level/senior executives as initiative/change sponsors is a good and effective practice.

Tune into Platform Engineering: success factors and Recommendations

First recommendation? Make a decision. The bigger your organization, the bigger development units and software development process issues are – the sooner, the better.

Measure and monitor the process from the very beginning – your organization will find out and quantify benefits sooner.

The implementation should be a step-by-step process of platform adoption by consecutive teams. The big-bang approach is not the right way in that case. Consequent and planned roll-out is necessary.

The aims, benefits, and time to achieve them should be strictly determined. And all project stakeholders should be systematically informed of its progress.

Platform Engineering is more about technology than DevOps. Thus, the evolution of a newly established platform may be quite dynamic. There are plenty of new tools, standards, patterns, and practices to learn and many more to come to the market. It is necessary to monitor and adopt the best of them continuously.

Every platform uniquely represents a business’s needs and requirements the software process must address. Together with our clients, we build a unique method of creating their platforms using the elements and licenses already available in the company’s assets.

On top of that, documentation is king – again. Detailed and up-to-date documentation is a foundation for an effective onboarding process, which should be started in the same breath as implementation. It works, helps, and simply levels up the overall probability of the final success of platform engineering introduction and operational work.

We also strongly recommend building your team – to avoid a situation when your partner becomes responsible for the evolution of your unique platform, with the same team which serves similar maintenance and development for other clients. Your unique platform will become increasingly similar to other platforms your partner’s team handles. Knowledge transfer will avoid vendor lock-in of the PE.