What Developers Want: Scaling Platforms to Meet User Needs
As more and more organizations realize that the migration of services to the cloud, and the adoption of more modular architectures is inevitable, the PaaS-based approach to delivering new applications is growing. For those struggling with innovation due to the restrictions of legacy core systems, platforms offer a vital lifeline as they allow for faster development in secure cloud environments.
But what do developers value when it comes to platforms? In-built tools and processes may be useful for some, but they are not always necessary. Understanding the needs of developers at an early stage is vital to ensure take-up and that platforms are subsequently scaled effectively, and contain the right tools to help developers deliver products to market more efficiently.
Gaining feedback on what developers value with regard to available tools, as well as their overall user experience when building applications, is essential before scaling out. Starting small is the most effective way of establishing what works and what doesn’t. This could mean testing the platform with a limited number of customers, or focusing on a limited geographical location, which ensures that issues are flagged early on before a mass rollout.
Having hundreds or thousands of users is an admirable goal, but it is important to establish the wants and needs of these users as early as possible. A number of factors will inform this understanding. Firstly, the nature of the development will be key. Low-code platforms, for example, are becoming more popular due to their accessible nature. These platforms come equipped with ready-made standardized core components, which makes them ideal for citizen developers or data scientists. By using the components and tools provided, new applications can be created in a matter of minutes through simply dragging and dropping elements using an in-built app builder.
The downside to attaching standardized low-code tools to a platform is that standardization can limit the sophistication of the tools on offer. Take the example of a banking platform. Financial technology firms will most likely form a significant portion of the user-base. As with any technology specialist, these agile firms will have advanced app builders and will be adept at creating complex products using their own technology stacks. For them, low-code app builders and tools present a risk, as they are proprietary technologies and so raise concerns about vendor lock-in. Developers relish the opportunity to use their own preferred tools – so there’s limited benefit in building prescribed tools into the platform itself.
Feedback and Features
To establish which features are most valued by developers, platform vendors should prioritize feedback at an early stage. Neglecting to do so can lead to the building and consequent maintenance of tools and features that were never needed.
Surveys are an easy way of getting structured feedback. In addition, putting in place a community website on which developers can troubleshoot issues, can help to identify common pain points. I would also recommend taking a qualitative approach and reaching out directly to some developers for more direct insights. It is important to have in-built telemetry features in a platform. This not only helps to monitor and audit the technical services, but also helps to build a usage dashboard which can determine almost in real-time the features that are most used, and from which locations.
Collaboration and Open APIs
A great benefit of platforms is that they allow large organizations to collaborate with smaller, more agile third parties. In my experience, the most effective tool for collaboration on these platforms is open APIs, as they allow third-party developers to access an organization’s core systems. This approach allows organizations to retain operational ownership of their proprietary systems, while providing developer partners the opportunity to share their skills and technologies and collaborate effectively to innovate new products and services at pace.
Collaboration is vital for established organizations as they seek to overcome their legacy core systems, many of which have been in place for decades. Creating new applications in-house, using full-stack developers, is both a time- and resource-heavy process. These developers often have their hands full maintaining legacy systems, so directing them to focus on innovating new applications will likely cause issues around work capacity. Of course, ripping and replacing legacy systems with more up-to-date, modular architectures is also an option, but the cost of such upheaval, as well as the high risk of outages, renders such a proposition unviable.
Open APIs solve the legacy problem by allowing organizations to run two development strategies in tandem. Firstly, in-house development will focus on evolving legacy systems, while collaboration with third parties in the open API PaaS environment will assist in delivering new products and services. A further benefit of a PaaS and open API approach is that it also allows in-house developers to build, test and run applications in the same secure environment as third-party collaborators, again removed from the risks that come with building directly on top of legacy systems.
Though users may value using their own technology stack and tools, rather than in-built, standardized core components, there is a need for some standardization. As a best practice, all APIs exposed on platforms should be open standards, such as REST, as this ensures maximum usability, and so truly opens up the innovation environment.
So, while there are many benefits to using a PaaS, the environment must be suited to the developers’ skillsets and needs. Low-code tools within platforms might provide the opportunity to create and deliver immediate value, but if developers want to build more advanced applications, they will seek out platforms that provide full coding environments and robust APIs. Starting small and getting feedback from developers early on will determine what tools they value in the PaaS-environment and so provide essential data when it comes to scaling up.
This article previously appeared on The New Stack.