How can a CDO tackle conflicting data demands?
The role of a chief data officer (CDO) has changed significantly over the past decade. Ten years ago, the job title was, more typically, data processing manager or head of data processing, and the job itself tended not to be recognised as a driver of added value.
Today, few senior decision-makers within technology businesses go more than a day without running up against privacy and security. The world has become so digitally interconnected that the role of the CDO has shifted from being about meeting operational requirements to performing the difficult balancing act between ensuring compliance and helping deliver the organisation’s strategic goals.
In line with this, it is crucial that CDOs avoid simply vetoing projects or putting a brake on them arising from compliance concerns. Instead, when dealing with any data request, they need first to understand what are the goals or objectives of the person making the request and then try to facilitate the request in a way that drive the operational goal, but at the same time protects privacy and safeguards security.
It could be that a direct approach does not work, simply because the law prevents it, but there may still be another way to achieve the same result. For example, most global laws stipulate that certain types of information cannot be used without the express consent of the individual. Yet, there may be related types of information that can be used under the right circumstances.
In the healthcare space, it is not unusual to receive requests for records showing a patient’s date of birth for use in specific kinds of project. Typically, in such a case the CDO will ask the obvious question: “Why do you need this piece of information?” to which the answer will generally be: “Well we need to know how old somebody is.”
In reality, the date someone was born does not tell you that. It tells you how to calculate how old they are. The data you are really looking for is not the date of birth of the individual concerned, but it is their age. And in this context, age is less critical and less sensitive than date of birth.
This is a perfect example of how a CDO can help to answer the key question – is there another way to get to the objective on which we are focused– in this case how old someone is - without exposing sensitive data and potentially breaching compliance requirements?
Another common example is where someone from the business asks for the names and addresses of everyone in a given area of a town with a view to understanding how many people are buying a product from this area. Again, by looking at the objective rather than just the request, the CDO can discover that the person does not actually need (or truly want) any personally identifiable information. They don’t need to know who these individuals are, but simply how many of them bought the product.
In line with this, the role of the CDO should never be simply to block progress but rather to help people within the business understand what they are looking to achieve and if there is another way of doing it that better meets compliance needs. Defining the objectives in terms of the goals rather than the inputs.
The negotiating and consultancy element of this is important because many people within the organisation immediately focus on the data that they think they can access rather than looking first at their end goal and what they require to achieve it. That’s where the CDO can help de-conflict ostensibly opposing needs for compliance and business benefit - and ultimately still get to the same result.
Of course, there will inevitably be certain objectives that simply cannot be fulfilled for compliance reasons. But for the most part, if organisations are acting ethically and within the law, there will be a way that they can achieve their business goals with respect to data. It is key that CDOs look to facilitate this. They don’t want to be regarded as an impediment. After all, no CDO that is perceived to be preventing the organisation from achieving its goals, will ultimately ever be successful.
At the end of the day, the CDO needs to understand what the organisation is trying to do and give them the ability to do it in a way that is not only compliant but also builds trust. Not only for the organisation and its customers and consumers, but also for their own role within the organisation. That way, they can get buy-in and be seen as part of the solution rather than an inhibitor to it.
By Ken Mortensen, Data Protection Officer, Global Trust & Privacy, InterSystems
Future-tech and IXAfrica: Full Life Cycle Expertise
Future-tech is unique among data centre consultancies for a number of reasons. Not only does the Reading-based firm have high levels of expertise in markets ranging from Helsinki to Johannesburg, but Future-tech offers services across the complete life cycle of a facility.
“We are involved with projects from the initiation to completion,” explains James Wilman, Future-tech’s CEO. “We go from initiation phase - which could mean the site selection process or technical due diligence for a merger or acquisition - all the way through establishing the brief, the various design stages, construction oversight, commissioning, operation, end of life cycle replenishment, and can start right back at the beginning with refurbishment.”
While some factors, like the facility requirements for major tenants, remain the same no matter where you are, Wilman explains that “it's the environmental conditions, construction methodologies, supply chain, and skill sets available in different locations that vary, and that makes this a very interesting job.”
Future-tech was selected by IXAfrica as the life cycle design strategic partner for its hyperscale campus project in Nairobi, Kenya. Wilman explains that, over the past year, Future-tech has been leveraging its strong local knowledge, working closely with Kenyan architects and engineers, and collaborating with both Guy Wilner and Clement Martineau, to help IXAfrica successfully deliver Kenya’s largest hyperscale data centre.
“Future-tech did its first project on the African continent in 2012 in Kenya. I've been involved in the data centre space there for a long time, and have known Guy for a number of years through projects and interaction in Europe,” says Wilman. “As the IXAfrica project came into being, Guy and I spoke about it as he knew that we were already quite familiar with the area. We assisted out with the initial planning and project design, and the relationship really grew from there.”
Wilman adds that the experience helping Future-tech support the IXAfrica project has been hard-won. “It's been a steep learning curve, figuring out how to work in Africa. Some of our earlier projects were quite challenging, but we're fortunate to be at a point now where working throughout the region feels really comfortable,” he explains. “One of the things about Nairobi - which we found out when we were working on our first project in the city back in 2012 - is that, because it's about 1,200 metres above sea level, the altitude actually de-rates the onsite equipment. Having your equipment perform less well because of the altitude can massively impact the whole facility.” Understanding the factors that define a local environment can be the difference between success and disaster for a data centre, and Future-tech’s extensive experience in Kenya is a key supporting factor for IXAfrica’s success in Nairobi.
Wilman has also developed a strong collaborative relationship with Guy and Clement. “We've got over a gigawatt of design projects going through our office at the moment with different clients, which means that we're always learning new things. What is refreshing about working with Guy and Clement is that when we bring them a new idea, they listen to us,” says Wilman. “We've had a good run in Nairobi with IXAfrica built off of a long relationship, and I hope we get to continue working with them on their future projects.”