 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Graziano Casto, developer relations engineer at Mia-Platform, offers his own definition of platform engineering: “Platforms are a place where people share value.”
He urges us to think about the strategy behind the creation of an internal developer platform (IDP). “Because when we talk about platform engineering with developers or technical people, they are thinking [of] technological stuff,” he told The New Stack at Kubernetes Community Days UK in London in October. “We wanted to bring light on the strategic path a company must take to build their own IDP.”
As organizations rush to adopt an IDP strategy, they often focus on the what — shared libraries, rules, infrastructure, compliance, security — but don’t always stop to answer the why. If a platform engineering team wants to create a platform that serves developers in the long run, it must bring together stakeholders from around the organization.
Mia-Platform created its Platform Journey Map workshop to help teams uncover a common language to discuss the objectives of platform engineering. The workshop brings together product, technology and people, and creates something to revisit as a team’s internal developer platform matures.
A lot of organizations get stuck on thinking of platform engineering as using a platform to tell developers what to do. In reality, it’s quite the opposite. You have to build something developers want to use.
“When you think of platform right now, you think of something that rules DevOps and infrastructure,” Casto said. But in his experience with customers, “companies approach platform engineering by trying to give developers a tool for self-service capabilities.”
As you head down the platform rabbit hole, however, you always want to integrate more and more. That could be infrastructure — which he said is usually the easiest thing to integrate first. Then, different stakeholders want to extend the IDP to integrate data, including data pipelines, catalogs and governance, which then demands security and compliance.
So far, this definition could be the old-school description of platforms that have existed since the beginning of the tech industry. What differentiates an internal developer platform from those traditional top-down platforms, according to Casto, is when an organization reaches a technical level of maturity and wants to use the platform as an enabler for composability.
“They are building over the years something that they want to isolate and could reuse to build something else and accelerate the time to market, to bring new products,” he said. That’s what drove Mia-Platform to create the Platform Journey Map workshop as a way to kick off its work with customers.
The key to unlocking your platform engineering strategy isn’t the what, but rather the how and why.
“The game we created is a brainstorming tool to align tech people with business,” Casto said, to get them discussing “the best strategies to integrate technology and accomplish the business strategic vision.”
Despite its look, the Platform Journey Map isn’t necessarily played like a traditional board game. It’s more of a concept map, Casto said, “designed primarily as a tool for discussion and comparison, helping to define the edges of a strategy.”
But if you read the board clockwise, it flows in the direction of platform maturity, fostering discussion around the following topics:
Not all organizations will follow this journey all the way through to exposing platform features externally. But most will likely have already begun with the first steps of building in the cloud and applying governance to their software development life cycle.
And, as it is the preferred way for developers to consume an internal developer platform, an API-based interface should also be an early part of a platform roadmap. Governance should also be considered early and often.
Interestingly, this platform journey game doesn’t address true platform engineering until about a third of the way around the board. Casto argued that you can’t really embrace platform engineering until governance and software life cycles are defined. Only then can you think about how you are offering these business and technical capabilities in a discoverable and composable way.
In the end, as you explore the gameboard, he emphasized that there is no linear path where your pieces need to follow every step: “Instead, think of it as a map, where you focus only on highlighting what you believe are the true priorities.”
These, of course, will change over time.
One of the challenges of platform engineering is that, as each technical organization is different, so will be its platform strategy. That’s why the workshop brings out different discussions from each group of participants.
Mia-Platform’s workshop has attendees working with real-world examples, each with:
Each participant’s role is in the workshop is to:
One example identikit was a retail company that had a small engineering team supporting online and brick-and-mortar partners, with touchpoints in the American and European markets. Each partner independently chooses its tech stack, which leads to inconsistent and poor code quality. The company is also worried about vendor lock-in.
The established end goal for the platform was to leverage APIs for a standardized user experience across all partners, with a self-service, discoverable interface that reduces burden on the small IT team.
When you’re looking to create a platform engineering strategy, you likely already know your company’s purpose, goals and tech stack — but writing it down is a good way to kick off your own workshop to clarify for everyone involved.
Depending on the size of your workshop, break into smaller groups, while the workshop facilitators act as stakeholders, including developers and C-level executives. Then use this board game as a brainstorming tool to identify priorities. These may include things like:
Different teams participating in the workshop are encouraged to challenge each other.
“You have to explain to me your strategy,” Casto said. Imagine, “I’m a technical [person], so you can talk to me about Crossplane, but I don’t know if my CEO will understand this.”
The workshop attendees are encouraged to collaborate to create a strategy before they put a platform owner in charge of building the platform team to execute it. Within an organization, the workshop ensures that everyone knows who has which capabilities to help identify the best candidates for a platform engineer. That role has to bridge technical and business goals.
This platform journey should consider constraints like budget and time to deliver — the largest factors in the build versus buy debate.
“Say you want to accomplish this in six months, so you have to understand which is the better solution,” Casto said. “Then the [teams] make a strategy to understand which are the priorities and define the power roles.”
Coming back to the retail example, one partner is a greenfield partner, while others are brownfield partners — the group must decide who to integrate with first.
“The last thing that is, for me, the most important part is to understand how to measure the success of your adoption,” Casto said, as measuring platform engineering is a common struggle, yet you cannot improve what you can’t measure.
“It’s important to measure the value you bring to the organization and how you can use this data to spot future opportunities to increase the value of the platforms.”
For each priority, workshop attendees are tasked with choosing KPIs and pitching their use cases and objectives to the other stakeholders.
An internal developer platform is just that, a platform that you continue to build and iterate on top of. Similarly, organizations should run the Platform Journey Map workshop repeatedly, as stakeholder needs will change.
“We have recurring events with customers where we use this tool with them to understand how the adoption is going and where we have opportunities to bring their platform to the next level,” Casto said.
Adapt the workshop to your organization and feel free to skip cells the first go-round. On average, Casto said, he finds the first lap around the map — or the first main delivery of your platform roadmap — takes six to eight months.
“The cells are not strictly defined,” he emphasized. “It’s just a tool to facilitate a discussion with customers, with peers, with solutions architects.”
The Platform Journey Map, Casto said, is meant to complement, not replace, the Cloud Native Computing Foundation’s Platform Engineering Maturity Model. The CNCF model, Casto said, is meant to challenge the platform team, while the map exercise is meant to align all stakeholders.
The game was developed about a year ago because Mia-Platform’s solution architect was finding it challenging to explain the adoption journey of an internal developer platform to customers.
“It’s much easier to explain something visual,” Casto said. As the Platform Journey Map gamifies the IDP strategy discussion, it facilitates brainstorming in order to “guide the path for you or your customer without forcing them to say something they don’t want to say.”
Also read: “How to Host Your Own Platform as a Product Workshop”
