A New Approach to Steering Strategic Enterprise Data Initiatives – Part 4 of 8
In Part 3 of this series, I explained a bit more about how the answers to the high-level executive questions about data need to be compiled, to enable even more insightful steering of your enterprise data transformation initiative. In this post, I continue the exploration of the “list-based” approach by explaining how to compile your list of systems.
Please read my Disclaimer by clicking here.
This may seem obvious to some, but I’ve been challenged on this in the past, so it’s worth addressing up front.
The answer is very simple: your systems contain your data. If you don’t do anything with your systems, you are working in theory land. You can spend as much time as you like on defining your metadata and agreeing data quality rules and all those lovely, data management-y things, but it’s not until you actually apply those definitions and rules to real data, in real systems, that your data management journey really begins and you can start driving some real change.
When you start identifying problems with your data, you will find those problems within your systems. It’s quite possible that some of the systems where you find the problems, didn’t cause the problems, but it’s the act of looking at your data, in your systems, and then assessing what led to the data getting there in the state that it’s in, that will lead you to understand the problems that you need to address, so that you can fix them properly.
Depending on the data a system contains, you will need to put different levels of data management and security arrangements in place.
…and that’s it, for now. As with the list of data, the titles that you use can be adjusted if you want to tailor them from the list above, and the multi-choice options can be changed to meet your needs and so on – but these are the basic things you need to capture.
In terms of things to note for your list of systems:
1. As with your data list, the “OK-ness” (or “Compliance” or “Fitness” or whatever) – should be a simple "yes" or "no", to enable a clear, rolled- up view. The simpler the better, to avoid a lack of clarity. However, whether a system is "OK" or not should be determined based on an assessment against a set of clear criteria, which are agreed by senior management. For example, a system might be OK if:
2. Each system's priority should be simple as well, but needs to be established in such a way that you don’t have everything grouped up at the top of the priority list, so that you can put the list in some kind of order. Sometimes it’s useful to have a “priority order number” column, where you literally assign a number from 1 to N, with a rationale column to explain why. The priority of systems is usually determined by a number of factors, such as:
The most important thing with the lists that you create, is that they are created in a way that makes them easy to interrogate. The columns of information you capture about your systems (or data, or processes, or whatever your list is managing), need to be designed consistently to enable slicing and dicing of their status in a meaningful way, to easily answer questions that senior management might ask.
The key thing to have in mind is: what questions is this helping us to answer? How does this help us manage our status and help us prioritise and track progress?
It’s worth going back to the executive questions again, to help refine the list and make good use of it. With you list, you should be able to answer:
There’s a fair amount of work involved in compiling and maintaining these lists, but the actual steps to doing so are quite straightforward and the benefits are significant, if done properly and used well.
So now you’ve got your list of systems, which enables you to get a handle on the key "containers" of your data. Next we’ll move onto the list that drives the most action…
Please read my Disclaimer by clicking here.
Why systems?
Before going into how to compile your list of systems and how “OK” they are, some people may be wondering – why do you need a list of systems, if you’re trying to manage your data?This may seem obvious to some, but I’ve been challenged on this in the past, so it’s worth addressing up front.
The answer is very simple: your systems contain your data. If you don’t do anything with your systems, you are working in theory land. You can spend as much time as you like on defining your metadata and agreeing data quality rules and all those lovely, data management-y things, but it’s not until you actually apply those definitions and rules to real data, in real systems, that your data management journey really begins and you can start driving some real change.
When you start identifying problems with your data, you will find those problems within your systems. It’s quite possible that some of the systems where you find the problems, didn’t cause the problems, but it’s the act of looking at your data, in your systems, and then assessing what led to the data getting there in the state that it’s in, that will lead you to understand the problems that you need to address, so that you can fix them properly.
Depending on the data a system contains, you will need to put different levels of data management and security arrangements in place.
What systems are in scope and how many of them are “OK”?
As with the list of data that I explained in the last post, I’d recommend a simple table for systems too, capturing the following:- System ID (to uniquely identify each one)
- System name
- Description
- Security classification (level of security of most sensitive data it stores/processes e.g. Internal only, Confidential, Secret)
- System criticality (high, medium, low)
- Authoritative source for (the dataset that it’s an authoritative source for, or “N/A”)
- Status (buy, sell, hold)
- Owner (name of specific person)
- OK-ness (OK, not OK)
- Priority (01 – High, 02 – Medium, 03 – Low)
- In scope? (yes, no)
- Data entities (e.g. Customer, Location, Product)
- Comments (including notes on rationale for priority, for not being in scope, for OK-ness etc as appropriate)
…and that’s it, for now. As with the list of data, the titles that you use can be adjusted if you want to tailor them from the list above, and the multi-choice options can be changed to meet your needs and so on – but these are the basic things you need to capture.
In terms of things to note for your list of systems:
1. As with your data list, the “OK-ness” (or “Compliance” or “Fitness” or whatever) – should be a simple "yes" or "no", to enable a clear, rolled- up view. The simpler the better, to avoid a lack of clarity. However, whether a system is "OK" or not should be determined based on an assessment against a set of clear criteria, which are agreed by senior management. For example, a system might be OK if:
- It’s got an owner
- It has an agreed security classification assigned
- It has an agreed service criticality assigned
- It’s clearly flagged as being an authoritative/golden/master source or not
- It has appropriate Data Quality controls in place, based on its classification
- It has appropriate Security controls in place, based on its classification
- It has appropriate Data Privacy controls in place, based on its classification and if it managed personal data
- It has appropriate Payment Cards controls in place, based on its classification and if it manages card data
2. Each system's priority should be simple as well, but needs to be established in such a way that you don’t have everything grouped up at the top of the priority list, so that you can put the list in some kind of order. Sometimes it’s useful to have a “priority order number” column, where you literally assign a number from 1 to N, with a rationale column to explain why. The priority of systems is usually determined by a number of factors, such as:
- Service criticality level
- Is it an authoritative source for any datasets (which other systems depend on)?
- The timeliness requirements of the data e.g. are other systems dependent on a real-time feed or is a daily batch sufficient
- Confidentiality of data it processes
The most important thing with the lists that you create, is that they are created in a way that makes them easy to interrogate. The columns of information you capture about your systems (or data, or processes, or whatever your list is managing), need to be designed consistently to enable slicing and dicing of their status in a meaningful way, to easily answer questions that senior management might ask.
The key thing to have in mind is: what questions is this helping us to answer? How does this help us manage our status and help us prioritise and track progress?
It’s worth going back to the executive questions again, to help refine the list and make good use of it. With you list, you should be able to answer:
- How did you choose the list of systems that are in scope? What have you left out and why?
- What does “OK” mean for your systems? What’s the impact of not being “OK”?
- How have your prioritised your systems?
- What are you doing to make more of your systems “OK”?
There’s a fair amount of work involved in compiling and maintaining these lists, but the actual steps to doing so are quite straightforward and the benefits are significant, if done properly and used well.
So now you’ve got your list of systems, which enables you to get a handle on the key "containers" of your data. Next we’ll move onto the list that drives the most action…
Comments
Post a Comment