The 4 Layers of DevOps for Financial Institutions

There has never been a more essential time to ensure teams work together and deliver features with speed and efficiency. Implementing DevOps practices into your workflows gives your business the structure for constant evolution, cutting costs and optimising efficiency. This ensures you can grow secure in the knowledge that you have the best systems in place to support your development, using automated processes and a personalised strategy to create resilient, future-proof growth. Here are the 4 layers of DevOps for financial institutions.

Infrastructure to Code 

It is important to clarify that the definition of ‘DevOps’ deviates from the perhaps more traditional banking definition, that being a union of Development people and Operations people, but rather it is a combination of Technical Development people and Machine Operations people. The machine operators that would’ve usually built the physical computing infrastructure now work on projects together with developers, becoming a single team. Machine operators are therefore able to help the developers understand how to construct and code the infrastructure of their applications for efficiency and longevity. Essentially, recreating the physical processing power infrastructure within code. 

Microservices 

Microservices are about system architecture. They are a fragment of code that give every function of an application its own ‘container’. The inputs and outputs of each fragment are static. This means we can change anything in the code without it affecting the rest of the system, giving us independently deployable services, this means we won’t need to do a complete system test or full impact analysis every time we want to make a change.

The benefits of microservices can easily be seen on the world’s most popular website: Google.com, the image sitting above the search bar is a Microservice. Consider how often that image changes? Now compare that with how often you’ve seen Google take down their entire system/website to make sure the image is going to work for everybody on the endless variety of devices that visit the website.

Microservices may be small but when they are appropriately constructed in their fragments, interfaced correctly and built out, microservices can make some of the most complex systems in the world. From collateral management entirely done on the web using microservices to trading systems for bonds and equities, microservices are leveraged to help keep your systems running at all times. Microservices reduce the amount of testing that has to be done substantially, and as many of you know, testing often chews up 30% - 50% of your budget on any well-run project. 

Build-to-Test 

This is a change in mindset. We used to write a spec, have a committee sit on it and then sign it off, put it under change control, give it to developers to code it, then finally to the quality assurance testing team. Now when using a collection of microservices to meet a customer need, we can build-to-test. This means the code can be built inside the testing tool, the advantage to this is the ease at which we can make changes to or test elements of a system, radically changing the pace at which testing models take place. Through this, by having infrastructure-to-code, developing in microservices, and building to test (all of the above), we achieve what is known as CICD (Continuous Integration, Continuous Deployment), and that means we can put changes into production on a regular basis without impacting the client base, even while they are still using the system. So how do we actually code this? 

Agile Methodologies

This is where the cultural mind shift occurs. This layer will consist of 3 elements. The 1st is the way in which we conduct our business requirements. Instead of having highly-qualified business analysts sitting down and consulting with users on how things are done, what if now the users can just ‘tell a story’. Perhaps they could say something like “I came in this morning and sat down at my desk and I put my finger on the finger print reader and it gave me a list of things that I have to do today.” That’s an example of a ‘user story’.

For all the technical people reading this: can you imagine what you would be coding if you received that story? Allow me to elaborate, it would go something like this - “I’d need fingerprint recognition, therefore biometrics. Then the application needs to automatically open upon recognition and on the right-hand side the user should see a list of actions that they need to take today.” By building entire pipelines of user stories that meet each specific user’s need, we can describe complex systems in terms that any user can describe.

These then go to squads, the 2nd element, which consists of about 7-12 people. Each squad will receive a number of user stories. What is a squad? A squad has defined roles, it’s made up of a Product Owner, Scrum Master or an Agile Coach and a number of technical and testing roles. In order for these squads to be highly productive they need to be co-operating fully throughout the day. But for those that are offshoring from east to west, or vice-versa, how can your squads be productive when there is up to a 10 and-a-half hour time difference? But if you were to offshore north to south you will be looking at an hour or two in time difference at the most, then you can begin to see highly productive squads who will all be awake at the same time.

Now the 3rd and final element, the squads will be given time boxes, typically 2 to 3 weeks, and they will sit down and create what is called a sprint plan by looking at the number of user stories they have, the size of their squad, how many they can get done within 2 to 3 weeks, and they will plan perhaps the next 3 or 4 time boxes. As they go through the process of developing, testing and putting into production they may need to make adjustments in order to meet that 2 to 3-week period, either by bringing some forward if they’re doing well and ahead of schedule or pushing a couple back to the next sprint if there’s been a delay.

This method enables us to have defined deliverables that can easily be changed. Now, why is that valuable? Ask yourself - how many times have you expected your next-year’s budget to be changed after 3 months, or 6 months, or 9 months? How many times has that happened to you in the past? By using these Agile methods, the ability to chop and change means that you can better control your budgets in a very volatile world, and let’s face it, the world has changed.