Coping with historically-grown information and data systems is probably one of the biggest internal challenges facing the most of the data-driven companies founded a couple of decades ago – especially financial institutions, such as banks and insurance houses. The examples of problems and challenges are numerous; from immensely huge costs of fulfilling legal requirements, such as those imposed by EU-GDPR or BCBS 239, to non-agile solutions and vague and limited insights into existing data, their structure, organization and usability.
In such situations, a development of a holistic and enterprise-wide approach is needed to tackle data-based challenges, to define the way of solving data-based problems, and to provide the guidance for achieving the ideal state of the data within enterprise. So obviously, we are speaking about the development of appropriate data strategy.
This article explains my approach to develop and to implement data strategy in enviroments with historically-grown information systems. It has its roots in one data strategy development project I done few years ago in UK, and I used it recently as a basis to successfully develop “IT data strategy” for another company.
Defining Data Strategy
Starting with data strategy is not the same as starting with the enterprise strategy. The reason is simple; enterprise strategy should define the way of achieving the vision of the enterprise defined by the management and other important and relevant stakeholders; data strategy on the other hand should define the way of achieving the ideal and the most optimal state of the data within enterprise, but taking into considerations the limitations and the requirements of the enterprise architecture framework.
Data Vision and Data Status-Quo in Enterprise
Bearing in my mind consequently imposed “data vision” that the company wants to achieve the most optimal state of the enterprise data, the first step in my approach was to clarify what is actually understood under such state. For that purpose I organized numerous workshops and meetings with relevant business and technical departments to discuss the status-quo of the data usage, data-based solutions, and data-driven products, while simultaneously covering perspectives of current, expected, and wanted experience.
The content I acquired during those activities described experiences, problems, challenges, expectations and ideal situations concerning the data, their application and their solutions. So, in addition to the insights into actual problems and business users’ frustrations, I had a pretty clear picture of the “data vision”, or, what people in relevant company actually understood under the phrase “the most optimal state of the data”.
Through categorization and schematic clusterisation of the content from different perspectives, I was also able to identify which categories of applications, solutions and technology concepts cause the biggest problems, and what categories of business functions and processes are the most challenging to be implemented.
Technical Status-Quo and Possibilities Analysis
Knowing that, I could continue with my next step, which included discussing applications and solutions (from clusters and categories identified as problematic), but only with relevant technical departments. The idea behind those activities was to understand how applications work, what parts of them make the biggest problems for tech guys, what kind of implementations make the biggest challenges, and to get any suggestions what could improve those applications and solutions, or even to get some ideas what could make the whole infromation technology situation better.
The most important result of such discussions was a clear identification of key interfaces which cause difficulties for data-relevant implementations and data maintenance, while other results included numerous suggestions how to improve and to optimize current applications and systems – in data use context, of course.
Preliminary Data Strategy based on Expert Opinions
Knowing the data problems, challenges and wishes of business and technical departments, I organized several “panel of experts” with external data domain expert and academics from my network. The aim of those panels was to identify the most appropriate way of applying perspective data strategy, taking into consideration current data situation, requirements or wishes of technical and business departments and the best industry practice. At the end, I had a list of (i) relevant concepts that should support the most optimal implementation of my data strategy, (ii) appropriate physical solutions to support those concepts, and (iii) clearly defined steps to introduce and apply those concepts.
From high to low levels of Data Strategy
The last high-level step in data strategy development was presenting it to the decision-makers and to the other relevant stakeholders, and of course, getting and incorporating the feedback. The final strategy had five main building blocks. After approval by relevant stakeholders, I started with low-level activities concering my strategy, meaning, I started with translating each of the five busilding blocks of the strategy into actual implementation artefacts.
For example, during recent develpment of “IT data strategy”, introducing a holistic IT data architecture was defined as the first build block, or as the first step in defined strategy. In that context, a clear guide was needed to conceptualize, define and to physically implement IT data architecture. So, in cooperation with numerous internal and external domain experts, I developed a concept of IT data architecture framework that represents strategic, tactical and operational perspectives of the data through different data models. The appropriate attributes of those models provide basis for comprehensive data documentation, and they enable data linage and identification of the complete data flow, regardless of type of data or its level, such as field, table, file, or interface. Those models, for example, connect business data definitions with relevant technical data objects, applications and systems, but also with relevant processes and relevant legal aspects. Those models as well introduce incorporation of requirements management process into data generation or definition process. It is identified that the comprehensive documentation and effective maintenance of such models at every level is possible with a good metadata software. Thus, in addition to data models content and structure requirements, to evaluate the potential metadata software in the scope of the functional software requirements, I initiated, organized, and moderated additional workshops with business experts and IT key figures. Also, it was my responsibility to propose the steps of technical implementation and integration of appropriate metadata software into existing information systems environment. I’ll explain in detail my approach to conceptualize, define, develop and implement data architecture in one of my next articles. However, as this article focuses on data strategy, I’ll leave it there.
In a similar way, depending on the data strategy step, I also “translated” four other building blocks of the strategy into technically understandable implementation artefacts. No matter what I defined or conceptualized, I always discussed it with relevant business and technical teams – to get additional insights and to be sure that they understand the value of proposed step, solution or a concept.
So, this article basically explained my approach to conceptualize, develop and implement appropriate data strategy in companies with historically-grown information systems. But, taking into consideration that every company has different environment, requirements and mission, every other data strategy will deviate from my approach at least a little bit. However, you can use approach presented here as a guide to develop your own data-based strategy.