Editorial & Advertiser Disclosure Global Banking And Finance Review is an independent publisher which offers News, information, Analysis, Opinion, Press Releases, Reviews, Research reports covering various economies, industries, products, services and companies. The content available on globalbankingandfinance.com is sourced by a mixture of different methods which is not limited to content produced and supplied by various staff writers, journalists, freelancers, individuals, organizations, companies, PR agencies Sponsored Posts etc. The information available on this website is purely for educational and informational purposes only. We cannot guarantee the accuracy or applicability of any of the information provided at globalbankingandfinance.com with respect to your individual or personal circumstances. Please seek professional advice from a qualified professional before making any financial decisions. Globalbankingandfinance.com also links to various third party websites and we cannot guarantee the accuracy or applicability of the information provided by third party websites. Links from various articles on our site to third party websites are a mixture of non-sponsored links and sponsored links. Only a very small fraction of the links which point to external websites are affiliate links. Some of the links which you may click on our website may link to various products and services from our partners who may compensate us if you buy a service or product or fill a form or install an app. This will not incur additional cost to you. A very few articles on our website are sponsored posts or paid advertorials. These are marked as sponsored posts at the bottom of each post. For avoidance of any doubts and to make it easier for you to differentiate sponsored or non-sponsored articles or links, you may consider all articles on our site or all links to external websites as sponsored . Please note that some of the services or products which we talk about carry a high level of risk and may not be suitable for everyone. These may be complex services or products and we request the readers to consider this purely from an educational standpoint. The information provided on this website is general in nature. Global Banking & Finance Review expressly disclaims any liability without any limitation which may arise directly or indirectly from the use of such information.


By Mark Warren, Perforce Software

Most people who work in and around business technology will probably have heard about DevOps by now.  Basically, it is all about bridging the divide between the software development teams (the guys who build the technology that supports financial services) and the operations teams (the IT guys who then have to make sure that tech supports those products in the real world, every day).  Traditionally, both entities have been very separate and that can hinder the performance or time-to-market of any technology-centric project, hence the rise of the DevOps movement, the basic tenet of which is to ensure smooth collaboration between both parties.

Problems that DevOps can help with include:

  • Better release management of the software supporting a financial product(visibility of risks, dependencies, release stage gates and compliance)
  • Deployment co-ordination – better management of ‘events’ around this (clear processes, documented tracking and reporting)
  • Deployment automation – there is a trade-off between the benefits of automation and perceived loss of control, so the DevOps movement aims to increase performance and productivity, while the risk that comes with frequent changes to the product being developed is managed and also ensuring better return-on-investment (so, asking quite a lot really).
Mark Warren
Mark Warren

DevOps is a great idea and one that is definitely gaining traction, especially since it is a good fit with the Agile methodology, also being increasingly deployed by all kinds of organisations. In the financial services market in particular, it can face a very practical hurdle, namely that while teams are often small, the people are often in different locations, even countries and timezones, not to mention multiple platforms and tools.  Take for example Perforce user NYSE Euronext’s dynamic platform for trading trillions of dollars is run by a six-person team on 14,000 servers and incorporates applications and processes from multiple companies.

Version management for DevOps
This is why an increasing number of organisations are now using version management as one way to make DevOps achievable.   Version management is long established in the software development world and also referred to as source code control or software configuration management.  In the DevOps world, it can become a mechanism for enabling a collaborative environment as all contributors can trust in a “single source of truth.” A good version management environment helps to balance control and flexibility, and should be platform and tool-independent, so it doesn’t matter if teams are using different systems and tools.

Under the DevOps approach, both teams remain engaged and accountable until code is reliably deployed on a production server and released to customers. We’re talking about a very agile and collaborative environment, one with potentially a lot of room for mistakes to be made, especially under time pressures. The development and operations teams need support to ensure this does not fall apart. For instance, the operations team need to know what versions and operating environments are currently in use.

The answer is to create an effective way to mutually share information, something that the current generation of version management tools are designed to achieve.  As well as source code, they can store just about everything associated with that particular software build and the developers just need to point the operations team towards a repository containing all that information, easy to download and accountability for different tasks obvious.

Every action and status can be tracked back: goodbye to just throwing stuff over the wall and hoping for the best.  In other words, who did what and when and where?  Armed with that information, it becomes a lot easier to analyse anything that has gone wrong and then agree a way forward.

Speed is another issue: the volumes of data created in a software project is massive (and becoming more complex, for instance the amount of smartphone platforms or languages that an app has to support), against which financial services companies have to balance the need to get products into the marketplace more quickly in order to stay a step ahead of the competition and keep customers happy.  The traditional problem has been that when projects are rushed out, the risks around system errors and breakdowns increases.  Again, the right version management can help to ensure that all the correct checks and balances are in place (together of course with automation tools).

When I say the ‘right’ version management system, I could of course be accused of bias towards my own company’s solution, but there are some fundamental considerations that are the same, regardless of the vendor involved.  If I was a customer in the financial services sector, here are a few things I’d look out for when seeing whether my current version management system is able to support DevOps, or if I was out shopping for a new one:

  • Track record – is there an established base of existing users in this market sector?  Does the vendor understand the particular requirements of this market?
  • Scale and distributed environments – if teams are spread across the world and if numbers of users are likely to increase, will the system be able to match that?  What about extensibility through APIS and integrations with my existing tools and workflows?
  • Support and product road map – I’d definitely look at the bigger picture.  I’d check that this is a company that’s likely to be around for a long time and whether it has a clear future road map and planned investment in product evolution.  Then I’d look at what kind of support is on offer.  I’d also ask for some reference sites to speak to and I’d see what the user community is saying online.

Version management is not the only piece in the jigsaw towards making DevOps work: a change in cultural attitude is equally important.  However, what it can do is create an environment between the development and operations teams that is a lot more collaborative and accountable, which after all, is at the heart of the DevOps idea.

About the Author:
Mark Warren is European Marketing Director for Perforce Software, used by thousands of organisations worldwide includingSalesforce.com, SAP, Deutsche Bank, HSBC and the New York Stock Exchange to manage their most valuable IP. Perforce products help teams work in concert on important digital assets including software code, documents, multimedia, spreadsheets, images and more. The company is headquartered in Alameda, California, with international operations in the United Kingdom, Canada and Australia. For more information, visit www.perforce.com