This message was deleted.

Wouldn’t it depend on the most pressing problem with the process in your org and which of those two (or maybe a combination) will make a solid and compelling MVP showcase an improvement and secure further commitment from the piloting team and buy-in from stakeholders?

I agree with Mike. If you follow the Team Topologies approach and treat the whole thing with a product mindset, the answer could be "a wiki page first" if that's what will solve the top need.

@Mike Kotsur you are absolutely right, it all depends on the actual needs in the organisation. For example, platform - enhance infrastructure reliability, portals - streamline developer experience. However, it’s a more nuanced thing in my opinion. Because likely we will face two problems mentioned above. In result, we need to decide where to start, who’s driving the change. Even doing these two (usually by separate teams) in parallel creates a lot of challenges. My humble opinion is to start with the platform first, clean up the mess underneath and provide consistent, automated experience. But I know there are some people who prefer to start with the abstraction first. @Steve Fenton interesting, let me get back to re-reading this part in Team Topologies.

#1: Cognitive Load recognition first

@Bartek Antoniak I think it’s fair to say that the platform is the most natural place to start, especially if you take the point of view: “you always have a platform, even if you don’t have it yet”. But I can def imagine situation when before improving the platform, you want to set up a portal, even if it works as a ticketing system for the platform team. That could, for example be useful, to limit the options and start standardization to address extreme discrepancies in environments used by other teams. Just speculating here, but I think you can see my point.

Just playing this back - this likely already happens in many organizations "by default". A common refrain is: "Please use this Jira workboard to file tickets for this team". You can also add watchers to that backlog and what not

@Jordan Chernev, yes, and it’s interesting to assess the situation and ask/measure what’s exactly wrong with this. I’m sure different orgs will have completely different feelings about the Jira situation, starting from ‘perfect’ to ‘impossible’.

To be honest, for enterprises Jira Tickets triggering Platform Services is not a very bad idea for a start. Everyone has access to jira, there is little risk about spreading the news of the platform (compared to a new portal) etc. Of course once the Platform is mature and we want to have more visibility of deployments, observabikity etc - jira will not be enough. But for a start, I’ve used it multiple times with success

Playing devils advocate a bit - if you were marketing your platform to external users; could you get away starting without a “shiny portal” landing page?

I’d rather do it, but once knowing that there is another bidder focused on fancy portal - but because of it, they will be one month later than me on the market ;) in „internal” scenario alternative to the platform not deployed in time is lack of board support and potential shadow IT (dozen ad-hoc „platforms”). But I am advocating it for large, difficult to change enterprises where IDP is a revolution enough. There, Developers overwhelmed with too many communication and explanations being done before, forced to orchestrate everything would be happy with simple, standardized ticket in such scenario. But again - I am advocating this approach only when there is a significant difference in time between jira ticket & backstage deployment. In small / well organized company, there won’t be. With traditional, large, regulated enterprise - yes, it may be, and then jira is „good enough” for a start. There are platforms I did „by the book” with Portal available fast for developers. There are also platforms I’ve led where Jira was the only option until Platform grew bigger and gained trust of the management. No single success scenario with Platform Engineering, just like no single IDP working for each company

I precisely had this 'discussion' yesterday. We are in the process of setting up a POC for an IDP. We think now, that setting it up as a portal first, structured documentation, search, links to available resources, etc. we have a 'shorter time to market' internally. With the assumption (we will check with a usergroup soon), that there first need is an overview of where to find what. And later extend this portal to a platform with more automation and self service options. The latter sounds like more and complex work and we want to get the users on board to provide us with what they actually need.

@Erik Leonard I’d love to hear how your experience of starting with a “index” portal goes - perhaps you could post back here in the future when you get the initial user feedback?

Sure, I am setting up a workgroup meet in two weeks where we will 'pitch' our assumptions to get feedback on it. As a Platform Team we think we know where the biggest pain is (since we get all the requests). But I want to validate that (and also have a shared goal with the users/user representatives)

You can do a simple Value Stream Mapping with users on how they release feature / bugfix / onboarding. Platform Engineering is no different than any software development, I recommend doing the short functional analysis first - and repeat that over and over. Good luck!