Building an RFP for an Internal Developer Portal

Building an RFP for an internal developer portal

Enterprise-scale digital service offerings and products are often elaborate and expensive pieces of technology that are designed to solve key business problems. Before a business buys or subscribes to any such products, they need to ensure that it serves its purposes accurately in terms of operational efficiency and return on investment. For example, the cost of a standard ERP software system for an SME can cost anywhere between $10,000 - $250,000 per year and more, depending on system specifications and whether it is a custom-made or a standard product. Naturally, buying a piece of technology this expensive requires companies to run extensive solicitation and budgeting processes that are supervised by all key stakeholders.

A standard software solicitation process requires businesses to draft several documents, like a Request For Proposal (RFP), a Request For Information (RFI), and a Request For Quotation (RFQ). These documents help the client company communicate their business needs in minute detail to vendors and request a thorough examination (sometimes including guided demos and free trials) of the software before making a financial commitment. Here’s what each of these documents is used for:

• A Request For Proposal (RFP): Is used to invite proposals for specific business software.
• A A Request For Information (RFI): Is a general request sent out by businesses describing the business problems that they’re looking to solve. Vendors answer these questions with a catalog of solutions that they believe can help solve these problems and boost the overall operational efficiency of the soliciting business.
• A Request For Quotation (RFQ): Comprises documents sent out by businesses as formal requests for a consolidated pricing structure for the products and services they wish to acquire. RFQs are usually sent out as a part of the RFP.

RFPs, RFQs, and RFIs are all part of an elaborate solicitation and vetting process run by businesses to ensure the quality and financial viability of purchases they intend to make. It needs to be noted here that enterprise-wide software solutions like developer portals often take months to implement and integrate with existing workflows. Businesses are required to fully integrate all existing solutions with their new acquisition and onboard relevant employees before they can start using the product. The sheer scale and cost of these purchases warrant a holistic point of view that involves businesses looking at them as long-term business decisions intended to help streamline their operations and generate a net positive ROI within a viable period of time. This makes it all the more important for businesses to generate request documents that communicate their immediate business needs clearly and concisely. To ensure their comprehensiveness and accuracy, the documents also need to be vetted by all stakeholders, including procurement teams, IT teams, and top-level executives.

RFPs are arguably the most important of these documents. Essentially, RFPs are requests soliciting in-depth proposals that cover everything from the proposed architecture and business capabilities of the system to its cost. Because of this need for detail, drafting an RFP often turns out to be a meticulous process that requires close collaboration between development and documentation teams.

Steps for setting up an RFP for internal developer portals

Internal Developer Portals (IDP) are extensive, company-wide resources that are developed with a specific set of business goals in mind. The primary purpose of an IDP is to help increase engineering efficiency and productivity, improve reliability, and accelerate velocity. This makes it extremely important for businesses to ensure that their IDPs are tailored to help with these specific projects with room for future expansion, as and when necessary. Here are the steps businesses need to take to draft a comprehensive RFP for a new IDP.

1. Determine the goals of your internal developer portal

The first thing to do here is to understand what kind of developer portal your business requires. As mentioned above, developer portals are usually tailored to cater to a company’s specific engineering needs. These needs, in turn, depend on the business’s most significant pain points and future goals. For example, let’s say company X has been suffering due to their inefficient development processes for the past few years. Their immediate business need is to help their development teams streamline all development and testing processes and encourage the adoption of best practices across departments. In that case, company X would require a holistic, scorecard-based setup for their IDP with clearly defined service ownership and system health and efficiency scores. Alternatively, another business might need their developer portal to help onboard new developers and introduce them to in-house APIs and services.

Once a clear set of business goals is agreed upon, businesses can work backward to determine what business capabilities their developer portal must have. Once this is done, teams can look to explore more questions about these capabilities, like what changes they envision a particular feature bringing to the development process, how important each feature is, and what are the primary features that the proposed developer portal is expected to have. The answers to these questions will ultimately help development teams draft more comprehensive RFPs that enable vendors to fully understand the business goals and immediate priorities being demanded. One way of categorizing all this information is by assigning a ‘Level of Need’ to each proposed feature. Your options can be:

• Features that are must-haves
• Features that are preferred
• Features that would be nice to have for the future

Critical considerations like automatically updating information onto the Service Catalog and the developer portal being a single, easily accessible pane of glass can be mentioned as separate line items to inform vendors about your top priorities.

2. Break down product requirements

Aside from standard developer-facing functionality, core foundational requirements like security, reporting, scaffolding and standardization, scorecarding, and service quality evaluations need to be accounted for in the RFP you send out. Further, the list of proposed features can often become long and confusing, given the numerous features and product areas that a standard IDP has. Categorization of features helps make the RFP more readable and easily accessible to vendors. It also helps your team ensure that every important consideration is accounted for within the RFP.

One of the most efficient methods of breaking down product requirements in RFPs is arranging everything according to specific product areas. These product areas encompass distinct chunks of correlated services and tools within the developer portal. A standard internal developer portal is made up of three key product areas:

Service Catalog

This is the first and arguably the most important part of any internal developer portal. A Service Catalog acts as a blueprint that tells developers about all the services present within their organization at any given time. Each service holds information like efficiency score, ownership information, runbooks, and other relevant documentation. RFPs for internal developer portals should have a separate section for its Service Catalog that lists all requirements and considerations like ease of access and availability of third-party integration.

Scaffolding Tool

Modern businesses often look to develop self-serve developer portals that can assist with existing projects and also help create new ones. This is where scaffolding tools can help. Scaffolding tools allow developers to auto-generate code, whether adding to existing projects or generating new ones, while ensuring that the code follows the golden path defined by the organization. This makes it easier for development teams to focus on generating business value than spending time working on the plumbing.

Scorecarding

Engineering organizations that are looking to build a culture of reliability, quality, and accountability look to Scorecards as a way to enforce and drive standards across the org. Scorecards should provide out of the box integrations to quickly develop standards without manual effort. They should also be highly extensible, letting different teams build Scorecards that best enable them to drive the standards that are most relevant to them.

Customization and extensibility

This is the part of the RFP where all custom considerations for the proposed developer portal are accounted for. It is a standard practice for modern businesses to tailor their internal developer portals to meet their business needs and goals. At the same time, companies want to equip their portals with tools that can help make them more dynamic and scalable. All of these require flexibility that allows users to customize the portal to assist with solving the company’s specific productivity and organization-related challenges. For example, if a company needs to encourage its employees to use its new Kubernetes platform, it can include custom Kubernetes adoption scorecards in the developer portal. Similarly, teams that want to boost development productivity can include service ownership and process efficiency scorecards that help developers recognize pain points and take active efforts to resolve specific issues.

These are only four of the several product areas that an RFP for an internal developer portal can include. The key here is to systematically list all product requirements in a way that makes it easy for your development team to verify every detail when the portal is being inspected. A highly organized RFP also helps vendors understand your company’s business goals and philosophies much better. It allows them to figure out the non-negotiables, the preferables, and the ‘good to haves’ within your proposed product design without spending time going back and forth with your teams. This can help simplify and quicken the entire process of finding the ideal digital service provider for your developer portal.

3. Pay special attention to third-party integrations

Third-party integrations are key to making an internal developer portal scalable and dynamic. They allow developers to do several things like ensuring code and service quality, gaining deeper visibility into services and development processes using dashboards, and tracking development processes all in one place without manual integration effort from your team.

These capabilities allow developer portals to go beyond being simple information repositories and become dynamic, productivity-enhancing tools that can prove to be a great asset for an engineering organization. This makes it important for teams to ensure that all third-party integration requirements are listed in the RFPs they send to vendors. All of these integration requirements can be listed as line items (with their own ‘Level of Need’ tag) within the third-party integrations section of the RFP. Here is an example to help visualize how this can be done:

Required 3rd Party Integrations

{{table}}

4. Implement advanced data querying and reporting capabilities

One of the key elements of a developer portal, and specifically the service and resource catalogs, is the ability to explore and extract data that has been added to the source of truth. Organizations need to ensure that their catalog is able to answer questions that may arise after building a data store of valuable information, particularly with the third party integrations for services and resources. The querying and reporting capabilities provide stakeholders such as security and TPMs a way to understand the service ecosystem in a way that static wikis do not. It’s important to include details about ad-hoc querying requirements in the RFP to ensure that your portal selection is able to handle the type of data access that your organization needs.

Building RFPs with Cortex

At Cortex, we help development teams gain unprecedented visibility into their architecture and create a culture of reliability and quality. We believe system visibility is crucial to streamlining development processes and driving the adoption of the best standards so that your teams can keep delivering high-quality software at scale. Our pioneering internal developer portal helps team.

• Improve engineering efficiency
• Automate and enforce standards like production readiness and security
• Track service ownership
• Ensure secure and streamlined cloud migrations

These features allow teams to build better, more expansive RFPs that cover everything from current requirements to future scopes and use cases of the proposed developer portals.

Book a demo with Cortex for more details.