How can different user personas get the best out of an internal developer portal?

The internal developer portal can help serve the needs of numerous user personas, and can even be configured to meet the requirements for multiple persona use cases.

Portal for Personas

The clue is in the name - an internal developer portal is for developers, right?

That’s true, but developer portals aren’t only for developers. In fact, portals can benefit a number of other personas including product owners, managers, SRE teams, DevOps, and more. 

Actually, if you take a product mindset when defining what to include in the portal, you can serve each one of the personas described above. This means engaging with all of the personas and determining the best way to provide them what they need in a portal and platform. The portal can then help to deliver solutions for these pain points by abstracting away complexity and providing meaningful visualizations for each persona. 

This would truly make the portal the central point of reference for anything platform engineering in your organization, maximizing your investment into the approach. In turn, you would reduce cognitive load as well as simplifying and standardizing the SDLC for everyone, from code to production, regardless of their role in the organization.

Using Portal capabilities to create user-centric views and actions

Incorporating a persona-based approach in a developer portal involves tailoring the experience to meet the specific needs of different user types or 'personas'. 

Port offers three building blocks aiming to create a personalized experience. The trick is to think about each persona and their needs, using the portal-as-product approach.

Personalization in Port is about taking the enormous amount of data coming from the engineering organization and making it usable and accessible to different users, with the ambition of providing a smooth, product-like experience that anticipates their needs and doesn’t burden them with the information they don’t need.

Personalized dashboards and homepages

By allowing each user type to have dashboards that reflect their specific needs and priorities, the portal provides meaningful insights and quick access to necessary information. These dashboards can be configured to show relevant metrics, scorecard statuses, open initiatives, or operational alerts, depending on the role and interests of the persona. 

Personalized self-service actions

Port allows you to create the right self-service actions for each persona, controlling form elements, manual approvals,the data shown to the user and more. This means that you can define different golden paths, inputs, levels of abstractions and more for different self-service actions for different users.

Folders

Rather than having to trawl through large numbers of pages within the software catalog, Port enables admins to curate portal pages into folders for specific use cases or teams. This means that the information aligns with the specific workflows of each persona. As a result, each persona has their own customized space within the portal with their specific dashboard pages, catalogs, etc.
You can arrange folders by teams, use cases (e.g. cost management), roles and more.

Role-Based Access Control (RBAC)

Port supports no-code RBAC that lets you define access permissions based on user roles, and ensures that each persona sees only the information relevant to their responsibilities. 

A DevOps engineer will want to see ample K8s data, for instance, while a developer will need that data to be abstracted for them, to avoid cognitive load. Indeed, as Viktor Farcic mentions in “mistakes when building internal developer platforms” one of the primary roles of platform engineering is not to consolidate all the data and toss it at developers, but rather to carefully consider how to abstract the data, making it both accessible and meaningful, within the role of the specific user.

Taking the portal-as-product approach to determine what personas need

One of our favorite answers for ‘how to customize the portal for personas?’ can be established using a portal-as-product approach, taking the “jobs to be done” framework as in:

“As [role] I would like to [do something]”. 

So, for instance, an engineering director may want to see a scorecard status of all services and all teams, while an engineering manager would want to see scorecards of each service, and a backend engineer will want to see scorecards for their services. 

It’s important to keep the different jobs each role is trying to fulfill in mind when defining the structure of the portal.

But what does that actually mean for all of the different personas? What are the use cases for them to get the most out of an Internal Developer Portal? Here are some examples we’ve seen from Port customers:

‍*Note that some of the use cases may apply to multiple personas, and the Portal can be configured to meet the requirements for multiple persona use cases*

Managers

Cost Management

Cost tracking is a notoriously difficult problem since while companies do track cost data, it is almost impossible to show that data within the context required by both managers and developers - for a specific service, in a specific environment or context.

Using Port, managers can:

• Integrate with FinOps tools or use cost data to get a view of the organization’s cloud computing infrastructure and costs as they relate to services, environments and more.
  
• Get a real time snapshot of all the costs within the engineering environment and attribute the cost to the right microservice and developer based on the definitions you’ve set in your data model.
  
• Create scorecards so that they can track costs in context: by developer, team, service and environment. They can set budgets for teams and services, get alerts for cost overruns and get a grasp of the costs and headcount associated with service migrations between teams. That same information can also be presented to developers - setting goals for cost reduction and making them aware of the cost implications of their actions.

Improve Production Readiness, Code Quality

Engineering organizations are always looking for ways they can establish clear standards of quality and maturity to drive alignment across teams. This is exactly what scorecards - benchmarks for each element in the software catalog - are made for. 

Using Port, managers can:

• Use scorecards to define and measure metrics for quality, production readiness, and developer productivity. 
• Compile scorecard data that is persona or use-case specific into dashboards that show what’s going on and allow for drill down when needed.
  
• Use scorecards to support initiatives and campaigns - set by managers - to improve production readiness or quality testing practices. This enables managers to clearly communicate standards, drive compliance, trigger actions when a scorecard is degraded such as freezing a deployment and track  DORA metrics, ownership and documentation.

Drive Security & Compliance

The portal consolidates and showcases vulnerabilities and misconfigurations across various tools and stages in the development life cycle, all in one place, becoming a centralized hub for security information. 

Using Port, managers can:

• Gain a holistic view of potential risks, enabling them to understand the security state of a resource or microservice within a certain context and then be able to address vulnerabilities and misconfigurations proactively, using developer self-service actions.

SRE teams

Single Source Of Truth

While SRE teams have a different toolkit to developers and DevOps, they too can have issues with tool sprawl and getting the desired information that they need. 
SREs need numerous tools in their armory - from APMs, incident management and observability tools. 

Using Port, SREs can:

• integrate the portal with these core SRE tools, making it easier for SREs to find the information they need with the additional context necessary to investigate incidents. 

Keeping Track of Standards

SREs rely on metrics that reflect an application’s performance or system health.

Using Port, SREs can:

• Use scorecards to gain access to metrics such as mean time to resolution, which can support their efforts in ensuring that services are meeting standards.
  
• Aggregate information from multiple tools in one scorecard.
  
• Define actions and establish standards for developers.
  
• Manage timelines for company initiatives such as migrations, from the portal. 

DevSecOps

AppSec Posture Management

Managing security vulnerabilities is a continuous task; it shouldn’t be left to DevSecOps to manually check for vulnerabilities in the various stages of the software lifecycle. 

Using Port, DevSecOps can: 

• Use the software catalog and visualization capabilities to locate and visualize what CVEs are in production and where as they integrate data from multiple sources. This means they can retrieve answers in seconds for questions such as ‘is Log4J in production and where?’ and ‘who is the owner of this specific CVE?’. 

• Visualize IaC misconfigurations in production. Having all of this information easily viewable means AppSec developers can better prioritize which CVEs and misconfigurations they need to attend to.

Developers

Perform Actions Without Assistance or Tickets 

Developers are often left having to fill out tickets to get the information or access that they need. This slows down the entire development process.

By using Port, developers can: 

• Automate dev to production workflows as Self Service:
  Scaffold a new service with all of its CI and tests in a single request, deploy a resource or spin up a developer environment. Gain autonomy and be more productive.
  
• Gain temporary permissions to databases, repos, Kubernetes namespaces, environments, cloud
• Use IaC without needing the in-depth domain knowledge
  Deploy resources to the cloud with a developer self-service interface with IaC under the hood, so you don’t need the in-depth domain knowledge usually required to interact with IaC. Instead, you just fill in a self-service form to inject the right data to IaC. Port abstracts all the rest and then injects the relevant inputs into the IaC file and git commits. Devs can then create resources as a self-service, deploy a new wordpress site to the cloud in a single request and spin up resources. 
  
• Maintain enhanced security, as self- service actions are defined using the RBAC mechanism. This also streamlines the user experience, preventing information overload and creating golden paths.

Manage Alerts and Incidents 

It’s common for developers to receive an increasing number of alerts from dozens of tools. It’s therefore difficult to understand the level of risk if something were to fail, so that certain alerts are prioritized and can be reacted to swiftly.
Using a portal, engineers can describe the entities they want in the software catalog, and can include alerts as part of it.

Using Port, developers can:

• Get a single pane of glass for all things alerts, in-context within the relevant software catalog entity and with all the relevant information required, such as the service, logs, or resource owner. 
• Get the information they need to investigate and understand which alerts to prioritize.
• Easily track the status, health and KPIs of their services using dashboards which present alerts from a number of applications and systems so they don’t have to move between different systems.
• Be selected as on-call rather than being alerted through a broader alert channel. They can then use self-service actions - actions that don’t rely on tickets or assistance - to act on the alert and remediate issues. 
• Benefit from pre-defined on-call developer self-service responses, so they can act against production environments quickly. 

See Services in K8s Context

The rise of cloud native and kubernetes created an increase in the complexity that developers need to be aware of in their ordinary flow of work. This presents more tasks and cognitive load, affecting productivity, and also making it difficult for developers to understand where their apps are running, what is deployed where and whether any changes are required for services to run as they should. (The same could be said for DevOps engineers).

Using Port, developers can:

• Gain visibility and understanding of what is actually going on in K8s. See who owns a service, where it’s deployed and also understand quality and standards with regards to K8s. 
• Use self-service actions so they can work independently and stop using email or slack messages to request DevOps support.
• Find the Kubernetes resources they need and better understand where services run, explore issues and troubleshoot, view K8S usage and details such as the cloud or domain they’re in, and get K8S metrics.

Manage Your Internal APIs

With the rise of microservices comes the rise of APIs. But it can be difficult for developers to find the information about APIs that they need - and this can negatively impact their productivity. 

Using Port, developers can:

• Use an API catalog which has been integrated into a software catalog to help developers answer questions about any API such as:  What is the average response time of this API? What was the last response time for this API? How stable is this API?
• See APIs of every published application (preventing them from redeveloping an endpoint that already exists), visualize service interdependency (both downstream and upstream) and understand how a misbehaving API affects services. 
• Use scorecards to keep track of organizational standards and best practices, and ensure the various APIs in the organization adhere to them. 
• Gain additional context into the APIs provided and consumed by services through the software catalog. 

Product Manager

Manage Feature Flags

Feature flags can help deliver new functionality to users quickly and safely but they’re complex to manage.

Using Port, product managers can:

• simplify feature flag management in a number of ways such as: using feature-to-service in production as a self-service, tracking feature flags in production, approving flags, managing flag triggers

Understand and Manage APIs

Keeping track of the huge number of APIs can make it harder for product managers that want to test a product’s capabilities or implement a new feature. 
Using Port, product managers can:

• Use the API catalog to better understand internal APIs and access API documentation and specifications. This can help them when testing current product capabilities or when planning to implement a new feature. 

Provisioning Environments to Test New Features

From time to time, product managers want access to features that are currently in development. This way they can test the feature or showcase the feature to a prospective customer.
Using Port, product managers can:

• Provision a new environment based on a specific development branch of the new feature, so that they can test it or demo the product