Without any doubt, we are in the age of cloud computing, shared services and hybrid infrastructure. Organizations, big or small, hyperlocal or multinational, no longer want to commission massively-interlinked systems that take too long to build and eventually prove too much to maintain. Of course, regulatory and performance constraints demand that organizations keep a lot of critical data on-premise, but that still leaves a lot of administrative processes that can be automated through third-party applications.
Proponents of cloud computing point to advantages such as the cost-effectiveness of a pay-as-you-use model and the ability to scale resources up, down or across as needed. There’s also the added benefit of leaving the ownership of maintenance, availability and upgrades to a third party who is contractually bound to provide high levels of uptime and performance. But for all this, there’s an important concern that needs to be addressed before any organization signs on the dotted line.
How secure is my data?
Data and information security remains one of the most important concerns for any CIO. It wouldn’t be too far off the mark to say that innovation is sometimes held hostage to such concerns. With so many ‘moving’ parts — in the form of bytes — an interconnected system is only ever as secure as its weakest component. As a result, proposals usually end up getting no further than this question: just how secure is my data?
Data governance for integrated systems
But for an organization that practices and promotes well-formulated data governance policies, the answer should come easily enough. Such policies offer clarity on the following:
1. Users and access conditions
Who must have access to the data, and what form of data should they have access to? Should the systems have robust controls? How many different levels of user roles are there? What are the performance benchmarks for the component applications?
2. Good data, bad data
What is the format of the data that must be used by, exchanged between or submitted to multiple components of the system? Like the game of Chinese Whispers, data that is moved across multiple systems cannot always be relied upon unless its format has been specifically defined in the policy. We already know the consequences of bad data. Defining data format can eliminate errors of commission and omission from being propagated all through the office network.
3. Interoperability protocols
What are the different applications that must mesh together into a coherent whole? What are the specifications for the APIs (or other protocols) that can be used to connect to the existing IT framework? What are the controls in place at each node to prevent unauthorized access or transfer?
4. Escalation rules
Who must have access to the system for maintenance and/or troubleshooting? What is the chain of command and the action protocols to be followed in case there is a breakdown in service or security? What are the service level agreements mandated for each data system so that catastrophes are localized?
The list above is not exhaustive, nor is it meant to be. However, it should give you a fair idea of the kind of answers a good data governance policy must offer for a hybrid infrastructure and the relevant steps for data governance implementation. With these answers, it will be easier for stakeholders — especially users and system architects — to plan for extensions and upgrades.
In addition to these questions that a data governance policy can address, it also makes sound business sense for a different set of reasons.
Why do I need data governance for integrated/hybrid systems?
For one, your IT infrastructure becomes easier to maintain. The whole process becomes people-agnostic and can survive the departure even of key personnel because it is properly documented. For instance, if you want to integrate a calendar service for your organization, your data governance policy should be able to tell you whether it’s feasible, who should be the administrators, what are the user controls to be granted for each role, and what are the protocols that need to be in place to guarantee safe, secure transmission of data.
For another, there may be fewer iterations needed to arrive at an optimal design because there are fewer unknowns. Data governance policies are not static, nor should they be. Instead, as new lessons are learnt, as new technologies and best practices are introduced, it should evolve to keep pace with these changes. Thus, at any given point of time, your policy can reduce the trial-and-error cycles that would otherwise be needed.
If you need help drawing out your data governance policy for interconnected systems, do talk to our consultants.