DevOps for Finance

A Ranger4 ThoughtPaper

www.ranger4.com © Ranger4 2014 1 

 

1. The State of Finance

1.1 The Systems State 1.2 High Level Recommendations

2.0 DevOps in Finance 2.1 Culture

2.1.1 The 3 H’s of Enterprise DevOps History Habits Heroics

2.2 Interactions 2.3 Automation

3.0 A DevOps ToolChain for Finance 3.1 Collaborative Lifecycle Management

3.1.1 A Bank Increases Developer Productivity by 34% 3.2 Taking Applications Mobile 3.2.1 Case Study Capital One Financial

3.3 Application Testing 3.3.1 Integration Testing 3.3.2 Service Virtualization 3.3.3 Case Study: Global Payments Platform (GPP) Replacement 3.3.4 Case Study: A Bank Delivers Quality Web Services Faster by Streamlining Application Testing

3.4 Application Release Automation 3.4.1 Case Study: Global 500 Banking Company

3.5 Application Performance Management 3.5.1 Case Study: Reserve Bank of New Zealand Achieves 4x ROI with AppDynamics

4.0 Getting Started Recommended Reading

www.ranger4.com © Ranger4 2014 2 

 

1. The State of Finance We’re out of the worst, we’ve weathered the storm, things are on the up again but things will also never be the same. Whilst growth may be being reported across most areas of the global economy, new pressures now come to bear in the finance industry: - Increased constraints and regulatory reforms to protect future financial health - Ever more demanding consumers wanting new, more flexible services - Absence of trust between participants - Market uncertainty:

- Remaining economic risk in more volatile economies/unstable regions - Unpredictability of results in the mega-growth regions

The core challenge is finding a balance between financial stability and healthy innovation in a fragile system.

1.1 The Systems State Just as the recent history of the financial industry has left it in a fragile state, the history of most financial enterprises’ IT system evolution has also left the legacy of fragility. Over years, decades even, applications and data have proliferated. Legacy systems are connected to new technology layers, calls are made from system to system, throughout ecosystems to payment gateways, market data. Ever more complex systems integrations have been created while system failure has become increasingly unforgivable and punitive. All at a time when users are demanding experiences that are more interactive, available and stable. And compliance and audit demand more from financial organisations to prove their risk mitigation at every step in the IT development and operations processes. The conflict between the desire to innovate and change and the need to maintain stability has never been more pronounced.

1.2 High Level Recommendations - Rationalize the portfolio of activities - fit assess and prioritise - Identify and eliminate operational constraints and weaknesses - Transform destructive organizational cultures - build trust and collaboration

www.ranger4.com © Ranger4 2014 3 

 

2.0 DevOps in Finance At the core of the DevOps movement is the vision to remove conflict between IT development and operations teams in order to speed innovation to market. DevOps achieves this in a number of ways: - Building trust through collaboration and involvement earlier in the software development lifecycle (culture) - Eliminating bottlenecks through focussed process improvement (interactions) - Building a DevOps toolchain to eliminate manual tasks where possible (automation) John Willis and Damon Edwards coined the acronym CAMS in 2010 (another DevOps giant, Jez Humble, added an L for ‘Lean’ to make CALMS, or for some people, CLAMS, later): - Culture - Automation (- Lean) - Metrics - Sharing

2.1 Culture And culture is where any DevOps project begins. The lack of trust endemic in the financial markets is often reflected in the culture of IT departments - and beyond (see our ThoughtPaper: DevOps for CMOs). In our work with across the software development lifecycle in the last couple of decades we have consistently preached:

People > Process > Tools We’ve given this an update in line with the uptake in DevOps philosophy:

Culture > Interactions > Automation To make the necessary cultural change, collaboration (or sharing) is essential. And metrics happen in all areas including culture. Cultural metrics are surprisingly easy to take (look at your organisation’s attitudes to blame and failure, how you organise teams, share knowledge and skills, motivate and reward behaviours) but virtually impossible to assign hard dollar value. Building a business case for DevOps around cultural change is very hard, but it is the foundation for everything that comes next - streamlining the interactions that take your new application releases to market and automating the interactions where possible.

www.ranger4.com © Ranger4 2014 4 

 

2.1.1 The 3 H’s of Enterprise DevOps There are examples of killer companies that are already DevOps Happy - but most of them were born that way. The Googles, Amazons, Facebooks, eBays and Etsys of the world were lucky to start their businesses at a time when they could build the technology in from day one. Other enterprises, particularly those in banking and the financial markets though have business models that didn’t start out as internet-based companies, even though they may be increasingly evolving that way. We’ve identified three areas older enterprises need to consider when they’re thinking about the cultural changes they need to make to embrace DevOps philosophies. We call them the three H’s. They are: History, Habits and Heroics. History You’ve got history. And, quite rightly, you’re probably proud of it. Your company may be decades old, an oak tree grown from an acorn, that’s evolved, diversified and grown and grown. More people, more stores or factories, outlets or branches, networks or routes. More revenue, profits rising and falling, MBOs, IPOs, mergers, acquisitions - ground-breaking times when you’ve streaked past the competition, eras of hardship where operations have been scaled back - but your company has a story. History’s important, we learn from it, it can give us a sense of place. Sometimes though, history can be an enemy of change. Legacy systems and processes can make it hard to effect change - it’s tough to make a juggernaut move direction fast. You’ve got to have a lot of power. Habits Humans have habits and old habits die hard. Change is difficult and DevOps demands change. It demands that you embrace new ways of working, revisit your culture and look at how you deal with blame, failure, how you organise teams and that you become obsessed with metrics. Measuring everything you do is a central DevOps tenet - it means you can measure your success and failures and change direction accordingly. It means you can write business cases and you’ll be able to report to the CEO exactly how far that new feature on your mobile app reached and how it converted into hard dollar sales for your company or how the changes you made to your release process mean you're releasing new code daily now. DevOps demands that everyone change - for DevOps to work, you need to collaborate, to involve everyone - yes, even Ops - early into development process, at requirements

www.ranger4.com © Ranger4 2014 5 

 

gathering stage, so that they know what’s coming downstream, so they can line up their resources to work on what's coming down the pipe. DevOps means everyone collaborating closely throughout the development and release cycle to ensure innovation gets to market at the highest possible velocity. Heroics  We all love a hero - but sometimes heroes, in fact, are bottlenecks. Perhaps there’s a system, in a critical part of a process, built by just one person. When the system works it takes away an onerous job for someone, but when it breaks, there’s only one person who can fix it. They are the hero. Staying late, coming in over the weekend to fix the problem, get the application running. Bottlenecks are what DevOps is here to hunt down. Another tenet of DevOps is the Theory of Constraints, introduced by Eliyahu M. Goldratt in his book ‘The Goal’. The theory states that any improvement not made at a constraint is an illusion - you will either rush work towards the bottleneck (enhancing the allure of your hero) or create a vacuum after the bottleneck (and have resources sitting around idling twiddling their thumbs).

2.2 Interactions So no more heroes - the aim is for an effectively collaborating team who share knowledge and involve everyone early in the software development process - that’s release managers at requirements gathering and testers at the early iterative development phases. DevOps is about sharing - knowledge, skills and generally being a good citizen who does their best to make sure the overall team’s goals are achieved. No man is an island, remember.

2.3 Automation Once you’re sure you have the right people in the right place and a clearly defined and operational process, you may look at tooling and automation to take you the final mile. Remember though, that any improvement not made at a constraint is an illusion - focus on your bottlenecks otherwise you’ll just be rushing work towards one or creating a vacuum after one. There are very few tools that can be implemented successfully without a clearly defined process to define its work - Application Performance Management is one since this can actually help you identify bottlenecks and it can be tweaked from its original set up as your process matures.

www.ranger4.com © Ranger4 2014 6 

 

3.0 A DevOps ToolChain for Finance Our high level recommendations for the finance industry when considering DevOps are to:

● Rationalize the portfolio of activities - fit assess and prioritise ● Identify and eliminate operational constraints and weaknesses ● Transform destructive organizational cultures - build trust and collaboration

As discussed in the previous section, you’re ready to consider tools and automation when your culture, people, processes and interactions are sorted - but where you focus will depend on your business. Your fit assessment and prioritisation and bottleneck identification will determine your starting point - but here follows some areas for consideration and case studies.

3.1 Collaborative Lifecycle Management Designed for the execution of a software delivery project, Application Lifecycle Management solutions coordinate people, processes, and tools in an iterative cycle of integrated software development activities, including planning and change management, requirements definition and management, architecture management, software configuration management, build and deployment automation, and quality management. In addition to the capabilities, the fundamental features of an ALM solution include traceability across lifecycle artifacts, process definition and enactment, and reporting. The most important benefit of an ALM solution is coordinating the people, processes and tools involved in a project to deliver innovation to stakeholders. Focus on the following imperatives as they implement an ALM approach best suited to their environment and culture:

● Use Real-time Planning ● Establish Lifecycle Traceability of related artifacts ● Enable In-context Collaboration ● Cultivate Development Intelligence ● Practice Continuous Process Improvement

www.ranger4.com © Ranger4 2014 7 

 

3.1.1 A Bank Increases Developer Productivity by 34%

“ Using the DevOps solution from IBM, we’ve integrated all of our development applications and improved communication significantly.” Software Development Manager at a bank in Brazil

Overview

This bank offers retail banking, private savings, insurance, investments and other traditional banking offerings to more than 50 million customers.

Business need To reduce IT costs, comply with banking and IT governance frameworks, and speed time to market, this bank sought to fully integrate its development toolset and automate its development approach.

Solution The bank engaged IBM® Software Services for Rational® to integrate and automate its software development processes with an application lifecycle management solution.

Benefits The solution helped increase developer productivity by 34 percent and reduce the creation of unnecessary requirements artifacts by 61 percent.

Components

IBM products and services that were used in this case study.

Software Rational Functional Tester, Rational Service Tester for SOA Quality, Rational Quality Manager, Rational Asset Manager, Rational Build Forge, Rational Application Developer, Rational Publishing Engine, Rational Method Composer, Rational Team Concert, Rational Software Architect, Rational Performance Tester

Hardware Power 780

Services Software Services for Rational

Solution Agile Software Development, Collaborative Lifecycle Management, DevOps

www.ranger4.com © Ranger4 2014 8 

 

3.2 Taking Applications Mobile  Mobile is the fastest growing consumer technology in history and is undeniably strategic. Just as users embraced online banking, they now expect to be able to access their accounts whenever they want, from wherever they are. As financial organisations build applications to satisfy and delight their newly mobile customers they face new challenges as a result of the increased complexity in developing for multiple mobile platforms.

Did you know that? (data provided by IBM)

● 91% of mobile users keep their device within arm’s reach 100% of the time ● 75% of mobile shoppers take action after receiving a location based message ● 96% year to year increase in mobile cyber Monday sales between 2012 and 2011 ● 90% of users use multiple screens as channels creating integrated experiences ● Global machine-to-machine connections will increase from 2 billion in 2011 to 18

billion at the end of 2022

Gartner says that developing mobile applications for enterprises presents unique challenges, including:

● Every mobile operating system has its own presentation style, interaction style and software stack

● Screen sizes, input modes and hardware capabilities differ amongst devices ● Devices and OS are constantly updating ● Network connectivity and power levels fluctuate widely in typical usage scenarios ● New consumer applications regularly extend and revise the standards for good

mobile applications

Using a Mobile Application Development Platform addresses these challenges and can:

● Reduce the costs of app development and maintenance ● Improve innovation time-to-market ● Enhance mobile app governance and security

3.2.1 Case Study Capital One Financial

Business Problem Summary:

● Now the 4th largest bank in the US ● Views mobility as a major channel for their business moving forward. Estimates

somewhere between 30-40% of their business could come through mobility in the coming years

www.ranger4.com © Ranger4 2014 9 

 

● Plan on developing dozens of mobile apps through a large internal development team focused on hybrid development

Current provider (Kony Solutions) could not scale from a development perspective to meet their needs for dozens of mobile apps, and was too expensive, negating the ROI (based on their experience building existing mobile apps

Technical Challenges:

● Integration with multiple back-end banking systems due to numerous acquisitions ● Required a high-end branded experience that provides a unique user experience

and comes across as innovative ● Leverage existing web assets ● Support large teams of mobile developers working on numerous applications. ● Scale to support millions of users and significant daily volumes

Technology Direction: Hybrid HTML5 apps using JQuery Mobile and Sencha Touch

How are the apps developed?

● Set up five teams of 8-10 developers each for onshore development at Capital One HQ in Virginia

● Use of Worklight IDE integrated with Capital One source control and software development life-cycle tools

Future Mobile Needs:

● Support for mobile payments and NFC devices ● Support for additional authentication and authorization standards (e.g., SAML) ● Integration with web content management systems within Capital One ● Support for WebSphere Application Server Network Deployment infrastructure

3.3 Application Testing Success or failure often depends on whose products or services are of the highest quality and lack of acceptable or poor software quality is blamed for more business problems than any other man-made product. You can overcome the challenges of delivering enduring software quality with quality management and testing solutions that will transform the way your business produces, validates and delivers software - from idea to go-live to retirement. Collaborative, integrated and optimized approaches to managing software quality help make quality

www.ranger4.com © Ranger4 2014 10 

 

management and testing activities a shared responsibility (DevOps) not siloed and disconnected so that you can better manage your existing resources, overcome schedule constraints, and increase your team productivity.

www.ranger4.com © Ranger4 2014 11 

 

3.3.1 Integration Testing Integration testing is a phase in software testing when individual software modules are aggregated and tested as a group. This phase occurs after unit testing and before validation testing. The inputs to the integration testing phase are the software modules that have been unit tested - they are combined into larger groups tests are applied to the groups as per their definition in an integration test plan. The output is the integrated system ready for system testing.

3.3.2 Service Virtualization

Service virtualization is a method to emulate the behavior of specific components in heterogeneous component-based applications and is used to provide software development and QA/testing teams access to dependent system components that are needed to exercise an application under test (AUT), but are unavailable or difficult-to-access for development and testing purposes. Virtualizing the behaviour of the dependent components means that testing can proceed without needing to access the actual live components.

3.3.3 Case Study: Global Payments Platform (GPP) Replacement This customer initiated a programme to replace their legacy global payments processing platform, which is responsible for handling all intercompany and interpersonal payments, with the exception of Faster Payments, which is handled separately. Timescales were very tight and the business impact of not meeting them was very high. Risk of Failure: High

Business Criticality: Critical

Programme scale: Very Large (£100m to £300m)

Problem Statement – following conventional test model

1. Testing the core payments processing platform was problematic without any of the feeding systems or interacting systems available to support initial testing

2. The components required to interact with the core payments processing platform were delivered, incrementally, over a 4 month period of time

3. The last components (critically, the accounting systems) were only available in a stable state less than 3 months before the target go live date

www.ranger4.com © Ranger4 2014 12 

 

4. The cumulative slip in delivery of infrastructure, middleware, key applications (such as accounting systems), Gold Copy Configuration and usable data, equated to a total slippage of 4 months against the critical path

Benefits Realised

1. Creating a ‘virtual component wrapper’ using virtual applications around the core payments processing platform enabled stand-alone testing of GPP

2. Testing of GPP was fully automated for Straight Through Processing (STP) of SWIFT inbound payments. This automated sub-GUI testing included the following functions:

a. Automated input injection of the SWIFT inbound payment messages

b. Automated validation of each payment at various stages, including the GPP database and the MQ exit queues

c. Automated responses from the virtualised applications

d. Automated validation of the outputs from GPP

3. This approach to System Integration Testing (SIT), using service virtualization enabled Agile Integration Testing with:

a. Virtual applications (VA’s) were used to stand in for any real time components which were unavailable

b. The Service Virtualization tool was used to stand in for the ESB until it was available – and injected the messages directly into GPP – simulating the format which the ESB would send

c. The Service Virtualization tool then switched to injecting the messages directly into the ESB – in the native SWIFT format (once the ESB had been delivered)

d. All STP testing was fully automated

e. All manual intervention testing was partially automated

f. The real components were dropped in as and when they became available

4. Roughly 80 unique virtual components were created and maintained to support the 1st and 2nd releases of this change programme. Virtualised components included:

a. The ESB – at various interception points

b. The Fraud control application

c. The real time foreign exchange rate application

d. The funds control decision application

www.ranger4.com © Ranger4 2014 13 

 

e. The SWIFT gateway

f. The primary accounting systems

g. Several others including a ‘Production to Test BIC conversion stub’, without which the programme would have ground to a halt in integration testing

The net result of the above was that 3 months critical path slippage was fully mitigated using Integration Testing and Service Virtualization.

Level of Change

● Introduction of a service bus to act as a routing and transformation agent between most interactions in the payments processing context – both real time (txns) and offline (files)

● Replacement of the legacy payments processing platform (bespoke payments engine) with a 3rd party COTS product

● Release 1 – all inbound SWIFT traffic ● Release 2 – all payments initiated from internal channels – both inbound and

outbound ● Integration of new platform with over 60 impacted systems, both real time and

offline

Sequence of Component Availability 1. GPP (3rd party COTS product) standalone – the core platform was available first

2. Certain middleware components (ESB sections) were available next

3. Certain real time interacting systems were available next – other side of middleware

4. All interacting systems were delivered in tranches

5. The total integrated landscape was made available to test, incrementally, over a period of 6 months

6. The last components (accounting systems) were stable enough to conduct E2E SIT less than 3 months before the planned Go Live date

www.ranger4.com © Ranger4 2014 14 

 

3.3.4 Case Study: A Bank Delivers Quality Web Services Faster by Streamlining Application Testing

Problem To accelerate the rollout of quality Web Services, this bank needed to reduce administrative and maintenance work associated with its testing process. In an organization where system unavailability has a direct impact on customer confidence, there is a heavy burden on the infrastructure to provide seamless services. As a result, the bank’s Quality Assurance Team must ensure that its Service Oriented Architecture (SOA) applications are of the highest quality. As the Web Services market matured, it quickly became clear that the bank’s proprietary testing solution was not the most effective way to deliver and maintain SOA applications. The bank often needed to divert resources from testing mission-critical applications to maintain and further develop the testing solution itself. There were also complexities relating to Web Services versioning and test bed maintenance. Thus, the assistant vice-president of retail banking began looking for best of breed applications that would enable the QA Team to focus on testing. Solution  To address its needs, the QA Team implemented a trio of unique testing solutions. While another web services tool handled manual functional testing, HP Quality Center software managed the testing workflow. Finally, IBM Rational Test Workbench software facilitated automated testing of SOA applications. Promoting seamless data sharing amongst testing tools, the Rational Test Workbench software offered a plug-in for the HP Quality Center software that provided the team with traceability from the requirements set to the engineer’s test cases and the automated test scripts. The QA Team used Rational Test Workbench software to store and execute procedure tests for its Web Services and IBM® WebSphere® MQ software. Testing in a black box environment without a user interface, the solution was used to build, store and analyze all test scripts. The solution’s ability to store an individual automated script for each application reduced the administration required to maintain different versions. Once the scripts were run, Rational Test Workbench software clearly showed where code had failed, enabling the QA Team to establish if the failure related to data, code or an environmental defect and assign the appropriate actions.

www.ranger4.com © Ranger4 2014 15 

 

Benefits  

● Promoted rapid execution and analysis across the entire test bed ● Reduced the time it takes to roll out quality SOA applications ● Facilitated seamless data sharing amongst testing tools

3.4 Application Release Automation It was Gartner that described Application Release Automation as a key to DevOps and most proponents of the DevOps movement see automation, once the people and process issues have been tackled, as the key tools and technology driver and ARA as the penultimate piece of the DevOps toolchain - followed by Application Performance Management. As applications have become increasingly critical to organisations' competitive advantage and businesses' push for innovation has seen a massive uptick with the arrival of social and mobile, developers are putting the pressure on operations to deliver the highest volumes of releases ever - a trend that is only forecast to increase exponentially. In the past, we have seen highly talented operations and administration resources eliminate manual release tasks by writing a script, and then another script. Many larger organisations have gone a few steps further and written some of their own tooling themselves - building task libraries, creating graphical user interfaces into their scripts and integrations into other tools for build and configuration management. But the scripts still suffer from the same issues around failures, troubleshooting and auditability. The first thing most organisations want when they consider automation tools is a boost in productivity. Those same talented staff who created all the scripts, are heroes when there's a system failure as they are the only ones with the knowledge to fix it, often become the bottleneck in the process (and most of them are bored doing this job too - their talents are much better used elsewhere). An automation tool allows you to:

● Create consistent, repeatable deployments ● Enable self-service so any authorised personnel can perform deployments within a

couple of clicks ● Roll back or redeploy instantly in the event of a systems failure ● Have a full audit trail of every action taken in the system ● Troubleshoot and fix at high velocity ● Integrate into your existing DevOps toolchain (Maven, SVN, Git etc)

www.ranger4.com © Ranger4 2014 16 

 

3.4.1 Case Study: Global 500 Banking Company

Challenges

● Error-prone manual tasks and duplicative processes ● Slow deployment to development and test environments ● The risk of instability due to managing multiple configurations and versions ● A lack of visibility across the enterprise, disconnects and confusion ● A lack of control over the deployment process adding security risk ● A lack of centralized deployment process ● Too many mistakes and rework

Results

● Find the reduction in cost and money saved to be the single greatest benefit they’ve seen since implementing a continuous software delivery solution.

● Purchased UrbanCode over the competition for the following differentiators: ○ Superior product functionality ○ Ease of use ○ Speed / ease of implementation

● Deployments are 50-75% faster with UrbanCode. ● Realized the value of their investment in their UrbanCode tools in 2 weeks – 1

month

Testimonials

“UrbanCode tools have allowed us to successfully begin implementation of an enterprise level solution in a very large organization full of customized one-off processes. The ease of use, numerous supported integration plugins, and templates within the tools have proven invaluable in allowing my organization to move at a rapid pace while seeing almost immediate results in terms of speed, reliability and audit traceability/transparency.”

3.5 Application Performance Management We know organisations today are running and managing the most complex and sophisticated applications ever, and whilst that's a good thing in that we're delivering smart solutions to our application consumers, it also means that more things can go wrong than ever before. And when things go wrong, it's painful.

www.ranger4.com © Ranger4 2014 17 

 

AppDynamics is application performance management software designed to help dev and ops troubleshoot problems in complex production apps. How? You can monitor your application health, and be alerted when there's an issue. Troubleshooting's easy when you can see your entire application and drill down as needed to see the code execution in the application server and database. Even more so when you can automate fixes. AppDynamics delivers:

● End user monitoring ● Real-time business transaction monitoring ● Application visualisation and management ● Business impact detection ● Performance spike visualisation ● Bottleneck identification ● Root cause diagnostics ● Reports, dashboards and comparison tooling

3.5.1 Case Study: Reserve Bank of New Zealand Achieves 4x ROI with AppDynamics Introduction The Reserve Bank of New Zealand is New Zealand’s central bank. It is responsible for operating monetary policy to maintain stable prices and assists in the functioning of a sound financial system for the country. In addition, it supplies New Zealand’s physical money and oversees and operates the country’s payments systems. Dozens of applications are critical to the bank’s daily functioning, allowing support staff and policy analysts to do their work. Greg Perrott, Software Architect at RBNZ, is responsible for the performance of several of these critical applications.

● Saved $38k with AppDynamics in first year ● Developers spend more time developing, less time troubleshooting ● Enabled development to proactively manage application performance

Challenges: No Time for Development

Perrott works on a team of fifteen developers that’s responsible for the support and maintenance of their existing applications as well as providing enhancements and developing new applications. When an end user calls the helpdesk, a member of Perrott’s team must stop what he’s doing and devote a few hours to fixing the problem. “We’d usually get out a workaround within an hour, but sometimes it would take longer depending on how difficult it was to locate the problem. Fixes usually aren’t deployed for a few days or even a week,” Perrott said.

www.ranger4.com © Ranger4 2014 18 

 

This meant that Perrott’s team was not as productive or agile as it could have been on its other projects. “Our ability to deliver enhancements has been greatly affected by support,” Perrott said. “It gets quite frustrating at times. There were occasionally periods of a week or more when no development progressed because of ongoing support issues.” One of the ongoing issues that Perrott’s team dealt with was long-running transactions and stalls relating to their .NET services. Because time series data was calculated on-the-fly in application logic and memory (rather than using stored procedures in the database) some requests took a long time to complete. Perrott’s team found they had to extend the time-out period for the client in order to reduce the number of failed transactions. “It wasn’t ideal because the end user still had to wait, but at least that way it would eventually return data,” Perrott said. Targeting these longer-running transactions was an ongoing project of Perrott’s, but without adequate visibility into the production application, it was a daunting task. “Ever since the system went live, I’ve been balking at the work around simplifying it,” Perrott said. “Without access to production data we simply couldn’t find which areas we needed to redesign in order to improve the slowest services and scale the application.”

Solution: AppDynamics for .NET

When Perrott began his free 30-Day Trial of AppDynamics, the bank had been experiencing an ongoing issue with a service client disconnecting from the services. “We had very little info to go on about what was causing the problem, and we weren’t able to replicate the issue in any other environment. It was very timely that I had started using AppDynamics,” said Perrott. During the trial period, Perrott put AppDynamics in the production environment and almost immediately found the issue and its root cause. “That pretty well sold us on enlisting the solution full-time.”

Benefits: Getting Proactive About Performance and Infrastructure

“AppDynamics provides us with a lot of information that we otherwise wouldn’t have access to without requesting a support account or getting someone from the infrastructure team and standing over their shoulder, instructing them what to do,” said Perrott. “Now we can solve the problems without help from the support or infrastructure teams, and we simply tell them what to fix.” The result of this additional visibility is that Perrott and his team spend significantly less time troubleshooting than before. “Before we got AppDynamics we would spend about a third of our time on support, and another 20% of our time on QA,” said Perrott. “This didn’t leave much time for enhancements and other development projects. With AppDynamics, we spend about a quarter of the time that we used to finding and fixing

www.ranger4.com © Ranger4 2014 19 

 

things.” Perrott estimates that AppDynamics has saved RBNZ $38,000 in productivity savings by reducing the time developers spend on support activities. Perrott also noticed that AppDynamics helps him find issues that were going unreported before. “I started finding things that clearly were impacting end users, but either they hadn’t reported them or had reported them in such a way that we were unable to identify the problem,” he said. “Now we’re able to fix those things, and we’re being more effective in our optimization. We’re targeting our .NET services with the most load and the longest response times.” Perrott thinks that AppDynamics has made a difference in how all infrastructure, development and support function at RBNZ. “I still feel we can get a lot more value from AppDynamics, but there has definitely been an improvement in our ability to provide support, our ability to upgrade the system, and our ability to be more proactive,” Perrot said. “Now we’re aware of problems and can fix them before they impact the business.”

www.ranger4.com © Ranger4 2014 20 

 

4.0 Getting Started So if you’re convinced DevOps can help you revolutionise your finance enterprise, where do you start? We recommend you begin by baselining your current state - being metric obsessed is a key feature of successful DevOps organisations and you can’t write a business case or recognise and reward success without a solid understanding of what you’re dealing with. At Ranger4 we’ve developed a DevOps Maturity Assessment and our own proprietary DevOps Maturity Index (a number generated by a complex analysis and our own algorithm analysing your cultural, process and automation maturity). You’ll also need a vision - a clearly articulated future state where you’d like to be. For a lot, but not all, organisations, this is Continuous Delivery. And then you’ll need a fit assessed, prioritised roadmap of how to get there - also a deliverable of the Ranger4 DevOps Maturity Assessment. Want one? Head over to www.ranger4.com or email us at hello@ranger4.com.

www.ranger4.com © Ranger4 2014 21 

 

Recommended Reading

1. “The yin yang of financial reform” - a study from the IBM Institute for Business Value

2. IT Revolution

3. DevOps Cafe podcasts

4. DevOps is Big Finance Companies - Does it Help? from Puppet Labs

5. DevOps: Solving the Engineering Productivity Challenge from PriceWaterhouseCoopers

6. DevOps.com Where the world meets DevOps

7. DevOps Days

www.ranger4.com © Ranger4 2014 22