Transforming Finance’s Ability to Provide Fast Business Insights by Rethinking Enterprise Architecture

Your decisions are only as good as your data: how to build real time reporting functionality into your systems Lars Wikstrom is speaking at Finance Transformation & Corporate Finance Boardrooms in London, February 10-12 2014 Let me paint you a picture of the future… You're overseeing a Finance function that is operating with a significantly simplified technology architecture; you've shifted your operations from being all around technology towards being all around logic; you can analyze more information than ever before – in a fraction of the time it used to take; your quality levels are reliably higher; and your risk exposure significantly lower. And let me add, the cost of your technology architecture is a fraction of what it was. It may sound like Space Odyssey 2050, but for Lars Wikstrom, Business Intelligence and Data Integration Wizard Extraordinaire, it’s a highly realistic, albeit still rare, scenario. Of course, people like Lars are a relative rarity. His passion is about enabling business through simplifying complex information architectures. He’s one of those folks who never accepts ‘no’ as an answer, and is always looking above and beyond whatever is currently in place. He doesn’t just engage in lofty, high-level architecture discussions, but likes rolling up his sleeves and drilling down into the details with the engineers. He’s the kind of guy who, in the course of a phone call, frequently breaks off to verify a fact or a definition online. Lars left a lasting legacy at Deutsche Bank (where he redesigned the bank’s technology architecture) and has equally left his mark on HSBC Bank. I was thrilled to get an hour on the phone with him, recently, to ask him about Enterprise Architecture & Business Intelligence. Lars, what made you choose a career in data architecture? Well, I didn’t start my life wanting to be a data architect. In fact, growing up in Scandinavia my dream was to be a game warden. I did a lot of different jobs along the way, and ended up making a name for myself in building OLAP cubes – basically, a way to leverage online analytical processing to answer multi-dimensional analytical data queries swiftly. This work really got me thinking about how to manage data more effectively, because the fundamental idea behind these cubes is that you pre-aggregate data, which means you get results in seconds. Everything that came afterwards was built on this recognition. You joined Deutsche Bank Shared Services in 2007, as Global Chief Architect for Business Intelligence and Data Integration. What does a title like that mean? The guy who hired me at the time effectively challenged me to use everything I had learned to date to transform Deutsche Bank’s service and technology platforms. It was a great job opportunity, and I relished the opportunity to apply some innovative thinking. One of the most significant changes we introduced was the standardization of hardware and operating systems into the equivalent of a private cloud – based on horizontally scalable infrastructure. I also identified that the two main applications in use at the time were themselves horizontally scalable, and so structurally configured them in the same way, and housed them on this common infrastructure. At the same time we built solutions that were Meta data driven, which meant: better and faster querying and reporting results. And that means money. Let’s stop for a moment. What do you mean by "horizontally scalable" infrastructure and applications? Horizontal scalability is a very important concept, and I am struck by how little it still appears to be understood. It's effectively about expanding process capability without running into overload issues by using multiple servers. Consider your laptop; its processing capacity is limited to one ‘box’. Now, if you could span many processing "laptops" from this one box, and scale horizontally, there would be no slowdown or overloading as a result of expanded operations. You’d get seamless transitions. To do this, though, you need to understand and address the core functionalities of your applications, as that’s where bottlenecks will appear. To avoid these bottlenecks, you need to allocate a reserved capacity for those functions. In my case, I sometimes allocated up to 5x the necessary capacity as a safeguard. This might seem like overkill, but it meant I was always sure, 100% confident, that the core functionality would be maintained at its optimal performance capacity, and it avoided delays, which cost you on both time and money. This has significant implications for reporting and data integration solutions, for example, as you are eliminating the possibilities of requests overloading, or slowing the system. What is the significance of Metadata [data about data] – meaning, how do you design processes to maximise their impact? To make your applications more agile, you need to build them in specific ways. This is basically about designing solutions to maximize your agility. When designing your systems, you want to ensure that if you need to introduce a change, you can do so in one place only, and it automatically transfers to all applications. Again, the most important impact of this is on time – cycle time. Agile, metadata-driven applications reduce cycle time from many months, to just weeks. And that is significant. How can you apply the same kind of "scalable" thinking to databases? There has been a very exiting new development in databases, called In-memory. Traditional databases tend to be limited by server capacity. A number of vendors, like Oracle, have been trying to overcome this limitation by designing new options like Oracle RAC (Real Application Clusters), which can run across 2-4 servers. But you still face the problem of core functionality being allocated to certain servers, and these being prone to experiencing overloads. Another example is Oracle’s Exadata. Now, if we consider that data volumes have been growing at an incredible rate, any problems you were already experiencing around data management are now multiplied. One solution is to move to a "shared nothing" architecture, in which each node is independent and self-sufficient, and there is no single point of contention across the system. More specifically, none of the nodes share memory or disk storage. The potential for sharing is enormous. So, whereas earlier we were discussing core functions, and allocating more capacity to them through horizontal scaling - taken a step further, shared nothing architecture has no core functionality at all allocated to specific servers – rather, you distribute it across all servers. This shared nothing architecture is characterized by an absence of top [master] nodes vs. slave [processing and storage] nodes, where the master nodes would otherwise present potential bottlenecks. Instead, any node can run the function. You’re now dealing with a logical, not physical, platform. Meaning, your requests for reports run across all servers without bumping into top nodes. The result, of course, is speed. How have you introduced this kind of innovative database design at some of the companies you have worked with – and what was the result? At Deutsche Bank, I saw the potential of this kind of technology because it allows you to scale endlessly to handle any amount of data. But let me start with a word of warning: What happens when you increase your hardware – your servers – is the probability of hardware failure increases. To mitigate this, you need to ensure you understand the mean time to failure of the different components of your hardware. You can only learn this from your vendors, who collect all the code information on warranty issues like motherboard failures, memory chip failures etc, which result in platform failure. You need to factor in this risk, but the benefits of a horizontally scalable platform are still worth the potential outage risk in my opinion. For example: a traditional database might take 4-10, maybe more, hours to run a query on say 1 billion records. If you use an In-memory database, this whole process will take just 1 to a few seconds – with the advantage that, if you match increased data volume with the same percentage increase in hardware [servers] you get no reduction in runtime or performance. In other words, a clean, shared nothing architecture offers you linear performance. Now, to your question on the impact we had on running reports and queries on the data…at Deutsche Bank queries that had taken minutes or in fact were not even possible to run as they overloaded the system, now ran in seconds. The problem we encountered was that the developers thought we had faked the tests. The figures were thought to be too good to be true. At HSBC we had a really challenging process in terms of the time it took to load a very large database and run the reports (days). Our calculations showed we would be able to run the same process in less than 30 minutes. The improvement in run times was expected to be in excess of 99%. The net impact in both cases would have been huge. So what is the implication of this kind of improved technology infrastructure for Finance leaders? Here is what my whole premise, my approach to data architecture, is based on: I know with absolute certainty that we can drastically reduce processing time for any number of queries on enterprise data – if we leverage horizontally scalable infrastructure with shared nothing architecture and in-memory database processing. There is no doubt in my mind that we can get results that previously took days, in less than a minute. I think what has led me down this path is that I see opportunities in technology and design which many others miss; because I don’t just see the high level overview, but I can also roll up my sleeves and talk CPUs, memory, and code with the engineers. And that is where many of these data architecture epiphanies occur. Today, many Finance executives face a data set that is expanding quickly, meaning it’s rapidly outgrowing its platforms. They overcome this by aggregating data – much as Google does when it pre-scans what’s out there to offer you superfast search results. This aggregated data forms the basis of financial reports. The problem arises when a figure is queried, and you have to go back into the system to verify its accuracy. Sometimes that means going back to business units, or picking apart the aggregated data, which costs time and money. It also takes hundreds, often thousands, of people to follow up on these kinds of manual verifications, especially within financial institutions. In-memory databases get you around the aggregated data hurdle by giving you access to all the information at the transactional level. So you can drastically shorten the time and effort to investigate figures, and you can hugely increase the accuracy of your reporting. And you can reduce the cost of reporting by 70-80%. That is a huge amount of money in the bank. And faster reporting means you can act on that information sooner – you can make better decisions in real time to avoid costly mistakes. _______________________________________________________________________________________________ 5 steps to implementing financial process risk calculations 1. Establish an in-memory database 2. Load into a data model at the transactional level 3. Define your risk calculations in r-code, for advanced statistical calculations 4. From sequel, execute your r-code on the same servers as your data 5. Leverage processing capacity through horizontally scaled infrastructure _______________________________________________________________________________________________ It sounds compelling. What’s preventing more Finance Leaders from adopting these ideas? To be honest, it baffles me, especially as the end-result can be run at a fraction of the cost. But big institutions that work with a lot of data have invested a lot of money in their systems, and they are often loath to introduce changes. They are so focused on their existing way of working and cannot think out of the box. Most of them have also become reliant on armies of DBA resources – database administrators – that have built up vast libraries of aggregated data focused on servicing specific queries. To improve data matching they have introduced indexes within the database. Again, this necessitates, firstly, a costly platform; and secondly, maintaining a team of costly DBA resources. The reality is, you could replace those resources with just 1 DBA by leveraging an in-memory database, with the benefit that you don’t need indexed nor aggregated data. An additional, and to me even more valuable, benefit is that you can focus on the logic of the data: What are you trying to achieve? What metrics do you need? How do you calculate them? So instead of expending effort on maintaining the database, you are thinking about how to leverage its capability for the benefit of the business. That is where Finance leaders should be focusing their efforts. How can you build risk calculations into data architectures to minimize your exposure? When you combine databases with reporting and risk calculations, you can bring the whole risk assessment much closer to operations by combining functionality. So for the business, benefits are multiplied. Traditionally, databases calculate risk data by moving the data to a computing platform and running the calculations there; then you update the original database. This takes a lot of time. My idea is to combine the database with risk calculations, instead of leveraging a separate database. You can do this by running external functions in an in-memory database. On each server, you install the code to calculate risk values. Then, when you query the database you call on these external applications. So you select the data and execute the risk calculation on the same platform. Now you can do in minutes what used to take half a day; and, again, less time equals less risk. As risk is a big concern for the Finance function, can you give me an example of this kind of risk application? Sure, I can give you one from the financial services industry. For a bank, a common risk calculation is called Value at Risk – or VaR – which is a widely used measure of the risk of loss on a specific portfolio of financial assets. Intraday VaR calculates this risk at various points in the day, and is a crucial reflection of risk for a financial institution. Other industries will have their version of this. The more recent the VaR calculation, the less your risk exposure. So the benefit of the approach I’ve just outlined is faster, more reliable calculation of Intraday VAR, and that means money for the bank. Now, when I’ve discussed this idea with people in the industry they say the problem with this solution is that it would decommission almost everything else they have in place, as it can consolidate multiple applications into one platform. Considering how many people that would impact – applications owners, managers etc – it’s not a popular option. But it can be done. I think it would take about 6 to 9 months to implement what I’ve just described, and it would save millions a day for financial services. Again, it’s not about redefining everything; it’s just about transferring a database to an in-memory model, loading the transactions, knowing how to define risk calculations, converting these calculations to r-codes; and executing on that. Who would take the lead in building out this kind of architecture? It would be the Head of Risk in some instances, or the CIO, depending on company structure. It should really be the business head, as it affects the whole company. A lot of data acronyms are being thrown around these days, and everyone wants to add a "Big Data" role to their team. Can you create some clarity on what this means? What all this interest in data boils down to is a lower run rate or maximising the value of data. That’s a key objective. You want to lower the percentage cost to operate a business compared to the money it makes. And to achieve this lower run rate you need to be innovative about how you look at data architecture and processing options. Big Data, meaning the expanding data sets that surround us, has garnered a lot of headlines and has its advantages, but I think a lot of it is hype. In-memory offers huge opportunities to change how we use information for the benefit of the enterprise and makes a lot of existing applications redundant. But to make the most of these opportunities you have to be able to think outside the box. Now, where Big Data has an advantage is where it leverages Hadoop platforms to handle unstructured data. It searches and stores relevant information from Twitter, web logs, etc, in files, so that Hadoop can easily access it for queries, based on programming language. But such a Big Data strategy requires developers to develop the querying code. And what happens when you commit to a set queries, and you need to programme each new query, is that you step away from what I call "train of thought" investigations, where you can follow, or act on, a new idea … and which allows you to be reactive and interactive. By limiting yourself to Hadoop-based queries, you are somewhat restricted in my view. How would someone who disagrees counter this? The main critique of traditional databases is that they do not allow for the analysis of unstructured data – social media etc, and that is true. But I also believe that few organizations today really have the maturity and need to analyze social data – though they all seem to want to jump on the bandwagon. What they do need to do is analyze and understand market data and operational data. And Hadoop certainly has a positive impact in areas like talent retention, because Social Media is important in branding. And although analyzing web logs is valuable – for example in tracing the causes of outages – there are other platforms, like Splunk, that can do this just as well, if not better. Thanks Lars, for your time. Interested in finding out more about Enterprise Architecture? Take a look at the programme for SSON’s Finance Transformation Summit in London on February 10-12, 2014. Our producer Katie Biltoo has asked leading finance executives to share how they have redefined their role and how their business is benefitting as a result. In particular, discussions will focus on how to drive improvements through business partnering, rethinking delivery models, and adopting technological advancements. The event is designed for Finance professionals at every level of maturity. View the programme now.

Transforming Finance’s Ability to Provide Fast Business Insights by Rethinking Enterprise Architecture

Upcoming Events

Future of Finance & CFO Select

HR Shared Services & Outsourcing Week

Agentic & Applied AI for the Enterprise

Finance Transformation Virtual Summit

Human-in-the-Loop: AI for Connected Record-to-Report

Smarter AP, Reduced Risk: How Medius uses AI to detect fraud and strengthen supplier engagement

Follow Us

Latest Webinars

Germany’s 1 January 2027 E-Invoicing Deadline: Timely Guidance for Time-Crunched Leaders

Why Shared Services and GBS Transformation Stalls and How to Overcome Change Fatigue

Through Trust and Governance: How AI Agents are Redefining Accounts Payable

Recommended

Leveraging Hyperautomation to Achieve Data Integrity

How GBS Can Read Data ‘Tea Leaves’ for Better Decision-Making

The Importance of Algorithms and Problem-Solving in Supporting GBS

Digitizing Unstructured Data Enterprise-Wide

How to Harness Analytics: The Rx Healthcare Remedy for Data Accessibility

SSON Analytics Announces the Top 20 Most Admired SSOs & GBS for 2021

Lion: Winner Of The Business Resilience Impact Award 2021, Australasian SSOW

Hiring People "Not Like You"

SSON JOB BOARD: Document Administrator - Makati City, PH - Odfjell Drilling

In (Accurate) data we trust

Develop "Agile" data lakes – or risk a data swamp

SSON JOB BOARD: ERP System Controller (SCM) - Odfjell Drilling

FIND CONTENT BY TYPE

SSON COMMUNITY

ADVERTISE WITH US

JOIN THE SSON COMMUNITY

Transforming Finance’s Ability to Provide Fast Business Insights by Rethinking Enterprise Architecture

Upcoming Events

Follow Us

Subscribe to our Free Newsletter

Latest Webinars

Recommended

FIND CONTENT BY TYPE

SSON COMMUNITY

ADVERTISE WITH US

JOIN THE SSON COMMUNITY