Last week Daysha attended Fintech:CODE in London with our good partners Atlassian where we were in the company of some of Europe’s leading banks. This blog summarises our learnings under three categories for those with an interest in DevOps and particularly for those in Fintech. Daysha also attended the Fincode 2018 event in partnership with XebiaLabs.
Adapting to a DevOps culture is still the biggest challenge for many companies in the financial sector. It’s not just IT people that resist change, more often than not it’s the business who think agile is just for IT folks. If the business is not driven to change in tandem with IT then initiatives will founder.
Where you see a strong business leader DevOps takes hold. Some large European banks have recently appointed new CEO’s with determination and vision. They have championed the implementation of agile for business and DevOps for IT and this has permeated through the organization. If DevOps initiatives cannot be aligned to business vision and outcomes there is a possibility that the conversation can turn into a religious war between agile and waterfall.
For organisations that are on the journey psychometric testing of new employees may be important to create new culture. Bringing in staff for their special technical skills without ensuring they are a cultural fit to the company can cause tension. It is integral that each member of the team has a shared understanding of DevOps.
Transformation change managers from a large multinational bank had some advice for those moving towards a DevOps culture.
- Act your way into a new way of thinking, don’t think your way into a new way of acting. Don’t wait to get training. Cargo cult can be a step in the right direction but important to identify this problem early.
- Create a picture of what good looks like by visiting or researching organisations that are further ahead on their agile journey. Don’t reference Spotify or Facebook. They don’t have legacy and have a different set of issues relating to how to put governance in place as they wish to IPO.
- Disciplined agile is enterprise aware. There is a tension between autonomy and visibility. The agile manifesto puts people before process but management needs visibility that is unobtrusive in order to plan. Disciplined agile says that there is a common set of processes so that tools can capture data as work flows left to right. This data informs management about where the next bottleneck is.
- Create flat structures. CTO has 2 x ‘n’ reports, Product Owner (what) and Architect Owner (how). ‘n’ could be a division or a program.
- Nurture culture – Invite don’t inflict. One particular bank now has 2000 people engaged in their agile community.
- To scale agility you must descale first. Achieve big through small.
- Block off command and control freaks. They create helplessness.
- Communicate everything THREE times.
- Pressurized middle. These are the people that relayed between C-level and troops that now have to lead process change. This is stressful unless they believe in what they are doing. They must have the unequivocal backing of those at C-level.
- It was quite clear over the 2 day event that there is a greater awareness and a growing appreciation of the need for release automation. Organisations that have been agile in development are now pressing for equivalent agility downstream
- Microservices are also becoming more widely recognised but not Kubernetes or Mesos as the solution. The ‘smaller’ the application pieces you build and release the more Continuous Delivery is relevant. Microservices are used increasingly for the customer facing pieces of an application, as the resilience of a containerized delivery architecture is best suited to applications with high availability requirements and a low cost footprint. Understanding how to decompose existing monoliths can be an issue. Rebuild or start again?
- DevOps and cloud are inter related. You can’t have cloud without DevOps/Automated pipelines. Any journey to cloud must start with DevOps for the data center. Simply replicating your data center in cloud is the most expensive solution.
- Some banks have started to use Elastic search technology to improve the customer experience. Now customers can traverse transaction history seamlessly.
Unfortunately we cannot name the companies under this heading but we can reveal their line of business and the details of their DevOps journeys.
- Traditional Insurance Organisations are being hurt by tech start-ups on mainland Europe. These new, innovative, fast-learning companies are able to adapt quickly to technology change whereas larger, more traditional organisations are constrained by existing business models such as broker networks.
- Companies engaging in RegTech are unable to align with DevOps. One organisation estimates they have 227 regulations worldwide to which they must remain compliant.
- A large UK bank’s burning platform for change was that their own in house process meant that to write “Hello World” took 3 months to go through 7 gates and produce 28 artefacts.
- Their divisional CEO’s use Kanban.
- Their Head of Transformation Change leads a team of 200 people (indirectly). 5 people report to him and to each of those another 5 reports and so on.
- Another interesting test case is a US bank who hired in a new Director of Software Engineering to guide change. This company are relatively mature in their DevOps journey however they still have annual budgets and struggle to get the business to think long term. Their infrastructure projects are also still waterfall. Some of their approaches to creating a DevOps culture include:
- Hiring from diverse backgrounds to reduce group think. This ultimately reduces risk though improved analysis.
- They have hired Open Source developers and have a public Github with more public commits than from the Bank itself.
- Their legal department have become adept in Open Source licensing.
- A Finnish Financial Services company have insourced legacy which has halved costs and improved time to market. Their new server build is now only 4 hours.
POSTED IN: DevOps Case study