Developer Productivity is top of mind this year—inching its way up Gartner hype cycles under names like ‘performance engineering,’ and ‘platform ops.’ While reaching fever pitch post-pandemic, it may still be another 5-10 years until these solutions reach full potential. Even those providing immediate uplift, like Internal Developer Portals (IDPs), have a long tail of use cases yet to be realized.
But engineering teams don’t need to wait long to see value, provided they start with the right foundations. The Cortex Engineering Maturity Curve was designed to help users extract value from their IDP—and other technologies—at every point on the path to engineering excellence. It’s a reflection of hundreds of customer conversations, a template for optimal onboarding, and a north star for our own product roadmap.
Most importantly, it ensures both Cortex and our customers establish the right foundations to continuing building for years to come. We’ve been incredibly intentional about the direction of this curve, and while many IDPs have begun adopting this flow, we expect many more to do so in the coming months. What’s more, we anticipate a waning of technologies built using frameworks that have not prioritized information architecture with flexible but logical defaults.
Two philosophies shaping today’s IDPs
Before we take a deeper dive into the maturity curve, it’s important to understand how differing philosophies about this space have shaped the toolset in-market today. In March of 2020, Spotify open sourced their tool for eliminating bottlenecks in service-oriented architectures, calling it, “a platform for creating a single consistent UI for your infrastructure and tools.” With the release of Backstage, a new category of developer tooling was born. Importantly, many of today’s IDPs pre-date this event (including Cortex). This fact contributes to a noteworthy dichotomy in IDP development philosophy, which we’ll return to in a moment.
As IDPs gained popularity over the next two years, the exact definition remained a bit murky. It wasn’t until 2022, when Gartner released their Innovation Insight for Developer Portals, that a bit more rigor was introduced—with a qualifying list of capabilities that included service cataloging, creation, integration, and optimization.
Reaching greater consistency in requirements, however, hasn’t proven to drive consistency in how these capabilities are developed, creating confusion about what’s actually most important when shopping for an IDP. Two main philosophies have surfaced, distinguished by the answer to one question: “Should an organization’s information architecture inform developer self-serve experience, or should developer self-serve experience inform an organization’s information architecture?”
Self-Serve-rooted IDPs: Built to prioritize abstracting away complexities in service creation
The first type of IDP was developed to prioritize developer self-service—removing bottlenecks to service deployment, while preserving extensibility. Purported benefits included increased flexibility and developer adoption, but risks included lengthy adoption timelines, and a disconnect between evolving org-wide standards. To address these gaps, solutions in this category like Backstage have begun to “shift left” on the service maturity spectrum by adding plug-ins like cataloging and scoring.
Information-rooted IDPs: Built to prioritize abstracting away complexities in information architecture
The second type of IDP attacked developer productivity by eliminating distractions to development—time spent searching for service information, or resolving incidents related to out-of-date services. Solutions in this sub-category, like Cortex, often start as catalogs and grow over time to include more capabilities for evaluating services and creating new ones. In contrast to self-serve-rooted IDPs, catalog-rooted IDPs benefit from foundations that prioritize information architecture with core primitives—speeding creation of new features without needing to redefine service logic or relationships.
Both types of solutions promote developer productivity, and address a range of personas and use cases. Truth be told, both may one day offer wholly overlapping functionality. The question is how those features will be built. The answer to which will have enormous implications for user experience and time to value.
Starting with the right foundations - The Cortex Engineering Maturity Curve
The Cortex engineering maturity curve traces the path we’ve observed successful engineering teams follow when progressing towards operational excellence. While agnostic to the Cortex platform itself, this curve now heavily influences our product development strategy, and directly reflects our customer onboarding process.
We’ve learned that putting information architecture at the center of an IDP drastically improves self-service experience from both a quality out output and speed of execution perspective. But we’ve also learned that this foundational work (aggregating resources, determining type and granularity of information, understanding ownership, etc) can be hard. It takes time, but unlocks the greatest potential for scale and extensibility when complete As a result, we’ve shaped the entire Cortex experience around making this foundational work as easy as possible—from investing in deep ecosystem integrations with logical defaults to abstract away information mapping, to increasing optionality for decisions like entity type and groups, to an onboarding journey that begins long before you touch a login page.
In the sections below you’ll read more about the engineering maturity curve, and how Cortex supports each phase.
Phase 1: Aggregate
What it is: The first step to accelerating developer productivity is enabling immediate access to reliable, up-to-date information about the services and resources they use every day. Well before templating new assets, it’s important to understand what you already have, where it lives, who owns it, and how each relates to one another. This step is by far and away the most critical for any engineering team on the path to operational efficiency—setting the foundation for all future functionality and workflows. It’s also the most overlooked, and can therefore become the most time-consuming, especially for IDPs that require you to re-define entities, fields, relationships, and dependencies, and/or those that don’t automatically sync information from across your ecosystem.
How Cortex helps: Cortex offers flexibility where you want, with logical defaults where you need. Mapping your information architecture is as easy as leveraging any one of our 40+ ecosystem integrations to automatically sync the entities and relationships that already exist across other tooling. This saves time, but more importantly, preserves consistency throughout your ecosystem.
What this phase unlocks:
Service aggregation and ownership
Dependency mapping
Up-to-date information for incident response
Phase 2: Assess
What it is: Once you’ve collected and categorized your services and resources, it’s time to think critically about their health. If you have existing security and compliance standards, which are out of date? Which pose a risk to the business? If you’re interested in improving efficiency across certain teams, product lines, or offerings, you’ll want to begin thinking about what operational excellence should look like, and how that rubric varies across differing use cases. Service scoring or grading has been noticeably absent from earlier iterations of IDPs focused more exclusively on service scaffolding, but is the most common request from Cortex customers today. Without knowing what good looks like, how can you create templates for new services that have measurable impact to velocity without sacrificing quality or reliability?
How Cortex helps: Cortex enables users to set and enforce standards of reliability, documentation, code coverage, deployment readiness, compliance alignment, and more. With fully customizable scorecards tuned to unique business initiatives or use cases, it’s easy for engineering leaders, SREs, and security experts to define best practice that best suits their ideal operating model, without worrying about restructuring their requirements for a one-size-fits-all approach.
What this phase unlocks:
Audit & compliance
Service maturity
Phase 3: Prescribe
What it is: Assessing the current state of your services is an important step towards service maturity. But as your team scales, use cases expand, scorecards grow in complexity, and initiatives are added with greater frequency, you’ll need a way to ensure compliance while removing any confusion about what to do next. The Prescribe phase is how the maturity curve scales with your organization, without draining your team’s time. It’s also the phase that is most likely to contribute to consistent improvement across all of your service maturity initiatives, and the one most likely to influence developer adoption through both gamification, and ease of action.
How Cortex helps: Outline exact steps users or subsets of users must follow to achieve compliance with an initiative in whole or in part on a specific timeline, with custom notifications to alert the right person, at the right time.
What this phase unlocks:
Increased developer adoption
Service migrations
Phase 4: Act
What it is: One of the final steps in a progression towards engineering efficiency is a repeatable and reliable method for creating new services according to best practice. This phase is what many developer portals were designed to optimize for—even before defining standards for service readiness and maturity. However, when tackled after setting standards of excellence, this phase results in DRYer code, speedier deployments, greater reliability, and a decreased rate of incident.
How Cortex helps: Use Scaffolder to quickly apply approved templates for new service creation. Follow with Actions to configure no-code events that deploy services in a single click, provision resources, and fetch temporary access keys, all in one place.
What this phase unlocks:
Self-service service creation
Workflow automation
Phase 5: Optimize
What it is: To promote a culture of continuous improvement amongst developers, it’s important to provide—in kind—a platform that continually evolves to meet their evolving requirements. This phase therefore becomes incredibly attractive to platform architects, and platform product managers that can own metric monitoring, incremental improvement, and use case extension.
How Cortex helps: Cortex speeds time to action through the Developer Homepage — a curated landing page experience that surfaces all contextual information for developers to take action quickly, in the order recommended, by the date specified. Unlike solutions that treat the homepage as an overview of all services, the Cortex Developer Homepage promotes intuitive action as quickly as possible, even suggesting “low hanging fruit” to improve scores and progress towards critical initiatives.
What this phase unlocks:
Clicks to value
Where we’re headed
We predict the IDP space will continue to expand dramatically over the next 5 years, with new players and niche offerings focused on improving developer experience. At the center of this activity we expect to find this same engineering maturity curve—serving as the new baseline for IDPs wanting to accelerate both product development and customer onboarding.
And while the majority of organizations we meet today might place themselves in phase 2-3 of their maturity journey, we expect the next year to produce the most significant innovation in phases 4 and 5. A wide-spread graduation to these levels of maturity will compel vendors to meet elevated expectations with new functionality for automating complex workflows, intuiting execution, and continually optimizing creation of new, more reliable and efficient services.
If you think Cortex might be able to help you on your own journey towards engineering excellence, schedule time to meet with us today.
