Considerations when implementing developer portals in regulated enterprise environments

There is a trend in the industry at present around developer experience. At the center of this is the developer portal. This concept is not new. Many enterprise environments have created their own platforms and tools that help streamline the process of getting teams coding faster in environments where everything is not easily accessible. 

There is also a large movement within the industry to provide frameworks and tools that build developer portals. The leading framework in this arena, Backstage.io, states on its website that a developer portal “restores order to your infrastructure and enables your product teams to ship high-quality code quickly.” These are very noble goals, much needed in many environments. 

However, if the portal is built quickly and executed without actually integrating or solving issues specific to that environment (regardless of what was used to build it), it can result in wasted time and resources. When considering implementing and operating a developer portal in an enterprise environment, there are some important questions that should be considered.

In this article, I will try to answer some of these questions and share some of my experiences with developer portals in regulated enterprise environments. I believe it is in environments such as these that developer portals have the greatest potential to be helpful.

[Related reading: Red Hat joins the Backstage.io community]

A little about me and the focus of this article

I have been lucky enough to be involved in creating two platforms designed to make developers more productive in a regulated enterprise environment. 

“Enterprises” are interesting and distinctive environments. They are the original technology innovators and, as a result of decades of running software, human structures have formed around enterprise technology that can make their workflows time-consuming and their environments complex (for more details, please see the blog entry: Modernization: Why is it hard?)

The term “regulated” is also interesting. This means that third-party entities have a say in how these enterprises use technology and can potentially impose fines if they feel standards are not being met.

If you combine “enterprise” and “regulation,” a culture starts to form where there are often many processes and procedures that can’t easily be changed when building and operating software. In my experience, working more effectively within these constraints is the best path forward.

I will be specifically focusing on regulated enterprise environments in this article.

Why build a developer portal?

Let’s start with the high-level idea of shipping code faster and getting infrastructure under control. Enterprise organizations are in a constant struggle to acquire and retain talent while operating the software they already have, building new software and not getting fined or publicly called out for a software issue in a critical system. Here are some high-level concepts of the benefits a developer portal can provide while taking these challenges into account.

Faster to market

At the end of the day, companies want applications that can give them a competitive advantage in production. Some might be internal applications that support internal initiatives (which are hopefully well aligned with value), others might be external applications that paying customers use and publicly evaluate. The window to take advantage of a competitive situation can often be short for publicly available applications.

For example, in these turbulent times of rate hikes, rising food costs and out-of-control housing prices, there are obvious short-term opportunities for savvy financial institutions to release software products that can help clients either get out of bad situations or benefit from sudden changes. Such products could result in massive financial gains and increase a company’s software reputation, attracting more talent their way. However, none of this is possible if teams are left waiting for weeks to get the tools they need to begin coding. A developer portal can be very helpful if it takes some toil out of giving teams what they need to start producing software.

Risk mitigation

If the enterprise is regulated—and most likely publicly traded—the risk of failure and loss of public confidence is a real concern. Lots of processes can often form to protect the company from this happening and, although one might argue that the processes are cumbersome, the risk that these processes mediate is real. Sadly, these processes conflict with the goal of moving faster. The developer portal can assist by correctly interweaving complex standards for code/configuration/environments for production that might not be fully known or understood by the average developer in the organization. 

Talent retention

Top talent is a challenge to recruit. If you advertise with the right buzzwords, you will get hundreds of résumés. In my experience, for every twenty résumés you read, only one candidate will be worth interviewing. When top talent is placed in a situation where they are endlessly waiting on tickets and/or meetings or told they can't get their code live because something was not addressed (that no one even made them aware of), you can bet they will start updating their résumés. This can be devastating because the costs in money and time to hire are very high.

Enabling top talent to produce easily allows enterprises to build and maintain their reputation. The developer portal may just be a quick stop for your top talent on their way to getting code moving to production, but, if done right, that quick stop could save weeks of frustration.

If a developer portal speeds up production, reduces risk and retains talent, it sounds like a no-brainer to build one for your teams. However, the devil is in the details.

How to starting building your enterprise developer platform

The benefits of a developer portal are compelling, but how should you approach building one? It’s important that your portal doesn’t become an exercise in busy work and that it actually reduces enterprise-specific pain points to achieve the benefits of speed, reduced risk and talent retention.

Include enterprise-wide stakeholders from the start 

In a siloed enterprise environment (especially one that is regulated), it’s not just developer teams that are involved in getting software to production. There are many stakeholders company-wide who will get involved at some point of the process. A useful exercise prior to starting might be to chart every team involved in getting an application into a production environment, and how they interact with other teams (ie: tickets, meetings, emails). With that knowledge, a developer portal can help streamline their inputs and oversight in a way that is less disruptive to teams trying to get to production.

The two most common non-developer teams are operations and regulation and compliance.

Regulation and compliance teams

Auditors, security analysts and architecture teams (perhaps ensuring there are no anti-patterns in code being released) could all have a say in how and when software can be deployed. In the event of uncertainty, these teams could enforce a ticket process so nothing gets into production without their explicit, granular oversight, or they could impose additional (and time-consuming) meetings and reviews to alleviate their concerns.

The developer platform can become valuable to these teams if it provides observability of things like change history (including who did the changes), scans being completed, results or use of the right infrastructure and configuration. A developer portal can also help rule out concerning patterns. Sometimes a whole process might exist to ensure a specific application is not deployed into a specific environment. By just ruling this possibility out through the developer portal, lots of tickets and meetings can be avoided.

Further examples of the benefits a developer portal can deliver are:

• Assurance that all key information is put into an enterprise-accepted immutable system and everyone who needs to access that information has it.
• Verification of separations of duty (i.e., the person who wrote the code is not verifying its integrity for a production release).

As a developer, you might roll your eyes at some of these processes. Why even have this stuff or these people? But remember that these processes are a response to historical risks and are hard to get rid of. A developer portal can interweave them into workflows in a less disruptive way.

Operations team

The DevOps movement has helped to improve culture around how software is built, tested and deployed. But the operation and updating of production in regulated enterprise environments are often still out of the reach of the teams developing the software. The SRE (site reliability engineering) movement is poised to improve this, but many organizations are still building these capabilities up.

There is a good chance that the operations team is a separate silo with little context about what the application does. Why does this matter? Well, in some environments the operations team can throw some curveballs when it’s time to get an application to production, and this could catch a dev team off guard. Often to help prevent this, there might be a process of meetings and tickets that end up becoming draining for the teams trying to code the release.

A developer portal can help by, for example, doing something as simple as adding some observability around who (a collection of active directory groups/permissions) is building what (a combination of runtime and target environment) early on in the process. However, the enterprise generally already has the tools to do all this. The missing step is often weaving these existing tools in the right place and making the inputs to these systems easier. A developer portal is the perfect place to do this.

Target the developers who need help the most

“Developer” is a very generic term. In some large financial service organizations, there can be thousands of developers with varying degrees of skill or experience. These can be separated into some rough categories. Keep in mind, not everyone will fit cleanly into these categories, but they are useful to help identify the characteristics of the developer who will benefit most from a developer portal in an enterprise environment:

• Overachievers: All environments have those that are able to get good results quicker than most other developers. They might often invest their personal time to make things work (which accounts for some of their results) and will be the first to come up with solutions for problems without anyone having to assign them to the task. This is a rarer commodity. This type of developer might balk at a tool that makes decisions for them. 
• Average developers: These are the developers that get the job done, but do not produce the same level of results the overachievers do. This could simply come down to them not as interested in investing their own time to work on projects or learn new skills. A workflow that makes decisions for them to get their work done faster could be very welcome.
• Specialists: Developers with narrower areas of expertise, for example, a React developer may struggle in other areas (e.g., configuring a Jenkins pipeline). A developer portal can be a lifesaver for specialists if it gets them moving in their area of expertise with less frustration.
• Contractors: At any given moment there can be thousands of contractors in an enterprise environment trying to produce code to meet tight deadlines. Often, a developer coming from a vendor will be totally new to the company and unfamiliar with the policies and people they need to work with. They might be overachievers, specialists, average or entry-level. Yet, they will have a timeline to deliver and will bill the company for each hour worked. Certain workflows in a developer portal can be invaluable to getting the most productivity from contractors.

Developers who build the portal and the developers who use it

It's been my experience that developer portals are often built based on feedback from overachievers. But are they the right people to determine how to help personas they might not even agree should be around (ie: consultants)?

While the overachievers can provide a lot of valuable input, they also usually don’t need (or want) help as much as other types of developers. This means they might not have the same perspective on what’s important when offering feedback (for example, they may accept an approach that has a steeper learning curve, expecting others to invest their own time to learn it). They can be very helpful when it comes to implementing the workflows in their environment, as long as they are interested in the outcome of the developer portal (and not just building for the sake of building).

You want everyone to benefit from a developer portal, but it’s important that it is primarily built for those who will benefit from it the most. In other words, the developer portal should be targeted at those who might struggle to get code to production in your company, most likely the average developers, some specialists and contractors.

Solve pain in your environment

Developers may not be happy about yet another tool for them to learn unless it makes their lives easier. The first step to building a successful developer portal is understanding developer pain in your environment and then solving for it.

A real and thorough assessment needs to be done on how to get from code to production in your environment. This needs to be a hands-on-heart review of what the environment is, not what the team wishes it was. Specifically, map out the following:

• Time required to complete each step
• Touchpoints required (tickets, meetings, emails)
• Step difficulty (a simple scale of easy, moderate, difficult) 
• Step approval and recording

Somewhere in this analysis, friction points that can be solved in a developer portal workflow will surface. For example, it might be a learning curve around a homegrown permissions tool that is affecting the workflow, making it time consuming to get the necessary tools. In this case, find a way to measure the pain (i.e., time to an outcome), then determine how the developer portal can improve upon it. It's important that you measure data to show this improvement. In this way, you can ensure that the developer portal provides value, and the team will want to use it.

Be cautious when tightly coupling to tools and runtimes

Sometimes you will have no choice but to tightly couple to a system or tool. However, tools and runtimes are always changing. Vendors get acquired, pricing gets too high and technology shifts to newer and shinier things. Ensure the workflows in your developer portal are as flexible as possible so that they don’t add to lock-in. The last thing you want is your company to be stuck paying for an expensive tool they desperately want to get rid of, because doing so would require a rewrite of the now-successful developer platform, used by thousands of developers.

Up and running: optimizing success

Let’s say you have launched a developer portal. You’ve targeted the right people, included workflows from the stakeholders who are pushing for tickets and meetings and addressed the pain points in your environment. But even with all this, how can you tell if your developer portal is a success? How can you maintain the best chance for consistent funding?

Constant measuring of success

If your goals are to be faster to market, mitigate risks and retain talent, you will need to track data to show how the developer portal is helping achieve these objectives. The speed at which a development team can move through a software feedback loop (code–deploy–test–observe–repeat) across environments (dev, qa, uat) to production is one measurement. Updating and improving software already in production could be another. Other gauges might be vulnerabilities detected in environments, the satisfaction of teams using the portal (before and after) or time spent in meetings before and after.

The type of metrics that you track will be specific to the concerns and goals of your company. Time should be spent to understand these concerns. The good news is that enterprises often have a plethora of tools to capture this data. The developer portal can become the place to tie these disparate data points together into a cohesive story. 

Be prepared for resistance and questions

Not everyone will love your developer portal. But maybe not everyone needs to. What’s important is that you have identified and solved pain points for the developer teams that were struggling the most, and you can show how they have improved. After launch, it is key to stay in touch with the development community to ensure the portal is kept in line with their goals and needs (but don’t forget the developer persona you built it for).

Unfortunately, internal budgets are usually tight in enterprises, and the competition for that money is high. Always be ready to show how the teams who truly need help are getting it, and demonstrate with data how the result is benefiting the enterprise. Some tips on making an internal business case can be found in this blog post.

Be prepared to be blamed for everything

Depending on the workflows created, your developer portal might end up being the front door to a lot of tools and systems. There will be issues that occur beyond anyone’s control (e.g., network outages, unexpected security vulnerabilities). If one of the underlying tools in the portal fails and a workflow stumbles, the developer platform itself will be blamed. The team supporting the developer platform in production needs to understand and expect this. It’s important to build in lots of observability, so it's clear what is working under the covers and to communicate with users so that they know when workflows are affected, why they are affected and when they will return to service.

Be creative when dealing with existing processes and teams

Ideally, you want to get rid of unnecessary tickets and meetings. But be aware that some cultural aspects might be hard to change. Think about how you can make improvements around these cultural bottlenecks.

If you hit an aspect of workflow that requires input from another team or tool, yet there is no API or system to integrate with, be creative. Open Jira tickets and assign work to increase visibility. Even having the system send an email to someone with all the necessary information (rather than making a frustrated developer do it) can make a difference.

Conclusion

Any developer will tell you there is nothing more satisfying than getting your code into production and seeing those first few successful operations or transactions. It makes all the pain, late nights and gallons of coffee worthwhile. 

Conversely, there is nothing more frustrating than putting all that work into a release only to find out it will never see the light of day. Or worse yet, you struggle to get started because you spend all your time waiting for access to an essential tool or system.

When a developer portal is focused on the people who need help the most and is inclusive of the gatekeepers to production, it makes it much easier for developers to achieve their goals. It will also provide a significant competitive advantage to enterprises looking to get software out in the world quickly, without risking their reputation or customers.

I hope these thoughts and observations can help guide your developer portal journey.

Learn more

• Red Hat joins the Backstage.io community