An Introduction to Data Strategy

A short history of Data

Tons of data are produced at different enterprise levels every day. Many different ways exist to classify data. There are operational data as well as analytical data, structured and unstructured data, internal and external data, actual and metadata. On operational level one can find transactions, transactional states, transaction Metadata, reconciliation data, master data, pricing and calculation data, data about operational risks and customer classification. Last but not least there are a lot of business partner communications over different channels in several unstructured formats. On analytical level many enterprises have created data warehouses and data marts during the past 20 years. The first and foremost target of those early analytical data stores was to support a comprehensive management information system by creating flexible reporting facilities. Data Mining came into the play a few years later. Techniques such as automatic generation of decision trees with entropy measures like GINI index, clustering algorithms, found their ways into data analysis in the early days of data mining. One big issue with data ware houses has always been the data quality and data enrichment. This is where data cleansing methods were introduced. External data sources have been used to enrich data or to get higher quality.  But this was not the only intention of adding external data sources into the system. Enrichment can be used to get more data related to a subject and to correlate them with the existing data in order to achieve new insights.

The Rise of Big Data

As technology evolved and new methods of handling and analyzing any kind of data appeared the value of data as an economic property increased. Big data, data science and artificial intelligence brought new opportunities to create Knowledge from Data. To relate different kind of data to each other in ways they haven’t been related before came into the spotlight. With those new capabilities new type of data became more interesting for analytics purposes. Data about data so called Metadata which one can imagine of as the data definition or data access statistics on the one hand side and unstructured external data such as content of social media sources like facebook, twitter, etc. on the other side. Many topics like data extraction, transformation and loading, data cleansing and enrichment, data protection and data privacy one will face on technical level in big data initiatives have been in place in data warehouse implementation already. Others like handling streaming architectures, automatic data type recognition emerged as specific topics to Big Data. The organizational challenges are much bigger in big data since big data has a more open scope than the very specific scope of Data warehouses.

Data Strategy, what’s that?

Data become strategic and hence there is a need for a systematic approach both on business as well as on technical level to improve value created by data. On business level an enterprise need to define
  • what should be achieved with data (vison),
  • which data are needed for that goal,
  • which methods are they going to apply to create new insight from that data and
  • what income that knowledge can lead to?
This is what a data driven business model is about. It stands at the very beginning of a data strategy an enterprise has to develop and follow in terms of monetarizing data. A data driven business model can be thought of the same way one creates a common business model. Imagine a business canvas. There you have a rectangle for key resources a business needs to create a value proposition. Data are such key resources. Hence, a data driven business model must give answers to the same questions asked in a business canvas. Coming from a business canvas approach it is also necessary to define a set of key activities to be taken in order to create the value proposition. What is an enterprise going to do with the data? Which kind of analysis methods should be applied in order to create information which leads to that knowledge? By finishing this task the most important part of a data strategy will be already delivered.

Causation vs. Effectuation

When it comes to choosing the right analysis methods for the data it is important to know the kind of problem that exists. In decision making there are two different classes of problems. In the first one there is a given predictable effect with a known probability. The target is to choose information gathering and analysis methods to select between the means to create that effect. This is called causation. In the second there are several unpredictable effects in place. The target is to find out which effect is more likely to emerge with given means. In this case the analysis has to apply experimental techniques to discover the underlying distribution of the unpredictable effects for given means. In data analysis one might follow a hybrid approach where both analysis methods can be applied.

Different Data Strategy approaches from here

During getting deeper into this subject I have discovered different definitions of a data driven business model. Some experts require a data strategy should also define a project plan which describes how an actual subset of the data should be analyzed with milestones, budget and all that project management stuff we all know. Other experts of data strategy development stop with creating a data driven business model. One interesting approach I have recognized starts with definition of key actors and key data. Then it switches to the customer and creates a customer profile. Value proposition is created by a so called Data-Need-Fit. From value proposition other parts of the business model such as key activities are derived.

But ….

Experts always call out the need for a systematic approach when a new idea and method appears. I have seen a lot of them in the past. Well prepared and best sold systematic approaches to master new challenges. At the end of the day one can measure the actual value contributed to the enterprises success by the impact an initiative has to the enterprises revenue regardless of how systematic and well prepared that initiative was. Unfortunately many of those approaches end up helping their inventors to create value. If you want to have an advice, choose the people for implementing your data strategy wisely. That’s the most important thing.

For further reading …

Data and Analytics – Data-Driven Business Models: A Blueprint for Innovation The new hero of big data and analytics: The Chief Data Officer Effectuation and Causation: The Effect of “Entrepreneurial Experience” and “Market Uncertainty”

Things not even Big Data can predict

An Open Mind can Move Mountains

She was about to start working for a large bank the next month. “Big Data Analyst” she told me. I was very impressed. Big Data, wow! I was always impressed of the way she used to do her job. Starting with those days when we were used to work together. She stayed always cool and friendly even when work was very tough. She had quitted her job already but we still whatsapped. Considering what she was doing before, Big Data was a huge step forward. October was heading to its end. We decided to meet for lunch once again. We agreed on a restaurant close to the river. You could sit outside at that place. It was a warm day when we met. One of those days at the autumn’s beginning where the sun still keeps alive hustle and bustle out there. She was already waiting when I arrived. She sat at a table outside with a nice view over the river. There was a big fat camera on the table, close to that a book about big data and analytics. “Hey!” I said, “What’s up? Sorry for being late!” I continued. “Hey!” she replied, “Don’t worry, all good!” she smiled. “What’s that for?” I pointed to the camera. ”Oh, Photography is one of my hobbies! It’s a good light today!” she explained, sounding like she’s bit proud of her camera.

Big Data with No Idea

After all that small talk stuff people bring up, when they don’t know each other very well but they feel like they have to go through, I asked her about Big Data. She started to tell, the very humble way she always told about herself. “Oh, I have no clear idea, I’ve just started reading this book here.” And then a remarkable overview of big data technology came through. I learned a lot about Cloudera distributions, Lambda architectures, Elastic Search, NoSQL database s and the amazing number of different open source initiatives for different purposes. That was what she has always been. A very skilled and open-minded computer scientist with no fear of change. She was going to start that job with a good general skillset in computer science and mathematics and no actual idea of big data. But with an open mindset and the will to learn. To learn fast. This happened two and a half years ago. Today she is her manager’s right-hand woman having a deep understanding of tools, technologies, what actually practically can be done and which pains one can expect in big data projects.

Delivery Thinking is made of These

Last Friday we met once again. This time she told me about automatic data loading, type and structure recognition via machine learning and the usage of database statistics for data analytics. Interesting stuff. I have never thought about it. But it’s true. Data access statistic harvested by RDBMS like oracle might be a good starting point for data analytics, indeed! Data frequently accessed are more likely to be important than the less accessed data. But she told me about the obstacles of getting access to data together with their metadata and statistics within a certain operational transaction processing database due to organizational barriers between different departments and lack of understanding as well. Apparently, you need to convince a lot of people and consider things like data privacy and data protection, when you want to get access to data for analysis purposes. Even though it is clear that there will be no way to track back customers or any other persons, you must go through a lot of bureaucracy to get the data. Obviously, there is a long way to go and yet she hasn’t lost her faith, optimism and open mind. Delivery thinking is made of these.    

Life punishes the Latecomer or the Compromise

How to transform an Incumbent to a Startup An Insurer to an Insurtech A Bank to a Fintech

I already wrote  about one of the key elements of a successful transformation: Courage. Courage to make the hard, but the right decisions. What are right decisions? If you want to perform like a startup you must create comparable conditions and environments.  And one of the most important parameters , possible the most important one is to operate without legacy. And legacy in today’s startup and digitalisation context usually means: IT Legacy.   That said my tip  is to replace  legacy as radically as possible.  Get rid not only of the one or other core system, but possibly rid off most if not all IT systems.

Distributed courage

Usually very few have the courage to decide in this direction.  Incumbents leave this playground to new startups doing often the very same business compared to the incumbents, but within a legacy-free environment.  These startups will be founded with or without the help of incumbents. In the area of Insurance Friday is one example. There are many other examples  for banking and insurance, even old ones. Think of First Direct in the UK. If you are  more brave than the standard you migrate some of the very important parts of legacy with light speed like Zurich Germany did with their new core system based on Guidewire and Open APIs. But if want to ‘play within the Champions League of Transformation’ and of replacing IT legacy you might decide like apoBank did end of 2017. They declared to migrating all existing IT systems and to start over from scratch with new core, but also with many other new supporting IT systems. This indeed is a risky decision and never a 100% guarantee for success, but a major step into the right direction, if you ask me. You need of cause process and organisation amendments as well, but you can now align these to fresh IT systems. And IT is at the heart of everything these days. We, I don’t know the end of this story. I only can state: Where no risks there no chances! This is also very genetic for a startup.

Please don’t switch to Amazon Panic Mode

No one size fits all

Currently everybody is talking about ecosystems – me, too. We are assuming the platformisation, the creating and implementation of ecosystems and the participation within should be one important step in ones Digital Strategy. But besides this very reasonable approach there is one kind of panic belief: Successful platforms like Facebook, Google or Amazon will disrupt every business line. I’m a fan of ecosystems and believe GAFA can disrupt a lot. But I don’t necessarily think, they will win everywhere and automatically. Especially, when you enter business models based on sensitive data and processes like the ones of banks and insurers. Why do I believe this? Because I’m very convinced, every transaction has a trust level like an ecosystem has as well. And only if one trust level matches the one of the underlying ecosystem one can  attract transactions in the long term successfully.

Today’s ecosysstem world

Facebook is an ecosystem with a trust level of one (very low).  Posting a picture of my last meal is a transcation with a trust level of one as well. Amazon is an ecosystem with a trust level of two. Buying retail stuff is usually a transaction with a trust level of two. A money transfer is based on trust level four (very high).  Insurers are usually ecosystems of trust level three or four (P&C versus Life). I don’t guess, a customer will cross these given ‘trust level swim lanes’. He will not process a level four transaction within a level one ecosystem in the long term. Ecosystems will attract only their level of transactions.  Or ecosystems need to increase their trust level. Platforms like Facebook or Google will have, from my perspective,  difficulties to increasing trust levels. Especially when you consider, what people are currently doing on these and how their general reputation looks like. Amazon indeed might have a chance to crossing the boarder. That’s, I believe, exactly the motivation behind their superior service excellence strategy, but it’s still a difficult story. Besides the soft facts (the view of the customer) you have to fulfill a lot of hard facts to power a level four ecosystem, e.g. level four verified customer identities, KYC, governance etc. That said I wouldn’t recommend all the insurers and banks to switch in Amazon Panic Mode, but to leverage exactly this given difference and advantage of being and becoming a Level Three or Level Four Trusted Ecosystem.    

Down to the Code in Rest Applications

Use HATEOAS to Separate Control Flow and Client Representation in Single Page Web Application

When it comes to “deliverythinking” sometimes we have to leave our flight level from 10,000 feets to somewhere closer to the actual code. This is at the end of the day what it’s all about: Code! Few days ago I talked with a friend of mine with which I used to work for a long time. We used to develop web applications with Vaadin back in 2014 when we were working together. We discussed how Vaadin has evolved since then and how easy you can create new web applications with it now. In such discussion you end up talking about single page applications and millions of different java script frameworks around that at some point in time.  It is actually impressive, how single page web applications managed to dominate this topic despite of the huge number of different frameworks, tools and technologies. But managing all this framework stuff in an enterprise world is another story. In today’s article I want to point to another interesting thing with single page applications which I talked with my friend. When you develop single page application one big issue is to hide all the business logic and the presentation flow from the client tier. It must not be part of the java script code delivered to the client. This must be considered when you design an API. Ideally client does not know anything about business logic and control flow of the application. In Rest Architecture there is a constraint principle called “ Hypermedia As The Engine Of Application State (HATEAOS)“. HATEOAS allows exactly this separation of control flow and client. “With HATEOAS [..] A REST client needs no prior knowledge about how to interact with an application or server beyond a generic understanding of hypermedia.” as Wikipedia explains. With other words a rest resource comes with a list of links which tell the client next interactions are possible starting from this served resource. As an example (Source Wikipedia) if you requested an bank account with
GET /accounts/12345 HTTP/1.1
Accept: application/xml
the response could be like
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: ...

<?xml version="1.0"?>
<balance currency="usd">100.00</balance>
<link rel="deposit" href="" />
<link rel="withdraw" href="" />
<link rel="transfer" href="" />
<link rel="close" href="" />
As you can see here from account with number 12345 you can perform deposit, withdraw, transfer or close. The linking piece between the client and the backend are the keys given in the rel part of the links. Of course there is an XML as well as JASON support for HATEOAS.
"firstname" : "Dave",
"lastname" : "Matthews",
_"links" : [
"rel" : "self",
"href" : "http://myhost/people"
For good old java developers Spring provides a project called Spring HATEOAS which currently is in a prerelease phase. Also you can find a set of best practices in API design at Microsoft Azure.

Digital Transformation to Keep up Revenue

The Winner Still Takes it All ….

It is commonly known that in times of low interests and intense regulations financial sector in Europe seeks for new ways to keep up profitability. Beyond low interests and increasing regulatory requirements also all of us know about the additional pressure digitalization is creating on the financial sector. Many articles, strategies and discussions have been published around that in the past few years. Well, there is no other answer yet to this new challenges then that one which all of us have learned somewhere in the past. A company may either reduce expenditures or increase earnings to affect profitability positively. That is what strategy is all about: Find ways to increase earning or reduce expenditures. Which processes are to be redesigned? Which systems are to be replaced? Which services are to be introduced and to whom Retail, SME or large enterprises? Having a look at the strategic answers banks and insurers find around these questions one very quickly may perceive that pretty much all of them start modernizing their IT. They do this because the hope to achieve several goals at once. They all hope to increase efficiency and reduce costs. They either have missed to replace IT in the past twenty years and hence carry a lot of technical debts or even if they have done that once during that period they need to redo because of the speed of technological progress. On the other hand they hope to create a set of new business areas where they might produce new sources of revenue. New IT may allow banks and insurers to expose parts of their business to the public so other companies might mash them up with other services and create new value propositions which in return will help banks and insurers to benefit from those kinds of network economics. Such kind of network effect for instance might appear by taking new FinTechs and InsurTechs into account. Those startups create new value propositions mostly for SME and retails business and they have a significant demand for foundation services they usually cannot provide themselves in first place. Working together with startups in almost all cases means bringing up new services for SME and retail and this fits to the strategy. ING for instance mainly targets SME for creating new business. ING is going to spend up to 800 million Euros for continued digital transformation until 2021 implementing new lending platforms for SME and consumers. Other banks and insurers are doing similiar things. Indeed there are bunch of initiatives like ING’s. Banks and insurers are introducing new core systems. They will be exposing their services semipublicly soon. They will operate clouds where third party applications can run. We will see a bunch of announcements for new application marketplaces operated by insurers and banks where developers offer new cloud based apps using the exposed services and cloud operating models. They might also use existing marketplaces such as SAP’s HANA or Salesforce’s AppExchange. I am very curious which one of those projects will succeed and which ones of those succeeded initiatives will actually survive. The principles of network economics teach us the winner takes it all. Hence, not all of them can win. And what I actually am asking myself is what if a developer decides to use services exposed by different banks and insurers in one single application simultaneously? Where does she publish the application? Does he publish and offer it on the marketplace of Bank A or Insurer B? On whose cloud will that application run when each bank or insurer offers its own cloud? How can hybric clouds or multi clouds establish solutions which really work?

Blind Date – A Transformation Approach

Architecture follows Strategy.  Project follows Architecture.

I would label myself as a ‘Hybrid Transformer‘  supporting technical and organisational transformations – following the one, given strategy. Doing it right translates typically to Architecture and Organisation as a Strategy!  And having worked within this context for quite a while what surprises me most is how badly companies are often prepared for huge transformations. Although spending two or often three digit sums of Million Euro seldom a clear strategy is defined nor is the base- or target-strategy,  -architecture or -organisation with its gaps documented and maintained at the beginning of or even during a project. After a visionary start companies often activate the ‘Program Auto Pilot’ and focus the technical tasks to migrating the one core to the next. Usually relying on third parties doing all the rest for you, but don’t really care for the development of your organisation as a whole. This might work, as a blind date works from time to time, if you find the one or two heroes for your fairy tale, but not very often. As a responsible person for huge transformations I would not only install an Architecture Office or an Architecture Board, hire Solution Architects to act as fire fighters,  I would implement, as one of my very first actions, a working Enterprise Architecture Process and Governance in order to control and manage not only my technology challenges, but also my architectural, organisational and strategic ones. Enterprise Management (EAM) is a rather mature discipline today. The tools and processes can be helpful and supportive applied carefully. The most popular one is TOGAF supported by the Archimate Modelling Language.  And TOGAF and Archimate are not only for techies. An ADM with its different viewports is helpful for everyone – from the developer to the CEO.

It constantly should tell you, where you are and where you want to go. And why!

If you start a huge transition program and you don’t find a working Enterprise Architecture with clear vision, business-,  architecture-baseline and target models aligned by defined processes and decision boards be very careful and ask necessary questions. (Strategy as a diagram – Credits to OpenGroup) A Blind Date can work, but it typically includes a lot more surprises than other dates. If you love surprises and firefighting don’t care for Enterprise- Architecture and -Management!    

Do not fear Transformation

Within the last 30 years (always mentioning experience is a tick of old men I guess) I often have been a part of large transformation programs. Over the years I understood more and more of the whole and my responsibilities became more senior either. In parallel the strategic value of transformation has massively increased as well. The digital evolution/revolution is accelerating the meaning of core transformation exponentially. This is the reason why I decided to blog this time about my next transformation program and to highlight success factors, pros and cons as far as external and internal compliance allows me to do, keeping in mind, this blog represents my opinion and not my employer’s one. So number one success factor for every transformation is courage. And courage is also the reason why I accepted my latest  job offer. I believe I have never seen a team and incumbent having been more brave to deciding things more massively. This impressed even an old guy like me: Courage to fight for your vision and dreams even in the darkest hour. Courage to stand against the nay-sayer. Courage to stand against ‘Bottle-Half-Empty’-guys. Courage to fight the compromise. Courage to accept having around a lot of people wanting you to fail. Courage to fight your and the fear of failing. Courage to laugh when there are only reasons to cry. Courage to stay friendly even when the nicest becomes unfriendly. Courage to think beyond the quarter. Courage to not having a Plan B. ‘One who chooses IBM because he doesn’t want to be fired’ is not the brave a huge transformation needs. So look into the eyes of your leaders and try to identify the necessary courage for the coming years. If you find it stay. I have not met many brave leaders the last three decades, but I met some!