A featured contribution from Leadership Perspectives: a curated forum reserved for leaders nominated by our subscribers and vetted by the Construction Tech Review Advisory Board.
Funding Circle
Adopting an Agile Development Environment to Drive Innovation
The benefits of cloud computing for the banking sector are not that different generally, but I think a notable area is in disaster recovery. With a "DevOps" approach, the emphasis is on automation and codifying as much infrastructure as possible. Rather than having a team focused on maintaining current systems, we focus our teams on being able to rapidly re-provision everything we need to run Funding Circle. This approach creates some constraints that actually help foster best practices. If we treat our infrastructure as immutable, we have to be very explicit about where and how we store data. When things break or start acting strange, the first thing we do is just delete and rebuild—the cloud equivalent of rebooting.
In general, we treat all of our automation tools in the same way we do with any code. There are code reviews, version control and unit tests. It's a first class citizen. Because there is nothing sacred about our production environment, it's easy for us to test changes in staging environments that work the same way. This lets us make changes faster and with much more confidence.
Also, banks have lots of information but can’t use it effectively to drive business. Data is both difficult to access and needed by more applications. It’s really important to have discipline around how data flows. The customer facing applications that back Funding Circle follow a microservice architecture, which basically means we have lots of small applications and databases. We're pretty strict about making sure data only moves one way. That means we don't have ETL (extract, transfer, load) scripts that "reach down" into our applications to pull data into a warehouse. That would mean an application upstream would need to know details about a database schema it's not responsible for, and it would break when the application changes.
Instead, we’ve designed each application to be responsible for generating its own reports in a standard format, typically just a simple CSV uploaded an AWS S3 bucket. We can then have unit tests that ensure changes to the application don't break what consumers are expecting.
We prefer to use event streams to drive the data we collect. Rather than reports processed in batch fashion, we like to make it cheap for our applications to publish information in response to business events we're interested in. That means our application platform has little to no awareness of how data is collected and allows us to do real-time computation for business intelligence.
The customer facing applications that back Funding Circle follow a microservice architecture, which basically means we have lots of small applications and databases
What banks need to do to foster innovation and growth is to adopt an agile development methodology and give some ownership to the technology groups to drive innovation. By ensuring that technology is seen as a means to truly enable the business rather than just a service unit, banks can start to attract to types of people that can have a huge impact.
One way to do this is to leverage Internet of Things. For banks this means opportunity for innovation. The way international banking is modeled can be reworked to better to support demand from both retail and business consumers for more competitive products. As marketplaces like Funding Circle, and services like Apple Pay, Venmo, even new currencies like Bitcoin become more commonplace, how money is moved between intuitions and customers will be strained. The internet of things will be a driver of demand for this change, but also serve a solution to change some of the current assumptions.
While managing IT organization and steering technology for our enterprise, one unique lesson that we have learnt is: You can't just will perfection; things will break no matter how much ceremony you introduce. Not everything is super-mission-critical. Isolate the things that are as much as possible, and make everything else very easy to change. More iteration will happen, things will generally move faster, and any issues will be fixed quickly with less of a blame culture. Be as transparent as possible around the current capability and problems with current systems or teams to help foster a culture of continuous improvement.
It's critical to aggressively combat complexity. Things slow down when people can't reason about how things work. When someone says, "let's test this thing for a few days before going live," I want to push back and ask why the passage of time will itself will give more information. If we can strip things down enough, we can have a more analytical understanding that leads to the confidence to move forward.
