Blog
/
/
Crafting an RFP for your internal developer portal
Internal Developer Portal

Crafting an RFP for your internal developer portal

Feb 28, 2024
Netta Borowitsh
Internal Developer Portal

Crafting an RFP for Your Internal Developer Portal

TL:DR: here are the items your internal developer portal RFP should list. 

We’re in the times of platform engineering. 

As a result, engineering organizations understand the pivotal role of internal developer portals in making a new developer experience that can unlock productivity and drive better engineering quality. These portals serve as centralized hubs where developers access tools, documentation, and resources vital for building, testing, and deploying applications within an organization.

Some organizations require the creation of a Request for Proposals (RFP) for an internal developer portal. This document should not only outline your organization's requirements but also serves as a blueprint for selecting the right solution provider to provide the internal developer portal that best matches your engineering DNA and platform engineering needs. 

At its core, an RFP for an internal developer portal should encapsulate the essence of your organizational objectives, technical prerequisites, and desired functionalities. 

The RFP should drive collaboration between stakeholders across various departments, including IT, development, operations, and security. By fostering open dialogue and soliciting input from diverse perspectives, organizations can ensure that the RFP encapsulates the collective wisdom and aspirations of the entire ecosystem, thus paving the way for a more cohesive and inclusive selection process.

What should the RFP for internal developer portals cover?

To achieve this objective, internal developer portals must embody certain core elements, approaches, and features.

1. Portal as Product Approach: The portal should be viewed as a product for developers, with an intuitive interface that reduces cognitive load and addresses user need effectively. Collecting insights from developers is crucial to refining the portal's features and functionalities continuously. 

2. Support End-to-End Developer Experiences: Developers should find all necessary resources and information conveniently within the portal throughout the software development lifecycle. From planning and development to deployment and production operations, the portal should offer comprehensive support and streamlined workflows.

3. Flexible Data Model: The portal's architecture should accommodate the unique needs and processes of different engineering organizations. It should allow for the customization of metadata schemas, support an open approach for data ingestion, and facilitate the evolution of the data model alongside changing requirements.

4. Personalized and Customized Experiences: The portal should enable personalized experiences tailored to various teams, roles, and personas within the organization. Granular role-based access control (RBAC), customizable dashboards, and organized folders contribute to a more user-centric experience.

5. API-First: All portal functionalities should be accessible through APIs, promoting interoperability and automation with platform tooling. API-first design facilitates seamless integration with external systems and enables developers to leverage portal data programmatically.

6. Automation: Leveraging real-time data from a centralized software catalog, the portal should support automated actions, such as notifications, alerts, and DevOps workflows. Automations enhance operational efficiency and enable proactive response to changes and incidents.

7. Portal-as-Code: Configuration and customization of the portal should be manageable through code using infrastructure-as-code (IaC) tools like Terraform. This approach ensures consistency, version control, and auditability of portal configurations.

8. No-Code RBAC: The RBAC model should be easy to configure without requiring extensive coding efforts. Granular policies and permissions should govern access to data and self-service actions, ensuring compliance and security.

9. Quick Time to Value: Organizations should prioritize rapid deployment and iteration of the portal to deliver immediate value to users. A community-driven approach, unified UI, and extensibility facilitate quick refinement and scaling of portal capabilities.

10. Secure by Design: The portal should use robust security to let you use it as SaaS without any reason for concern.

In essence, the recipe for internal developer portal success lies in combining these foundational elements while accommodating the specific needs and dynamics of each organization. By adhering to these principles, platform engineers can design and deploy developer portals that foster collaboration, enhance productivity, and drive innovation within their organizations.

To access the RFP list - click here.

{{cta}}

Book a demo right now to check out Port's developer portal yourself

Book a demo
{{jenkins}}

It's a Trap - Jenkins as Self service UI

Read more
{{gitops}}

How do GitOps affect developer experience?

Read more
{{ebook}}

It's a Trap - Jenkins as Self service UI. Click her to download the eBook

Download eBook
{{cyberark}}

Learning from CyberArk - building an internal developer platform in-house

Read more
{{dropdown}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

Microservices SDLC

  • Scaffold a new microservice

  • Deploy (canary or blue-green)

  • Feature flagging

  • Revert

  • Lock deployments

  • Add Secret

  • Force merge pull request (skip tests on crises)

  • Add environment variable to service

  • Add IaC to the service

  • Upgrade package version

Development environments

  • Spin up a developer environment for 5 days

  • ETL mock data to environment

  • Invite developer to the environment

  • Extend TTL by 3 days

Cloud resources

  • Provision a cloud resource

  • Modify a cloud resource

  • Get permissions to access cloud resource

SRE actions

  • Update pod count

  • Update auto-scaling group

  • Execute incident response runbook automation

Data Engineering

  • Add / Remove / Update Column to table

  • Run Airflow DAG

  • Duplicate table

Backoffice

  • Change customer configuration

  • Update customer software version

  • Upgrade - Downgrade plan tier

  • Create - Delete customer

Machine learning actions

  • Train model

  • Pre-process dataset

  • Deploy

  • A/B testing traffic route

  • Revert

  • Spin up remote Jupyter notebook

{{tabel-2}}

Engineering tools

  • Observability

  • Tasks management

  • CI/CD

  • On-Call management

  • Troubleshooting tools

  • DevSecOps

  • Runbooks

Infrastructure

  • Cloud Resources

  • K8S

  • Containers & Serverless

  • IaC

  • Databases

  • Environments

  • Regions

Software and more

  • Microservices

  • Docker Images

  • Docs

  • APIs

  • 3rd parties

  • Runbooks

  • Cron jobs

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

Contact sales for a technical product walkthrough

Let’s start

Open a free Port account. No credit card required

Let’s start

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start

Contact sales for a technical product walkthrough

Let’s start

Open a free Port account. No credit card required

Let’s start

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start

Let us walk you through the platform and catalog the assets of your choice.

I’m ready, let’s start