Seven key guiding principles for delivering PaaS to drive innovation in Financial Services

At a recent meeting of technical leaders in the financial services community, we picked up on a previous discussion around Platform-as-a-Service (PaaS) and how, under continuous pressure to evolve and keep up with fierce competition, organisations within the financial services sector need to continuously adapt to meet – and even exceed - customer and employee expectations. The attending companies shared their insights and experiences under Chatham House rules and so, whilst we can’t share specifics, I would like to summarise some of the key ways in which PaaS is being used to transform the way innovation is happening in financial services.

The successes that we’ve seen in FS in this field to date have involved a significant commitment from the IT and developer teams at financial services institutions. The teams have to work together in order to ensure that the platform is being used to innovate, with developers encouraged to evaluate and build applications using the new options available. Real success with PaaS can only be achieved through wider buy in across the business, a flat hierarchy so everyone knows what is going on, and a commitment to the strategy, beyond those putting the platform in place. Ensuring that the developer team is open to trying things in a new way, from day one, is critical.

Here are seven key principles emerging in the adoption of PaaS in financial services today:

Start small and build up: In order to drive PaaS success, start with a small pool of people to define how the platform will work within your business. Ensure this team is made up of those within the IT and developer teams, and together put in place systems and processes to define how PaaS should be used. You could also run coding sessions with a select group of coders from your team, pitting them against each other to drive innovation using PaaS. This type of activity is great for driving engagement with new systems at the start of the process and encouraging new ideas for use cases.

Create and test key processes: Particularly when combining PaaS with legacy systems in a “Bi-Modal IT” structure, ensure your team is clear on how and when it is appropriate to use PaaS and build on these circumstances as time goes on and confidence in the platform increases. When new work comes to the team, decide on a case by case basis which is appropriate for PaaS versus the more traditional approach and, as you ramp up usage of PaaS, ensure that there is encouragement from the top to use PaaS to speed up the development of new applications and services. The lead for implementing PaaS should take on a “product manager” role, informing the team as new PaaS capabilities come online and ensuring there is a service statement which outlines how PaaS will work for the business in practice. Organisations should also ensure that developers are working towards building true active/active applications. Building in application resilience from the start is crucial and giving developers a means of testing this functionality is key.

Be prepared for failure, but put measures in place to prevent it:  As part of the development process for business applications, the dev team must have code that can cope with failure anywhere, and have the means of testing for every eventuality, e.g. simulated failure of a datacentre. This will deliver a full understanding of the new IT environment and ensure resilience regardless of the underlying platform.

Embrace a new, app-centric view of security and storage: It’s crucial to have a security adviser in place throughout the app dev and deployment process, to speed up delivery of the new applications, and make the most of the agility afforded by PaaS. A central part of this discussion will focus on data and data access, as this shift in platform will likely result in the adoption of new data fabrics as well as data being pushed and pulled from more traditional data sources. This means that coding teams must change their methodology, thinking about data storage up front, rather than just thinking about the application needs in themselves.

Deal with deprecated functions: PaaS is ultimately about the ability to rapidly develop and update applications. Developers often include open source components within their applications and dealing with changes to open source components is a key part of the PaaS journey. Deprecation of open source features occurs often and assessment of the impact of these is key. If they aren’t vital, then it’s not an issue remove them from your application; if they are vital, move them to the top of the hit list for the next application iteration.

Build for the requirements you have now: PaaS doesn’t always have to represent a long term strategic commitment to a platform, as technology is changing at such a rate. Instead, focus on equipping your business with the agility required to react to the changing environment. Implementing PaaS is a significant step in enabling your business, allowing for changes in the market to be factored in to your strategy for new application development on the fly.

Set up monitoring to review PaaS usage. Once you’ve trained the team building, maintaining and deploying applications on how best to use the PaaS environment, consider how and when the process can be expanded to further app/dev teams at a rate which suits your business. For the IT team, this means educating the team to consider all the options available to them for application development and deployment.

Are you a dev or an infrastructure manager in the financial services community? Be great to get your thoughts on your experiences of working with PaaS in your environment.