I write about data management, but this topic is deliberately none data specific. It actually applies to many aspects of one's work and life - but since I am a data geek - the content and examples will focus on data. You can extrapolate and draw behavioral conclusions on other domains of productivity.
Let's get started. Some people would say that a good design is imperative for success, and sufficient time should be spent on that phase of the project. They are of course - right. Other people say you need to deliver results, respond to market changes and generate revenue and contain costs, otherwise the business does not survive. These people are of course - also right. So how can both groups be right? The answer is balance.
One of the most valuable lessons you will learn (if you have not done so already) is that balance is as important as substance. What I mean by this is that there is an optimal point, where over-engineering becomes a hindrance, while lack of design can lead to unacceptable results. We will get to data in a minute, but my favorite example on this life-lesson is from civil engineering: suppose you are tasked to build a bridge across a river. You need it long enough, but not too long. If you measure your materials to the millimeter - chances are you are over-engineering the process and will spend too much time and money getting the exact "right" measure for your bridge. On the other hand, if you just grab a few planks of wood and start building, not only do you have a risk of bridge instability, you might actually have too little wood, or too much left over. In all cases, you will probably need to extend the time and effort to complete the bridge in order to compensate for these shortcomings. What you need is a balance: make a "good-enough" plan quickly enough, and then build a bridge correctly with optimal time and effort.
Now let's talk data management. One of the typical problems in today's information chaos age is the need to build or upgrade the train bridge while the train is already speeding along the tracks. Another well-known metaphor is building a plane while it is already in flight. The overwhelming criteria in this type of operation is stability. As long as we do not lose business or cause harm. This often leads to patches and workarounds and compromises in good design which eventually leads to issues in costs and strategic alignment. Raise your hand if you felt frustrated on not being able to implement a good design, because of time pressure or concerns about systemic risk. For example, not only is it expensive to change a data model (migration costs will make your executives cringe), but there often seems to be limited foresight as to the strategic benefits.
This is when the conversation needs to shift gears, and the balance needs to be struck by managing expectations. Understand where the business is going, and agree what is best from a technology and design perspective. Then start creating a balance by managing changes such that new parts are created ahead of time, and then brought to the bridge when opportunity allows it. Justify the "extra" efforts by identifying and quantifying the architectural benefits (in other words what you stand to gain or lose in the longer term). You may conclude that your data model should not change right now, but every time it changes it does so in a deliberate direction. It will also help you to understand its limitations and sensitivities better which helps with systemic risk management. The notion of managing expectations and creating a common architectural vision will also funnel independent views of resources in the business to work together under a joint effort, and will allow you to harness many minds to improve progressing in a common and agreed direction.
Now tell me, are you working towards implementing a strategic data management plan, or just doing localized data fire-fighting?
Let's get started. Some people would say that a good design is imperative for success, and sufficient time should be spent on that phase of the project. They are of course - right. Other people say you need to deliver results, respond to market changes and generate revenue and contain costs, otherwise the business does not survive. These people are of course - also right. So how can both groups be right? The answer is balance.
One of the most valuable lessons you will learn (if you have not done so already) is that balance is as important as substance. What I mean by this is that there is an optimal point, where over-engineering becomes a hindrance, while lack of design can lead to unacceptable results. We will get to data in a minute, but my favorite example on this life-lesson is from civil engineering: suppose you are tasked to build a bridge across a river. You need it long enough, but not too long. If you measure your materials to the millimeter - chances are you are over-engineering the process and will spend too much time and money getting the exact "right" measure for your bridge. On the other hand, if you just grab a few planks of wood and start building, not only do you have a risk of bridge instability, you might actually have too little wood, or too much left over. In all cases, you will probably need to extend the time and effort to complete the bridge in order to compensate for these shortcomings. What you need is a balance: make a "good-enough" plan quickly enough, and then build a bridge correctly with optimal time and effort.
Now let's talk data management. One of the typical problems in today's information chaos age is the need to build or upgrade the train bridge while the train is already speeding along the tracks. Another well-known metaphor is building a plane while it is already in flight. The overwhelming criteria in this type of operation is stability. As long as we do not lose business or cause harm. This often leads to patches and workarounds and compromises in good design which eventually leads to issues in costs and strategic alignment. Raise your hand if you felt frustrated on not being able to implement a good design, because of time pressure or concerns about systemic risk. For example, not only is it expensive to change a data model (migration costs will make your executives cringe), but there often seems to be limited foresight as to the strategic benefits.
This is when the conversation needs to shift gears, and the balance needs to be struck by managing expectations. Understand where the business is going, and agree what is best from a technology and design perspective. Then start creating a balance by managing changes such that new parts are created ahead of time, and then brought to the bridge when opportunity allows it. Justify the "extra" efforts by identifying and quantifying the architectural benefits (in other words what you stand to gain or lose in the longer term). You may conclude that your data model should not change right now, but every time it changes it does so in a deliberate direction. It will also help you to understand its limitations and sensitivities better which helps with systemic risk management. The notion of managing expectations and creating a common architectural vision will also funnel independent views of resources in the business to work together under a joint effort, and will allow you to harness many minds to improve progressing in a common and agreed direction.
Now tell me, are you working towards implementing a strategic data management plan, or just doing localized data fire-fighting?
No comments:
Post a Comment