Whether talking about Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) or Infrastructure-as-a-Service (IaaS), cloud technology is moving at an ever increasing rate. Cloud vendors are able to see what their customers are doing with their cloud products and are thus able to make rapid enhancements to those areas giving most value. In addition, user groups are growing ever closer to the vendors and are a much more integral part of the vendor’s ecosystem, allowing rapid dialogue around product roadmaps and enhanced feature sets.
Those companies who have been highly successful in leveraging their subscribed cloud products are able to move with much improved agility. This is particularly true of successful consumers of PaaS who are delivering features and functionality to their customers daily, with high performers delivering multiple times a day.
This isn’t being achieved by hiring large teams of development resource, this rate of delivery is achievable with small focussed teams because modern PaaS suites enable developers to concentrate on development rather than deployment. Development pipeline technologies, containers, serverless environments and micro services are all underlying enablers that abstract deployment and operation away from the development teams.
Companies are now organising by function where their developments team own particular areas and are responsible for not only delivering new features, but also own the deployment and running of their area. This is essentially the DevOps ethos where the workflow is develop the code, commit that code to a central repository and use an automated deployment pipeline to deploy in a blue/green or canary fashion in line with existing RFC/governance procedures. The deployment layer is abstracted away so that from the developers’ perspective, once the code is committed they can move onto the next development task rather than become embroiled in lengthy, manual change management, deployment and operational handover. Any issues from any given release are owned by the development team and code can be easily rolled back should that be necessary. This ethos is applicable to all types of development in the cloud, be that code in PaaS, integrations in IPaaS, data management in DaaS (Data-as-a-Service) or functions in FaaS (Function-as-a-Service).
However, that is not to say the landscape becomes uncontrolled. Rather governance is improved by clear visibility of code repositories with access restricted via permissions as well as clear audit trails detailing releases and rollbacks. These automation capabilities should augment existing business controls for testing and sign off, such as a Change Advisory Board (CAB).
Increasingly, low code is becoming prevalent when discussing cloud platforms particularly within the IPaaS space. It is also starting to gain traction within the PaaS space. There are productivity advantages to be taken here as low code not only offers the opportunity to increase the productivity of existing developers but also allows a spread of the overall development workload by allowing “citizen” developers to produce new, less complex features. Across the organisation this allows increased total output.
For institutions, the conversation becomes less about what language we (re)develop in, whether we use a low code environment or what runtime containers we use and becomes more about how we could structure and improve working practices to take advantage of the agile processes these modern platforms allow.
In summary, increased developer productivity is essential if institutions are going to maintain a competitive edge to their digital offerings. With organisational costs under strict control, increasing resource is often not a viable option so institutions must look at other ways of increasing the productivity of their existing pool of resources. The way to do this is to automate out non-value add tasks allowing focus on delivery of new and innovative features. Thus procurement of any development platform should have this as its central tenet.