Tech Needs Architects
What can fintech learn from architectural design ? Surprisingly, quite a lot. I started my career in architecture, working for Norman Foster (architect of Apple’s headquarters) and then Fisher Park, set designers for the Rolling Stones. Today, I’m a partner with Anthemis, a VC firm that focuses on financial services. And there are many lessons from my previous career that apply today as I watch the fintech sector evolve.
Design lies at the heart of both architecture and software. People continuously try to define what design is (which maybe means designers are not good at designing design), and the reason is perhaps because there is no single type of design but several. Here I’m going to talk about three that are relevant to both architects and fintech: blueprint-based design, recipe-based design, and systems design.
These three design types operate at different levels and apply to both architecture and technology alike. Blueprint-style design can be used to design individual buildings or software components; a recipe approach is best for neighborhoods or software services; and systems design applies to cities or businesses.
Architects normally don’t build things. An architect comes up with plans, which are then given to the person who executes them – the contractor.
This is the first step in dispelling a myth that permeates not only fintech but the whole of technology. This myth, often propagated by technology investors, is that ideas don’t matter, just execution. Of course this is convenient for VCs who rely on the free flow of ideas for access to deal flow, and don’t sign NDAs.
But in between an idea and the execution is a plan; this is what architects do and it differentiates between bad ideas and ideas that have the potential to change the world. To take one example: PayPal. In its original form, PayPal was a simple idea: to be able to transfer money between digital devices. But the original plan for that idea, to beam it via infrared on Palm Pilots, wasn’t great. The plan evolved into using email addresses as a proxy for a bank account number, which was unique and memorable. From there it developed into a plan for execution that allowed PayPal to become a multibillion dollar company rather than a widget for a soon-to-be-obsolete device. The idea remained constant, but execution was impossible until the right plan was in place. Where an idea stops and a plan starts is not always obvious, but the combination of the two is what makes ideas work, not just execution.
When financial services were primarily delivered via physical outlets, many of the design “touchpoints” in their services were literally architecture– big expensive stone buildings with columns and pediments or, more recently, high-tech glass and steel. This was mostly signaling: Ironically, banks were spending money on expensive architecture to show they were so good at securing and making money that they could afford to. What was missing was the customer; those outlays were meant to speak to brand value, but not practical value. They were like thrushes, which sing themselves to death to show they are so good at catching worms, they can afford to waste calories.
In the digital era, this kind of signaling is much cheaper since visual digital design is cheaper – so cheap that the signaling benefit has gravitated away from design to the underlying functionality and services. Ergonomic software that is of sufficient quality signals digital nativeness and modernity and improves brand perception. It can also go further than the physical signaling of architecture and actually deliver the customer an improved product. In this way, fintech design has made existing financial services better and more accessible for consumers.
If you designed a fruitcake the way most individual buildings are designed – via blueprints (or their modern CAD equivalent), every fruitcake would look the same and the nuts and fruit would have their individual coordinates defined. In other words, it would feel mass-produced rather than crafted and organic.
When thinkers such as Jane Jacobs looked at the design of neighborhoods rather than individual buildings they realized the importance of their organic nature and basis on design patterns rather than blueprints. Christopher Alexander outlined an entire manual of how this might work in A Pattern Language. Alexander’s patterns were recipes rather than blueprints for architecture but his work resonated more with computer programmers rather than architects. Programmers realized that algorithms are recipes, and so this type of design had a lot to teach people creating patterns for software. For example, most UX design today is based on assembly of best practice patterns and flows, and these sometimes look at a whole service (service design) where the flows are connected, both offline and online.
This is where design extends beyond the Christopher Alexander approach and looks at not just how to create recipes for things, but how they grow and evolve over time. Cities are built on flows, they have inputs and outputs, they produce culture, and they are home to businesses. They are systems.
Businesses are also systems, and by combining product design with business model design, you can create well-designed companies on demand. This is a relatively new field called venture design.
Using modern, technology-enabled financial services as an underlying structure, it is possible to embed finance into other sectors, to make them digital finance-enabled, much like embedding internet approaches into many sectors allows them to be digitally native. We can make non-finance companies financially native. This approach is not about creating internet-enabled financial services, but the internet of financial services.
The parallels between the design of buildings and cities allow for a systems thinking approach to the design of financial services. This goes beyond the fintech of online or app-based banking to imagine what financial services look like when they serve all aspects of life. For financial and tech leaders looking to build a new industry, they should consider the complexity and integration of architecture and the built environment.