You may think you’re effectively governing your business network data, but are you really? To answer the question, let’s first define a couple of important terms — “business network” and “data-flow governance.”
What is a business network? Traditional governance and management methodologies have long focused on the business’s governable assets, which can include:
- A directory of users who transmit data through a network and create data flows and access policies
- A data repository protected with encryption keys and associated backup, archive, and recovery procedures
- A collection of network zones protected by firewalls and router policies.
If what is carrying the governable assets is the business network itself, then our answer to the above question is “yes,” because the enterprise does, without question, effectively own and govern its directories, endpoints, and applications.
But it gets more complicated when we introduce cloud services to the mix. This expands the definition of the business network to include multi-enterprise data flows — an entirely different animal.
In this scenario, the bar is raised, forcing us to think through how we can govern data flows that are coursing through infrastructures and endpoints we don’t control. How are we supposed to govern a data flow and secure its journey across the applications and platforms of our business partners?
What tools will we need to achieve that level of control? Given this broadened perspective of the business network as a collection of flows, not just a collection of networking assets, what exactly does it mean to effectively “govern” it?
The data flows we’re trying to manage have life cycles. They’re born, their business purposes are identified, and they’re registered in repositories — all of which make it possible to track the corners of the infrastructure they’ll touch throughout their life cycles, even if some of those corners are not under our control.
Eventually, data flows are decommissioned, which presents yet another challenge: If we don’t have a good inventory of what a data flow’s assets are (that is, devices, services, applications, and network components) and by whom they are being used, how can we decommission the data flow, shut a service down, or perform a cloud migration? Plus, these semi-active, perhaps even fallow, assets can quickly become vulnerable to attack — with back doors left unlocked and keys held by persons unknown.
In this context, our applications, business processes, and endpoint connections become critical — you could even say value-added – components of governing data flow, because they help us analyse and classify the data flows even if we don’t manage the infrastructure from which they originate. They demand encryption, digital rights management, and mobile device management technologies that prepare the data for unknown handlers and destinations, so that they themselves don’t become security challenges!
With an understanding that the network is in a constant state of flux, we need to think of governance as a discipline not merely of life cycle management, compliance, and operational support, but of continuous improvement and refactoring. This perspective is certainly clear when there is a special event like a migration, whether due to a technology refresh or a merger.
When we imagine data flows not just technically but also in their business context, we can begin evolving the way flows are organised, enriching the metadata, enhancing the historical perspective we can attach to data flows, and valuing the business insight a Big Data analysis can yield over this repository.
So, in the pursuit of governing the flow of data, does it make sense to try to reverse-engineer an existing ecosystem in an effort to figure out what’s happening with those flows? Should we apply analytics to data flows, logs, and feeds culled from vast batches of Big Data; derive de facto SLAs; improve our metrics; and then use the results as a baseline for managing the ensuing data-flow life cycle?
These are heady strategies, certainly. And they’re admittedly impractical strategies in some instances, as well, since many business flows are infrequent — a quarterly or annual process, for example. We must exercise caution in those instances or else, as we reverse-engineer our business network in an effort to more effectively govern it, we’ll risk bringing down the existing-albeit-antiquated governance model too quickly and careening headlong into disaster.
If a new era of effective data-flow governance will take time to establish — if it’s a tree that will need time to take root and grow — then now is the time to sow the seeds. Improving the quality of the governance of business network data, initiating the inventory and assessment process, and investing in tools that will give us a data-centric approach and the ability to maintain governance without direct infrastructure control are all lofty goals.
But in an age where cloud services and multi-enterprise data flows are adding complexity to what was already a complicated governance task, they’re more than mere goals — they are crucial responsibilities that we cannot afford to shirk.