Sometimes it is easier to explain something by the definition of state where this something is missing.
Let’s assume, that this blog post is not about Platform Engineering – which is a relatively new concept, and take something we all know – like… purchasing a car. People purchase cars more than 100 years, most of us either did it by ourselves or at least experienced the situation, even in the movies. Purchasing the car is smooth… because the purchase process is supported by the Platform! This Platform contains tools – like manufacturing, ordering, distribution, financing etc; and services, like a way to order the car, the way to test it etc.
For a 100 years we mastered both tools&services and integrated them into a nice experience for the end customer. But let’s imagine we didn’t – and we have all tools & services, but not integrated and serving the real purpose. Let’s imagine we don’t have the Platform, considering four situations I call: a bustle, a nerdosis, a buzzword, a give-me-admin. And all of them combined: a combo. And then – what if we have a Platform 🙂
A bustle
Buying a car…
Imagine a situation, where you visit the Car Showroom to buy your new Wrangler. The salesman approaches you and tells you this:
“We sell cars, but without tires, windows, seats, lights and wheel chair. But you can easily buy those things which will fit you best! There are many tires shops, windows shops or seats shops in our town – you just need to visit them, buy and assemble by yourself; or bring it to us for assembly, but you’ll wait few months”.
Ridiculous, right? You are not a mechanic. You don’t have time nor knowledge to know what to buy so it fits your new Wrangler. You just want a car which you can drive!
Building a Software…
If you have ever worked in organisation without a Platform, you don’t need to imagine it. You know this situation from experience.
Your Team is setting up, backlog is ready, you can’t wait to start coding…. but:
- for a repository, you need to go to Admins & explain the structure you want to run;
- for CI/CD you need to go to DevOps Team (they said they have ready pipelines);
- for databases, you need to go to Oracle Team;
- for Kubernetes Cluster – also DevOps Team – but first, you need to go to Infrastructure Team for resources;
- and you need to request some space & indexes in ElasticStack from Ops Team.
- … shit. I have everything, but all network connections between those are closed. Ok, last one, Network Team.
Seven jira tickets and three weeks later, your Team is ready to code! Of course if everything goes smoothly.
You may say now – not that bad, three weeks for a setup. But if you have 6-people team, each person makes ~ 30$ per hour, the whole thing will cost you about ~21 600$ just for waiting. Cost is even higher if your team need to integrate all of this after receiving. You can buy a new Opel Astra for that, every time a new Team starts building something.
And this is a situation, where we wait just 3 weeks. I’ve seen the company, where it took 4 months to set everything up. Not to mention a chaos all this jira tickets and communication are causing. Probably Opel Astra for just a management and reporting – and a nice Lamborghini for all the waiting & workarounding.
A nerdosis
Buying a car…
Imagine a situation, where you visit the Car Showroom to buy your new Wrangler. The salesman approaches you and tells you this:
“Yes, we sell cars, but in parts. You just need to simply assemble your car. But don’t worry! We’ll give you instructions…”.
If you are a mechanic – and you want to do some modifications, for WRX Race or Offroad – this is a fine method for buying cars. But you are in minority. I’ve checked. In Poland, we have 221 000 companies related to vehicle mechanics. Assuming there are 2 people working in each, we’ll have something about 400 000 mechanics. Meanwhile, we have 22 000 000 drivers. It means that a nerdosis-way of buying cars is acceptable for ~1.8% of potential customers.
“But Chris, this model of sales works perfectly – look at Ikea!”. You are correct – but what is easier for an average person, assemble 10-piece-of-wood furniture – or a car? Ikea can do it, because Cognitive Load for assembling simple dresser is much lower than assembling a modern car. And Platforms are invented to limit the Cognitive Load for their users.
Building a Software…
A nerdosis is a bit better situation than a bustle – but with different challenges. You have a nerdosis, where you need to build a Dev & Ops capabilities for you application from a blocks, pre-configured by single DevOps Team – and integrate it into a working environment by yourself. And it is fine… as long as you know how to do it. As long as it is not a Cognitive Load, which slows down the very thing you need to focus on: Business Features delivery.
I’ll give you an example. We were building a DevOps Platform for a large company. We have a sprint planning for an observability part of the Platform, and we were discussing acceptance criteria for provisioning logging capability. One of the Platform Team members proposed that in order to integrate any application with our Logging Solution, developers will need to add the agent into their environment and change some configuration in their application in three places.
I protested – for me it was too complicated. Four steps to do, where one of those were doing some action on Kubernetes pods. This Company had Application Teams with different tech skills. Most of those teams were overworked with business features delivery – so first, they do not have time to perform any changes in Kubernetes pods. Second – they would need to learn how to do it. We needed to find a way, which will be easy for any developer, similar to what developers do every day.
As a result of (short) brainstorming, we decided that we need to engineer a way to integrate any application with Logging Solution by simply adding a library to the application code. Of course, we needed to create such library in a Platform Team for each used programming language.
From the perspective of a Developer – integrating app with a Platform is adding one simple line to the code of the app. That’s all. No nerdosis, no changes in Kubernetes, no four-step-instruction. Just adding a library. And for some apps that are too busy to do even this – we did it by ourselves.
Nerdosis is simply a way of serving the technology by DevOps Team which is not compatible with Applications Teams maturity. “Digesting” the Dev & Ops environment by Application Team should be smooth – if they are mature enough, playbooks & pre-configured blocks may be fine (because App Team will know what to do with it and have their tailor-made environment in 5 minutes). But if Application Teams do not have skills, time & need to get their hands dirty with DevOps Tools – Platform should provide them with simplifications & abstraction layers.
A buzzword
Buying a car…
Imagine a situation, where you already bought new Wrangler. But, there is a Service Action on upgrading the motor controllers, so your car emits less carbon. You came to the saloon, the salesman approaches you and tells you this:
“There is a need to make the motor controllers update. Here is the cable, the laptop & the new version of the software. Update your car“.
For anyone interested into electronic modifications, this will not be a problem. But, majority of the car drivers will be very confused, and probably replies with “I won’t do it! It’s your job as a car mechanics!“. They want to drive their cars, not make them better…
Building a Software..
A buzzword is a situation bit similar to nerdosis – an enforced need to do some actions by Application Teams related to upgrades or new tech introduction on the shared environment. It is a situation, where the new tool is being released when DevOps Team understands it – but without any abstraction, instruction or even enabling for Application Teams – so they need to invest their time anyways.
An example. I was consulting one Tribe in a large company. They have few applications, each of them had a dedicated Team – and one Team intended to be* responsible for introducing new tech & practices, which application teams requested: like feature toggling, new toolset introduction, micro-frontends best practices and pre-defined components etc. Let’s call this team a Research Team.
* Intended to be was an actual issue I found in this setup. Research Team was doing a lot of PoCs, research & reading. And once they (Research Team) knew how something works and saw a value it it – they simple threw it to Application Teams. And Application Teams were expected to incorporate it into their delivery environment & practices. The result was that Application Teams needed to spend some time anyways to figure out what Research Team supposed to deliver as a service – but they didn’t. What was missing is this last touch, making those PoCs, tools & practices really usable.
What I recommended for this company was to transform Research Team into Platform Team + run some Enabling Teams once there is a need to PoC or research something. If you read Team Topologies, you know what I mean. If you didn’t – do it, it’s a weekend-long read which will simply change your perspective forever.
A give-me-admin
Buying a car…
This is a situation, where you were treated with a bustle, nerdosis and buzzwords for many years, with many Wranglers.
At this point, you are no longer a simple driver. You are an expert in Jeep Wranglers. And you think, you’ll do a Wrangler design and manufacturing much better – at least for your specific needs.
So this time, you go to the Car Showroom, summons the Salesman and says:
“I know perfectly what needs to be done to make better Wranglers. Just put me in charge of the factory, I’ll make all modifications from design to production by myself!. Or better – give me my own factory, why not.”
Guess the answer from Jeep Salesman 🙂 and even if you are perfectly skilled to do all of this, you are going to end up with a Wrangler which is perfect for you. And maybe perfect for some other people – but you can’t be sure it will be perfect for an average user. Maybe it will be – if so, start your own car company. Elon did that with success!
Building a Software..
A give-me-admin situation is often a result of a bustle, a nerdosis & a buzzword combined. The Application Team over time gains an in-depth knowledge to modify environment for their own vision – and they want to do it.
The problem is when they are forbidden because they have a shared resources with others. This is a moment where they build shadow-IT.
What I usually* recommend in this situation is to… allow them having everything they want, but with a responsibility for it. Or invite them to build a Platform. Either the way, they will became Platform Customers at the end, when they’ll see that using Platform as a Service is better than a need to maintain their own toolset.
*usually: because sometimes such a Team is not mature enough to do it, only thinking they are. Or when there are some regulatory requirements blocking such approach. Each situation needs to be validated separately. There is no magic solution for every situation 🙂
A combo!
A Combo is when you have all those situations: a bustle, a nerdosis, a buzzword and a give-me-admin all in once in your organisation.
As a result, you may encounter those problems:
- You have many technologies, which are actually doing the same thing –
- like some applications utilising Zabbix and others ELK, causing cross-domain debugging difficult;
- like different CI/CD & repositories, causing apps & people migration between teams difficult; finally, l
- ike GDPR troubles, deleting customer data from all that tech.
- You need to maintain those tools & hire people knowing much more than average tech stack;
- you pay both for Zabbix and ELK
- you pay both for Harbour & Vault operations
- you need people who knows all that staff.
- Your Application Teams are not quite sure who is responsible for what – making a chaotic communication in case of troubles
- All of this causes a poor time-to-makret for business features – because you need to maintain heavy technology portfolio rather than deliver new business value.
So… what if I have a true Platform Team?
How to fix a bustle, a nerdosis, a buzzword or a give-me-admin situations? By transforming your DevOps (or Integration, or Data, or Infrastructure…) Team into a Platform Team. It is a topic related not only to the technology configuration, but mostly a change in mindset & responsibility boundaries between Teams.
You need to start with two things. First is – define what a Cognitive Load really is. Second – make your future Platform Engineers look at their work from their Future Customer (Stream-aligned Team*) perspective, not a technology perspective. You are no longer “setting up ELK”. You are providing logging capability to your Stream-aligned Teams. This backlog-building philosophy & techniques I’ve concluded here.
*Stream-aligned Teams are the once focused on a particular stream of work – part of application, set of applications, the application. Their job is to deliver business value by introducing features & taking care of operations. Their job is not to play with technology.
Buying a car with a Platform
Imagine a situation, where you visit the Car Showroom to buy your new Wrangler. The salesman approaches you and tells you this:
“Hello Sir! Here is a Tablet, where you can easily configure your new car – with a colour you like, the seats and the power of engine. I will help you with a selection, take care of finances, insurance, everything. And your car will be ready in few weeks – you can pick it up and take your family on nice vacations!”
This is a common situation today – because Car Saloons understood that we want cars to drive them, not to study them.
And I have to say – some Car Companies seems to overload us, drivers, with a selection even today. When I was buying my recent car, I gave up in many configurators, because the number of choices & customizations to be done were overwhelming. But it was only my Cognitive Load. I have many friends who likes that experience and opportunity. For me – it was too much. This is why I drive Subaru now, and they are driving other Cars. Not every car will fit everybody – just like there are no Platforms which fits every case.
Building a Software with a Platform
Let’s assume an average, not-very-mature Delivery Teams – with a strict timeline to do a business application delivery. The Cognitive Load for them is setting-up and maintaining the Environment, but they are experienced with Tekton CI/CD from the previous project they were working on.
They enters the organisation. They submits a jira ticket, where they provide information on the application name, their active directory group, the language of the application, preferable branching strategy & databases to use – and some business details necessary to determine size & locations of end-users. This jira ticket is
In 15 minutes, they receive a complete Delivery & Operational Environment, meaning:
- All of the Team members have an access to a repository for their new application;
- In this repository, they find a demo services with the languages;
- This demo services have a ready-to-use Tekton CI/CD pipelines , which are deploying this demo application to their environments in Kubernetes – up to production;
- This demo services are integrated with Logging, Monitoring, Tracing Toolset; on which team members can log into and define their own dashboards, alerts & filters;
- This demo services are using databases the Team requested;
- And finally – team members receives instructions from a usage perspective for everything.
Having all of this, our Delivery Team can start their work on the app, without waiting, without a need for any config, without in-depth studying all environmental components. They can focus on Business Value.
This is just an example – there can be an abstraction to build such environment by themselves, using Internal Developer Platform. It can be a merge-request to some YAML or JSON definition – finally, there can be a pre-defined components on which delivery team can build their own environment using Terraform. The method we select needs to fit a skillset of Application Teams.
There will be also other Platforms, like API to easily integrate, Data to easily make data-driven decisions, AI to train models… What is necessary – Platform needs to target Cognitive Load. No more, no less. And this is the whole magic behind Platform Engineering.
For my polish-speaking visitors…
All of those situations – and some more details on Operating Models – you can find on my YouTube channel!
