A sound understanding of enterprise architecture can guide CEOs around the bear traps of digitalization by helping them make concrete and commercially-viable links between IT infrastructure and business models...
In my previous post, I talked about a "grey zone" between business models and IT systems and tools. I chose to call it "grey" because it appears to be chronically misunderstood, and consequently neglected, by banking CEOs. I've been thinking about how to define this grey zone a bit better, and I propose to have a go at it by trying to put myself in the harassed mind of a CEO for just a moment.
So, I'm a bank CEO and I want to implement a digital banking business model. I've also heard a lot about APIs, the cloud, big data, analytics, agile development, adaptive user-interfaces, etc. and I understand that all of this stuff is foundational to successful digital businesses nowadays, in banking and beyond.
But there are quite a number of things I don't really understand. How do I choose which of these IT tools my business will need and won't need – in other words, what is the concrete link between my business and the IT infrastructure? How do I ensure that my bank uses these tools in the right way so that the digital bank I build today won't be obsolete tomorrow? Most fundamentally, dare I invest in these tools knowing that the business model I have chosen to implement may be completely obsolete in two years' time? Wouldn't it just be simpler to buy a packaged one-stop-shop digital banking solution from a leading vendor, and stop asking myself all of these questions?
Moreover, I may have this uneasy feeling that my bank's overarching business objective - becoming a competitive "digital bank" - is notoriously vague, which would imply that building a viable bridge between my target business model and my underlying IT infrastructure is... impossible? The more articles and research I read, the less I know what "digital banking" really means; I feel that, as one article puts it nicely, there is only "consensus on the vagueness".
Finally, because digital banking business models and the IT infrastructure supporting them are bound to evolve continuously and perpetually, wouldn't it be a good idea to look for something or somewhere that can provide some form of continuity or stability through time? Surely, stable and continuous change is much cheaper to manage than chaotic and sporadic change...
So now you've looped this loop of thought: how can you, as a CEO, ensure that your bank has the "right" IT infrastructure when the very definition of your business is, and will be, changing every day?
If you think that it is your CIO's job to answer these questions on his/her own and give you the answers, then (I respectfully argue) you certainly shouldn't be the CEO of a technology-driven banking business. Where the CEO needs to be today is in a position, if not to answer these questions on his/her own, to at least lead a detailed debate around these questions with his/her CIO (note that I avoid saying "with the IT organization", because the bank should definitely not be split into a business organization plus a separate, siloed IT organization).
Even though I am not the CEO of a bank, the circular question we have just posed has tickled me enough to go seek answers. I haven't had to go very far to start finding answers because I happen to sit a few chairs away from some of the most experienced banking technologists in the world as well as people who have spent their careers in the trenches, implementing IT at banks of all shapes and sizes (including hopeless pear-shaped banks) all over the world.
Now, all of the conversations I have with my brainy colleagues at some point tend towards the theme of architecture. In fact, the recurring expression that emerged over and over again in our conversations was "enterprise architecture".
It emerges that enterprise architecture ("EA" in short) provides a nice bridge between the business – a.k.a. the "enterprise" – and how IT infrastructure and tools are set up in relation to each other – a.k.a. the "architecture" – , in order to optimally serve the business as it evolves over time.
So, it appears that EA – or rather the absence of proper EA – may be the infamous "grey zone" that banks neglect while they focus relentlessly on the glitz of business models and/or the grit of implementing myriad hyped-up IT tools.
While EA is not an IT "solution" specifically designed for digital banking, it is a really fundamental and useful approach to help us deal with our "grey zone". With EA, we're not looking at what IT solutions can do for banks' employees and customers. Rather, EA can help us understand how a CEO can structure the bank's business and its IT estate to ensure that both can evolve smoothly, rapidly and cost-effectively over time.
In other words, it seems that EA could be a useful way to concretely link up all the digital banking business buzzwords and geek-talk flying around the place these days. And this is why I figure that a sound understanding of EA might spare bank CEOs from a range of traps, namely:
- Believing that you will eventually transform your bank as a whole by addressing discrete digital banking challenges (e.g. data-driven customer-centricity) with discrete IT solutions (e.g. an analytics platform)
- Viewing your bank in isolation from the rest of the world i.e. trying to reduce the complexity inherent to the fact that your bank is part of a complex ecosystem of disruptive competitors, disruptive innovators, whimsical consumers, etc.
- Focusing exclusively on both extremes of the decisional process - strategy (choosing the right business model) and operational execution (implementing & running multiple IT systems) - while neglecting the middle bit
- Thinking in static terms - the problematic "now" vs. the ideal future state i.e. looking at solutions that appear ideal today but are likely to be useless in two years' time
- Wasting energy on managing chaotic and sporadic change at both the business model level and the IT level
- Spending too much time on fluff such as customer-centricity, governance and cross-functional cooperation, which consultants love to dissert on, but which are bound to be hot air in a sclerotic enterprise
So enterprise architecture is where my journey into the "grey zone" begins. I'm pretty convinced that getting to grips with EA - and implementing proper EA - will help any banking CEO make much better IT-related decisions to achieve concrete, sustainable digital transformation.
In my next post, I'll have a look at the key principles of EA as well as the various ways of concretely implementing it in your bank.
PS: If you're wondering why my posts are relatively infrequent, it's because I rely on irritatingly intelligent and cultured technologists to get the answers I am looking for. Vulgarizing the information they provide - densely populated with buzzwords and (sometimes tenuous) references to philosophy, classical music and theoretical physics – takes time & effort!
Have any thoughts, questions, hate/lovemail? Feel free to comment below!