The big deal in IT for Australian banks is core banking. ‘Core banking’ is shorthand for replacing old product systems with more modern and flexible versions. Most Australian banks are doing this – CBA spent $2bn over five years – but the ones who reap the benefits over the long term will be those who address two strategic problems.
The premise for core banking projects is simple. Each bank has dozens of different product systems, many over 15 years old, each hard-coded to support a different product or a group of products. This is expensive to manage and makes it difficult to innovate across product sets. And the world has changed. Rapid innovation is now essential rather than optional.
To successfully upgrade product systems, two strategic problems need to be addressed. Firstly that the system design will make assumptions about the future competitive landscape, and secondly that enabling product flexibility can lead to management complexity.
The problems are based on learning from the experience of telcos who upgraded their billing systems in the early 1990s. In the 1990s when telcos were deregulated, competition was based on long distance call pricing. Regulated telcos had made vast profits from long distance calling, and competitors rapidly went after those margins as soon as markets were deregulated.
To compete, incumbent telcos upgraded their billing systems to enable flexible pricing. You want to offer cheap calling to China after 7pm? Sure. After the new systems were implemented, it took about 15 minutes to implement, and didn’t require any programming expertise. This was fantastic for competing with long distance calling competitors.
It was not so fantastic when fixed line and broadband competition emerged. The new billing systems proved totally inflexible in enabling new plans and pricing for non-calling products. This was because they assumed fixed lines would continue to be non-competitive, and broadband simply didn’t exist when the systems were designed. When I managed fixed line and broadband products in the late 1990s, it took 12 months and over $1m (a lot of money in the 1990s) to upgrade the new billing system to support new products and pricing.
Core banking systems run the same risk. If they focus on enabling flexibility in deposits and lending pricing – which don’t get me wrong, is a useful thing – they create an assumption that the basis of competition will be the pricing of existing products.
What happens if the basis of competition changes and e.g. moves to the structure of the products themselves? Banks with new systems may be no more able to innovate and compete than those with 20 year old systems. And both will be at a disadvantage to new competitors with systems built around the new product or service.
The other problem telcos found is that pricing flexibility quickly becomes difficult to manage. We had 14,000 calling plans for 1m customers, so it was difficult to quickly work out whether an innovation was good enough for enough customers to be worth pursuing. And if it was and we launched a new plan, sales and service staff needed to be able to answer the ‘will I be better off on this new deal’ question for any given customer who contacted them. (Remembering too that flexible pricing is a two-edged sword, customers perceived telcos were deliberately making pricing complex to make more money, which created a high level of distrust.)
So is it a case of ‘be careful what you wish for’?
Not quite. The good news is that IT systems in 2014 can be architected very differently to the 1990s. Banks who recognise these challenges can build much more flexible systems. This is not by anticipating the nature of future competition (not possible) but by creating open architectures that make future development simpler, faster, and less expensive. And by adding sophisticated analytics tools, to make the task of managing complex pricing much easier.
New IT systems need to enable rather than constrain innovation. The key is to avoid monolithic systems, and create open architectures, with supporting analytical tools, that enable flexibility and innovation across any product.
The astounding comeback by Oracle USA to win the 34th America’s Cup against Etihad Team New Zealand last week has created an intriguing mystery. Oracle emerged from 8-1 down in a first-to-nine-points competition, to win 9-8. Since then, media and online forums have buzzed with theories ranging from fair to foul as to how Oracle USA pulled off a victory even described by the official America’s Cup website as “one of the most improbable in the history of sport”.
The competition started on 7 September and was scheduled for two races per day, provided winds were not too strong for safe racing. By 10 September, Oracle was 4-1 down. They promptly postponed the next race, allowable under the rules, and fired their tactician, replacing him with the most successful sailor in Olympic history, Ben Ainslie (link).
Nine of the subsequent races were postponed mostly due to winds being too strong. Adding in scheduled rest days, this meant from 10 Sept when Oracle were 4-1 down, to the close of 21 Sept when the score was 8-5 still in ETNZ’s favour, there were 4 days with only one race and crucially 5 days with no racing at all when Oracle (and ETNZ) could practice and improve their performance. Oracle then totally dominated the last four days of sailing winning all six races, to take the Cup 9-8.
After the initial races, it was widely acknowledged, including by Oracle (link), that ETNZ had a major upwind advantage due to their superior tacking and foiling skills. Yachts can’t sail directly into the wind so on the upwind leg of each race it is necessary for boats to take a zigzag path changing direction by ‘tacking’. ETNZ had also spotted a loophole in the rules allowing the catamarans to sail up on the foils attached to each hull, transforming a water-bound catamaran into a much faster hydrofoil. This is not an easy thing to do, or do consistently, so spotting this opportunity before the Cup started was a serious advantage.
So how did Oracle go from clear disadvantage to romping home in just 9 days? There are three prevailing theories:
- Ben Ainslie plus tweaking the boat was the key. Given Ainslie is English this is naturally the version of events favoured by the UK media (link). However, the scale of improvement is too large for this to be plausible. Grant Dalton, CEO of ETNZ, estimates Oracle improved by over 1.5 minutes in those 9 days, from 50 seconds slower to 50 seconds faster. Based on an average race time of 25 minutes, this is a 7% performance increase. And this from a team of already world-class sailors. It would be a truly remarkable feat of leadership to increase team performance by this much this quickly. And any tweaking of the boat could have been copied by ETNZ. Likelihood: low.
- Team NZ choked. This emerged from the NZ sports media (link) during Oracle’s eight straight wins in the second half of the competition. The NZ sports media have been jittery and quite frankly neurotic since the New Zealand failed to win five Rugby World Cups in a row until the All Blacks succeeded in 2011. The trouble with this theory is the problem wasn’t that ETNZ’s performance got worse; it was that Oracle’s got so much better. Likelihood: low.
- Oracle cheated. This theory runs along the lines that Oracle installed a “stability-assistance system” that enabled the boat to go up on its foils at the touch of a button. Automation is forbidden under the rules which do not allow any equipment powered by stored sources of energy (except for human arms and legs). The source for this appears to be a single NZ journalist although it was widely picked up by other media, and has been hotly denied by Oracle (link). Likelihood: unknown / unproven.
There is a fourth and much more plausible theory based on the use of Big Data, which I like to call the ‘bionic sailor’ theory. The idea is that Oracle gathered and analysed massive amounts of data on their and ETNZ actions and performance during the races, and atmospheric, wind and weather conditions, enabling Oracle to reverse engineer ETNZ’s advantages (which Oracle admitted early in the competition they didn’t understand (link)) as well as provide pre-race analysis. This, combined with a sailor of Ainslie’s calibre who could use the insights to direct the team during the race, the tweaks to the boat, and the time for extra practice, added up to provide the 1.5 minute improvement.
This theory is based on four factors; sailing is a sport based on complex decision-making in a fast-changing environment with multiple variables so is highly susceptible to computer analysis. Oracle built “elaborate television production facilities” (link) for the race that could have been used to track and monitor Oracle and ETNZ, as well as provide broadcast coverage. Oracle has ready access to the world’s best database software, data scientists, and software programmers who could use video and sensor feeds to manipulate immense volumes of data, run major simulations and constantly improving things for Oracle. And finally, Oracle had much greater funds during the competition than ETNZ; meaning ETNZ had neither the money nor the on-tap computing capability to come back against Oracle. Likelihood: unknown but the most plausible.
The upshot is it appears no accident a team sponsored by one of the world’s largest database and software companies pulled off one a great upset. And you can guarantee Oracle will have already started improving their capability for the next America’s Cup.
It may be the start of a new frontier where Big Data is used much more extensively to improve sporting performance. And with wearable computing emerging, Big Data may end up turning a number of sports on their heads.
Either way, my advice to Team NZ and the Australian Bob Oatley who has just announced he is challenging for the next America’s Cup, is don’t even think about competing without a seriously heavyweight team of software engineers and data scientists. Oh and you better throw in some military-level internet security to avoid any unsportsmanlike hacking.
A great sponsorship opportunity for Microsoft or SAP?