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).

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