Platform Engineering - Implementation

The platform engineering (PE) evolved from a community of engineers around 2021 and is based on the PaaS concepts. It has been several years that I have been heavily engaged in platform engineering at several organizations. These are net new initiatives and I would still put them in early adopter bucket. Prior to that I have partnered with a dozen+ fortune 100 organizations helping them achieve architecture and process maturity via cloud-native architecture and DevOps culture. 

What is platform engineering?

If you are new to PE, please feel free to read up: https://humanitec.com/platform-engineering 

How to get started?

Like any other capability, platform engineering should be based on business and customer value. Being relatively new concept, it is difficult to identify the benefits from PE for customers and business. Use current state analysis to define a path to different levels of maturity as target states. This will also help justify the business and customer benefits of PE and allow for developing a roadmap that can be delivered iteratively. 

The other key concept to remember here is that platform team will be responsible to deliver most of these capabilities, but the software development and IT teams would need to collaborate constantly. Typically the platform is based on a flavor of K8s, hence the applications and services that run on it should also follow a strict set of guidelines. In reality, there will be gaps from the applications to take full advantage of the platform. If the platform is on premise infrastructure there will be additional dependency on the IT teams. The platform requirements typically involve some security capabilities, these would mean involvement of Information Security as well. 

The platform journey

Foundation

As you can tell, this is not a simple set of goals anymore and requires a lot of collaboration with other departments and one can expect to get into conflicting priorities, pushbacks etc. A lot of these teams might still be living in a legacy state and priority from them might be difficult. Hence, the recommendation is to have a ELT sponsor for the PE initiative and culture, otherwise it might become pulling teeth trying to deliver on the roadmap.  

Once you have the roadmap established with milestones, it is obvious to seek budget and resources to create a plan. The roadmap and plan is to make sure that there is some level of effort and ROI established through KPIs. 

The Crawl - Walk - Run Approach

The delivery is best driven via agile/scrum methodology using proper tools like tracker, source control and other tools for automation. Setup a mechanism to collaborate with the stake-holders on a regular cadence, this can be achieved within the agile process, but at times the collaboration needs to happen early on and at a higher level. 

Celebrate every milestone achieved in this journey with cross functional teams. As you start on this journey, there will be deviations, but shouldn't be more than 25% in a given quarter. You might be wondering, so what are the concerns?

The Challenges

In my experience of driving greenfield PE initiatives I faced challenges from the software and IT groups in adopting and supporting the initiative due to various reasons, which I'll highlight below. These can impact the delivery of PE roadmap and sometimes can even stall or rollback. Change is not so normal for groups and leaders who have spent over a decade in the same organization/group and created some of the tech debts. Hence it is critical to have the PE-sponsor be part of ELT, be well connected to the PE community and a promoter of PE culture. 

Software Challenges

  • Application in-compatibility - application doesn't scale or not compatible for the platform or insecure application container etc.
  • Poor developer standards - platform becomes the cause of all issues and blame shifts to PE
  • Lack of Accountability - no commitment for addressing tech-debt from software leadership
  • Non-technical leadership - defend the legacy practices, resistance to change, poor judgement
  • Conflicting priorities - possible delays due to less focus on platform scoped tasks

IT Challenges

  • Non-technical leadership - defend the legacy practices, resistance to change, poor judgement
  • Bottleneck with infrastructure - can't procure/provide infrastructure in a timely manner
  • Legacy processes and controls - PE automation around infrastructure suffers
  • Conflicting priorities - possible delays due to less focus on platform scoped tasks

Leadership Support

Achieving platform engineering capabilities require constant support from the ELT. Without this, the PE team is faced with constant conflict of priorities and other cultural pushbacks. 
  • Focus - having a constant focus and prioritization on PE is key to it's adoption and success.
  • Trust and collaboration - conflict with stakeholders is common, but can greatly benefit from support from ELT. 
  • Conflict resolution mediation - sometimes the conflicts need mediation from leadership.
  • Promotion of PE culture - without a quarterly promotion of platform engineering the teams tend to take it lightly. 

To Conclude

Platform Engineering is not a quick win, rather a multi-quarter journey to iterate, enhance and mature the platform. I emphasize the need to establish and maintain "Fact and KPI based decisions and collaboration" with ELT sponsor, so that the journey remains relevant, valuable and grounded in reality for the internal and external customers. 

Comments

Post a Comment

Popular posts from this blog

Team morale - Linkedin

Image
I'm not surprised by this report. In decades of technology leadership, here are the key strategies I follow: ✅Prioritize the team's goals over personal agendas. ✅Cultivate expertise aligned with business objectives. ✅Acknowledge and reward effort alongside outcomes. ✅Uphold fairness, honesty, and impartiality. ✅Provide factual explanations for decisions. ✅Foster collaboration across all team directions. ✅Remove obstacles, distractions, and promote open feedback. Recognize signs of dysfunction: ❗Absence of clear roadmap, processes, services, or products. ❗Disregard for innovative ideas and experimentation. ❗Serial top performer or promotion. ❗Tolerating bullying or harassment for control. ❗Discouraging facts, questions, or feedback. ❗Fixating on gaps rather than achievements. Consider a successful sports team where each member has a defined role, redundancy, and enjoys the journey to victory. Achieving excellence demands strategy, skill, dedication, and continuous learning. U.S....
Read more

Platform Engineering (as Service) & Architecture - One Use Case

Image
This has been marinating in my head for a while, it's time to spit it out. I will cover my approach at F****A around why, what, who and how I helped mature the organization. To give a brief background, when I landed there, I spent some time meeting with my peers, leaders and team to gauge the current state software architecture and delivery. I was also given a list of objectives from my leadership team, most of which were multi year scope, but I was able to start on the top few priority items immediately. I decided to jot these down so that I could spread this across the organization. The What and Why? This set the foundation of the capabilities and why they are important for the organization.  Why Not? I also decided to create some distinction of why we decided to move towards Platform Engineering from DevOps . It was important to capture this distinction for everyone.  Who did What? The next big question was how to structure the team around these capabilities (What). It's n...
Read more