One of the things every data management professional will notice when they start working in an environment is what I like to call the Data-Business (DB) distance. This is the degree of separation the realities of the day-to-day data design and operations have in relation to the business value of the products or services the business provides.
In a small business, especially a new one, you will find a very short DB-Distance. The innovations are tightly coupled to customer needs, the revenue streams are volatile, and every little decision can potentially make or break the business. So naturally, the small team running the business is highly collaborative and sensitive to the impact each decision has on the business.
When the business grows, more people join the company, higher degrees of separation are introduced by creating more distinctive layers of responsibilities, and along the way, the distance of the technical decision around data management and the end customer grows. This is a major problem for a lot of organizations.
Take for example any sizable company, where the technology department includes an infrastructure team, a database or wherehousing support team, a separate project team with analysts, architects and developers. Now inject all these different people and domains with specific outlooks on how to provide better service and efficiencies (think strategy, architecture and governance). You will quickly realize that the degree of separation between the customer experience and the technical implementation decisions are overwhelmed by many push and pull, political and otherwise domain-specific "machines".
To address this challenge, data management professionals, who must look through these layers, and protect the interest of the business value of the data, have to become creative, and get strong support from their managers and project sponsors.
How do you do this? Firstly, you need to recognize how far your data (management and design practices) are from the business value. You need to consider how many service components layers you have between the consumption and distribution of the data (is the scope of your project correct?); then you need to consider the strategies and governance structures that might divert your attention from ensuring the data will deliver its value promises (is the mandate to impact existing control structures correct?); then, you need to consider the people and mind-sets that you might need to overcome (or bypass) in order to persist the correct changes to the environment (do you have the right people change management component in place?).
Once you identify and qualify the DB-distance in terms of the dimensions mentioned above, your next step is to play out practical scenarios on how these dimensions can affect the outcome of the effort to improve the customers' experience. This can end up looking quite scary and pessimistic, but the purpose is to build a strong case to empower the right mechanism to streamline the data value through these layers. By establishing a focused collaboration that is designed to reduce the distortion of the DB-distance layers - you can create an effective control mechanism, which serves as a management tool to help you ensure data-business success.
So what are you waiting for? Go identify your specific DB-Distance factors and do not shy away from pragmatic and real forces at work. Play the scenarios, get support and create a valuable tool for your business to control the distortions of your data-business distance.
In a small business, especially a new one, you will find a very short DB-Distance. The innovations are tightly coupled to customer needs, the revenue streams are volatile, and every little decision can potentially make or break the business. So naturally, the small team running the business is highly collaborative and sensitive to the impact each decision has on the business.
When the business grows, more people join the company, higher degrees of separation are introduced by creating more distinctive layers of responsibilities, and along the way, the distance of the technical decision around data management and the end customer grows. This is a major problem for a lot of organizations.
Take for example any sizable company, where the technology department includes an infrastructure team, a database or wherehousing support team, a separate project team with analysts, architects and developers. Now inject all these different people and domains with specific outlooks on how to provide better service and efficiencies (think strategy, architecture and governance). You will quickly realize that the degree of separation between the customer experience and the technical implementation decisions are overwhelmed by many push and pull, political and otherwise domain-specific "machines".
To address this challenge, data management professionals, who must look through these layers, and protect the interest of the business value of the data, have to become creative, and get strong support from their managers and project sponsors.
How do you do this? Firstly, you need to recognize how far your data (management and design practices) are from the business value. You need to consider how many service components layers you have between the consumption and distribution of the data (is the scope of your project correct?); then you need to consider the strategies and governance structures that might divert your attention from ensuring the data will deliver its value promises (is the mandate to impact existing control structures correct?); then, you need to consider the people and mind-sets that you might need to overcome (or bypass) in order to persist the correct changes to the environment (do you have the right people change management component in place?).
Once you identify and qualify the DB-distance in terms of the dimensions mentioned above, your next step is to play out practical scenarios on how these dimensions can affect the outcome of the effort to improve the customers' experience. This can end up looking quite scary and pessimistic, but the purpose is to build a strong case to empower the right mechanism to streamline the data value through these layers. By establishing a focused collaboration that is designed to reduce the distortion of the DB-distance layers - you can create an effective control mechanism, which serves as a management tool to help you ensure data-business success.
So what are you waiting for? Go identify your specific DB-Distance factors and do not shy away from pragmatic and real forces at work. Play the scenarios, get support and create a valuable tool for your business to control the distortions of your data-business distance.
No comments:
Post a Comment